"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 typesingle 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 coprocessing for 80bit extended precision available at the bit level, you can find that a simple floating point addition is actually faster than a 32bit 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
