Slashdot Mirror
Cygnus & Intel Donate ia32 gcc ia32 Backend
AT writes "Cygnus has released the source for a new x86 backend for gcc. The new code focuses on better PII optimization. Intel contracted the changes from Cygnus.
The code isn't quite release quality yet, but it should be intergrated into gcc 2.9x source tree around August. "
Hopefully this won't be an isolated incident considering the
number of chips coming outta Intel in the not-so-distant-future.
If I understand correctly, the K7's L1 cache is fast but small (64/64), and the L2 cache can run at variable speeds. Some of the earlier systems tested had it running at 1/3 core clock IIRC, while the systems that AMD released benchmarks for had it at 1/2 core clock (again IIRC). The chip supports an L2 cache running at full core speed, so it will be up to the module and RAM makers to provide the infrastructure for that (running an off-chip cache at 500+ MHz isn't trivial).
To continue: The K7 also supports an L3 cache on the motherboard. IIRC this was slow, but I don't remember the exact specs.
As AMD is the one putting together the modules for the K7, the design burden for providing a full-speed L2 cache is in their court. IIRC they were planning to sell half-core-speed systems initially, and offer full-core-speed systems as higher end later (presumably when yields on full-core-speed parts went up).
It will be interesting to see what happens when they move to 0.18 micron. They could fit a fairly large L2 cache on-die, but size would still be less than the maximum that the off-die version supports (up to 8 megabytes IIRC).
This is true for GCC 2.8. There's a new Sparc back-end in EGCS which should bring GCC into the latter half of the 90's finally.
One nice thing about the new back end is that it actually understands the Ultra-Sparc's scheduling requirements so that it can actually get four instructions issued each cycle. When you lump in the Haifa scheduler technology as well as the advanced pointer analysis and so on, I think 3.0 will shape up to be a much stronger contender.
In the meantime, I'd expect EGCS's performance numbers to still lag Sun's SparcWorks compiler for a little while, based on the following reasons:
So that's about it. I can't really comment on the C++ differences, except to say that I would imagine alot of the binary bloat comes from GCC having to "roll its own" exception handling and infrastructure, whereas Sun probably offloads alot of that to proprietary, platform-specific libraries.
--Joe--
Program Intellivision!
It would appear Intel is trying to keep its x86 flavor more attractive than other x86 flavors by stacking the compilers in its favor as well. I might be cynical, but I think that Intel is banking on getting a few of the ducats that people are saving on Open-Source Software by having them upgrade to an Intel x86 instead of an AMD or Cyrix part.
After all, the compiler supports Intel-specific optimizations, so why not?
The problem, of course, is the fact that AMD and Cyrix probably do not have the resources to fund/promote similar efforts, so this does end up being a means for Intel to un-level the playing field.
On the bright side, alot of x86-specific tweaks will help all x86 variants, not just Intel's x86s. (For instance, register allocation that understands the highly non-orthogonal IA32 register file would be a big step forward for all x86's. There was an interesting paper in MICRO-31 about that, IIRC. Also, scheduling to avoid AGIs and other hazards generally helps all flavors.) So, the picture isn't as bad as the paragraph above might have painted.
Nonetheless, if you want AMD-specific tweaks to GCC, then why don't you see if you can contribute to the tweaking effort? Even if all that means is beta-testing proposed changes on your machine for robustness and performance improvements, it'll still help. Poke around egcs.cygnus.com and ask what's up.
--Joe--
Program Intellivision!
I think GCC is one of the best compilers for the IA32 architecture, but for other platforms the native compilers are usually better. For instance, on MIPS based machines, SGI's MIPSpro compilers are usually much better than gcc, particularly as you increase the amount of optimization. Unfortunatly I don't have any hard numbers to back this up, just my own personal experiances.
I read the internet for the articles.
EGCS will become GCC. If I recall correctly, when EGCS is "finished", it will be released as GCC 3.0. In the meantime, EGCS releases are numbered as GCC 2.9x and EGCS 1.x in parallel, it appears.
Poke around egcs.cygnus.com for the complete scoop, as I'm sure I don't have my facts 100% straight (although I have them close).
--Joe--
Program Intellivision!
I know someone who did some benchmarking with various compilers on high end RISC hardware (SGI Origin 2000 and Sun Starfire). It was doing fluid dynamic modelling, and the code was about 400,000 lines. The egcs compiler was about 3x slower at compiling the code. For actual generated code, for a variety of tests/setups, the egcs code was much slower on several tests (9x slower on one test), and on one or two tests it was actually slightly faster than the commercial compilers. On a few tests the egcs code failed to work due to bugs in the egcs compiler.
Compiling for high end hardware is very hard, and you generally need compilers that know the hardware to get the best results, which is why it's not that surprising egcs/gcc didn't do too well on the high-end hardware - because it rarely gets used for such things.
Sun have a long, detailed white paper on egcs VS Sun's compiler. They quote 34% faster SPECint code and 127% SPECfp code with their own compiler. They also promote some other things - better development environemnt, hence improving productivity. btw, Sun's standard compiler costs $500 and their pro one cost $1500, I believe... (of course, if you're paying developers to write code, saving two-man weeks of time could be enough to justify that $1500, for the guy working from home, the cost is prohibative)
Sun have said they're working on some stuff to help people writing software that works correctly on Solaris and Linux more easily. It'd be nice if they made their compilers work under Linux and be free to non-commercial useage.
Except that GPL does not require that Intel distribute its gcc-related work outside of Intel. So they could have simply continued to keep it inside Intel (no pun intended) and used it to show what their processors could do.
Christopher A. Bohn
cb
Oooh! What does this button do!?
Actually, having an optimized compiler does impact the bottom line (moreso on some platforms than others).
In Intel's case, it's largely psychological. Already, people go with Intel because they feel that it's gotta be faster/better/etc because they're the company driving the platform, whether that is actually true. Bits like this serve to reinforce that image.
Also, consider that the entire RISC paradigm was made possible by compiler technology. Surely you weren't expecting people to hand-code major applications all in assembly code, were you? To an application writer on modern machinery, the performance you get from your compiler IS the performance you get from the architecture and the chip. If you can improve the performance from software, that's less silicon area that you need to spend on the problem, which translates into smaller die sizes, higher yields, and therefore lower prices, higher margins and happier customers.
And then there's the more exotic architectures, such as the one I work on at my day job -- the TMS320C6000 family VLIW DSPs. A good compiler is an absolute must for such a beast, and the absence of one would make the platform more of a computer science curiousity than a successful DSP. VLIWs work by moving all of the pipeline management out of silicon and into the compiler, making the compiler one of the most important components of the system. Intel's EPIC platform presents a similar situation.
Therefore, don't underestimate the power of good compilers to increase the value of a given processor platform. They're part of the essential infrastructure which keeps a platform supported and raises it to new heights, and in the case of Intel's x86, they serve as an additional tool in their arsenal for differentiating and improving their platform over the competition -- other x86 vendors and RISC vendors.
I've seen architectures that were very good and/or clever architectures but were difficult to program by hand. Lack of good tools support sent these to an undeserved early grave. The early VLIWs fell into this category (Multiflow's Trace is remembered as having the world's slowest compiler -- a victom of being ahead of its time), as did some DSPs (such as the 320C80 family... sniffle).
Now, one of the angles on Intel's move that I missed earlier is that improving GCC's x86 performance in general (whether or not it applies specifically to Intel's x86 flavor) is that it can help x86 *nix's (including Linux) to eat their way into the RISC-dominated workstation market. I can see this being very important to Intel's bottom line, since servers and engineering workstations are high-margin items. And so, the plot thickens... :-)
--Joe--
Program Intellivision!
I am afraid you may have missed the point. AMD is much smaller than Intel and likely does not have the resources or the credibility to influence people to make brand-specific compiler optimizations.
I would rather see a collaborative effort to optimize x86 code for all x86 CPUs, not for a specific brand of CPU.
Even if AMD could influence compilers would we want them to? Imagine GCCK6-2, GCCK6-3, GCCPENTIUM, GCCP2, GCCP3, yadda yadda....
As for Intel dominating, they were being investigate just like Microsoft except that none other than AMD proved Intel is slipping.
-Clump
> I applaud the improvement of gcc, but it is a
:-)
> little wrong to say this backend is ``donated''
> isn't it? It is derived from GCC so must be
> under GPL if it is to be distributed at all.
Since this is the terminology used on the EGCS
page, it must be right
> Or do I miss something?
For code to be distributed with GCC, releasing
under the GPL (or another GPL-friendly licence) is
just the first step. The more important step is
to assign the copyright of that piece of code to
the Free Software Foundation. If you don't assign
copyright it won't be part of the official GCC,
plain and simple (it doesn't prevent you from
distributing unofficial patches, of course).
So, the word "donate" makes perfect sense in that
the copyright of that code was "donated" to the
FSF.
You wouldn't need multiple versions of gcc -- just provide more allowable arguments for the existing command-line arguments for gcc. gcc -m=cpu -march=cpu
Christopher A. Bohn
cb
Oooh! What does this button do!?
Both Intel and Microsoft have certain marketing philosophies to try to prove that they aren't *really* joined at the hip, market-wise. One thing Intel does is support alternative OSs and try to promote compiler technology. Microsoft tries to run on Alpha, etc.
AMD might realize that this is really all nose-thumbing at Microsoft on Intel's part. Is an optimized GCC a good thing? Yes. Will any optimized compiler make any difference at all in a CPU-maker's bottom line? Not really.
--
Business. Numbers. Money. People. Computer World.