Thread Subject: Int 32 processing speed: Is it a bug

Hello,
Here is my code which tells the difference in double precision and
integer type calculation. All the variables were defined out side
'for' loop and we are interested in 'for' loop time cycle only.

If you run the code, you will see the integer arithmetic 10 times
slower than double precision.
Please let me know why it is slower and what is the solution?
I guess matlab saying that it is doing some integer math but it is
doing double precision only.
Naresh,
#####################################
%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
######################################

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. Reason: Nobody would have to type the above code line
without this "support", since this line is not only slower than just
c = a+b; in double, it also requires more memory (to hold the
converted values). For the remaining applications (saving space in
large MAT files, providing data for I/O functions) it is not much of
an issue to use the type conversion functions.

I would be glad if somebody from The Mathworks could explain if it is
planned to extend the integer support to real integer calculations,
and if there is a way to implement this somehow into the current
version.

Heinrich

"Heinrich Acker" <Firstname.Lastname@web.de> 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@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/

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@web.de> 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@ll.mit.edu>
> MIT Lincoln Laboratory
> MATLAB FAQ: <http://www.mit.edu/~pwb/cssm/>
>

Naresh.Bajaj <naresh.bajaj@gmail.com> writes:

> 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.


If we put this in an M-file, the accelerator kicks in. If we use a
much higher number of iterations to get a stable result, I get:

z= 10000000

Elapsed time is 0.060923 seconds.
Elapsed time is 0.094684 seconds.

That's pretty close. The only real gain I would expect from adding
integers instead of doubles is the smaller memory size. Which effect
is eliminated when you choose scalars instead of matrices. I expect
modern processors manage to add two doubles in equivalent time to two
integers.

But MATLAB also does saturated arithmetic on integers, so there will
be an additional comparison for integer arithmetic.


If speed is an issue for you, you might consider "using matrix
calculation", which would probably help.


--
Peter Boettcher <boettcher@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/

Peter,

from the release notes of R14 I learn:

"Integer Arithmetic. You can now combine numbers of an integer data
type with numbers of the same integer data type or type scalar
double. MATLAB performs arithmetic as if both inputs had type double
and then converts the result to the same integer data type."

I call this an unnecessarily complicated statement, because after
reading it three times, I understand that the following is meant:

"Matlab does all arithmetic in double, regardless of the input types.
It handles the conversion for you."

Which requires two lines instead of five, and does not camouflage
the fact that integer arithmetic is not implemented.

My statement about speed is not an assertion, but based on tests like
the following (please note these are not scripts):

function speed_int
a = int32(5);
b = int32(1);
for k = 1:1e7
   a = a+b;
end

function speed_double
a = 5;
b = 1;
for k = 1:1e7
   a = a+b;
end

>> tic, speed_int, toc
Elapsed time is 0.321482 seconds.
>> tic, speed_double, toc
Elapsed time is 0.095971 seconds.

The OP gave a different example on scalars, so it would perhaps be
better to look into that topic a bit deeper, instead of simply typing

> Is this a question or an assertion? A simple test shows that it is
> not correct:

The conclusion from the different test results, including yours, is
the following for me:

We, as Matlab users, can not really isolate the calculation time from
the time required for reading variables and storing results, whatever
test we conduct (matrix or loop). Therefore, int32 is faster when
reading from/writing to memory dominates the execution time, while
the same operation in double is faster when the arithmetic operation
itself dominates.

Thank you for your offer on speeding up my code. I know why I'm here.
I learn a lot, although I'm beyond the usual hints for vectorization
or preallocation. But my simulations easily eat up every improvement
I can get, because it's always useful to refine the models. So I
don't want to choose between one type of improvement or another, I
need all of them - on top of the high efficiency of programming in
Matlab. So I still think it is misleading to say your system supports
integer *arithmetic* if all calculations are performed in double.

Heinrich

----------------------------------------
Peter Boettcher <boettcher@ll.mit.edu> writes:
> But MATLAB also does saturated arithmetic on integers, so there will
> be an additional comparison for integer arithmetic.

That depends on the platform. Some Pentium instruction sets provide for
saturated arithmetic directly, and MATLAB uses those if possible.

--
Steve Eddins

Development Manager, Image Processing Group
The MathWorks, Inc.

I also agree with Heinrich. When everything is doing in double
precision then whats the point in telling that we support integer
arithmatic.
My project is to simulate the Hardware algorithm in fixed point m
program. I have to compare the both the results. If matlab does
internally every thing in double precision and out put integer value,
I might get totally different results. So that was my concern.
Regards,
Naresh
Heinrich Acker wrote:
>
>
> Peter,
>
> from the release notes of R14 I learn:
>
> "Integer Arithmetic. You can now combine numbers of an integer
> data
> type with numbers of the same integer data type or type scalar
> double. MATLAB performs arithmetic as if both inputs had type
> double
> and then converts the result to the same integer data type."
>
> I call this an unnecessarily complicated statement, because after
> reading it three times, I understand that the following is meant:
>
> "Matlab does all arithmetic in double, regardless of the input
> types.
> It handles the conversion for you."
>
> Which requires two lines instead of five, and does not camouflage
> the fact that integer arithmetic is not implemented.
>
> My statement about speed is not an assertion, but based on tests
> like
> the following (please note these are not scripts):
>
> function speed_int
> a = int32(5);
> b = int32(1);
> for k = 1:1e7
> a = a+b;
> end
>
> function speed_double
> a = 5;
> b = 1;
> for k = 1:1e7
> a = a+b;
> end
>
>>> tic, speed_int, toc
> Elapsed time is 0.321482 seconds.
>>> tic, speed_double, toc
> Elapsed time is 0.095971 seconds.
>
> The OP gave a different example on scalars, so it would perhaps be
> better to look into that topic a bit deeper, instead of simply
> typing
>
>> Is this a question or an assertion? A simple test shows that it
> is
>> not correct:
>
> The conclusion from the different test results, including yours, is
> the following for me:
>
> We, as Matlab users, can not really isolate the calculation time
> from
> the time required for reading variables and storing results,
> whatever
> test we conduct (matrix or loop). Therefore, int32 is faster when
> reading from/writing to memory dominates the execution time, while
> the same operation in double is faster when the arithmetic
> operation
> itself dominates.
>
> Thank you for your offer on speeding up my code. I know why I'm
> here.
> I learn a lot, although I'm beyond the usual hints for
> vectorization
> or preallocation. But my simulations easily eat up every
> improvement
> I can get, because it's always useful to refine the models. So I
> don't want to choose between one type of improvement or another, I
> need all of them - on top of the high efficiency of programming in
> Matlab. So I still think it is misleading to say your system
> supports
> integer *arithmetic* if all calculations are performed in double.
>
> Heinrich

Hi Heinrich and Naresh.

The overly complicated statement in the doc, as pointed out by Peter
Boettcher, applies to mixed integer-double operations.

In addition, as pointed out by others, the saturating model on overflow
makes for slower execution of integer arithmetic particularly at the command
line where there are no optimizations.

However, as pointed out by Steve Eddins, when you do the kind of vectorized
math that MATLAB is known for on strict integr operations, we use
optimizations including hardware specific calls to perform the saturating
integer arithmetic as quickly as possible.

These days MATLAB is a complicated beast, optimized in many different ways.
If you try to benchmark at the command line on an isolated scalar, you're
not going to get optimal results.

If you are trying to simulate fixed point hardware, integer arithmetic in
MATLAB is no the way to go. Try the Fixed Point Toolbox.

Penny Anderson
The MathWorks, Inc.

"naresh" <naresh.bajaj@gmail.com> wrote in message
news:ef189a6.6@webx.raydaftYaTP...
>I also agree with Heinrich. When everything is doing in double
> precision then whats the point in telling that we support integer
> arithmatic.
> My project is to simulate the Hardware algorithm in fixed point m
> program. I have to compare the both the results. If matlab does
> internally every thing in double precision and out put integer value,
> I might get totally different results. So that was my concern.
> Regards,
> Naresh
> Heinrich Acker wrote:
>>
>>
>> Peter,
>>
>> from the release notes of R14 I learn:
>>
>> "Integer Arithmetic. You can now combine numbers of an integer
>> data
>> type with numbers of the same integer data type or type scalar
>> double. MATLAB performs arithmetic as if both inputs had type
>> double
>> and then converts the result to the same integer data type."
>>
>> I call this an unnecessarily complicated statement, because after
>> reading it three times, I understand that the following is meant:
>>
>> "Matlab does all arithmetic in double, regardless of the input
>> types.
>> It handles the conversion for you."
>>
>> Which requires two lines instead of five, and does not camouflage
>> the fact that integer arithmetic is not implemented.
>>
>> My statement about speed is not an assertion, but based on tests
>> like
>> the following (please note these are not scripts):
>>
>> function speed_int
>> a = int32(5);
>> b = int32(1);
>> for k = 1:1e7
>> a = a+b;
>> end
>>
>> function speed_double
>> a = 5;
>> b = 1;
>> for k = 1:1e7
>> a = a+b;
>> end
>>
>>>> tic, speed_int, toc
>> Elapsed time is 0.321482 seconds.
>>>> tic, speed_double, toc
>> Elapsed time is 0.095971 seconds.
>>
>> The OP gave a different example on scalars, so it would perhaps be
>> better to look into that topic a bit deeper, instead of simply
>> typing
>>
>>> Is this a question or an assertion? A simple test shows that it
>> is
>>> not correct:
>>
>> The conclusion from the different test results, including yours, is
>> the following for me:
>>
>> We, as Matlab users, can not really isolate the calculation time
>> from
>> the time required for reading variables and storing results,
>> whatever
>> test we conduct (matrix or loop). Therefore, int32 is faster when
>> reading from/writing to memory dominates the execution time, while
>> the same operation in double is faster when the arithmetic
>> operation
>> itself dominates.
>>
>> Thank you for your offer on speeding up my code. I know why I'm
>> here.
>> I learn a lot, although I'm beyond the usual hints for
>> vectorization
>> or preallocation. But my simulations easily eat up every
>> improvement
>> I can get, because it's always useful to refine the models. So I
>> don't want to choose between one type of improvement or another, I
>> need all of them - on top of the high efficiency of programming in
>> Matlab. So I still think it is misleading to say your system
>> supports
>> integer *arithmetic* if all calculations are performed in double.
>>
>> Heinrich

Penny,

I would be glad if you would read my post completely. I did not do my
tests on the command line, but by calling functions. So I'm using all
the fine optimizations. Result: the same operation is faster on
doubles compared to int32 when using scalars.

It is obvious from this result that integer arithmetic is not
implemented, since int32+int32 is a single machine operation on all
platforms of interest. Nothing is faster, and Peter's statement that
a double+double is as fast, is simply wrong, because the FPU has to
compare the exponent, shift one mantissa and *then* add the
mantissas. On a Pentium 4 for example, this takes 5 machine cycles
compared to one for int32 (some sources even explain that the integer
ALU can do two operations per cycle).

I have to add that not all algorithms can be vectorized, since the
vectorization police is never far away in this group. So
vectorization is not a general way to optimize, it depends on the
application.

Since the tests on scalar variables with otherwise identical code
*prove* that integer operations are slower in Matlab, I don't want to
be fooled by the statement that there is integer arithmetic. The docs
for a complicated software can only work if language is used
precisely, and type conversion is not arithmetic. Instead, I would
like to know if The Mathworks has any plans to implement the
advertised integer arithmetic. It shouldn't be that difficult.

Heinrich

"Heinrich Acker" <Firstname.Lastname@web.de> writes:

> Penny,
>
> I would be glad if you would read my post completely. I did not do my
> tests on the command line, but by calling functions. So I'm using all
> the fine optimizations. Result: the same operation is faster on
> doubles compared to int32 when using scalars.
>
> It is obvious from this result that integer arithmetic is not
> implemented, since int32+int32 is a single machine operation on all
> platforms of interest. Nothing is faster, and Peter's statement that
> a double+double is as fast, is simply wrong, because the FPU has to
> compare the exponent, shift one mantissa and *then* add the
> mantissas. On a Pentium 4 for example, this takes 5 machine cycles

*plonk*

--
Peter Boettcher <boettcher@ll.mit.edu>
MIT Lincoln Laboratory
MATLAB FAQ: http://www.mit.edu/~pwb/cssm/

You can rest assured that we are working hard to give you the best quality
software. Performance issue is definitely high on the list.

I agree that the performance of the integer for-loop is not as good as the
double one. But saying that this is due to lack of true integer
implementation is not exactly correct either. As Penny pointed out, this is
more likely due to the lack of optimizations in some area.

MATLAB has been working in double precision floating point arithmetic for
more than 20 years. There were a lot of optimization methods introduced for
double only in the past. With the introduction of the integer arithmetic in
R14, our first goal is to provide a useful subset of integer math for our
customer. Based on valuable feedback like yours, we are now catching up not
just on performance but also in functionality. I cannot tell you the exact
timeline for all these. But I can tell you that we are working very hard in
improving our products.

Out of my curiosity, does our round-and-saturate model works for you? You
seem to want the standard C truncate-and-wrap integer arithmetic. If this is
the case, you should look at the Fixed Point Toolbox as suggested by Penny.

Bobby Cheng
Numerical Analyst
The MathWorks, Inc.

"Heinrich Acker" <Firstname.Lastname@web.de> wrote in message
news:ef189a6.8@webx.raydaftYaTP...
> Penny,
>
> I would be glad if you would read my post completely. I did not do my
> tests on the command line, but by calling functions. So I'm using all
> the fine optimizations. Result: the same operation is faster on
> doubles compared to int32 when using scalars.
>
> It is obvious from this result that integer arithmetic is not
> implemented, since int32+int32 is a single machine operation on all
> platforms of interest. Nothing is faster, and Peter's statement that
> a double+double is as fast, is simply wrong, because the FPU has to
> compare the exponent, shift one mantissa and *then* add the
> mantissas. On a Pentium 4 for example, this takes 5 machine cycles
> compared to one for int32 (some sources even explain that the integer
> ALU can do two operations per cycle).
>
> I have to add that not all algorithms can be vectorized, since the
> vectorization police is never far away in this group. So
> vectorization is not a general way to optimize, it depends on the
> application.
>
> Since the tests on scalar variables with otherwise identical code
> *prove* that integer operations are slower in Matlab, I don't want to
> be fooled by the statement that there is integer arithmetic. The docs
> for a complicated software can only work if language is used
> precisely, and type conversion is not arithmetic. Instead, I would
> like to know if The Mathworks has any plans to implement the
> advertised integer arithmetic. It shouldn't be that difficult.
>
> Heinrich

Bobby Cheng wrote:
>
> You can rest assured that we are working hard to give you the best
> quality
> software. Performance issue is definitely high on the list.

Sometimes in a controversial thread, the positive things are not
mentioned at all. So let me add that you are definitely successful in
delivering a high quality product - one that is worth to be improved!

And yes, MATLAB's performance in double precision floating point
arithmetic is very good, especially for an interpreted language that
has a lot to do during execution, due to the freedom not to declare
variables and to change their type and size dynamically.

It's very good to read that you are active in improving the integer
performance.

> I agree that the performance of the integer for-loop is not as good
> as the
> double one. But saying that this is due to lack of true integer
> implementation is not exactly correct either. As Penny pointed out,
> this is
> more likely due to the lack of optimizations in some area.

I believe you, but I cannot understand it really. After preparing the
execution of a arithmetic operation by branching for type and size,
three things have to be done for a scalar:

1. read the operands: one step per operand for int32, two for double
on a modern 32bit processor
2. do the arithmetic: faster for integer if the integer ALU is used,
as I pointed out before
3. store the result: like step 1 - less to do for int32

So if all three steps are faster for int32, how can the whole thing
be slower - if not because of the detour of doing conversions? Please
explain if it is possible to disclose this.

> Out of my curiosity, does our round-and-saturate model works for
> you? You
> seem to want the standard C truncate-and-wrap integer arithmetic.
> If this is
> the case, you should look at the Fixed Point Toolbox as suggested
> by Penny.

My applications would benefit from fast integer arithmetic,
regardless of the model. I just seek for speed in general Matlab
programs, which usually can't tolerate saturate or truncate either.
Only in cases where the int32 range is sufficient, integer can work
for me. One important example are index variables. Another the data
that comes from digitizers with 16 or 24 bit at most.

I have no opinion on which model to choose, if only one is possible,
but I read very good reasons backing both of them. So the natural
solution for a general-purpose tool would be a switch for it. I guess
the challenge would be to implement this without a performance
sacrifice. What do you think about a startup option? That way, you
could support both models, but avoid a performance sacrifice, because
only code for the chosen model would be loaded into memory. Of
course, another is*-function is also needed then.

Peter Boettcher wrote:
>
> *plonk*

Honestly, I would like to know what that means, I'm clueless! My
dictionary says 'cheap wine', which doesn't seem to make much sense
here...

Heinrich

Heinrich Acker wrote:
<SNIP>

 
> Peter Boettcher wrote:
>>
>> *plonk*
>
> Honestly, I would like to know what that means, I'm
> clueless! My dictionary says 'cheap wine', which doesn't
> seem to make much sense here...
>
> Heinrich

*plonk* usually means that the poster that gets plonked (plonkee?),
in this case you, get included in the plonkers newsreader kill file.
This means that your future messages don´t display in his reader or
that they are flagged as nonsense/spam.

/PB

PB wrote:
>
>
> Heinrich Acker wrote:
> <SNIP>
>
>
>> Peter Boettcher wrote:
>>>
>>> *plonk*
>>
>> Honestly, I would like to know what that means, I'm
>> clueless! My dictionary says 'cheap wine', which doesn't
>> seem to make much sense here...
>>
>> Heinrich
>
> *plonk* usually means that the poster that gets plonked (plonkee?),
> in this case you, get included in the plonkers newsreader kill
> file.
> This means that your future messages don´t display in his reader or
> that they are flagged as nonsense/spam.
>
> /PB

Thank you for the explanation. I'm surprised about this attitude from
him - if somebody posts what I don't like - plonk - and my image of
the world remains intact.

Heinrich

Heinrich Acker wrote:
>
> PB wrote:
> >
...
> > *plonk* usually means that the poster that gets plonked (plonkee?),
> > in this case you, get included in the plonkers newsreader kill
> > file.
....
> Thank you for the explanation. I'm surprised about this attitude from
> him - if somebody posts what I don't like - plonk - and my image of
> the world remains intact.
 
I think it was an apparent attitude problem...an apparent attitude of
your knowing better than TMW of what the internals of Matlab "must" be
doing...perhaps not intended, but it is sure easy to read it that way.

Hello Heinrich,
Let me try to answer your question as to why scalar int performance is
sometimes slower than double scalar performance. To put it simply,
MATLAB integer math is *not* equivalent to C/C++ integer math, you can't
reasonably compare the two. MATLAB integer math performs saturation on
its results and C/C++ does not, i.e. values that are out of range for
that particular int type are saturated to be the min or max value for
that type. I'll try to explain in detail what is going on, but to make
the answer simpler I will only discuss what happens for addition on
Intel/AMD platforms.

1. For addition on int8, uint8, int16 and uint16 values, MATLAB uses MMX
instructions to perform saturated arithmetic. For int32 and uint32
addition there is custom integer assembly code.

2. The MMX registers used to perform int operations are either 64 or 128
bits depending on what your particular CPU supports. So, for example,
this means that you can add 8 (or 16) 8-bit integers in one instruction.
Also, loading or storing an MMX register to memory is special optimized
instruction on the Intel architecture. These are two of the reasons
vectorized integer operations can be so fast. Now, if you are doing a
single scalar operation you will be under utilizing the MMX registers.
There is no way to just load a single 8 bit value into an MMX register.
  You have to perform the operation on the entire register width and
then throw away the parts you don't care about.

3. In addition to #2, MMX performance can depend on whether memory is 16
byte aligned or not. There is no way to guarantee this alignment in the
general case. So, your performance may vary depending on whether your
scalar value happened to be allocated on a 16 byte aligned block of
memory or not. Even 8-byte alignment sometimes matters for regular
memory access and is generally faster than non-8-byte aligned loads and
stores.

4. For the non-MMX code (i.e. int32 and uint32), the custom assembly is
not a single integer addition instruction. It must first add the two
numbers and then do the saturation check. For unsigned integers this is
about 5 instructions and more like 10 for signed integers. Scalar
floating point addition is done with a single floating point
instruction. But, due to the way modern CPUs are pipelined, code
alignment, caching, etc. you can't really say a particular instruction
always takes N cycles. You can't just add up instruction counts to make
a comparison. If you are really curious take a look at the following
document to see how complicated the issues are (this is the optimization
manual for Pentium 4 straight from Intel):

ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf

I hope this addressed your concerns.

Thanks,
Bill Nell

Heinrich Acker wrote:
> Bobby Cheng wrote:
>
>>You can rest assured that we are working hard to give you the best
>>quality
>>software. Performance issue is definitely high on the list.
>
>
> Sometimes in a controversial thread, the positive things are not
> mentioned at all. So let me add that you are definitely successful in
> delivering a high quality product - one that is worth to be improved!
>
> And yes, MATLAB's performance in double precision floating point
> arithmetic is very good, especially for an interpreted language that
> has a lot to do during execution, due to the freedom not to declare
> variables and to change their type and size dynamically.
>
> It's very good to read that you are active in improving the integer
> performance.
>
>
>>I agree that the performance of the integer for-loop is not as good
>>as the
>>double one. But saying that this is due to lack of true integer
>>implementation is not exactly correct either. As Penny pointed out,
>>this is
>>more likely due to the lack of optimizations in some area.
>
>
> I believe you, but I cannot understand it really. After preparing the
> execution of a arithmetic operation by branching for type and size,
> three things have to be done for a scalar:
>
> 1. read the operands: one step per operand for int32, two for double
> on a modern 32bit processor
> 2. do the arithmetic: faster for integer if the integer ALU is used,
> as I pointed out before
> 3. store the result: like step 1 - less to do for int32
>
> So if all three steps are faster for int32, how can the whole thing
> be slower - if not because of the detour of doing conversions? Please
> explain if it is possible to disclose this.
>
>
>>Out of my curiosity, does our round-and-saturate model works for
>>you? You
>>seem to want the standard C truncate-and-wrap integer arithmetic.
>>If this is
>>the case, you should look at the Fixed Point Toolbox as suggested
>>by Penny.
>
>
> My applications would benefit from fast integer arithmetic,
> regardless of the model. I just seek for speed in general Matlab
> programs, which usually can't tolerate saturate or truncate either.
> Only in cases where the int32 range is sufficient, integer can work
> for me. One important example are index variables. Another the data
> that comes from digitizers with 16 or 24 bit at most.
>
> I have no opinion on which model to choose, if only one is possible,
> but I read very good reasons backing both of them. So the natural
> solution for a general-purpose tool would be a switch for it. I guess
> the challenge would be to implement this without a performance
> sacrifice. What do you think about a startup option? That way, you
> could support both models, but avoid a performance sacrifice, because
> only code for the chosen model would be loaded into memory. Of
> course, another is*-function is also needed then.
>
> Peter Boettcher wrote:
>
>>*plonk*
>
>
> Honestly, I would like to know what that means, I'm clueless! My
> dictionary says 'cheap wine', which doesn't seem to make much sense
> here...
>
> Heinrich

@Bill:

Thank you very much for your answer. If it is primarily the
saturation that makes integer arithmetic slow, please consider to
make saturation an option. It's a pity if the performance is limited
for all programs by a feature that is only useful for some.

@Duane:

I'm not proud of everything I wrote in this thread. The topic is
important for me, but many things went wrong. The problem was that I
wanted to keep this alive until a real answer comes in. However, in
the posts before the real answer, I was told that:

- the issue does not exist
- that I have to be grateful for the integer support that others find
useful
- that modern processors manage to add two doubles in equivalent time
to two integers (which is wrong for the pentium 4 according to intel
sources, and does not contradict Bill's reply, as Peter and I were
both talking about the add operation itself)
- that I don't have to benchmark at the command line (after posting
an example with functions)

My failure is that I did not manage to insist on a real answer with
the minimum of impoliteness and provocation. Sorry for that, it's
difficult in a foreign language.

Concerning the attitude: Peter placed his *plonk* not at the point
where I write about Matlabs integer implementation, but where I wrote
that his assumption on integer vs. double add is wrong. So if
somebody tells you one of your assumptions is wrong, simply plonk him
out of your world. That's an attitude the scientific world does not
need at all.

In article <ef189a6.16@webx.raydaftYaTP>,
 "Heinrich Acker" <Firstname.Lastname@web.de> wrote:

> Concerning the attitude: Peter placed his *plonk* not at the point
> where I write about Matlabs integer implementation, but where I wrote
> that his assumption on integer vs. double add is wrong. So if
> somebody tells you one of your assumptions is wrong, simply plonk him
> out of your world. That's an attitude the scientific world does not
> need at all.

I was also getting tired of your assertions that mathworks
employees were essentially lying about what was in their
own product. This is what you told Penny, who tends to
know what she is talking about as a Mathworks employee.
It appeared to be verging on a rant.

I imagine others besides me and Peter were also feeling
frustration. He expressed his opinion on how to handle a
rant.

John


--
The best material model of a cat is another, or preferably the same, cat.
A. Rosenblueth, Philosophy of Science, 1945

Those who can't laugh at themselves leave the job to others.
Anonymous