[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Chris Rackauckas
Nevermind. You have a non-zero probability of having zero offspring since it's Poisson. This works if every element is at least 1. However, you can have the population size decrease, which then causes errors if you resize first. But then you still want to put the new elements in the first n slot

[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Chris Rackauckas
I see it now. Sum the elements to resize the array, and then loop through backwards adding the values (so that way you don't overwrite what you haven't used). On Thursday, July 21, 2016 at 8:34:11 AM UTC-7, Kristoffer Carlsson wrote: > > Sum the elements and resize the array to that length?

[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Kristoffer Carlsson
Sum the elements and resize the array to that length?

[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Chris Rackauckas
Let me explain. The easy place to add an in-place operation with resize! would be with the RNG call, rpois. I used resize! to make the Poisson RNG go a little faster. It's now: function rpois!(n::Int,p::Vector{Float64},out::Vector{Int}) resize!(out,n) for i in 1:n @inbounds out[i

[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Steven G. Johnson
On Thursday, July 21, 2016 at 5:37:12 AM UTC-4, Chris Rackauckas wrote: > > Maybe. I thought about that, but I don't think that satisfies the "elegant > and compactness" requirement, unless there's an easy way to do the growing > without too much extra code hanging around. > Why is `resize!`

[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Christoph Ortner
feels like one may want a little auxiliary package that can make available small chunks from a long pre-allocated vector. On Thursday, 21 July 2016 10:37:12 UTC+1, Chris Rackauckas wrote: > > Maybe. I thought about that, but I don't think that satisfies the "elegant > and compactness" requireme

[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Chris Rackauckas
Maybe. I thought about that, but I don't think that satisfies the "elegant and compactness" requirement, unless there's an easy way to do the growing without too much extra code hanging around. On Thursday, July 21, 2016 at 1:54:10 AM UTC-7, Christoph Ortner wrote: > > could still preallocate a

[julia-users] Re: Help Julia win a performance comparison!

2016-07-21 Thread Christoph Ortner
could still preallocate and grow as needed? On Thursday, 21 July 2016 02:48:58 UTC+1, Chris Rackauckas wrote: > > Most of the arrays are changing size each time though, since they > represent a population which changes each timestep. > > On Wednesday, July 20, 2016 at 6:47:39 PM UTC-7, Steven G.

[julia-users] Re: Help Julia win a performance comparison!

2016-07-20 Thread Chris Rackauckas
Most of the arrays are changing size each time though, since they represent a population which changes each timestep. On Wednesday, July 20, 2016 at 6:47:39 PM UTC-7, Steven G. Johnson wrote: > > It looks like you are allocating lots of arrays in your doStep inner-loop > function, so I'm sure yo

[julia-users] Re: Help Julia win a performance comparison!

2016-07-20 Thread Steven G. Johnson
It looks like you are allocating lots of arrays in your doStep inner-loop function, so I'm sure you could improve it by moving the allocations out of the inner loop. (In general, vectorized routines are convenient but they aren't the fastest way to do things.)