ICC bypass or how to keep dirty monopolist at bay. back

(L) [2006/05/18] [tbp] [ICC bypass or how to keep dirty monopolist at bay.] Wayback!

ICC, depending on options, may sprinkle your binaries with various checks trying to cripple the competion; the end result is either lower than expected performance or a binary refusing to run for no good reason:

(L) [2006/05/18] [toxie] [ICC bypass or how to keep dirty monopolist at bay.] Wayback!

Is this only needed when not specifying a certain CPU architecture to compile for?! (for Linux: -mcpu & -march)

(cause otherwise it didn't change a thing on the Opteron here)

(L) [2006/05/18] [tbp] [ICC bypass or how to keep dirty monopolist at bay.] Wayback!

Hmm. It allows to run code compiled exclusively for one architecture on the equivalent AMD chip by fooling retarded checkings (and to avoid being served crappy version of overloaded runtime libc/etc routines).


From the doc for Qax (compare that to Qx)

(L) [2006/05/20] [tbp] [ICC bypass or how to keep dirty monopolist at bay.] Wayback!

I've run a little experiment with my sphere flake thingy on win32 that shows i'm objectively not completly full of it; as i've used the original version, delta are not very large as a large part of the time is spent in the output and so on. Anyway results are stable so comparing them is legit.


Best of 3 runs:

(L) [2006/05/20] [Lynx] [ICC bypass or how to keep dirty monopolist at bay.] Wayback!

Uhm...do i understand correctly that QxB and QaxB, both bypassed, should execute the same code?


And i'm surprised GCC 4.2 is that close...though that's Linux i guess? Or does it work that well with Cygwin?

About 3.4...heh...WTF?