 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How slow is converting between floating-point representation and integer
representation?
I'm seeing a very large performance hit when I do this, and I'm trying
to figure out whether this is just one of the performance
characteristics of a typical CPU, or a software bug.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> How slow is converting between floating-point representation and integer
> representation?
>
> I'm seeing a very large performance hit when I do this, and I'm trying
> to figure out whether this is just one of the performance
> characteristics of a typical CPU, or a software bug.
Which language? Any example of the code that shows what you are actually
doing?
--
Severi Salminen
http://www.iki.fi/severi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> Which language? Any example of the code that shows what you are actually
> doing?
If I add up a few thousand 32-bit signed integers, it takes 20 seconds.
If I use double-precision floating-point, it takes 43 seconds.
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.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> 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.
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.
> 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Severi Salminen wrote:
>
>> Which language? Any example of the code that shows what you are actually
>> doing?
>
> If I add up a few thousand 32-bit signed integers, it takes 20 seconds.
>
> If I use double-precision floating-point, it takes 43 seconds.
>
> 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 tried adding up 1e10 (10 billion, using Finnish meaning of "billion"
:) floats to a float variable (in 2 nested for loops). It took around
10s. Adding up 1e10 floats to an int variable took 30s. So the
conversion took some time. I tried with C++ with no optimizations at all.
But I agree with Warp. Adding up few thousand integers should definitely
not take 20s.
--
Severi Salminen
http://www.iki.fi/severi
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:49987420@news.povray.org...
> Orchid XP v8 <voi### [at] devnull> wrote:
> > 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
Fundamentally wrong? Of course. He already mentioned Haskell, didn't he?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> >> 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?
20 seconds to add up 100 million integers is still quite a lot.
I find it ironic that you constantly comment on the "unfounded" prejudices
relating to the speed of Haskell in the other group, yet time after time you
demonstrate in practice how Haskell is orders of magnitude slower than a
simple C++ program. This isn't the first time that I remember.
> > 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+?
I have hard time believing my computer is 30 times faster than that.
Twice or three times as fast I could still maybe swallow, but not 30 times.
(Athlons are rather notorious for being much faster than the Pentium4 line
with the same clockrates.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I find it ironic that you constantly comment on the "unfounded" prejudices
> relating to the speed of Haskell in the other group, yet time after time you
> demonstrate in practice how Haskell is orders of magnitude slower than a
> simple C++ program. This isn't the first time that I remember.
Well, you look at Haskell and how it's used, and it "looks" like it
should be insanely slow. (E.g., recursion is used everywhere.) It's easy
to think it has no performance at all.
And yet, when you look at things like the Great Language Shootout,
Haskell beats several supposedly "superior" languages. Last time I
checked, it's near the very top of the main scoreboard.
> I have hard time believing my computer is 30 times faster than that.
> Twice or three times as fast I could still maybe swallow, but not 30 times.
> (Athlons are rather notorious for being much faster than the Pentium4 line
> with the same clockrates.)
OK, well I just wrote a small C program to do the same thing... and it
segfaulted at me.
So then I looked up the printf() manpage to find out what the correct
magic code is, and tried again... 0.8 seconds to do the integer sum.
Based in this information, I conceed defeat. I have no idea what's gone
wrong here.
PS. I just changed the Haskell program. It now takes 0.5 seconds - which
is even faster than C. But I still have no idea why the first version
wasn't this fast, so that's not much comfort.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> PS. I just changed the Haskell program. It now takes 0.5 seconds - which
> is even faster than C. But I still have no idea why the first version
> wasn't this fast, so that's not much comfort.
So maybe it's because I'm using this version of the compiler that I
built myself, and it's broken in some way?
Er, no. Just tried it with the release version. The numbers are a
fraction of a second slower still. Either way, two equivilent
formulations of the program have wildly different runtimes.
Interestingly, on my much more powerful desktop PC [with yet another
version of the compiler], the "slow" version only takes 2 seconds. But
the "fast" version is too quick to time, so something is still wrong.
Ah, the bitter taste of utter defeat.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
