On Friday 13 January 2006 14:24, Trenton Adams wrote: > On 1/12/06, John Myers <[EMAIL PROTECTED]> wrote: > > On Thursday 12 January 2006 18:45, Tom Smith wrote: > > > Well, if they're /not/ mutually exclusive, another question that comes > > > up is... > > > > > > If a program is compiled with sse or sse2 support on a Pentium II, will > > > the program run slower than it otherwise would? (Some of the programs I > > > have are compiled and then distributed to servers with different > > > CPUs--P-IIs and P-IVs, mainly.) > > > > If a program uses an instruction that the processor doesn't support, the > > program will be sent SIGILL, the default action of which is to terminate > > immediately. > > Are you absolutely positive of that? I *thought* (would have thought) > compilers these days would compile in conditional use of such > instructions? That way if large blocks could benefit from these new > instructions, they would use them, otherwise fall back to a common set > of instructions. Of course this wouldn't be very beneficial for small > sections of code. I've been wondering about this for quite some time > though, but never bothered to investigate.
I'm not _absolutely_ positive, but to do so would likely result in _slower_ code, maybe breaking even occasionally. Using C/C++ as the language: - blocks of multiply-compiled code can be no larger than a single fuction, as the compiler does not know what other functions call that function, and given current build systems, _cannot_ know. Exceptions: inline functions count where the function is inlined, and file-scope (static) functions can be optimized together, but only if they are only called by other file-scope functions, as the compiler can generate a complete list of callers. - the code must be recalculated and duplicated not just for each technology, but for each meaningful and distinct combination of technologies, meaning more conditionals and more branches (and larger code) - code size plays a large role in program performance. Many people report that gcc -Os often gives faster executables than gcc -O3 - How far back do you want to go? Each generation (and brand) of processors adds new technologies and techniques, and the fastest code for one processor may be the slowest for another. -- # # electronerd, the electronerdian from electronerdia #
pgpIiINz58oPn.pgp
Description: PGP signature
