Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enumerate allocates for arrays of mutables #16190

Closed
JaredCrean2 opened this issue May 4, 2016 · 5 comments
Closed

enumerate allocates for arrays of mutables #16190

JaredCrean2 opened this issue May 4, 2016 · 5 comments
Labels
performance Must go faster

Comments

@JaredCrean2
Copy link
Contributor

Using enumerate to iterate through array of mutable objects allocates, but using a simple for loop does not:

type MyMutable
  a::Int
end

immutable MyImmutable
  a::Int
end

function sumit(arr)
  val = 0
  for i=1:length(arr)
    val += arr[i].a
  end

  return val
end

function sumit2(arr)
  val = 0
  for (i, obj) in enumerate(arr)
    val += obj.a
  end

  return val
end

nel = 5000
arr = Array(MyMutable, nel)
arr2 = Array(MyImmutable, nel)
for i=1:nel
  arr[i] = MyMutable(i)
  arr2[i] = MyImmutable(i)
end

# warmup
@time sumit(arr)
@time sumit(arr2)
@time sumit2(arr)
@time sumit2(arr2)

println("\nfinal times:")
@time sumit(arr)
println("  mutable explicit for loop @time printed above\n")

@time sumit(arr2)
println("  immutable explicit for loop @time printed above\n")

@time sumit2(arr)
println("  mutable enumerate @time printed above\n")

@time sumit2(arr2)
println("  immutable enumerate @time printed above\n")

results:

final times:
  0.000043 seconds (5 allocations: 176 bytes)
  mutable explicit for loop @time printed above

  0.000009 seconds (5 allocations: 176 bytes)
  immutable explicit for loop @time printed above

  0.000123 seconds (10.01 k allocations: 312.688 KB)
  mutable enumerate @time printed above

  0.000008 seconds (6 allocations: 192 bytes)
  immutable enumerate @time printed above

also, using for obj in arr rather than enumerate does not allocate.

@yuyichao yuyichao added the performance Must go faster label May 4, 2016
@StefanKarpinski
Copy link
Member

StefanKarpinski commented May 4, 2016

This is due to the fact that currently types that contain mutable values must be heap-allocated and values that refer to heap-allocated values must themselves be heap allocated. This is essentially the same as #10899 and #14955 (which, afaict are dups of each other), has the same root cause as #1168 and would be addressed by #11714 or #12205.

@carnaval, what's the status of stack-allocating objects that refer to the heap? Wasn't that one of the major goals of the Green Fairy work?

@yuyichao
Copy link
Contributor

yuyichao commented May 4, 2016

This one doesn't need stack allocation to work. The type inference should be able to elide the allocation. This is one of the left over case in #16021 .

@StefanKarpinski
Copy link
Member

Even better that we can solve this without needing to solve those other issues.

@KristofferC
Copy link
Member

Dup of #10899 and other similar issues

@KristofferC
Copy link
Member

Not a dup according to #23240

@KristofferC KristofferC reopened this Aug 13, 2017
yuyichao added a commit that referenced this issue Nov 5, 2017
This allow us to handle certain object allocations with object reference fields.
DSE is particularly useful on LLVM 5.0+ where we can take advantage of llvm store to load
forwarding to delete objects that's only used as local buffer.

This is also a prototype for the next gen optimization in type inference and to guide
the new IR format necessary for it.

Fix #16190
yuyichao added a commit that referenced this issue Nov 5, 2017
This allow us to handle certain object allocations with object reference fields.
DSE is particularly useful on LLVM 5.0+ where we can take advantage of llvm store to load
forwarding to delete objects that's only used as local buffer.

This is also a prototype for the next gen optimization in type inference and to guide
the new IR format necessary for it.

Fix #16190
yuyichao added a commit that referenced this issue Nov 5, 2017
This allow us to handle certain object allocations with object reference fields.
DSE is particularly useful on LLVM 5.0+ where we can take advantage of llvm store to load
forwarding to delete objects that's only used as local buffer.

This is also a prototype for the next gen optimization in type inference and to guide
the new IR format necessary for it.

Fix #16190
Keno pushed a commit that referenced this issue May 5, 2018
This allow us to handle certain object allocations with object reference fields.
DSE is particularly useful on LLVM 5.0+ where we can take advantage of llvm store to load
forwarding to delete objects that's only used as local buffer.

This is also a prototype for the next gen optimization in type inference and to guide
the new IR format necessary for it.

Fix #16190
@Keno Keno closed this as completed in 5b2a859 May 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Must go faster
Projects
None yet
Development

No branches or pull requests

4 participants