OK, so now I'm super confused now.
I think there's a couple of things going on here (setindex vs vectorised)
When using vectorised versions, allocations will happen regardless of
setindex or not.
Using phat[:] = 1./(1+exp(-vector))instead of phat = 1./(1+exp(-vector))will
roughly be the same performance / allocation.
The allocation is happening on the RHS.
In version 1 (phat[:] =), phat is reused, but RHS is gc'd.
In version 2 (phat =), RHS is assigned to phat, but old phat is gc'd
The performant (non-allocating) versions are the explicit loop versions:
for i = 1:1000, j = 1:8000
phat[j] = 1./(1+exp(-vector[j]))
end
or @devec equivalent.
Am I missing something?
On Friday, October 9, 2015 at 2:01:39 AM UTC+11, Patrick Kofod Mogensen
wrote:
> Thanks again for the answer. This stuff really opened my mind to a lot of
> stupid thinks I have done in my code. The constant allocation and freeing
> of memory is very apparent when using @allocated on some of the code I'm
> working on right now. The allocated memory is drastically reduced, as one
> would expect, with a performance gains as well.
>
> On Thursday, October 8, 2015 at 8:15:22 AM UTC-4, Simon Danisch wrote:
>>
>> Well it is a little more complicated actually.
>> Julia is only copying references, while Matlab seems to lazily copy the
>> whole array
>> <http://www.mathworks.com/help/matlab/matlab_prog/memory-allocation.html>
>> .
>> Doing stuff you did is bad for two reasons.
>> Consider:
>> *function test(n)*
>> * a = rand(10^5)*
>> * for i=1:n*
>> * a = a[:] # or e.g. rand(10^5) or a+1, anything that creates a new array
>> with the same type*
>> * end*
>> * a*
>> *end*
>>
>> *a[:]* is a getindex operation which currently copies. This means you're
>> overwriting the reference from* a *with a new reference.
>> Now it's the job of the garbage collector to figure things out. This puts
>> a lot of pressure on it, since you're constantly allocating new memory and
>> freeing up old one (you're overwriting the one and only reference to old
>> *a*). From what I know, this could be handled better with some
>> cleverness, but isn't right now.
>> It's not entirely clear where the best place is to optimize this. One way
>> would be to use in place operators, which is not as straight forward as one
>> might expect: https://github.com/JuliaLang/julia/issues/249
>>
>> For immutables this is handled pretty well by LLVM, though.
>> Because it's Julia, it's pretty straightforward to find out:
>> https://gist.github.com/SimonDanisch/c614016d9f9551f8f64c#file-jl
>>
>> When in doubt, @allocated, @time and @code_llvm and @code_native are your
>> friends to find out what's going on under the hood.
>>
>>
>> Am Mittwoch, 7. Oktober 2015 22:25:00 UTC+2 schrieb Patrick Kofod
>> Mogensen:
>>>
>>> So I asked a question over at
>>> https://github.com/lindahua/Devectorize.jl/issues/48#issuecomment-146307811
>>> and it seems that I have got something completely wrong.
>>>
>>> It seems that the following
>>>
>>> index = rand(8000)
>>> phat = zeros(8000)
>>>
>>> phat = 1./(1+exp(-index))
>>>
>>> binds the output of the calculation on the rhs to a _new_ vector phat,
>>> not the original vector. This really means I have misunderstood
>>> preallocation/re-using memory in Julia completely! @blakejohnson suggests
>>> that I use
>>>
>>> phat[:] = 1./1+(exp(-index))
>>>
>>> instead. As this puts the calculations in the already preallocated
>>> vector phat.
>>>
>>> Question 1) Can I learn more about this in the documentation ? I'm
>>> having a hard time finding anything, probably because [:] is hard to use as
>>> a search phrase, and I'm not sure what concepts to search for.
>>>
>>>
>>>
>>> I often wrap my variables in a type, but this seems like an extremely
>>> bad idea in combination with devec. I have taken Blake Johnsons examples
>>> from github, and added a few
>>> https://gist.github.com/pkofod/fb6c4b8ffcca1a056363
>>>
>>> Question 2) What is it that makes test4() and test6() run so slowly?
>>> test1() and test3() seems to perform equivalently fast. I use this kind of
>>> setup all the time, and I am surprised that this method allocates so much
>>> memory.
>>>
>>> Bad news: I've been doing Julia ALL wrong!
>>> Good news: Time to learn some more!
>>>
>>
