A benchmark, mostly GC

[Don]

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.