   intrinsics?
  I've been writing my own math library, just to brush up on my linear algebra and learn some stuff, and when looking up info on some more efficient math algorithms,  I came across intrinsic functions, and I've been reading a bit about them.  I also read on the MSDN site that there are intrinsic versions of functions like memcpy().  Are these commonly used?  Are there any downsides?  and do you have to register these types of instrinsic functions with the compiler before you use them? Also, are there any good articles or resources on intrinsic functions, and how they work?  Thanks   
Quote:Original post by godsenddeathAre these commonly used? yes, everywhere....  Quote:Original post by godsenddeathAre there any downsides?  nope (obviously be careful of memory alignment as you would with asm). Well that's not strictly true. There are two common problems with intrinsics:1. Portability. They only work for Intel processors (although there are equivalents for other architectures, eg PowerPC, or Intel AVX). 2. You have a compiler that isn't great at optimising intrinsics (eg VC2005). In the case of 1, you can probably ignore that unless you are worried about iPhone development. I have to say though that porting a fully working math lib written in SSE intrinsics to altivec intrinsics for PS3/360 isn't that difficult.... For 2, I've only seen people complaining about VC2005, and most of the people making the complaints are usually sorely lacking in their understanding of how the processor works. For example, the most common complaint is that the compiler will not under any circumstances make use of more than half the registers available. The reality is that if you make use of more than half the registers, then Hyper-Threading can't work. The rule of thumb is to be extremely sceptical if people say compiler X produces in-efficient intrinsic code..... Also be careful if you are targetting the ATOM processor. A lot of the SSE2 double precision funcs are slower than simply using the FPU.... Quote:Original post by godsenddeathand do you have to register these types of instrinsic functions with the compiler before you use them? You can't register intrinsics. Typically you are locked to whatever the compiler supports. VC2008, icc and gcc all support upto SSE4.1; VC2005 upto SSE2.Quote:Original post by godsenddeathAlso, are there any good articles or resources on intrinsic functions, and how they work?  MSDN describes all of the intrinsics, as do the Intel compiler docs. For more info on *how* they work, you really should be asking how the CPU works - in which case consult the Intel CPU programming and optimisation guides.   ;Quote:Original post by godsenddeathAre there any downsides? The downsides are that the compiler must support them.. and usually harder to understand. Another downside is they may not get improved performance an all machines.If a function uses intrinsics for MMX processors, processors without them could incur a penalty, depending on how the function was implemented. To be honest intrinsic functions are really only used at lower levels of math.. if you want to do symbolic or dynamic you probably won't go near intrinsic functions.   ;Quote:Original post by TntrickerQuote:Original post by godsenddeathAre there any downsides? The downsides are that the compiler must support them.. Intel, gcc and VC++ does support them. If you are not using one of those compilers, you need to get help.... Quote:Original post by TntrickerAnother downside is they may not get improved performance an all machines.Such as? __m128 add2(__m128 a, __m128 b){  return _mm_add_ps(a,b);}On every compiler that supports intrinsics, that still adds 4 pairs of numbers together faster than the FPU can. Care to qualify that statement further? Quote:Original post by TntrickerIf a function uses intrinsics for MMX processors, processors without them could incur a penalty, depending on how the function was implemented.Correction. It would crash a 286/386/486DX, and some very early pentium CPU's that did not have MMX. IIRC, should work fine on more or less every processor after the 166 pentium from 1995 or so.... Secondly, we are living in an age of 64bit computing. Why would anyone want to write MMX code anymore when SSE2 is now the guaranteed base line? What's wrong with SSE and SSE2 exactly?Quote:Original post by TntrickerTo be honest intrinsic functions are really only used at lower levels of math.. if you want to do symbolic or dynamic you probably won't go near intrinsic functions.TO be honest, the OP wants to use intrinsics to write low level math routines concerned with linear algebra. By every conceivable measurement, that's the ideal time for intrinsics to be used.....   ;  Thanks a lot, that's pretty much all I needed to know.   ;Quote:Original post by RobTheBlokeIntel, gcc and VC++ does support them. If you are not using one of those compilers, you need to get help.... They do support them but they don't support the same set across all versions of their compilers also the functions may have different names etc.. (I can't think of any that don't but it still possible)Quote:Original post by TntrickerAnother downside is they may not get improved performance an all machines.Quote:Original post by RobTheBlokeOn every compiler that supports intrinsics, that still adds 4 pairs of numbers together faster than the FPU can. Care to qualify that statement further? Correction. It would crash a 286/386/486DX, and some very early pentium CPU's that did not have MMX. IIRC, should work fine on more or less every processor after the 166 pentium from 1995 or so.... your right.. it was lack of an implementation understanding on my part. I was thinking some of the SIMD intrinsics had fallback functions if the compile target didn't support the SIMD opcodes. Apparently it's just common to do so in applications that use intrinsics. "Another downside is they may not get improved performance an all machines" <- I was thinking about 80-bit floats.. but since there are no fallback functions it doesn't matter.http://ds9a.nl/gcc-simd/fp-simd-builtins.html"They will not gracefully fall back to regular floating point instructions, nor will they work on a different CPU from for which they were intended." *notedQuote:Original post by RobTheBlokeSecondly, we are living in an age of 64bit computing. Why would anyone want to write MMX code anymore when SSE2 is now the guaranteed base line? What's wrong with SSE and SSE2 exactly?nothing is wrong with SSE2 or SSE3 or SSE4 or SSE5 or any of the various other  opcodes extensions they've come up with.. it was just the first that came to mind.   