>> If I add up a few thousand 32-bit signed integers, it takes 20 seconds.
> 
>   What are you using? A 8086? In fact, I think even a 8086 could sum
> a lot more than a few thousands of integers in 20 seconds.

You understand that when I said "a few thousand", I just meant "a lot", 
right? I wasn't being rigorous about the number.

Actually the number I'm using is 10^8, which is... er, let me see... 100 
million?

>   Out of curiosity, I tried a small test program in my computer which
> creates an array of integers, then goes through it and calculates the
> sum of all the integers. I had to use an array of 100 million integers
> before I got even some measurable delay, and that was 0.7 seconds.
> 
>   I bet most of the time was caused by cache misses because of the
> humongous array (taking 400 megabytes of memory) rather than the summing
> process.

Uhuh. And are you by any chance running this on an AMD Mobile AlthonXP 
1400+?

>> If I use double-precision, and then convert each number to an integer, 
>> and then add it to the total, it takes 6 minutes.
> 
>> I'm wondering whether the hardware is actually that slow, or whether 
>> this is a performance bug in Haskell's number libraries.
> 
>   I think there's something else fundamentally wrong with the system you
> are using than summing integers or converting between floats and ints.

I hacked into the numeric library and called the low-level C primop 
directly, and runtime dropped to 68 seconds, rather than 6 minutes. I 
believe this clearly demonstrates that there is something Very Wrong 
with the default numeric implementation...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message