Jason House Wrote:

> Gregor Richards Wrote:
> 
> > Jason House wrote:
> > > I ported some monte carlo simulation code from Java to D2, and performance is horrible.
> > > 
> > > 34% of the execution time is used by std.random.uniform. To my great surprise, 25% of the execution  time is memory allocation (and collection) from that random call. The only candidate source I see is a call to ensure with lazy arguments. The memory allocation occurs at the start of the UniformDistribution call. I assume this is dynamic closure kicking in.
> > > 
> > > Can anyone verify that this is the case?
> > > 
> > > 600000 memory allocations per second really kills performance!
> > 
> > Java has a much better garbage collector than D, as it doesn't need to be conservative.
> > 
> >   - Gregor Richards
> 
> The code is written to explicitly avoid memory allocation, especially in tight loops. Without this dynamic closure, the garbage collecor would never run. This case is especially pathetic since the call to ensure will never trigger.
> 
> This is part of a mini language shootout. The Java version I cloned runs 4x faster. This is only one piece of a much bigger problem.

I was wrong about the 4x thing. I have bad hardware. After fixing the accidental allocation and running both the D and Java version on the same box, they're only 1% different.

"Jason House" wrote
> Jason House Wrote:
>
>> Gregor Richards Wrote:
>>
>> > Jason House wrote:
>> > > I ported some monte carlo simulation code from Java to D2, and performance is horrible.
>> > >
>> > > 34% of the execution time is used by std.random.uniform. To my great surprise, 25% of the execution  time is memory allocation (and collection) from that random call. The only candidate source I see is a call to ensure with lazy arguments. The memory allocation occurs at the start of the UniformDistribution call. I assume this is dynamic closure kicking in.
>> > >
>> > > Can anyone verify that this is the case?
>> > >
>> > > 600000 memory allocations per second really kills performance!
>> >
>> > Java has a much better garbage collector than D, as it doesn't need to be conservative.
>> >
>> >   - Gregor Richards
>>
>> The code is written to explicitly avoid memory allocation, especially in tight loops. Without this dynamic closure, the garbage collecor would never run. This case is especially pathetic since the call to ensure will never trigger.
>>
>> This is part of a mini language shootout. The Java version I cloned runs 4x faster. This is only one piece of a much bigger problem.
>
> I was wrong about the 4x thing. I have bad hardware. After fixing the accidental allocation and running both the D and Java version on the same box, they're only 1% different.

When you say 'fixing the accidental allocation' you mean removing the case where a dynamic closure was allocated?

I just want to make sure that is clear.

-Steve

Steven Schveighoffer Wrote:

> "Jason House" wrote
> > Jason House Wrote:
> >
> >> Gregor Richards Wrote:
> >>
> >> > Jason House wrote:
> >> > > I ported some monte carlo simulation code from Java to D2, and performance is horrible.
> >> > >
> >> > > 34% of the execution time is used by std.random.uniform. To my great surprise, 25% of the execution  time is memory allocation (and collection) from that random call. The only candidate source I see is a call to ensure with lazy arguments. The memory allocation occurs at the start of the UniformDistribution call. I assume this is dynamic closure kicking in.
> >> > >
> >> > > Can anyone verify that this is the case?
> >> > >
> >> > > 600000 memory allocations per second really kills performance!
> >> >
> >> > Java has a much better garbage collector than D, as it doesn't need to be conservative.
> >> >
> >> >   - Gregor Richards
> >>
> >> The code is written to explicitly avoid memory allocation, especially in tight loops. Without this dynamic closure, the garbage collecor would never run. This case is especially pathetic since the call to ensure will never trigger.
> >>
> >> This is part of a mini language shootout. The Java version I cloned runs 4x faster. This is only one piece of a much bigger problem.
> >
> > I was wrong about the 4x thing. I have bad hardware. After fixing the accidental allocation and running both the D and Java version on the same box, they're only 1% different.
> 
> When you say 'fixing the accidental allocation' you mean removing the case where a dynamic closure was allocated?
> 
> I just want to make sure that is clear.
> 
> -Steve

Yes. You are right. The allocation of the dynamic closure was the only performance problem, and consumed 25% of my execution time.  I called it accidental because Andrei was unaware that he had done it.