Slashdot Mirror

← Back to Stories (view on slashdot.org)

GNU GCC Vs Sun's Compiler on a SPARC

Posted by timothy on from the real-numbers dept.

JigSaw writes "When doing research for his evaluation of Solaris 9 on his Ultra 5, Tony Bourke kept running into the same comment online over and over again: Sun's C compiler produces much faster code than GCC does. However, he couldn't find one set of benchmarks to back this up and so he did his own."

10 of 72 comments (clear)

  1. What CPU? by keesh · · Score: 3, Informative

    I wish this guy would tell us what CPU he's using. There's a hell of a lot of difference between the low-cache and high-cache CPUs (yes, these will work in a u5 as well as a u10). Looks like he's using a low-cache one, where there's not as much difference (and where the 64bit penalty isn't as noticeable).

    1. Re:What CPU? by Oinos · · Score: 3, Informative

      If you follow the "evaluation" link, it tells you. UltraSPARC IIi 333MHz 2MB Cache.

    2. Re:What CPU? by nelsonal · · Score: 4, Informative

      It's the same guy who bought a Sun system on ebay and has been writing columns on shiny new (to him anyway) system. The specs from the purchase article:

      The system I'm using is a second generation of the Ultra 5, released in late 1998. Here are the specs:

      System: Sun Ultra 5
      Processor: UltraSPARC IIi 333 MHz, 2MB cache
      Memory: 256 MB
      HD: Seagate Medalist 7200 RPM IDE Pro 9140 8.4 GB
      IDE Controller: Built-in UDMA2, 33 MB/s max
      CD-ROM: 32x IDE
      Video Controller: Sun PGX24 (ATI Mach64), 4 MB VRAM
      Network: Built-in 10/100 NIC (hme, "Happy Meal" interface)

      My knowledge of sun processors is a little lacking in the UltraSPARC II range, so I'll leave it to you to evaluate this one, My only exposure is the dead server CPU module for a paperweight. It and a foxtrot on the corkborad are my own version of the geek purity test.

      --
      Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
    3. Re:What CPU? by carsont · · Score: 3, Informative

      The specs of the machine were in his first article.

      It's the 333 MHz processor with the 2 MB cache. (The same one that's in the U10 I'm using right now, by the way).

      --

      Ubi dubium, ibi libertas.
  2. Actually, he did by Anonymous Coward · · Score: 1, Informative

    Read the articles. 2MB cache, 333 MHz UltraSPARC IIi

  3. Re:Why does this suprise ANYONE by ctr2sprt · · Score: 3, Informative
    I mean gcc's strength has never been fast code (all though it is no slouch) it has been cross platform.
    That's gcc's de facto status, but from the section of its info pages called "GCC and Portability:"
    The main goal of GCC was to make a good, fast compiler for machines in the class that the GNU system aims to run on: 32-bit machines that address 8-bit bytes and have several general registers. Elegance, theoretical power and simplicity are only secondary.
    It's interesting to note how gcc has turned out. I wonder what caused the change; if it were market forces, or changing developer priorities, or just coincidence.
  4. Re:well, for $2995 vs. $0.00... by cant_get_a_good_nick · · Score: 3, Informative

    The Sun compiler has some optimizations, not turned on in this test, that gcc doesn't even offer. Scheduling optimization based on profiles from previous runs (rarely used) optimization and inlining across source files and across all program object files, ordering to help pagefault analysis, enable instruction prefetch, etc. If would be interesting to see if these have vast or just incremental improvements in the runtimes. I think Sun is adding auto-parallelization to future compilers. Most people don't use these optimizations since they imply some work and some testing to see whether or not they help a particular dataset. I know we don't, by the time we get something that we could test, we're already on a new codebase.

    That said, the fact that a generic compiler like gcc is within spitting distance of Forte or SunONE or whatever they call it this week is impressive.

  5. Re:Why does this suprise ANYONE by AT · · Score: 3, Informative

    Actually, in early iterations, gcc killed most vendor's compilers, including Sun's. This was mostly because most vendors's compilers were absolutely terrible when gcc was first released. Since then, compiler technology has made huge advances and vendors have spent lots of effort improving them. At the same time, with the increasingly complex scheduling requirements of todays RISC processors, making a compiler fast takes a lot more work. Designing a portable instruction scheduler that performs good on very different processors is nearly impossible (though gcc does it surprisingly well).

  6. Re:"clear" winner??? by DAldredge · · Score: 4, Informative

    The OpenSSL code has highly optimized assembly for those functions under x86. On other archs it is just C code that the compiler has to optimize.

    That may explain the speed difference that you are seeing.

  7. Re:well, for $2995 vs. $0.00... by 0x0d0a · · Score: 2, Informative

    Scheduling optimization based on profiles from previous runs (rarely used)

    gcc supports this.

    --
    May we never see th