Re: [DUG] Int64 or floating point faster?
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: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] 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 pie...@insync.za.netmailto:pie...@insync.za.net 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 jsm...@deltics.co.nzmailto:jsm...@deltics.co.nz 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 r...@stationplaylist.commailto:r...@stationplaylist.com 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: delphi@listserver.123.net.nzmailto:delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nzmailto:delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nzmailto:delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nzmailto:delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nzmailto:delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nzmailto:delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Int64 or floating point faster?
@Cameron, you appear to be confused. Yes, Delphi uses a standard implementation of single and double types - the IEEE standards. But I don't know where you got the idea that this standard involves a naive pairing of two ints (of any size). Floating point types are *far* more complex than that. e.g. the internal representation of the value 1 in Double is not (0x0001).(0x) but (0x3fff).(0x) How would I describe it otherwise ? Why, the same way that IEEE 754 describes it of course. ;) http://en.wikipedia.org/wiki/Double-precision_floating-point_format Single is similarly not a naive pairing of two int16's. In fact, the closest I can even think that Delphi has to such a limited implementation for decimal values is the Curreny type, but even that isn't a pair of integers, rather a straightforward fixed point with a scalar of 10,000, yielding 4 fixed decimal places. Back to the OP... If you are using Delphi 7 and were thinking of using Single precision, then I strongly recommend that you do some tests with some representative sample data to establish the most efficient approach, but as a rule of thumb I would expect to find that Single precision would be more efficient than Double (and in the older.Win32 compilers I wouldn't be surprised if these had an even greater performance advantage over Int64). The question then is whether Single precision is adequate for your needs or if you need the additional capacity of Double. If you are inclined toward Int64 for some reason, be aware that there was a bug in the Delphi Int64 arithmetic in older Delphi versions. The 32-bit compiler doesn't use hardware op-codes for Int64 operations but emulates these in software, which is why Int64 performs less well than Double: I'm fairly sure this is the case even today (hence the comparative performance of Double and Int64 even in the XE4 32-bit compiler), but absolutely certain that it is the case with the older Delphi compilers. The details of the bug escape my memory right now, other than that it was a basic arithmetic error in the compiler emitted code (and something of an edge case), rather than a bug in an RTL function. i.e. not something that can be easily avoided. But I am sure your tests will show that Single or Double are more efficient anyway. On 17 August 2014 20:09, Cameron Hart cameron.h...@flowsoftware.co.nz 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:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *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 pie...@insync.za.net 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 jsm...@deltics.co.nz 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
Re: [DUG] Int64 or floating point faster?
Just one suggestion, why not look at assembler code in delphi to count the lines and add up the operands to get the cpu cycle total number? :-) My 2 nz cents Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Int64 or floating point faster?
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 pie...@insync.za.net 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:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *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 pie...@insync.za.net 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 jsm...@deltics.co.nz 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
Re: [DUG] Int64 or floating point faster?
Leigh, I'm not sure that this would be a reliable indicator of performance. Surely some opcodes are more expensive than others ? The relationship between opcodes and CPU cycles is not 1:1 afaik. On 18 August 2014 08:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Just one suggestion, why not look at assembler code in delphi to count the lines and add up the operands to get the cpu cycle total number? :-) My 2 nz cents Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Int64 or floating point faster?
Hi Jolyon, Sorry for the confusion. I mean add each operand of the assembler code corresponding to certain value of cpu cycles together to get a rough idea. Div is far more dear than plus for sure :-) Of course take care of condition jump/jump as this will multiple the figures depends on how many jump it will be. Regards Leigh On 18 August 2014 09:11, Jolyon Smith jsm...@deltics.co.nz wrote: Leigh, I'm not sure that this would be a reliable indicator of performance. Surely some opcodes are more expensive than others ? The relationship between opcodes and CPU cycles is not 1:1 afaik. On 18 August 2014 08:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Just one suggestion, why not look at assembler code in delphi to count the lines and add up the operands to get the cpu cycle total number? :-) My 2 nz cents Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Int64 or floating point faster?
That would be odd since the IEEE single and double types were introduced in TP 5.0 and use of these was always dependent on having a math co-pro. Perhaps it was the real type ? I'm not sure how that was implemented 'under the hood' back in the day (although these days it's just a synonym for Double) although with a range of 1E-32 to 1E+38, an int32.int32 pair wouldn't have worked (and iirc it was a 48-bit type anyway, hence it lives [lived?] on as Real48 for people who really need/want it). I am interested to find out more about this elusive type as I'd be curious to see how it was implemented (I find this sort of thing fascinating). :) On 18 August 2014 10:50, Pieter De Wit pie...@insync.za.net wrote: Hey Jolyon, I was also under the impression it was a double int. I am damn sure it was documented like this for Pascal 5.5. Even if I can find it now, it doesn't matter since I think we have proved that Delphi uses the IEEE std :) Cheers, Pieter On 18/08/2014 08:47, Jolyon Smith wrote: @Cameron, you appear to be confused. Yes, Delphi uses a standard implementation of single and double types - the IEEE standards. But I don't know where you got the idea that this standard involves a naive pairing of two ints (of any size). Floating point types are *far* more complex than that. e.g. the internal representation of the value 1 in Double is not (0x0001).(0x) but (0x3fff).(0x) How would I describe it otherwise ? Why, the same way that IEEE 754 describes it of course. ;) http://en.wikipedia.org/wiki/Double-precision_floating-point_format Single is similarly not a naive pairing of two int16's. In fact, the closest I can even think that Delphi has to such a limited implementation for decimal values is the Curreny type, but even that isn't a pair of integers, rather a straightforward fixed point with a scalar of 10,000, yielding 4 fixed decimal places. Back to the OP... If you are using Delphi 7 and were thinking of using Single precision, then I strongly recommend that you do some tests with some representative sample data to establish the most efficient approach, but as a rule of thumb I would expect to find that Single precision would be more efficient than Double (and in the older.Win32 compilers I wouldn't be surprised if these had an even greater performance advantage over Int64). The question then is whether Single precision is adequate for your needs or if you need the additional capacity of Double. If you are inclined toward Int64 for some reason, be aware that there was a bug in the Delphi Int64 arithmetic in older Delphi versions. The 32-bit compiler doesn't use hardware op-codes for Int64 operations but emulates these in software, which is why Int64 performs less well than Double: I'm fairly sure this is the case even today (hence the comparative performance of Double and Int64 even in the XE4 32-bit compiler), but absolutely certain that it is the case with the older Delphi compilers. The details of the bug escape my memory right now, other than that it was a basic arithmetic error in the compiler emitted code (and something of an edge case), rather than a bug in an RTL function. i.e. not something that can be easily avoided. But I am sure your tests will show that Single or Double are more efficient anyway. On 17 August 2014 20:09, Cameron Hart cameron.h...@flowsoftware.co.nz 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:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *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 pie...@insync.za.net 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
Re: [DUG] Int64 or floating point faster?
that’s clearer now. after taking some time to refresh on IEEE I was confusing how you would think of a floating point with how it is actually encoded. that link shows how it is stored in 64 bits and clearly it is not two int types, however the essence is that two integral numbers are used to determine the float value. From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Jolyon Smith Sent: Monday, 18 August 2014 11:26 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Int64 or floating point faster? That would be odd since the IEEE single and double types were introduced in TP 5.0 and use of these was always dependent on having a math co-pro. Perhaps it was the real type ? I'm not sure how that was implemented 'under the hood' back in the day (although these days it's just a synonym for Double) although with a range of 1E-32 to 1E+38, an int32.int32 pair wouldn't have worked (and iirc it was a 48-bit type anyway, hence it lives [lived?] on as Real48 for people who really need/want it). I am interested to find out more about this elusive type as I'd be curious to see how it was implemented (I find this sort of thing fascinating). :) On 18 August 2014 10:50, Pieter De Wit pie...@insync.za.netmailto:pie...@insync.za.net wrote: Hey Jolyon, I was also under the impression it was a double int. I am damn sure it was documented like this for Pascal 5.5. Even if I can find it now, it doesn't matter since I think we have proved that Delphi uses the IEEE std :) Cheers, Pieter On 18/08/2014 08:47, Jolyon Smith wrote: @Cameron, you appear to be confused. Yes, Delphi uses a standard implementation of single and double types - the IEEE standards. But I don't know where you got the idea that this standard involves a naive pairing of two ints (of any size). Floating point types are far more complex than that. e.g. the internal representation of the value 1 in Double is not (0x0001).(0x) but (0x3fff).(0x) How would I describe it otherwise ? Why, the same way that IEEE 754 describes it of course. ;) http://en.wikipedia.org/wiki/Double-precision_floating-point_format Single is similarly not a naive pairing of two int16's. In fact, the closest I can even think that Delphi has to such a limited implementation for decimal values is the Curreny type, but even that isn't a pair of integers, rather a straightforward fixed point with a scalar of 10,000, yielding 4 fixed decimal places. Back to the OP... If you are using Delphi 7 and were thinking of using Single precision, then I strongly recommend that you do some tests with some representative sample data to establish the most efficient approach, but as a rule of thumb I would expect to find that Single precision would be more efficient than Double (and in the older.Win32 compilers I wouldn't be surprised if these had an even greater performance advantage over Int64). The question then is whether Single precision is adequate for your needs or if you need the additional capacity of Double. If you are inclined toward Int64 for some reason, be aware that there was a bug in the Delphi Int64 arithmetic in older Delphi versions. The 32-bit compiler doesn't use hardware op-codes for Int64 operations but emulates these in software, which is why Int64 performs less well than Double: I'm fairly sure this is the case even today (hence the comparative performance of Double and Int64 even in the XE4 32-bit compiler), but absolutely certain that it is the case with the older Delphi compilers. The details of the bug escape my memory right now, other than that it was a basic arithmetic error in the compiler emitted code (and something of an edge case), rather than a bug in an RTL function. i.e. not something that can be easily avoided. But I am sure your tests will show that Single or Double are more efficient anyway. On 17 August 2014 20:09, Cameron Hart cameron.h...@flowsoftware.co.nzmailto:cameron.h...@flowsoftware.co.nz 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: delphi-boun...@listserver.123.net.nzmailto:delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nzmailto:delphi-boun...@listserver.123.net.nz] 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
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 pie...@insync.za.net 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 jsm...@deltics.co.nz 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 r...@stationplaylist.com 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: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Int64 or floating point faster?
Single precision would be adequate for what I need. I didn’t explain it very clearly. My current calculation is like this. Var64bit := Var16bit * Var32bitB div Var32bitC; If Var64bit 32767 then Var64bit := 32767; If Var64bit -32768 then Var64bit := -32768; Var16bit := Var64bit; I made the target Int64 since Var16bit * Var32bitB can end up bigger than an Int32 number. I believe that forces the compiler to use In64 multiplication. Or perhaps this has the same effect... Var32bitA := Int64(Var16bit * Var32bitB) div Var32bitC; The alternative is to store (Var32bitB / Var32bitC) in a Single var. I suppose I should do my own tests if the speed is not so obvious. Ross. From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Jolyon Smith Sent: Sunday, 17 August 2014 11:52 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Int64 or floating point faster? 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 r...@stationplaylist.com 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: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
[DUG] Int64 or floating point faster?
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: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
