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.

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

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.