|
|
|
This thread is locked; no one can reply to it.
|
| Fixed point, again |
|
Peter Wang
Member #23
April 2000
|
http://www.allegro.cc/forums/view_thread.php?_id=488085 appears to be locked out now. Anyway, what should we do with fixmul/fixdiv then? From the benchmarks, this is what I suggest: IA32/asm: fixmulasm, fixdivasm IA32/C: fixmuli, fixdivf otherwise: fixmull, fixdivf Those choices aren't optimal, but I squinted hard and that's as much of a pattern as I could see from the results we got. Suggestions welcome.
|
|
Evert
Member #794
November 2000
 |
Quote: http://www.allegro.cc/forums/view_thread.php?_id=488085 appears to be IA32/asm: fixmulasm, fixdivasm Looks about right. I still don't understand why fixdivl is so slow on an AMD64, I'll have to take a closer look at that. |
|
Thomas Harte
Member #33
April 2000
 |
Quote: Those choices aren't optimal, but I squinted hard and that's as much of a pattern as I could see from the results we got. Suggestions welcome. I know it wouldn't fit very well into the current Allegro build system, but should it ever adopt a configure script, perhaps a test could be done pre-compile time to determine the fastest option on that system? If we're talking about what to do with the fixed point routines in general for the future, can all that overflow stuff be cut? You don't get overflow flags on any integral data type and you do pay quite a bit for it on branch predicting CPUs. [My site] [Tetrominoes] |
|
Elias
Member #358
May 2000
|
Quote: I know it wouldn't fit very well into the current Allegro build system, but should it ever adopt a configure script, perhaps a test could be done pre-compile time to determine the fastest option on that system? I think, such a test should be made at runtime. At least personally, I run mostly binary linux programs.. so a compile time test wouldn't help. -- |
|
Milan Mimica
Member #3,877
September 2003
 |
Such tests would be highly inaccurate. Remember that we're talking about multitasking operating systems and you never know what may be happening out there at the time you are performing tests.
-- |
|
Thomas Harte
Member #33
April 2000
|
Quote: I think, such a test should be made at runtime. At least personally, I run mostly binary linux programs.. so a compile time test wouldn't help. Alas these are inline functions (which gcc at least seems to actually inline) so that isn't possible! Quote: Such tests would be highly inaccurate. Remember that we're talking about multitasking operating systems and you never know what may be happening out there at the time you are performing tests. Although that is true, the tests did seem to show orders of magnitude of difference between the methods on some architectures where there was no such difference on others. So such a test could return some useful information even if the results could not be relied upon as conclusive. [My site] [Tetrominoes] |
|
Evert
Member #794
November 2000
|
Quote: I know it wouldn't fit very well into the current Allegro build system, but should it ever adopt a configure script, perhaps a test could be done pre-compile time to determine the fastest option on that system? What do you mean? Allegro already uses a configure script. Quote: At least personally, I run mostly binary linux programs.. so a compile time test wouldn't help. That's the price you pay for running pre-compiled binaries: they're not nescessarily optimised for your system. Quote: Such tests would be highly inaccurate. Remember that we're talking about multitasking operating systems and you never know what may be happening out there at the time you are performing tests. The absolute speeds are not important. The timings posted in that other thread are reproducible within about 1% on the systems I tried. |
|
|
