Hi all,

I ran into this timing issue - computing 1+1 with integers is much

slower than doing the same with double typed numbers - and mixing integer

types is even slower. Any idea why?

My timings are below. (scilab CVS, i686)

Enrico

-->hrtimer();for i=1:10000; 1+1; end; hrtimer()

ans =

0.075238

-->hrtimer();for i=1:10000; uint8(1)+uint8(1); end; hrtimer()

ans =

0.173999

-->hrtimer();for i=1:10000; int8(1)+int8(1); end; hrtimer()

ans =

0.182417

-->hrtimer();for i=1:10000; uint8(1)+1; end; hrtimer()

ans =

0.423906

-->hrtimer();for i=1:10000; int8(1)+1; end; hrtimer()

ans =

0.429134

-->hrtimer();for i=1:10000; int8(1)+uint8(1); end; hrtimer()

ans =

0.926458

addendum (sorry for the self reference) --

The last three examples take the detour of %i_a_i.sci, which is

inefficient (this was a lapse, _I_ submitted it), so the longer time is

explained; but why the 2nd and the third, which should use a native

SCI/routines/int/i_a_i.f? And wouldn't it be better to implement in

native, rather than percent form, also the other mixed type operations?

The last three examples take the detour of %i_a_i.sci, which is

inefficient (this was a lapse, _I_ submitted it), so the longer time is

explained; but why the 2nd and the third, which should use a native

SCI/routines/int/i_a_i.f? And wouldn't it be better to implement in

native, rather than percent form, also the other mixed type operations?

>>>>> "Enrico" == Enrico Segre < XXXX@XXXXX.COM > writes:

Enrico> Hi all, I ran into this timing issue - computing 1+1 with

Enrico> integers is much slower than doing the same with double

Enrico> typed numbers - and mixing integer types is even

Enrico> slower. Any idea why? My timings are below. (scilab CVS,

Enrico> i686) Enrico

Enrico> --> hrtimer();for i=1:10000; 1+1; end; hrtimer()

Enrico> ans =

Enrico> 0.075238

Enrico> --> hrtimer();for i=1:10000; uint8(1)+uint8(1); end; hrtimer()

Enrico> ans =

Enrico> 0.173999

Enrico>--> hrtimer();for i=1:10000; int8(1)+int8(1); end; hrtimer()

Enrico> ans =

Enrico> 0.182417

Here the efficiency differences are due to the evaluation ot the

functions uint8 or int8

try this

-->un=1;

--> hrtimer();for i=1:10000; un+un; end; hrtimer()

ans =

0.1

-->un=uint8(1);

--> hrtimer();for i=1:10000; un+un; end; hrtimer()

ans =

0.1

Enrico>--> hrtimer();for i=1:10000; uint8(1)+1; end; hrtimer()

Enrico> ans =

Enrico> 0.423906

Enrico>--> hrtimer();for i=1:10000; int8(1)+1; end; hrtimer()

Enrico> ans =

Enrico> 0.429134

Enrico>--> hrtimer();for i=1:10000; int8(1)+uint8(1); end; hrtimer()

Enrico> ans =

Enrico> 0.926458

as you stated in your following post the costs here are due to the

fact we have choosen to have these operations defined by overloading

functions, so the user can change our conversion conventions.

--

Serge Steer

Inria Rocquencourt

BP 105 78153 Le Chesnay CEDEX

email: XXXX@XXXXX.COM

fax:(33) 01 39 63 57 86

Enrico> Hi all, I ran into this timing issue - computing 1+1 with

Enrico> integers is much slower than doing the same with double

Enrico> typed numbers - and mixing integer types is even

Enrico> slower. Any idea why? My timings are below. (scilab CVS,

Enrico> i686) Enrico

Enrico> --> hrtimer();for i=1:10000; 1+1; end; hrtimer()

Enrico> ans =

Enrico> 0.075238

Enrico> --> hrtimer();for i=1:10000; uint8(1)+uint8(1); end; hrtimer()

Enrico> ans =

Enrico> 0.173999

Enrico>--> hrtimer();for i=1:10000; int8(1)+int8(1); end; hrtimer()

Enrico> ans =

Enrico> 0.182417

Here the efficiency differences are due to the evaluation ot the

functions uint8 or int8

try this

-->un=1;

--> hrtimer();for i=1:10000; un+un; end; hrtimer()

ans =

0.1

-->un=uint8(1);

--> hrtimer();for i=1:10000; un+un; end; hrtimer()

ans =

0.1

Enrico>--> hrtimer();for i=1:10000; uint8(1)+1; end; hrtimer()

Enrico> ans =

Enrico> 0.423906

Enrico>--> hrtimer();for i=1:10000; int8(1)+1; end; hrtimer()

Enrico> ans =

Enrico> 0.429134

Enrico>--> hrtimer();for i=1:10000; int8(1)+uint8(1); end; hrtimer()

Enrico> ans =

Enrico> 0.926458

as you stated in your following post the costs here are due to the

fact we have choosen to have these operations defined by overloading

functions, so the user can change our conversion conventions.

--

Serge Steer

Inria Rocquencourt

BP 105 78153 Le Chesnay CEDEX

email: XXXX@XXXXX.COM

fax:(33) 01 39 63 57 86

you're right, I overlooked it is a function call! Thanks for the explanation,

enrico

1. findcontrol("PlaceHolderPrice") why why why why why why why why why why why

2. Unexpected integer addition result

3. [Info-Ingres] default size of result in integer addition.

4. how 2 add integer addition modulo 2^32

5. Addition for 'short' unsigned integer types

7. [OT] addition of many integers in a file

8. how to add integer addition modulo 2^32

9. SSE2 and MMX performace - Almost same when performing integer addition

10. requesting program for integer addition modulo 2^32

12. integer overflow detection would be a nice addition.

13. integer addition taking CARRY into account

14. addition of many integers in a file

15. Integer overflow, why and why not ?

4 post • Page:**1** of **1**