Maybe thinking of

phat[:] = 1./(1+exp(-vector))

as

tmp = 1./(1+exp(-vector))
copy!(phat, tmp)

helps to understand what is going on better?


On Thursday, October 8, 2015 at 11:12:54 PM UTC+2, Greg Plowman wrote:
>
> 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!
>>>>
>>>

Reply via email to