float or double?

Use a lot of typedefs. Then you can change from float to double and back just by changing a couple of typedefs, and easily test if it affects the running speed.

Well, why don''t you do some tests and find out for yourself?

The truth is that the largest performance issue involving floating-point is when converting to integers. Beyond that, there''s little difference. But, again, do your own tests.

Perhaps I have coded my test wrong, but on my 1.4Ghz equivalent machine (AMD chip), I timed add, multiply, and divide operations executing 199999800 times over. Checking how long it took to perform these operations using a float, and then perform the same operations using a double.

The timed results were consistently very close, and allowing for inaccuracies in the GetTickCount() call (I should have used a highperformance counter, but didnt bother looking it up), I reckon its a safe assumption to claim they would be the same had the time counter been completely accurate.


-- Ofcourse results will vary quite a bit depending on how the generated code fits the CPU''s pipelines. Mine would cause a stall on each instruction as all 3 operations modify the same result variable --


regards,

GeniX

www.cryo-genix.net

quote:

---

I reckon its a safe assumption to claim they would be the same had the time counter been completely accurate.

---

Yes, your results are correct - doubles and floats execute at the same performance. Actually, the FPU doesn''t know about the difference. As soon as you load a floating point value (float or double, doesn''t matter), the FPU will convert it to a 80bit internal format, and *all* floating point computations will operate on that 80bit format. When writing back the floating point value (fst opcode), it will be reconverted to either 32 or 64 bit.

But there still are two differences. First, a double requires twice the memory of a float. This will of course lead to higher cache stressing, and might result in delays due to cache line reloading.

A second important point is the current FPU precision mode. Operations such as divisions are performed using a certain user-adjustable precision. The higher the precision, the longer it takes to compute the result. You can change the precision by modifying the FPU control word. By default, it is set to maximum precision. But be careful, you will lose a lot of accuracy, if you set it to minimum. The results are also very platform dependent, on highly optimized FPU''s (as in the AMD Athlon series), the difference is very small, and you should keep the default at maximum precision.

In conclusion, I''d say use doubles, if memory is no problem. Use floats only, if operating on large arrays. Or if you use a 3D API that operates on floats anyway (OpenGL and D3D both do). Mixing floats and doubles in one equation is free. But explicitely converting between a float and a double (or vice-versa) costs two FPU opcodes.

/ Yann

so is the double-> float conversion time 0?

An external double->float conversion is not 0, as you have to load the float, and save the double:

fld qword ptr [mydouble]
fstp dword ptr [myfloat]
  

But it takes the same time for the FPU to convert a float and a double into it's internal format. So, if you have an algorithm that loads a value anyway, then it doesn't matter if it is a float or a double, it will be the same speed (neglecting cache miss issues, of course):

fld ...
fadd dword ptr [myfloat]
fmul ...
etc...
  

If you replace the fadd with:

fadd qword ptr [mydouble]
  

then the FPU will not experience any performance penalty (execpt cache related).


[edited by - Yann L on February 27, 2003 10:23:06 PM]

The speed difference is in the amount of memory you have to access. Doubles take up twice as much space, so if you have a lot of them to manipulate, it takes twice as long. This assumes your application is memory bandwidth bound. If you have a complex algorithm or crappy code/environment you might be processor bound in which case there won't be much difference.

[edited by - Magmai Kai Holmlor on February 28, 2003 3:41:47 AM]

btw, is there a way to utilize the 80bit precision (using a C data type or maybe assembly language?) or is that 80bit precision for internal use only?

thanks,
-duck

Sorry, this is a bit off topic, but does there exist a list somewhere that sais how many opcodes each mathematical function uses on modern processors?

e.g. converting from float to int, multiplying two ints, multiplying two floats, etc...

quote:

---

btw, is there a way to utilize the 80bit precision (using a C data type or maybe assembly language?) or is that 80bit precision for internal use only?

---

In ASM, yes:

fld TBYTE PTR [80bitvalue]
...
 

In C/C++, it depends on the compiler, some expose this functionality through the ''long double'' data type. Keep in mind, that 80bit is a TBYTE (ten bytes), which is not 4byte aligned, and will be very slow to operate on CPU level. Most compilers will probably pad it to 96 or 128bit boundary, which will waste a lot of RAM.

quote:

---

Sorry, this is a bit off topic, but does there exist a list somewhere that sais how many opcodes each mathematical function uses on modern processors?

---

Yes, you have basic opcode cycle count lists. But those are meaningless, if you don''t know how to interprete them, ie. how the CPU/FPU internally works. The number of cycles can change from the norm, due to pairing, overlapping, cache misses and reloading, AGI stalls (address generation interlock), alignment issues, etc.