[squeak-dev] LargeInteger benchmarks?

Hi -

I'm looking for benchmarks that can be used to compare the speed of
large integer operations. Does anyone have some benchmarks for those?
Any ideas how to devise a couple of them that have realistic performance
characteristics?

Cheers,
   - Andreas

Andreas Raab a écrit :
You could try using tests from ArbitraryPrecisionFloat at squeak source
http://www.squeaksource.com/ArbitraryPrecisionFl/.

These are crunching a lot of LargeInteger ops.
Only pre-req I'm aware of are patches Integer>>asFloat and
Fraction>>asFloat from mantis ( http://bugs.squeak.org/view.php?id=3564 
http://bugs.squeak.org/view.php?id=3568 ).

Nicolas

nicolas cellier wrote:
> You could try using tests from ArbitraryPrecisionFloat at squeak source
> http://www.squeaksource.com/ArbitraryPrecisionFl/.

Heh. They are indeed great large integer crunchers ;-) Not exactly what
I was looking for but certainly good to give it a workout.

Thanks!
   - Andreas

nicolas cellier wrote:
> You could try using tests from ArbitraryPrecisionFloat at squeak source
> http://www.squeaksource.com/ArbitraryPrecisionFl/.

One thing that was interesting when I was running the tests is that the
failed for both testExpLn and testLnVsFloat. It seems like either fdlibm
  or your code is off by one bit. For example:

(1 asArbitraryPrecisionFloatNumBits: 53) exp asFloat hex
=> '4005BF0A8B145769'

1 asFloat exp hex
=> '4005BF0A8B14576A'

(3 asArbitraryPrecisionFloatNumBits: 53) ln asFloat hex
=> '3FF193EA7AAD030B'

3 asFloat ln hex
=> '3FF193EA7AAD030A'

Any ideas what could cause this? I would have expected these two to
agree on the result.

Cheers,
   - Andreas

Andreas Raab wrote:
> Hi -
>
> I'm looking for benchmarks that can be used to compare the speed of
> large integer operations. Does anyone have some benchmarks for those?
> Any ideas how to devise a couple of them that have realistic performance
> characteristics?

This one:

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=pidigits&lang=squeak

is quite a microbenchmark but it effectively stresses all of:

- LargeInteger x LargeInteger performance
- LargeInteger x SmallInteger performance
- GC performance on LargeIntegers

(GST for example is great on the first two and sucks on the last, so
it's good for small n and bad for large n...)

Paolo

Andreas Raab a écrit :
Hmm...
On linux with libm.so.6
ldd `which squeak`
         linux-gate.so.1 =>  (0xffffe000)
         libutil.so.1 => /lib/libutil.so.1 (0xb7f4c000)
         libdl.so.2 => /lib/libdl.so.2 (0xb7f48000)
         libm.so.6 => /lib/i686/libm.so.6 (0xb7f23000)
         libnsl.so.1 => /lib/libnsl.so.1 (0xb7f0c000)
         libc.so.6 => /lib/i686/libc.so.6 (0xb7dcc000)

I have a good agreement on these:

1 asFloat exp hex. '4005BF0A8B145769'
3 asFloat ln hex. '3FF193EA7AAD030B'

This is consistent with ArbitraryPrecisionFloat if i extend precision:
(1 asArbitraryPrecisionFloatNumBits: 53+16) exp mantissa hex.
'15BF0A8B1457695356'

The last 16 bits are 16r5356 < 16r8000, thus round to nearest even mode
did round correctly to 69, only a ceiling mode (round toward infinity)
would round to 6A.

Same with 3 ln:
(3 asArbitraryPrecisionFloatNumBits: 53+16) ln mantissa hex
'1193EA7AAD030A976A'

16r976A > 16r8000, thus round to nearest even does round to 30B, a floor
mode (round toward negative infinity) or truncate mode (round toward
zero) would give 30A.

It is as if fdlibm did always set Least Significant Bit to zero... A
wrong interpretation of nearest even ?

Anyway, i do not always have a good agreement on larger Float cases...
It would be better to check against a multiple precision library like GMP.

Nicolas