Board index » cppbuilder » Speed of float and int calculations

Speed of float and int calculations

Hello,I'm writing some routines to draw bitmaps like sprites (moving
from one point to another "cleaning" the
background,transparency,fading,stretching ecc...)
I made all my routines using float variables,if I rewrite everything
with int variables would I get much more speed?

Example:
{
Draw routines (Canvas->Draw of 24bit bitmaps with dimensions from
40x40 to 640x480)
some float operations (about 20 divisions) to calculate next position
ecc ecc

Quote
}

If  everything is 100%,and how much time does the draw routines takes?
(much more than the simple float operations? if yes even if I do
everything with int operations I would not improve speed too much)

Other question about the ScanLine of TBitmap:
If I use a 24 bit bitmap,how can I read the various RGB components?

for y {
  ptr= ....
    for x {
       v=ptr[x] (c is the palette color in the BCB example)
                     (but if I use a 24bit bitmap?)    
       r=ptr[x*3]
       g=ptr[x*3+1] (is this right? or is BGR? or is 0BGR because is a
TColor value?)
       b=ptr[x*3+2]
        }

Quote
}

Thanks!
 

Re:Speed of float and int calculations


I would expect you to see a speedup.  Especially with this compiler.
:)

--
Chris (TeamB)

Quote
m.durliNOS...@bo.nettuno.it wrote:

> Hello,I'm writing some routines to draw bitmaps like sprites (moving
> from one point to another "cleaning" the
> background,transparency,fading,stretching ecc...)
> I made all my routines using float variables,if I rewrite everything
> with int variables would I get much more speed?

Re:Speed of float and int calculations


Quote
: m.durliNOS...@bo.nettuno.it wrote:
>Hello,I'm writing some routines to draw bitmaps like sprites (moving
>from one point to another "cleaning" the
>background,transparency,fading,stretching ecc...)
>I made all my routines using float variables,if I rewrite everything
>with int variables would I get much more speed?

Chances are that you get LESS speed.

The Intel FPU arithmetics nowadays are faster than their integer
counterparts.

--
Stefan Hoffmeister       http://www.econos.de/
No private email, please, unless expressly invited.

Re:Speed of float and int calculations


Quote
Stefan Hoffmeister wrote:
> Chances are that you get LESS speed.

> The Intel FPU arithmetics nowadays are faster than their integer
> counterparts.

Many of the CPU opcodes for floating points are not actually generated
with BCB.  All the trancedental functions (sin, cos, tan, etc) have
in-processor opcodes available but are not used.  BCB calculates these
values in *software* using BIG macros that determine quadrants and
angles, etc.  They are very accurate (more than Intel's processor
values) but are much slower.

In non-scientificly administrated comparisons, I've seen floating
point math done by Visual Basic (which uses the CPU to do the math
directly) to be approximately twice as fast as equivalent BCB compiled
code.

<ouch>

--
Chris (TeamB)

Re:Speed of float and int calculations


Quote
Chris Uzdavinis (TeamB) wrote in message

<36547D62.15F04...@uzdavinis.com>...

Quote
>...In non-scientificly administrated comparisons, I've seen floating
>point math done by Visual Basic (which uses the CPU to do the math
>directly) to be approximately twice as fast as equivalent BCB compiled
>code.

><ouch>

You can say <ouch!> again!  It's not just Visual Basic, and not just the
transcendentals.  Even straight inline code for +, -, *, and / appears to
run at 1/2 to 1/3 the speed of old stalwarts like Watcom C/C++.  So, if you
needed fast transcendentals, even if you were willing to write your own,
you're stuck anyway.  The only other option I know of is inline assembler.

For a 500,000-line program like ours, which is nearly all arithmetic (our
only transcendentals are rare calls to pow() or log()), it's impractical to
resort to assembler.  That's why you use a compiler in the first place.

As far as accuracy is concerned, we've compared megabytes worth of binary
floating-point values produced by Borland against those produced by Watcom.
The outputs are byte-for-byte identical.  There is apparently no need to
sacrifice speed for accuracy in our application.  Probably there are
applications where it is necessary, and the writers of those applications
should have the option of using slow floating-point, instead of the rest of
us having no option at all.

Well, not quite no option.  We can always switch to someone else's compiler.
--
Phil Colbert
Technology Manager
Integrated Actuarial Services, Inc.

P.S.: If you know of ANY other options, PLEASE tell us!!!

Re:Speed of float and int calculations


Quote

> Well, not quite no option.  We can always switch to someone else's
compiler.
> --
> Phil Colbert
> Technology Manager
> Integrated Actuarial Services, Inc.

> P.S.: If you know of ANY other options, PLEASE tell us!!!

Put all of your intensive code into .DLLs and compile those .DLLs with
MSVC(From all Ive heard on this, MS compilers are faster than anything in
both int and fp calculation.) Lets hope Inprise gets this right for Builder
V4.

Steve

Re:Speed of float and int calculations


Quote
sgordon wrote in message <01be1c12$390e9a80$88b24acf@prog-1>...
>Put all of your intensive code into .DLLs and compile those .DLLs with
>MSVC(From all Ive heard on this, MS compilers are faster than anything in
>both int and fp calculation.) Lets hope Inprise gets this right for Builder
>V4.

>Steve

I thought about that, but I've not explored DLLs yet, and am not sure what
special steps must be taken in order to insure that the dynamic linking
works properly between the two compilers.

A DLL provides a standard way of finding a function entry point, but merely
having a function entry point is not enough.  I would expect to see
parameter-passing problems and other stack problems (since the stack layouts
aren't guaranteed to be compatible) and register problems (register usage
may differ).  I would also expect to see unresolved externals (since the
Borland .EXE would not provide the DLL with the MS runtime library routines
that the DLL calls).

Any ideas how to actually accomplish what you suggest?
--
Phil Colbert
Technology Manager
Integrated Actuarial Services, Inc.

Re:Speed of float and int calculations


: "Phil Colbert" <PColb...@compuserve.com> wrote:

Quote
>I would expect to see
>parameter-passing problems and other stack problems (since the stack layouts
>aren't guaranteed to be compatible) and register problems (register usage
>may differ).  I would also expect to see unresolved externals (since the
>Borland .EXE would not provide the DLL with the MS runtime library routines
>that the DLL calls).

STDCALL and CDECL are standarized calling conventions.

Register clobbering is standardized, too.

Unresolved externals: link the MS RTL code into the MS DLL or ship the
MS RTL.

--
Stefan Hoffmeister       http://www.econos.de/
No private email, please, unless expressly invited.

Re:Speed of float and int calculations


On Wed, 2 Dec 1998 19:54:42 -0600, "Phil Colbert" <PColb...@compuserve.com>
wrote:

Quote
>Any ideas how to actually accomplish what you suggest?

Sure... it's done all the time.  Declare your functions as extern "C" so
they use C linkage.  THen, make sure you use __stdcall calling convention
(for functions that do not have variable number of arguments).

I have posted numerous examples on how to do DLLs.  Search dejanews and
it'll be plain enough.

+----------------------------------------------------------------------+
| Jody Hagins                                                          |
| Automated Trading Desk            "Fame is a vapor, popularity is an |
| 389 Johnnie Dodds Blvd, Su. 200   accident, and money takes wings.   |
| Mt. Pleasant, SC  29464           The only thing that endures is     |
| j...@atdesk.com                   character."                        |
|                                        - O.J. Simpson, 1979          |
+----------------------------------------------------------------------+

Re:Speed of float and int calculations


On Thu, 19 Nov 1998 14:58:26 -0600, "Phil Colbert" <PColb...@compuserve.com>
wrote:

Quote
>Well, not quite no option.  We can always switch to someone else's compiler.
>--
>Phil Colbert
>Technology Manager
>Integrated Actuarial Services, Inc.

>P.S.: If you know of ANY other options, PLEASE tell us!!!

I would recommend using another compiler for FPU operations.  Build a DLL
for those routines which use it most often, and link the DLL with Builder.
BCB is by far the best C++ compiler for windows.  However, it does have its
deficiencies, and this is one of them.

+----------------------------------------------------------------------+
| Jody Hagins                                                          |
| Automated Trading Desk            "Fame is a vapor, popularity is an |
| 389 Johnnie Dodds Blvd, Su. 200   accident, and money takes wings.   |
| Mt. Pleasant, SC  29464           The only thing that endures is     |
| j...@atdesk.com                   character."                        |
|                                        - O.J. Simpson, 1979          |
+----------------------------------------------------------------------+

Re:Speed of float and int calculations


Quote
Jody Hagins (TeamB) wrote:

> I would recommend using another compiler for FPU operations.  Build a DLL
> for those routines which use it most often, and link the DLL with Builder.

Alas, this is not always simple to do. For instance, I have a C++
library that does geometry and hence a lot of floating point. Since
classes and overloading are used heavily, it is not simply a matter of
declaring things "extern C".
I can't pass a polygon object from BCB to another compiler (which will
have a different layout), and converting this to an array of
coordinates, then call a wrapper function and then convert back will
probably cost just as much performance as using BCB fpu operations
(apart from the hassle).

Quote
> BCB is by far the best C++ compiler for windows.  However, it does have its
> deficiencies, and this is one of them.

A rather serious one, I think.

Re:Speed of float and int calculations


On Fri, 04 Dec 1998 15:00:58 +0100, Geert-Jan Giezeman <ge...@cs.uu.nl>
wrote:

Quote
>Alas, this is not always simple to do. For instance, I have a C++

Agreed on all accounts.

+----------------------------------------------------------------------+
| Jody Hagins                                                          |
| Automated Trading Desk            "Fame is a vapor, popularity is an |
| 389 Johnnie Dodds Blvd, Su. 200   accident, and money takes wings.   |
| Mt. Pleasant, SC  29464           The only thing that endures is     |
| j...@atdesk.com                   character."                        |
|                                        - O.J. Simpson, 1979          |
+----------------------------------------------------------------------+

Re:Speed of float and int calculations


Quote
>Alas, this is not always simple to do. For instance, I have a C++
>library that does geometry and hence a lot of floating point. Since
>classes and overloading are used heavily, it is not simply a matter of
>declaring things "extern C".
>I can't pass a polygon object from BCB to another compiler (which will
>have a different layout), and converting this to an array of
>coordinates, then call a wrapper function and then convert back will
>probably cost just as much performance as using BCB fpu operations
>(apart from the hassle).

There is one possible workaround, though it may not be very
attractive:

declare all the classes member functions as inline, and have them call
regular extern "C" functions for the implimentation:

struct base
{
        // data declarations here

Quote
};

extern "C" void foo(base* b);

class myclass: public base
{
        foo() { ::foo(); }

Quote
};

John Maddock
http://ourworld.compuserve.com/homepages/John_Maddock/

Re:Speed of float and int calculations


Quote
Stefan Hoffmeister wrote in message <36684da5.485...@forums.inprise.com>...
>STDCALL and CDECL are standarized calling conventions.

>Register clobbering is standardized, too.

>Unresolved externals: link the MS RTL code into the MS DLL or ship the
>MS RTL.

>--
>Stefan Hoffmeister       http://www.econos.de/

Thank you, Stefan.  I'll give it a try, after I pick up a Microsoft
compiler.  (Though I'd rather have the option to get the calculation speed
with Builder alone...)
--
Phil Colbert
Technology Manager
Integrated Actuarial Services, Inc.

Other Threads