On 11.12.2011 17:33, Andrei Alexandrescu wrote:
On 12/11/11 9:23 AM, dsimcha wrote:
My optimizations make very little difference on this benchmark, but for
good reason: It's not a very good GC benchmark. I ran it with my GC
profiling code enabled and it only spends around 10% of its execution
time in GC. We need to figure out why else this benchmark may be so slow.
I'll venture an opinion (without having profiled the code).
The code uses BigInt, which makes eager allocations and custom work for
each operation. But a good portion of the loop is spent using small
numbers, so using the small integer optimization and native operations
helps a lot.
I think we need to add reference counting and small int optimization to
BigInt to make it competitive.
Andrei
Yeah. Also important to note that BigInt was written assuming that
something like TempAlloc would become available. Its GC usage is
terrible without it.
OTOH looks like this is a case where it'd be much faster to use fixed
length integers rather than BigInt (I think that's true of nearly
everything in RosettaCode) -- strict upper bounds are known on the
length of the integers, they aren't arbitrary precision.
I think these are toy examples, though, they're completely
unrepresentative of real-world code.
