Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Functions optimized for doubles only

Subject: Functions optimized for doubles only

From: Matt

Date: 6 Mar, 2009 17:05:03

Message: 1 of 5

I sometimes find that certain functions are optimized for type double data only.
For example, in the following, summation using doubles as considerably faster than for uint32.

 a=uint32(rand(3000)<.5);
tic;n1=sum(a(:),'double');toc,
tic;n2=sum(a(:),'native');toc,
Elapsed time is 0.026064 seconds.
Elapsed time is 0.086038 seconds.

I would expect the opposite since uint32 is both of shorter word length and also (I think) because floating point summations are more complex than integer summations.

I find this with other functions too such as permute(). It is faster to convert a type single array to doubles first and then apply permute than to to apply permute directly to the original type-single data.

Does anyone know how these things come about? I thought that MATLAB had migrated to C++ some time ago. If so, shouldn't it be possible to template the argument data types to all of the various functions and thus simultaneously optimize the functions for all data types?

Subject: Functions optimized for doubles only

From: James Tursa

Date: 6 Mar, 2009 19:52:01

Message: 2 of 5

"Matt " <xys@whatever.com> wrote in message <gorl3v$44g$1@fred.mathworks.com>...
> I sometimes find that certain functions are optimized for type double data only.
> For example, in the following, summation using doubles as considerably faster than for uint32.
>
> a=uint32(rand(3000)<.5);
> tic;n1=sum(a(:),'double');toc,
> tic;n2=sum(a(:),'native');toc,
> Elapsed time is 0.026064 seconds.
> Elapsed time is 0.086038 seconds.
>
> I would expect the opposite since uint32 is both of shorter word length and also (I think) because floating point summations are more complex than integer summations.
>
> I find this with other functions too such as permute(). It is faster to convert a type single array to doubles first and then apply permute than to to apply permute directly to the original type-single data.
>
> Does anyone know how these things come about? I thought that MATLAB had migrated to C++ some time ago. If so, shouldn't it be possible to template the argument data types to all of the various functions and thus simultaneously optimize the functions for all data types?

First, for your particular example, the 'native' option has to do a lot of extra work that you are not considering. For example, consider this:

>> a = [100 100 -100]
a =
   100 100 -100
>> u = int8(a)
u =
  100 100 -100
>> sum(u)
ans =
   100
>> sum(u,'native')
ans =
   27

The sum of the numbers is clearly 100 + 100 - 100 = 100, right? So what happened with the 'native' calculation? Why did it get 27? That is because MATLAB does not do modulo arithmetic with the integer classes, it does max & min value clipping. So the 'native' option forces MATLAB to check every single intermediate result for overflow to see if clipping is warranted. i.e., the 'native' option is doing something like this:

int8(double(int8(double(100) + double(100))) + double(-100))

The result of the first add is 200, which gets clipped to 127, then subtract 100 to get 27 as the final answer.

That's a lot more work than just

double(100) + double(100) - double(100)

Second, in general don't assume that an integer operation is faster than a double operation just because it is integer vs floating point, shorter, etc. That is highly platform dependent. E.g., on a modern PC with numeric co-processing for 80-bit extended precision available at the bit level, you can find that a simple floating point addition is actually faster than a 32-bit integer addition.

Third, I suspect that MATLAB does a lot of integer class operations actually as double in the background, saving them from building a complete suite of library functions for all of the individual types. So just because variables are integer class, I would not assume (in MATLAB, anyway) that the background calculations are actually done as integers like you would expect in C or C++.

James Tursa

Subject: Functions optimized for doubles only

From: Matt

Date: 6 Mar, 2009 20:17:01

Message: 3 of 5

"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in message <gorut1$f2v$1@fred.mathworks.com>...

> Third, I suspect that MATLAB does a lot of integer class operations actually as double in the background, saving them from building a complete suite of library functions for all of the individual types.

But again, why would they need to do that? If MATLAB is using C++ under the hood, couldn't they use C++ generic functions to handle all the types? Or would that make the software too huge?

Subject: Functions optimized for doubles only

From: Doug Schwarz

Date: 6 Mar, 2009 21:52:39

Message: 4 of 5

In article <gos0bt$rrc$1@fred.mathworks.com>,
 "Matt " <xys@whatever.com> wrote:

> "James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in message
> <gorut1$f2v$1@fred.mathworks.com>...
>
> > Third, I suspect that MATLAB does a lot of integer class operations
> > actually as double in the background, saving them from building a complete
> > suite of library functions for all of the individual types.
>
> But again, why would they need to do that? If MATLAB is using C++ under the
> hood, couldn't they use C++ generic functions to handle all the types? Or
> would that make the software too huge?


What makes you think that any of the numerical computations were
programmed in C++? It is more likely that they are farmed out to
libraries that were written in Fortran. Furthermore, those libraries
were (mostly, at least) not written by TMW.

I'm far from an expert in C++ or Fortran, but my impression is that
Fortran is much faster for these things than C++ (something to do with
multiple pointers that can point to the same memory and how that affects
code optimization possibilities, if I understand correctly).

--
Doug Schwarz
dmschwarz&ieee,org
Make obvious changes to get real email address.

Subject: Functions optimized for doubles only

From: James Tursa

Date: 7 Mar, 2009 09:31:00

Message: 5 of 5

"Matt " <xys@whatever.com> wrote in message <gos0bt$rrc$1@fred.mathworks.com>...
> "James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in message <gorut1$f2v$1@fred.mathworks.com>...
>
> > Third, I suspect that MATLAB does a lot of integer class operations actually as double in the background, saving them from building a complete suite of library functions for all of the individual types.
>
> But again, why would they need to do that? If MATLAB is using C++ under the hood, couldn't they use C++ generic functions to handle all the types?

No. I don't know if you are aware of this, but even C/C++ intrinsic operators do not operate on all of the C/C++ intrinsic integer types. Basically, everything shorter than an int gets converted to an int before *any* of the arithmetic operations takes place. This is called the "usual unary and binary conversions" in the language. For example, take these simple code snippets:

unsigned char uc;
// Case (1)
uc = 1;
uc = -uc;
if( uc < 0 ) {
    printf("uc is negative\n");
} else {
    printf("uc is non-negative\n");
}
// Case (2)
uc = 1;
if( -uc < 0 ) {
    printf("-uc is negative\n");
} else {
    printf("-uc is non-negative\n");
}

For Case 1, uc starts out with a value of 1. The -uc operation is actually carried out as follows:

uc = (unsigned char) ( - ((int) uc) );

So first uc gets converted to an int 1, then the unary minus takes place to give -1, then the result gets converted back to an unsigned char, which with the modulo requirements of the conversion gives 255. So the result of the first if-test fails and the message printed is "non-negative".

For Case 2, however, the test is carried out as follows:

if( ( - ((int) uc) ) < 0 ) {

So first uc gets converted to an int 1, then the unary minus takes place to give -1, then the test is done. This time the test is true so the "negative" message is printed.

The above example was for unary minus, but this conversion happens for all the intrinsic arithmetic operations.

Bottom line, there are no fundamental operations available in C/C++ for many of the smaller intrinsic integer types, so expecting MATLAB to somehow use them in the background for calculations on each individual integer class just because MATLAB was built with C/C++ is not reasonable.

James Tursa

Tags for this Thread

No tags are associated with this thread.

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us