Pieter, better to stick to what tests *show *to be best, not what "intuition" suggests *should* be. ;)
A Pentium CPU doesn't have opcodes for floating point... but it does have an FPU which does. The 32-bit Delphi compiler may not make the absolute best use of the available silicon (e.g. MMX), but it will at least make use of the FPU. But the 32-bit Delphi compiler doesn't use CPU opcodes for Int64 operations - even if they are present in the hardware) which I think is why - in *tests* - Int64 arithmetic Is significantly less efficient than Double arithmetic. Something was bugging me that I had forgotten something... and I had... There is also the "Comp" type. This is listed as a "real" type in most documentation but is in fact an Int64. The difference is that operations involving this type are performed in the FPU, rather than through software emulation of a 64-bit integer. So it's possible that Comp might provide a performance advantage over Double. Again, testing will be the key to answering the question of whether or not it does in practice. On 18 August 2014 08:37, Pieter De Wit <[email protected]> wrote: > Hi, > > > > No, it appears I was wrong. > > > > Delphi (at least pascal and by default, I assume then delphi) stores > "real"'s as per the IEEE std. > > > > See : > https://www.informatik.uni-hamburg.de/RZ/software/SUNWspro/pascal/lang_ref/ref_data.doc.html > > > > It's a weird layout which results in (if I understand this correctly) a > multiply instruction to even set the value: > > A real number is represented by this form: > > (-1)sign * 2 exponent-bias *1.f > f is the bits in the fraction > > > > I would hate to work out the CPU cycles needed to multiply real's... > > > > Either way - you going to end up with a LOT more CPU usage multiplying > real's vs int - *unless* you need a real, stick to int :) > > > > A tip from me - I would load the source ints into a few arrays and then > use threading to make it faster/use more cores. > > > > (This did spark off a talk about if Intel/AMD include a math co-pro with > each core - if not, you really have to stick to threaded int64 - even more > so if your CPUs are hyperthreaded, then you need int64 as a single core > serves 2 HT cores - research the early days of HT for more info on this :) ) > > > > Cheers, > > > > Pieter > > > > On 17/08/2014 20:09, Cameron Hart wrote: > > I'm confused now as I'm pretty sure Delphi uses a standard format to > represent float (the same format used anywhere else for that matter). In > which case a float is essentially two int32 (or other int's depending on > the scale of the float). Ie a single used two int16. > > > > One int represented the mantissa the other the exponent (in essence the > decimal portion). Together they resulted in the floating point value. > > > > How would you describe this otherwise? > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Jolyon Smith > *Sent:* Sunday, 17 August 2014 12:54 p.m. > *To:* NZ Borland Developers Group - Delphi List > *Subject:* Re: [DUG] Int64 or floating point faster? > > > > That's curious. Who are "they" ? It doesn't sound like any floating > point implementation I ever came across in Delphi (or anywhere else, for > that matter). O.o > > > > On 17 August 2014 12:28, Pieter De Wit <[email protected]> wrote: > > Hi Jolyon, > > From memory, they used 2 int32's to make a float - this could have been > int16's - memory is very vague on this :) The one was used to represent the > whole numbers and the other was to show the decimal numbers > > Cheers, > > Pieter > > > > On 17/08/2014 12:05, Jolyon Smith wrote: > > @Pieter - I don't understand what you mean when you say that "float was > int32.int32". For starters, "float" is an imprecise term. If you mean > "single" then the entire value was always 32 bit in it's entirety. If you > mean double then it was always 64 bit. What is this "in32.int32" type of > which you speak ? O.o > > > > On 17 August 2014 11:52, Jolyon Smith <[email protected]> wrote: > > I think there are too many variables involved to give an answer to this > question without some of those variables being reduced to known values. > > e.g. what hardware ? what version of Delphi ? x64 target or x86 ? what > precision of floating point ? > > Having said that, in a quick test knocked up in my Smoketest framework I > found that Double comfortably outperforms Int64 when compiling for Win32 > but that both Double and Int64 demonstrated improved performance when > compiling for Win64 and that whilst Double still showed some advantage it > was not as significant (and in some test runs the difference was > negligible). > > If you are targeting FireMonkey you will have to bear in mind that the > back-end compiler is different to the x86/x64 backend, so results obtained > using the WinXX compilers will not necessarily be indicative of performance > on the ARM or LLVM platforms. > > > > Conditions: > > > - Delphi XE4 > > - Running in a 64-bit Win 7 VM > > - No testing was done for correctness of the results. > > > > > > > > On 16 August 2014 15:30, Ross Levis <[email protected]> wrote: > > Would I be correct that int64 multiplications would be faster than > floating point in Delphi? My app needs to do several million. > > > > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe > > > > > > > > _______________________________________________ > > NZ Borland Developers Group - Delphi mailing list > > Post: [email protected] > > Admin: http://delphi.org.nz/mailman/listinfo/delphi > > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe > > > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe > > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe > > > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
