Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Windows Programming Stats

Speed Test 2: Comparing C++ Compilers On WIndows 132

Nerval's Lobster writes "In a previous posting, developer and programmer Jeff Cogswell compared a few C++ compilers on Linux. Now he's going to perform a similar set of tests for Windows. "Like all things Windows, it can get costly doing C++ development in this environment," he writes. "However, there are a couple notable exceptions" such as free and open-source cygwin, mingW, Express Versions of Visual Studio, and Embacadero. He also matched up the Intel C++ Compiler, Microsoft C++ Compiler, and the Embarcadero C++ 6.70 Compiler. He found some interesting things — for example, Intel's compiler is pretty fast, but its annoying habit of occasionally "calling home" to check licensing information kept throwing off the rests. Read on to see how the compilers matched up in his testing."
This discussion has been archived. No new comments can be posted.

Speed Test 2: Comparing C++ Compilers On WIndows

Comments Filter:
  • by Joe_Dragon ( 2206452 ) on Tuesday November 26, 2013 @02:12PM (#45528839)

    does the Intel one still slow down on AMD systems and or trun out code with AMD slow down blocks?

  • by jameson ( 54982 ) on Tuesday November 26, 2013 @02:16PM (#45528891) Homepage

    Based on his description, he is using a very synthetic benchmark:

    The code I’m testing contains no #include directives, and makes use of only standard C++ code. It starts with one class, and then is followed by 6084 small classes derived from various instantiations of the template classes. (So these 6084 classes are technically not templates themselves.) Then I create 6084 instantiations of the original template class, using each of the 6084 classes. The end result is 6084 different template instantiations. Now, obviously in real life we wouldn’t write like that (at least I hope you don’t).

    So in his own words, the code does not reflect realistic compiles. There is no reason to assume that the result generalise to any programs that anyone actually cares about.

    Also, there are no error bars of any kind listed.

    In other words, I have no reason to assign any meaning to these numbers.

  • Re:Calling home (Score:5, Interesting)

    by fuzzyfuzzyfungus ( 1223518 ) on Tuesday November 26, 2013 @02:21PM (#45528991) Journal
    Depends on the paranoia of the DRM implementation.

    A simple "We sell to corporations, so we don't expect cracks but we do expect optimists trying to install a few extra seats" licensing system really just needs to (ideally over SSL, hear that, LG?) phone home the serial number at intervals and get a 'yes/no' in response.

    The more paranoid systems, designed on the assumption that the client will be under active attack, may be considerably murkier. Something like 'BD+', for instance, for Blu-ray DRM, mandates a proprietary, blackbox virtual machine (with access to the client hardware's memory and the ability to run native code, including applying persistent patches to the client system, in addition to what it does internally) that executes whatever blob of BD+ code burned into the disk you try to play.

    A system like that, or an AV-like 'signature' system that is designed to have one or more parts of the client DRM continually interrogating one another in novel ways to detect compromises in the authentication mechanism would be more or less indistinguishable from a binary, because it would be one.

    For something like a compiler, rather than a game, or some precious 'premium content', I'd expect the former; but I've underestimated human stupidity before.
  • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday November 26, 2013 @02:26PM (#45529057) Journal
    My understanding is that they never explicitly 'slowed down' AMD systems; but that the binaries produced by their compiler refused to honor the capabilities flags of non-intel processors (eg. even if an AMD CPU lists 'SSE2, SSE3' among supported instructions, it would get the fallback to non-SSE instructions, while Intel CPUs would get whatever their supported instructions lists specified). No actual 'here be lots of NOPs for no reason'; but x87 on a machine that can do recent SSE is probably enough to achieve the same effect...)
  • by Anonymous Coward on Tuesday November 26, 2013 @06:15PM (#45531961)

    Long, long ago some review site ran a Via CPU based system while spoofing the CPU ID to appear as an Intel CPU of similar capabilities.
    They expected a few percent gain in the FP and INT benches, but oddly got an 8-fold increase in reported memory bandwidth. The other benchmarks appeared to reflect a real increase in memory performance.

    Don't wipe your arse with Intel, they're so dirty you'll end up shittier.

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...