GNU GCC Vs Sun's Compiler on a SPARC

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."

Comments

What CPU?

[keesh]

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).

Re:What CPU?

[Oinos]

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

Re:What CPU?

[nelsonal]

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.

Re:What CPU?

[carsont]

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).

Re:What CPU?

[nelsonal]

You know this is a geek website when someone asks a [hypothetical] question and has three answers within ten minutes.

ah 2.95.3, we hardly knew ye

[dingbatdr]

To me this was the most interesting line of the article:

Sun's compiler was the clear winner. Surprisingly, the older version of GNU's GCC beat 3.3.2 by a very slim margin.

One of my favorite version numbers (2.95.3) is still getting good press. Cool.

dtg

Re:ah 2.95.3, we hardly knew ye

[3-State Bit]

Never trust a naked busdriver
Because they have nothing to lose?

Actually, he did

[Anonymous Coward]

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

web graphics 101?

[Anonymous Coward]

Be nice if we could read the gifs.

OT,but someone has to make the [NO CARRIER] joke

[Anonymous Coward]

I used Sun's new compiler to compile new drivers for my old 14.4 faxmod=20 ]} } } }&..}=3Dr}'}"}[NO CARRIER]

Why does this suprise ANYONE

[MerlynEmrys67]

I mean gcc's strength has never been fast code (all though it is no slouch) it has been cross platform. You can use GCC on everything from the biggest 64 bit procs down to the smallest embedded CPUs.

Of course a vendors supplied compiler that doesn't have to even think about potential optimizations for another platform will outperform it. It is a testiment to the gcc folks that it is even close.

Re:Why does this suprise ANYONE

[ctr2sprt]

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.

Re:Why does this suprise ANYONE

[duffbeer703]

Those are Richard Stallman's goals, which don't really mirror anybody else's.

And since the excerpt was from the info pages for GCC, you and stallman are likely the only humans to have ever read it.

Re:Why does this suprise ANYONE

[Vladimir]

GCC is an excellent compiler. I was surprised why it didn't beat SUN's CC. In my experience, gcc frequently generates code which is at least as good or slightly better than vendor's compiler (at least for DEC, SPARC and Intel platforms). There are special cases, say OpenMP, SSE2, ect, when vendor's compiler does a better job (and gcc currently doesn't support openmp), but in most cases I can easily believe that gcc will be the best. In addition, knowing that a certain version of gcc compiled 8000 Debian packages for 10 different platforms and didn't failed (or if failed, a bug was submitted) is a good indicator that you can trust this compiler. Add to this that compiler gets better with each release and I think it will soon be what Linux is for UNIX - making the rest obsolete.

Re:Why does this suprise ANYONE

[AT]

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).

Re:Why does this suprise ANYONE

[cant_get_a_good_nick]

Those may have been Stallman's original goals, but not necessarily of gcc anymore. Remember that the maintainers of gcc now aren't the original Stallman lead, FSF gcc folks, but of the splinter egcs group that forked gcc because they were extremely frustrated with the progress of gcc under the FSF. Once it became evident that egcs was making progress leaps and bounds past the FSF gcc, (to Stallman's credit) work on FSF gcc was dropped, and the egcs gcc became the official gcc.

People think that "The Cathedral and the Bazaar" was made in comparison between commercial and non-commercial programming models. It actually was modeled on FSF gcc (the Cathedral) and Linux kernel (the Bazaar) development. Eventually, at least in gcc development, the Bazaar won.

Re:Why does this suprise ANYONE

[ksheff]

Actually, I first started using gcc because it was significantly faster than Sun's compiler for its M68K machines. Of course that was almost 15 years ago, but I know that's one of the reasons it became popular. I don't think this was the case for the early Sparc based machines though. Our sysadmin at the time said that in order to get decent performance out of the chips, Sun had to put more effort into the compilers than it did for the previous machines. FWIW, on Data General's M88K-based machines, gcc (& lots of the GNU utilities) were the vendor supplied tools for the platform.

Re:Why does this suprise ANYONE

[Chris_Jefferson]

I've always thought this is a slightly strange target. Surely the point is that a compiler should be the one piece of software which is tailered to each CPU it runs on, so that the rest of us who write C/C++/whatever don't have to?

Re:Why does this suprise ANYONE

[j-pimp]

Add to this that compiler gets better with each release and I think it will soon be what Linux is for UNIX - making the rest obsolete.

I was talking to some Novell engineers at Linux World. They all love watcom. The watcom toolchain is being ported to linux. It already self bootstraps. Novell owns SuSE. I expect SuSE will be making use of watcom for linux in the future. All my projects are going to use Watcom from now on. I'm sick of the annoying voo-doo neccessary to make a cross compiler between unix and mingw/cygwin/djgpp using gcc. Watcom lets me cross compile out of the box. Granted the IDE needs some work, but wmake very powerful, though unique. All the basic unix userland you expect for a makefile (cp, rm, install) is a builtin command and calls to the tool chain (compiler, linker etc) are loaded as DLLs saving system calls, thus improving performance.

GCC is very mature, popular and supported, but its not going to be the only kid on the block for long now that Watcom is open source.

Re:Why does this suprise ANYONE

[Vladimir]

All I can say - competition is good. If Watcom is a decent compiler and will be able to compile kernel and Linux distro I am very glad. Most likely gcc team look critically what is good and what is bad and improve things were needed.

Re:Why does this suprise ANYONE

[turgid]

I was talking to some Novell engineers at Linux World. They all love watcom.

Perhaps that's because Netware was written in Watcom C? Netware was very impressive in its day (late eighties, early nineties) having many features that we take for granted in Linux today. Watcom's C compiler used to be the best on the market for PeeCees, and could produce flat, 32-bit code for DOS extenders back when Microsoft C was still messing about in 16 bits. If you wanted to write an NLM for Netware, you used Watcom. It also targetted OS/2. Those were the days.

Re:Why does this suprise ANYONE

[j-pimp]

If you wanted to write an NLM for Netware, you used Watcom. It also targetted OS/2. Those were the days.
Yeah netware guys said netware was built using watcom. Also, the watcom dev team all seem to use OS/2 Warp.

Re:Why does this suprise ANYONE

[j-pimp]

All I can say - competition is good. If Watcom is a decent compiler and will be able to compile kernel and Linux distro I am very glad. Most likely gcc team look critically what is good and what is bad and improve things were needed.
Its my understanding that thekernel is chock full of GCCisms, however userland is a different story. Main obscacle to compiling kernel on watcom will be convincing Linux to accept patches that remove the gccisms or provide watcomisms as appropiate. I do believe that this will give gcc a kick in the pants.

Bad Statistics?

[Josh Booth]

See Tony Bourke's older article, which conluded that 64 bit binaries are slower than 32 bit binaries. This set of statistics he posted has totally obliterated his previous conclusion. He had only used GCC 3.3.2 and assumed that compiling for both 32 and 64 bits were optimized similarly. However, in most of the benchmarks he did with Sun's compiler, 64 bit programs came ahead of 32 bit ones. This means that GCC 3.3.2 is not as well optimized for his computer for 64 bits as for 32 bits, while the Sun compiler is. If he had just looked at his own data, he would have seen that.

Re:Bad Statistics?

[Shanep]

However, in most of the benchmarks he did with Sun's compiler, 64 bit programs came ahead of 32 bit ones.

Looks like to me that Sun's 64bit code won 7 out of 22 tests against Sun 32bit code.

The rest are either loses or near ties.

well, for $2995 vs. $0.00...

[amarodeeps]

...and a better performance not even all of the time, especially on a 32-bit platform, I choose GCC.

However, I'd like to see a well-thought out criticism of this piece. It seems like someone always has a good counterpoint to any given set of benchmarks.

Re:well, for $2995 vs. $0.00...

[cant_get_a_good_nick]

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.

Re:well, for $2995 vs. $0.00...

[0x0d0a]

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

gcc supports this.

Re:well, for $2995 vs. $0.00...

[calidoscope]

Sun sells the "Compiler Collection" for $995, which consists of the C/C++ and FORTRAN compilers without the GUI application builder.

Sun used to (and may still do) claim that their compiler produced better code than GCC.

Sun's FORTRAN compiler is much more complete than g77/g95 - no offense intended to either Craig Burley or Toon Moene.

Re:well, for $2995 vs. $0.00...

[Cajal]

" I think Sun is adding auto-parallelization to future compilers."

They already have this. Do -xautopar when using cc.

Re:[TROLL]Re:ah 2.95.3, we hardly knew ye

[cant_get_a_good_nick]

Using DEPRECATED compilers is just as stupid as using DEPRECATED kernels(2.4, just to name one)
How is 2.4 deprecated? 2.6 is not even in all distros yet. Even Linus says wait on 2.6.1 or 2.6.2 to get any real work done.

"clear" winner???

[ajagci]

So, the benchmarks show maybe a 10-15% difference in favor of Sun's compiler. Does that Sun's compiler a "clear winner"? I think not.

First of all, it's far from clear that those differences are real. You can get much bigger differences from just changes in caching behavior, even with the same compiler.

Then, there is the question of whether Sun's compiler is actually correct. A lot of commercial compilers intentionally skirt or break the letter of the ANSI standards once you start enabling optimizations. GNU C/C++ is usually more careful.

Finally, you have to ask whether it matters. So, Sun's overpriced machines using their overpriced compilers run a bit faster than their overpriced machines using a free compiler. So what? If you want bang for the buck, or even just maximum bang, why in the world would you buy a Sun these days anyway?

Re:"clear" winner???

[SewersOfRivendell]

Assuming he measured correctly, 15% is a lot. It's the minimum threshold for user-perceivable speed improvement, among other things. A lot of people would kill to have 15% faster compilers, kernels, databases, window managers, etc.

Re:"clear" winner???

[Blkdeath]

Finally, you have to ask whether it matters. So, Sun's overpriced machines using their overpriced compilers run a bit faster than their overpriced machines using a free compiler. So what? If you want bang for the buck, or even just maximum bang, why in the world would you buy a Sun these days anyway?

Without doing any sort of conclusive tests, I've tested three of my machines with

openssl speed rsa dsa

for speed. Here's how it panned out;

• AMD Athlon XP1800+ - 1000% as fast
• AMD K62-400 - 200% as fast
• Power Macintosh 750 195MHz G3 - 100% as fast

In short, I'm not terribly impressed with the power of that UltraSPARC processor; especially considering it's so closely matched with my two lower-end boxes.

Re:"clear" winner???

[DAldredge]

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.

Re:"clear" winner???

[spitzak]

We would pay good money for a 5% improvement! (this is the promised, but so far undelivered, advantage of using Intel's CC over GCC on Linux. We already use it on Windows, but there it is 40% better than VC6).

Re:"clear" winner???

[Blkdeath]

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's why I tested a Mac with a 138MHz speed deficiency which came up almost number-for-number evenly matched with its processing superior.

Is there some documentation as to the machine-specific optimizations of OpenSSL on the various architectures it supports?

Re:"clear" winner???

[Corfitz]

So, the benchmarks show maybe a 10-15% difference in favor of Sun's compiler.

Sun's overpriced machines using their overpriced compilers run a bit faster than their overpriced machines using a free compiler.

In my eyes I would rather spend the $2995 on buying a new PC. Hell ... if I wait 6 months before I buy it I'll easily get a 10-15% speed increase on all the programs running on the machine (+ have money to spare).

Re:"clear" winner???

[0x0d0a]

I've seen Mac UI people say that 30% is the minimum threshold.

The point I was most interested in is that gcc and Sun's compiler are about the same speed on 32 bit code, and Sun pulls ahead on 64 bit code.

Re:"clear" winner???

[aminorex]

PowerPCs are "brainiac" chips. They
do a lot more per cycle than do the more
deeply pipelined ultrasparcs, which in turn
do a lot more per cycle than do the absurdly
deep x86s.

Re:"clear" winner???

[ron_lima]

Well, 10 to 15% is a very low rate taking into account the costs for each compiler. GCC may be slower, but, what is the benefits regarding its price? In this matter, I rely my opinion in the cost/benefit ratio. An additional stuff to talk about: no matter which one creates the fastest code. I think, as a programmer, that the code must be optmized first by design, then by the compiler. I've seen a lot of programs that relies its performance to the compiler with absolutely bad design. My comments in this matter are not very compliant with the discussion, but sometimes I see some bad software designs that are optmized only by a native compiler in a given platform. I see that all the time in the company where I work: endless loops full of database accesses and crazy decisions that leads the CPU to a very crazy load. Bad design for sure!

Re:"clear" winner???

[jim3e8]

I recently compiled gzip with HP's cc and saw perhaps a 10% improvement over gcc 3.3.2 with the right options. This is just a single data point, but I was surprised I didn't get more of a speedup. Even more surprising was that the stock gzip binary was even with gcc, so either HP's compiler improved, they didn't use it, or they optimized conservatively.

Re:"clear" winner???

[Shanep]

In short, I'm not terribly impressed with the power of that UltraSPARC processor; especially considering it's so closely matched with my two lower-end boxes.

I have a Sun Ultra 10, 333MHz UltraSPARC IIi with 2MB cache and 128MB RAM in one bank (I realise I can get better memory bandwidth while using two banks).

I can confirm, the machine runs like a two legged dog.

If it were not for the fact that I want to improve my Solaris skills (the whole reason I bought the machine), it would be running OpenBSD as my firewall.

In everything I have thrown at it, my 300MHz G3 iBook and 300MHz PII kill it so badly that using percentages to compare them is a waste of time. I prefer to say 2-3x slower.

Compiling all of OpenBSD 3.4 -stable macppc and generating release packages (system, X11 and ports), my little iBook, with slow little 6GB notebook drive took 5 hours to complete. On the other hand, doing the same for OpenBSD sparc64 took 7 hours on this Ultra 10 with a much faster 7,200 RPM desktop drive. I would not be surprised if the iBook could have done it 2-3x faster given the same drive.

I am however interested in Linear Feedback Shift Register Pseudo Random Number Generator designs. I used to build them in hardware but that gets pretty limiting when you're just a hobbiest. I am thinking of writing a simulator that finds maximal stream length designs so I think this 64bit CPU (being the only 64bit one I have) will be a good candidate.

Then again, maybe I should just get an Opteron, declare Sun "soon-to-be-dead" and enlist this Ultra into the OpenBSD/PF armed forces.

PS, I realise that SCO's imminent death with slow the demise of Sun and I do like Sun gear and would rather not see them go belly up. I have not been watching them financially lately. Are they looking any better?

More technical brilliance from OSNews

[duffbeer703]

Next they'll be concluding what language is fastest by writing "Hello World!" in C (compiled in 64 & 32 bit), Logo, Perl and Prolog.

I hope to be posting a full writeup on how much faster MS-DOS is compared to BSD using boot times as a benchmark.

Re:More technical brilliance from OSNews

[RevAaron]

Umm... The comparisons had a lot more to do than hello world or boot times. Perhaps you missed the other sections of the article?

Re:More technical brilliance from OSNews

[mystran]

You forgot Befunge and Lazy K..

Sun's compilers are optimized for the big iron

[lindsayt]

It's important to remember that Sun's compilers are optimized for Sun's big machines, so you don't really see the biggest advantages of the Sun compilers on single or even dual CPU machines. The Sun compilers really shine on the massively SMP machines such as the 10K, 12K, and 15K.

Of course I don't have any links to benchmarks that prove this, so take it or leave it. But Sun specifically does not care about compiler optimization for their "toy" machines such as the Ultra 5, Ultra 10, Blade 100, etc. Basically, if your Sparc CPU isn't a straight II or straight III, Sun's not as concerned with you.

Re:Sun's compilers are optimized for the big iron

[Anonymous Coward]

This is utter rubbish.

On all modern machines, the first rule of good code performance is to keep memory access to the very minimum, by utilising cache. This happens to be exactly what helps big SMP machines too. There is no tradeoff there.

A secondary but still important aspect is the theoretical execution speed you get when you disregard cache misses. The important things here are picking an efficient instruction stream, and good instruction scheduling and register allocation. This is as important on "toy" machines as it is on big SMP...

"Of course" you don't have links, so why am I replying to a troll?

Re:Sun's compilers are optimized for the big iron

[addaon]

Um, you're right about the two ways to get good performance... but loop unrolling for an 8MB cache is a totally different animal than unrolling for a 1MB cache (you start talking about doing multiple-level unrolling, and hoisting invariants through n, as opposed to 1, loop boundary). Similarly, an efficient instruction stream is different when you have 2 ALU's, 2 L/S units, and 160 rename registers than when you have 2 combined, and 16. Scaling of these features on a processor leads to a lot more than linear, or even quantitative, scaling in compiler strategies.

Re:Sun's compilers are optimized for the big iron

[Vladimir]

I wonder what makes you think so? I once tried to squeeze max performance of a program that had to run on 8 cpu sparc box (each @750Mhz) with 16G mem. (is it "toy" machine or not? read on) The program was nothing fancy: binary search in an array of 64bit packed structs of the total size ~2GB (so we could run 8 processes simultaneously in 16G), plus some postprocessing.

First observation: 64bit mode was twice faster than 32bit one (you sort of expect that).

Second observation: gcc with "-m64 -O3" produced code that was 2% slower than the best I could get from Workshop5 compiler and was 5% faster from what I could get from Workshop7 (or whatever is the latest). I'm not sparc expert, but I read all their recommendation on the web, man pages and played with "advanced" options, like prefetch, etc. Actually, 2-5% may be a measurement errors, as I didn't repeat tests many times (though I compared results)

Third: even the fastest fastest code was 3 times slower than performance of P4@2.8Ghz on the same inputs, so dual P4 with HT enabled would likely to provide me with the same raw performance. I wish I could test Opterons in 64 bit mode!

Of course, I can believe that there are some applications where workshop's cc is significantly better, but I never encoutered them.

Re:[TROLL]Re:ah 2.95.3, we hardly knew ye

[keesh]

It is available in all non-DEPRECATED distros.

Re:[TROLL]Re:ah 2.95.3, we hardly knew ye

[Brandybuck]

Using DEPRECATED compilers is just as stupid as using DEPRECATED kernels(2.4, just to name one)

Reason number 27 that I switched from Linux to FreeBSD. I got sick and tired of being treated like a lame poser just because I was still using last week's kernel.

the achille's heel?

[MrLint]

Well slice it which ever way you want, this jives with what i hear about the virtual water cooler. gcc is all well and good on x86 (as where its been tweaked for ages) but not always the best elsewhere. MacOS X is where i hear this mostly. The more aggressively it get used outside of x86 land the more it will get tweaked.

Move along nothing to see here.

Re:the achille's heel?

[Anonymous Coward]

Err dude, gcc isn't always the best on x86 either... but it looks pretty damn f'ing well and good to me on SPARC, actually. It is usually within a few % of the Sun compiler. Impressive.

Oh yeah it also compiles code for dozens of other CPU architectures.

Re:[TROLL]Re:ah 2.95.3, we hardly knew ye

[Anonymous Coward]

Reason 2 why I switched from FreeBSD to Linux: Linux creams FreeBSD in performance. Reason 1: FreeBSD zealots.

Re:[TROLL]Re:ah 2.95.3, we hardly knew ye

[Anonymous Coward]

Reason number 26 must have been that you bite on messages clearly marked [TROLL] -- seems to be a pretty common trait among *BSDers.

-fast not that fast for most cases

[iMMo]

The author uses -fast for all compilation with the Sun compiler, but that really isn't what it's meant for. The manual page for the compiler states that -fast is only good for a small portion of code in a program which requires the most optimization. In most cases, it results in optimizations that increase code size, and in my experience, change results of some operations. For instance, attempting to compile OpenPGP extensions to Perl (Crypt::OpenPGP, Crypt::RSA, Crypt::DSA, etc.) resulted in some strange departures from the expected test suite results. Compiling with a more reasonable optimization level (and no other changes) resulted in correct test suite results.

Basically, the compiler docs suggest that -fast is intended to be used with the -# flag, which expands the -fast macro into all of it's component switches. It is then up to the user to pick and choose the optimizations that are kept on for the entire code base, and which are only kept for sections of code which beneifit from extreme optimization.

Long and short: it would be interesting to see these results with a reasonable set of switches. I use Solaris 9 on a dual 450MHz Ultra 60 workstation, compiling with Forte C 5.5. For most tasks, I use the optimization flags '-xO3 -xarch=v8plusa -xspace'.

My $0.02

Benchmarks and leapfrogging

[StarBar]

It is a totally waste of time and money to compare compilers that have the feature set you want. By the time you have evaluated, purchased and start using the compiler of choice all compiler vendors and gcc has new optimizations in place making your choice outdated.

I worked for a compiler vendor once and at a particular point in time Greenhill Oasis, a competitor, compared Drystones benchmarks values in an advertisment between ourselvs, gcc and their own compiler. They turned out to be 3 to 5 times faster than us and almost twice as fast as gcc at the time (10 years ago). Obviously thay had put in specific Drystones optimzations in the compiler so we did the same and counter striked their figures in 6 months at 35% faster code if I remember it correctly. During the meantime we lost quite some business, still we did better than them on regular code, debugability and jada jada, all along.

It is a leapfrog game, choose the tools you like and don't make assumptions solely on benchmark figures. I am 100% gcc today and would only use anything else if a particular cross target wouldn't be mature enough or on the limit for the system performance.

Re:Benchmarks and leapfrogging

[Viol8]

Yes , it must take all of a few days to evaluate your program compiled under different compilers. And as we all know , new compilers come out every few hours. Right?

Re:Benchmarks and leapfrogging

[StarBar]

If you are going to spend a huge amount of money on compilers for a project lasting more than a few days that is. And for smaller projects I don't see that your budget would allow spending about $1-2K per simultanous user, which is a common charge for commercial UNIX based compilers.

Your time is better spent finding better ways to solve your problems than fighting for an extra 20% performance out of compiler optimizations. When compilers tries to make tricky optimizations ugly and hard spotted compiler bugs often arises that will waste much more of your valuable time to find... this is only common sense!

-march instead of -mcpu

[platipusrc]

would it have improved the scores for gcc any if he had used the march flag instead of the mcpu flag? It seems to me that it might have made at least a little bit of difference.

Re:-march instead of -mcpu

[Carewolf]

Not on sparc. mcpu on sparc means the same as march on i386. For mcpu behaviour use mtune on sparc.

Of course, this puts forward the question...

[0x0d0a]

...of who is using SPARC instead of x86 if they're worried about a 5% performance difference.

Re:Of course, this puts forward the question...

[Moraelin]

Not even only x86.

Much as I'm not really a Mac fan, if you want a RISC and Unix based workstation, just get a G5 with MacOS X. There you go. It's Unix, it's RISC, and it runs circles around Sun's workstations, at a fraction of the price.

Or yeah, x86. Get a cheap Dell, install Linux on it, and there you go. It's a Unix workstation. Sun's over-priced under-perfoming stuff won't even come near it in terms of performance.

Re:Of course, this puts forward the question...

[aanantha]

Yes, G5's and Pentium 4's do run circles around Sun workstations. But Sun's money is in their servers. Most people writing software for Suns aren't even looking at their workstations now, only their servers. The only real reason to buy a Sun workstation these days is for developing and testing software that you run on a Sun server. If you want a 32+ processor system with fast I/O and a robust design, then you're not going to find a Mac or PC that's going to do that. And a multiprocessor is going to be more compact than a computing cluster.

Re:Of course, this puts forward the question...

[Moraelin]

Of course, if instead of paying millions for that huge 32+ server, they:

A. Hired a competent programmer, for a change, and

B. stopped letting a clueless maketroid or PHB insist that the software must have all possible buzzwords (e.g., instead of directly write a value in the database, it now sends a SOAP message over MQ to an EJB, which finds and parses another XML message _in_ the SOAP message, and parses it to find the value and table name) ... then they could do the exact same job on a "measly" 4 way Xeon or Opteron.

To be blunt, _extremely_ few sites need server farms of 32+ CPU machines. Google does. Slashdot probably could use such servers too. A small B2B site with maybe 5,000 registered users total (not concurrent users!) does _not_.

I'll say that 99% of those monsters exist _only_ because some management droid gets a boner from buying millions of dollars worth of buzzwords. And then sinking more millions into consultants to even make it work. And to round it off, then they get the cheapest burger-flippers, who couldn't design _or_ code an efficient (or even working) architecture if their life depended on it.

Re: the best SSA of the world

[Anonymous Coward]

http://people.redhat.com/dnovillo/pub/tree-ssa/sna pshot/gcc-ssa-3.5ssa-0.20040129.snapshot.src.rpm

open4free

Missing information...

[vasqzr]

Which compiler is fastest at the act of actual compilation?

If GCC compiles mysql in 10 minutes and Sun's compiler takes 15...

Which compiler makes smaller binaries?

Re: the best SSA of the circus-world

[Anonymous Coward]

More useful information for optimizers, builders, testers, dummies, ...:

http://gcc.gnu.org/projects/tree-ssa/
http://people.redhat.com/dnovillo/pub/tree-ssa/sna pshot/
http://people.redhat.com/dnovillo/pub/tree-ssa/sna pshot/gcc-ssa-3.5ssa-0.20040129.snapshot.src.rpm (24.4M)
http://people.redhat.com/dnovillo/pub/tree-ssa/pap ers/
http://people.redhat.com/dnovillo/pub/tree-ssa/pap ers/gccsummit-2003-proceedings.pdf (1'383'108 bytes)
== http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-pr oceedings.pdf (1'383'108 bytes)
http://people.redhat.com/dnovillo/pub/tree-ssa/pap ers/nordu2003-slides.pdf (102'895 bytes)
http://people.redhat.com/dnovillo/pub/tree-ssa/pap ers/nordu2003.pdf (153'101 bytes)
http://people.redhat.com/dnovillo/pub/tree-ssa/pap ers/tree-ssa-gccs03-slides.pdf (90'925 bytes)
http://people.redhat.com/dnovillo/pub/tree-ssa/pap ers/tree-ssa-gccs03.pdf (87'507 bytes)

ftp://ftp.kernel.org/pub/linux/devel/binutils/binu tils-2.14.90.0.8.tar.bz2 (11'015'696 bytes)

open4free

SIMD instructions on SPARC

[Anonymous Coward]

I recall that the SPARC processor has an equivalent instruction set to MMX. I also recall that the Sun C compiler supports this and that GCC does not. For those of us involved in signal processing and image processing this would be a big win.

Also this would seemingly be a very big win for the Sun C compiler.

Any thoughts on this?

Also, it would be really nice to see some benckmarks with more floating point intensive operations.

- Andrew

Re:SIMD instructions on SPARC

[calidoscope]

IIRC, you're looking for the medialib package - a collection of libraries that support VIS (Visual Instruction Set). I would guess that these libraries would link to Sun's compilers and not necessarily to gcc.

Sun could do a lot more to promote use of the VIS.