• Jason House <jason.james.house gmail.com> Oct 28 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Oct 28 2008
• Jason House <jason.james.house gmail.com> Oct 29 2008

Jason House <jason.james.house gmail.com> writes:

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.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"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 

Jason House <jason.james.house gmail.com> writes:

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.