Board index » delphi » comp vs. int64 (was bug with comp)

comp vs. int64 (was bug with comp)

In the provious thread, I mentioned that one of my rouintes was
50% faster with comp than with int64.  It depends on what you
are doing.  In my tests, when adding, int64 is about 6-7 times
faster than comp.  When multiplying, comp is a little faster
than int64.  / in comp is about 17 times faster than DIV with
int64, but it rounds instead of truncating.  int( / ) in comp is
8-9 times faster than DIV on int64.  So if you have any
divisions or mods, cop is probably going to be significantly
faster than int64.  If it is restricted to add, subtract, and
multiply, it will be a lot closer, and int64 should be faster,
unless there are a lot more * than +.

Jud McCranie

 

Re:comp vs. int64 (was bug with comp)


Hi.

Quote
Jud McCranie writes...
>In the provious thread, I mentioned that one of my rouintes was
>50% faster with comp than with int64.  It depends on what you
>are doing.  In my tests, when adding, int64 is about 6-7 times
>faster than comp.  When multiplying, comp is a little faster
>than int64.  / in comp is about 17 times faster than DIV with
>int64, but it rounds instead of truncating.  int( / ) in comp is
>8-9 times faster than DIV on int64.  So if you have any
>divisions or mods, cop is probably going to be significantly
>faster than int64.

I would also mention that if your tasks allow vectorizing or paralleling,
then writing code with comp is probable much better than using only int64. I
would also recommend in critical tasks to combine in64 and comp.

ps. Isn't it offtopic?
Bye.
/lexi

Re:comp vs. int64 (was bug with comp)


Quote
"lexi" <l...@ufanet.ru> wrote:
>I would also mention that if your tasks allow vectorizing or paralleling,
>then writing code with comp is probable much better than using only int64. I
>would also recommend in critical tasks to combine in64 and comp.

>ps. Isn't it offtopic?

I don't think so.  Comp and int64 are data types used in Delphi,
and I think it is certainly on topic to discuss their relative
merits, etc.

Jud McCranie

Re:comp vs. int64 (was bug with comp)


Quote
Jud McCranie wrote:

> In the provious thread, I mentioned that one of my rouintes was
> 50% faster with comp than with int64.  It depends on what you
> are doing.  In my tests, when adding, int64 is about 6-7 times
> faster than comp.  When multiplying, comp is a little faster
> than int64.  / in comp is about 17 times faster than DIV with
> int64, but it rounds instead of truncating.  int( / ) in comp is
> 8-9 times faster than DIV on int64.

Based on your results I suspect that you are testing on a Pentium class
computer (as opposed to a PII)  You'd find the results were quite
different on the PII.  Many of the remaining differences can be
explained by the fact that Comp calcs are performed as floating point
calcs.  Since they are actually saved as integers they have to be
converted upon each load/store operation which is expensive.
Consequently, I believe that you'll find that going with double instead
of comp would be faster.

If you want to maintain your current storage format (i.e. comp or int64)
I suggest that you try converting first to double before doing any
significant calcs in floating point then convert back.

--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/

Re:comp vs. int64 (was bug with comp)


Quote
Robert Lee <rh...@nwu.edu> wrote:
>Based on your results I suspect that you are testing on a Pentium class
>computer (as opposed to a PII)  

No, it was a Pentium II.

Quote
>Since they are actually saved as integers they have to be
>converted upon each load/store operation which is expensive.

Hmmm.  I was testing lines like z := x * y; so the load and
store time is included.

Quote
>Consequently, I believe that you'll find that going with double instead
>of comp would be faster.

Double doesn't give you the same range as comp, and extended is
slower than comp.

Jud McCranie

Re:comp vs. int64 (was bug with comp)


Quote
On Tue, 11 Jan 2000 22:24:58 -0600, Robert Lee <rh...@nwu.edu> wrote:
>If you want to maintain your current storage format (i.e. comp or int64)
>I suggest that you try converting first to double before doing any
>significant calcs in floating point then convert back.

Converting Comp to Double sacrifices precision.
--
Ray Lischner, http://www.tempest-sw.com/nutshell
author of Delphi in a Nutshell

Re:comp vs. int64 (was bug with comp)


Quote
lisch.at.tempest-sw....@nojunkmail.com (Ray Lischner) wrote:
>>If you want to maintain your current storage format (i.e. comp or int64)
>>I suggest that you try converting first to double before doing any
>>significant calcs in floating point then convert back.

>Converting Comp to Double sacrifices precision.

Right, and the conversions are too costly too.
Jud McCranie

Re:comp vs. int64 (was bug with comp)


Quote
Jud McCranie wrote:

> Robert Lee <rh...@nwu.edu> wrote:

> >Based on your results I suspect that you are testing on a Pentium class
> >computer (as opposed to a PII)

> No, it was a Pentium II.

Hmm, the overhead in the int64 mult function must be worse than it
appears.

Quote
> >Since they are actually saved as integers they have to be
> >converted upon each load/store operation which is expensive.

> Hmmm.  I was testing lines like z := x * y; so the load and
> store time is included.

yes exactly,  in comp x and y have to be converted to fp then multiply
then converted back to store in z.  the conversions take much longer
than the multiplication itself.

Quote
> >Consequently, I believe that you'll find that going with double instead
> >of comp would be faster.

> Double doesn't give you the same range as comp, and extended is
> slower than comp.

Yes, that is a problem, but I wasn't sure if you were actually using all
those digits.  I suppose the best solution would be to manually select
double or comp on a variable by variable basis. Not a very attractive
proposition though.

--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/

Re:comp vs. int64 (was bug with comp)


Quote
Robert Lee <rh...@nwu.edu> wrote:
>yes exactly,  in comp x and y have to be converted to fp then multiply
>then converted back to store in z.  the conversions take much longer
>than the multiplication itself.

Yes, but still in my test on a P-II, it is only a little slower
than int64 multiplication.  And division is so much faster with
comp than int64 that it will usually outweigh the difference in
mult.

Jud McCranie

Re:comp vs. int64 (was bug with comp)


Quote
Jud McCranie wrote:

> Robert Lee <rh...@nwu.edu> wrote:

> >yes exactly,  in comp x and y have to be converted to fp then multiply
> >then converted back to store in z.  the conversions take much longer
> >than the multiplication itself.

> Yes, but still in my test on a P-II, it is only a little slower
> than int64 multiplication.  And division is so much faster with
> comp than int64 that it will usually outweigh the difference in
> mult.

Wait a minute, I thought you said that comp was faster than int64 on
multiplication?

Here's my own test (PII):

        integer         int64           Comp            double

Add     0.10            0.44            0.97            0.70
mult    0.33            1.76            1.13            0.83
div     3.21            3.97            2.61            3.39

This is based on 3 operations per statement and 14 statements per
timing.  Note that I didn't get your difference on division.  However,
the time for division is a function of the divisor value(s).

Finally, you can achieve int64like add performance by doing a lot of
ugly casting:

  Pint64(@Result)^:=Pint64(@Result)^+Pint64(@a)^+Pint64(@b)^;  // time =
0.48

BTW, I find it ammusing that the helps claims that you should switch
from comp to int64 for "better performance"

--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/
Updated November 8

Re:comp vs. int64 (was bug with comp)


Quote
Robert Lee <rh...@nwu.edu> wrote:
>Wait a minute, I thought you said that comp was faster than int64 on
>multiplication?

No, I said that comp was slightly slower than int64 on mult in
my test.

Quote

>    integer         int64           Comp            double

>Add 0.10            0.44            0.97            0.70
>mult        0.33            1.76            1.13            0.83
>div 3.21            3.97            2.61            3.39

>This is based on 3 operations per statement and 14 statements per
>timing.  Note that I didn't get your difference on division.

Did you try it with both operands in the division being > 2^32?

Quote
>the time for division is a function of the divisor value(s).

Yes, it does for int64.  I think the floating points are pretty
much independant of the values.

Quote
>BTW, I find it ammusing that the helps claims that you should switch
>from comp to int64 for "better performance"

It depends on what operations you are doing.

Jud McCranie

Re:comp vs. int64 (was bug with comp)


Quote
On Thu, 13 Jan 2000 13:12:16 -0600, Robert Lee <rh...@nwu.edu> wrote:
>BTW, I find it ammusing that the helps claims that you should switch
>from comp to int64 for "better performance"

There are three reasons to use Int64 instead of Comp:

1. Converting to a string works with Int64, but not with Comp. For
reasons that escape me, Delphi's floating point to string formatting
functions have a hardwired limit of 18 digits of precision, despite the
fact that the maximum decimal precision of Comp, Extended, and Currency
is 19 digits.

2. Int64 is not subject to the vagaries of the floating point control
word. Some Microsoft functions and DLLs arbitrarily change the FPU
control word. If the precision is set to single or double instead of
extended, the precision of Comp (and Currency) suffer. The workaround
(if you must use Comp or Currency) is to use SafeLoadLibrary instead of
LoadLibrary, and to check your results carefully and thoroughly.

3. Int64 supports integer operators, such as shl and shr.

As has been mentioned elsewhere in this thread, you can use Comp for
arithmetic (if you know the FPU precision is extended), and cast to
Int64 for converting to a string or performing a shift or bitwise
operation.
--
Ray Lischner, http://www.tempest-sw.com/nutshell
author of Delphi in a Nutshell

Re:comp vs. int64 (was bug with comp)


Quote
Jud McCranie wrote:

> Robert Lee <rh...@nwu.edu> wrote:

> >Wait a minute, I thought you said that comp was faster than int64 on
> >multiplication?

> No, I said that comp was slightly slower than int64 on mult in
> my test.

In your first post you had it flipped then.  

Quote
> Did you try it with both operands in the division being > 2^32?

No not specifically.  Is that the key? I'd like to include this topic on
my web site so if you have any other gotcha cases please elaborate.

Quote
> >the time for division is a function of the divisor value(s).

> Yes, it does for int64.  I think the floating points are pretty
> much independant of the values.

No they vary too (try easy values like dividing by 1) they can be three
times faster.

Quote
> >BTW, I find it ammusing that the helps claims that you should switch
> >from comp to int64 for "better performance"

> It depends on what operations you are doing.

Yes it does. But the help implies that int64 is always better, which is
clearly not true.

--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/

Re:comp vs. int64 (was bug with comp)


Quote
lisch.at.tempest-sw....@nojunkmail.com (Ray Lischner) wrote:
>There are three reasons to use Int64 instead of Comp:

>1. Converting to a string works with Int64, but not with Comp. For
>reasons that escape me, Delphi's floating point to string formatting
>functions have a hardwired limit of 18 digits of precision, despite the
>fact that the maximum decimal precision of Comp, Extended, and Currency
>is 19 digits.

Yes, that's one thing that started this discussion.  Even so,
you can do the calculations in comp and transfer to int64 to
convert to a string.

Quote
>2. Int64 is not subject to the vagaries of the floating point control
>word. Some Microsoft functions and DLLs arbitrarily change the FPU
>control word. If the precision is set to single or double instead of
>extended, the precision of Comp (and Currency) suffer. The workaround
>(if you must use Comp or Currency) is to use SafeLoadLibrary instead of
>LoadLibrary, and to check your results carefully and thoroughly.

I didn't know about that.

Quote
>3. Int64 supports integer operators, such as shl and shr.

That's true.

Quote
>As has been mentioned elsewhere in this thread, you can use Comp for
>arithmetic (if you know the FPU precision is extended), and cast to
>Int64 for converting to a string or performing a shift or bitwise
>operation.

Yes.

Jud McCranie

Re:comp vs. int64 (was bug with comp)


Quote
Robert Lee <rh...@nwu.edu> wrote:
>> No, I said that comp was slightly slower than int64 on mult in
>> my test.

>In your first post you had it flipped then.  

Here is a quote from my message in this thread 1/13, at 10:09
"Yes, but still in my test on a P-II, it is only a little slower
than int64 multiplication. "

Quote
>> Did you try it with both operands in the division being > 2^32?

>No not specifically.  Is that the key?

I believe so.  The numbers I put into the comps and int64 were >
2^32, and int64 division seems to take a very long time then.
Otherwise it is a special cast that could be handled faster.

Quote
> I'd like to include this topic on
>my web site so if you have any other gotcha cases please elaborate.

The only other thing I can think of right now is that I had
checks off for these tests.  If you have checks on, I suspect
that the int64 operations will suffer more compared to comp.

Quote
>No they vary too (try easy values like dividing by 1) they can be three
>times faster.

OK.  I was testing the same numbers when I compared int64 to
comp, to keep the test valid.

Quote
>Yes it does. But the help implies that int64 is always better, which is
>clearly not true.

Right.

Jud McCranie

Go to page: [1] [2]

Other Threads