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 [1] > 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 [1] > > 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 [1] 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 [1] Unsubscribe: send an email to [email protected] with Subject: unsubscribe Links: ------ [1] http://delphi.org.nz/mailman/listinfo/delphi
_______________________________________________ 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
