Re: Int 32 processing speed: Is it a bug
- From: Naresh.Bajaj <naresh.bajaj@xxxxxxxxx>
- Date: Wed, 19 Oct 2005 11:41:08 -0400
Hi,
It is confirmed that matlab is not doing any integer arithmetic in
double precision. But if you observe, it is faster when you do
calculation in matrix format. When I am using just addition of two
scalar quantities, integer arithmetic is slower. I was wondering what
could be the reason.
I am not planning to use any matrix calculation in my program.
Regards,
Naresh
Elapsed time is 0.017342 seconds.
Elapsed time is 0.071173 seconds.
%Double precision
%Here is the simple matlab program that tells you the difference in
%speed between double and integer type casting.
z = 10000
i = 1;
e = 2;
tic
for(m=1:z)
i=i+e;
end
toc
%Integer precision
%Here in this case, even though we define the variable outside the
%for
%loop and do the computation loop matlab is 10 times slower than
%double precision algorithm. Why it is slow? If you don?t believe,
%try it for your self!!!!!!
z = 10000
i = int32(1);
e = int32(2);
tic
for(m=1:z)
i=i+e;
end
toc
Peter Boettcher wrote:
>
>
> "Heinrich Acker" <Firstname.Lastname@xxxxxx> writes:
>
>> I have observed this also on R14 to R14SP3. It seems that
> arithmetic
>> calculations are always fastest in double. Operations that do
not
>> involve arithmetic calculations, like transposing a matrix,
> however,
>> can be faster in int32. The usual mixture of operations seems
to
> be
>> slower with integer types. This is disappointing sometimes,
> although
>> the integers (and single) are useful for storing large amounts
of
>> data.
>>
>> When I discovered that I cannot speedup my programs by using
> integers
>> where appropriate, I felt a bit tricked, because the R14
release
>> notes explain:
>>
>> "MATLAB Version 7.0 now supports many arithmetic operations and
>> mathematical functions on the following nondouble MATLAB data
> types:
>> single int8 and uint8 int16 and uint16 int32 and uint32
>>
>> Most of the built-in MATLAB functions that perform mathematical
>> operations now support inputs of type single. In addition, the
>> arithmetic operators and the functions sum, diff, colon, and
some
>> elementary functions now support integer data types."
>>
>> "Support" means that you don't have to type
>>
>> c = int32(double(a)+double(b));
>>
>> in order to add two int32 a,b. But this is what happens
> internally.
>> Although it is mentioned later in an unnecessarily complicated
>> statement about operations with mixed data types that all
> calculation
>> is performed in double, I think it is misleading to call this
> integer
>> support. ...
>
> Is this a question or an assertion? A simple test shows that it is
> not correct:
>
> a = 100*rand(1000,1000);
> b = uint16(a);
>
> tic
> for i=1:100
> c = a+a;
> end
> toc
>
> tic
> for i=1:100
> d = b+b;
> end
> toc
>
>
> Elapsed time is 2.662986 seconds.
> Elapsed time is 0.727666 seconds.
>
>
> The addition of uint16's is much faster than addition of doubles.
> Therefore, no conversion to double is done before the addition.
>
> The "unnecessarily complicated" statement is perhaps necessarily
> so,
> because it applies only to mixed data types. In fact, uint16 +
> uint8
> is not supported at all.
>
> Maybe you are thinking about matrix operations? Those are
> different.
> They use machine-optimized BLAS calls that only operate on double
> (and
> single?) floating-point format. Sure, I suppose that could be an
> enhancement request, to add custom BLAS calls for matrix multiplies
> on
> integers, for instance, but the precision is very limiting anyway.
>
> Sorry you feel "tricked" by the very real support for integer types
> that many of us have been waiting for for a long time. People here
> are usually good at helping to speed up code. Maybe you'd like to
> post your problem in a more general way, and see if we can find a
> way
> to speed it up?
>
>
> --
> Peter Boettcher <boettcher@xxxxxxxxxx>
> MIT Lincoln Laboratory
> MATLAB FAQ: <http://www.mit.edu/~pwb/cssm/>
>
.
- Follow-Ups:
- Re: Int 32 processing speed: Is it a bug
- From: Heinrich Acker
- Re: Int 32 processing speed: Is it a bug
- From: Peter Boettcher
- Re: Int 32 processing speed: Is it a bug
- References:
- Int 32 processing speed: Is it a bug
- From: naresh . bajaj
- Re: Int 32 processing speed: Is it a bug
- From: Heinrich Acker
- Re: Int 32 processing speed: Is it a bug
- From: Peter Boettcher
- Int 32 processing speed: Is it a bug
- Prev by Date: Re:
- Next by Date: Re: Neural network training
- Previous by thread: Re: Int 32 processing speed: Is it a bug
- Next by thread: Re: Int 32 processing speed: Is it a bug
- Index(es):
Relevant Pages
|