There is an interesting but rarely mentioned technique in a C++ context: signature-based polymorphism, a more permissive variation of subtype polymorphism, usually called duck typing. Two objects having nothing in common can share an implicit interface and be commonly manipulated by such an interface with no inheritance involved. Part I and Part II. Also, making use of SIMD units such as MMX, SSE, or AltiVec is usually a tradeoff of portability for speed. Recent versions of GCC include an extension that allows you to write vector code without sacrificing portability. Take a look at how to use it.
C++ Polymorphism; Vector Programming with GCC
2007-04-22 General Development 8 Comments
1) Quote from that article:
return vec_all_eq((vector int)v1, (vector int)v2);
v4si compare = __builtin_ia32_cmpeqps((v4sf)v1, (v4sf)v2);
Indeed, very good portability has been achieved…
2) Moreover on MIPS you MUST declare vector of size 4bytes (not 16 as in intel/ppc) and gcc is dumb enough not to split 16 byte vector into 4 vec operations, but it does 16 non-vector ops, so add #ifdef MIPS to that
_portable_ piece of code….
Both articles contain errors :/.
The first one states that by ‘mimicking a v-table’ one can get something that is ‘fast due to inlining’. This is completely wrong – there will only be possibility of inlining in case of trivial code, e.g. when the call is made in the block in which the object has been constructed. In other cases one usually cannot avoid making an indirect call using the function pointers – which is exactly the same as a virtual function would do.
The second article states that comparing integers is practically the same as comparing floats. This is also wrong – a NaN is not equal to anything, even to itself. If you want to compare an integer that happens to correspond to a NaN, you’re out of luck.
Edit: These articles are very interesting otherwise.
Edited 2007-04-22 10:48
there is a library that works like that: macstl
but I think it’s not improved anymore :/
What’s sad about most of these “vector” ops is that they work mostly with 32bit floats.
Test our code at work with standard x86 floating point instructions we get faster optimzed executable code using doubles vs floats on 32bit, with 64bit being dramatically faster with doubles compared to floats.
The biggest problem is that we need to maintain precision normally to between 1e-8 to 1e-10 (normalized data sets)
Perhaps the next gen vector instructions will help more with scientific type applications.
Right now what holds back actually deploying apps using 64bit vectorized floats are the number of older gen socket 940 (and 754) machines out there that only have SSE2 support.
Edited 2007-04-23 13:28