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.
It turns one conditional branch into two.
Christopher A. Bohn
cb
Oooh! What does this button do!?
Yes, it was noted on the egcs list. The actual code in the compiler is right (it includes an "a = -1" equivalent at the end).
I'm wondering why exactly compiler portability matters? If I write standards compliant C/C++/FORTRAN/Ada code it doesn't matter what compiler I use.
Of course, gcc seems further behind on standards compliance than the proprietary compilers I've used.
I would presume that AMD, having a lower budget than Intel, is hoping that the intelligent community would see the benefits in its technology and download the specs to use them. AMD has all of its optimization information (VERY good information) available for its chips. http://www.amd.com/K6/k6docs/ for example.
- Michael T. Babcock (Yes, I blog)
Yes, there are more conditional branches, but fewer instructions are executed overall. The overhead of the if should be rather small, as it is probably executed much less than the loop code.
I first used gcc on Sun3's (m68K based) and it was definitely better than the compilers from Sun. However, it wasn't that much better, if not worse than the sparc compilers. It was my understanding that with RISC environments, performance is greatly affected by the quality of the compiler, so the computer manufacturers spent a lot more time and money producing good compilers. Let's just hope that other chip manufacturers will help out cygnus with other gcc backends
the good ground has been paved over by suicidal maniacs
You also have to understand that the MIPS compilers also have a utility called cord that will re-arrange code and data so that functions that are used a lot will be close together in memory. This increases the probability that they will be kept in the caches. I believe someone is working on a GNU equivalent called grope.
the good ground has been paved over by suicidal maniacs
Wow! Now all the non-hand-coded-assembly in the distributed.net client will be faster! Imagine the incredible increase in keyrates we'll see on x86 machines!
We might get a whole additional key per day!
-Chris
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).
Which makes it nice to see Intel doing ir right this time.
I remember seeing a review (BYTE i think) of
various compilers and gcc finished near the top
on several platforms for executable speed. Does anyone know how GCC rates these days?
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!
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 think is more about for Profit companies getting it. Intel knows that for them to get out of the hands of MS, they must help the OSS people. I also think that they know that compilers are becoming too big and unmanagable for single group of people to handle. In some cases, hundreds of programers from around the world with a little free time and alot of skills doing what they like but not for a living, is what you need.
Don't believe me, look MS's compiler. With all those people and money, it still produces some pretty bad code. Also, Intel may also be trying to deversify from its relationship with MS. Something they could not get away with a couple of years ago, but in todays anti-MS and the government breathing down MS's back they can do.
All in all, a good move on Intels part.
Linux O Muerte!
Or do I miss something?
I'm continually amazed at the naivety demonstrated by AMD.
Not getting 3DNow! support into everyone's compilers, for instance. Not getting K7/Athlon support into those compilers loooong before the CPU is released.
Little wonder Intel dominates. It knows how to manage outside the organization as well as it knows how to manage inside...
--
Don't like it? Respond with words, not karma.
Will this be integrated with egcs also? I thought it had officially replaced gcc. I use it exclusively now...
Anyone care to speculate on what this will mean in terms of speed/binary size for PII chips?
I love it when something gets improved.
Do not read this
And how about AMD-specific tweaks for the Linux kernel? The recommendation that we configure for i386 for AMD processors (including K6-3! and presumably K7!) makes me hesitate as I consider my new box.
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
3 times faster to compile orbinaries that runs 3 times faster?
I don't care if it takes longer to compile, the speed of the binary is far more important.
who shot the cat in the hat to experiment is insane
It should give a boost to Apache, Samba and the kernel. I'd like to see what the differences are. Perhaps we'll see another round of Linux vs. NT...
Does anyone have numbers for real applications?
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!?
Anyone think code from the pgcc fork will get re-integrated into gcc 3.0? IIRC, it does include some support for AMD processors, too.
Christopher A. Bohn
cb
Oooh! What does this button do!?
intel has woken up because they have this in their labs for a V long time !
the idea that they could sort out unix world by just giveing out some of their tecnology and generate good press
what we need is for IA-64 stuff to be sorted out for instance the trimeran could be ported over to IA-64 it would help alot for ol gcc
and how about sorting out floating point with 3d now or streaming instructions ???
ah well good move well done Intel
referances GO TO IT >>>>> Trimaran
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
The next release will be gcc 2.95, hopefully out in July, and will _not_ contain the new backend. The new backend is scheduled for gcc 3.0, which is also expected to contain stuff such a new ISO conformant C++ library (i.e. with templated iostreams and living in the std namespace).
I doubt we will see gcc 3.0 this year, which also means the backend will take a long time to reach users.
Last time I bought a computer I looked at the AMD web site and all it said was how unbelievably well their processors worked with all kinds of Windows. Like if there was no other OS out there ... And then I remembered this embarassing affair with the AMD K6's >64MB problem, where they simply brushed the linux folks off, instead of helping them figure out what was wrong (IIRC, it turned out to be a K6 bug).
:-(
...
Someone who works there told me that their marketing folks want to push AMD processors into the business sector, and that they want to wipe out the perception that AMD processors are only for hackers. With this in mind, I don't see AMD doing anything for gcc/linux/*BSD in the forseeable future
But then again, I might be proven wrong by future events
Cheers
Rudi
If you have access to the intel compilers for Visual C you know what a boon this is.
I wrote a Reversie game for a CS class I had in school. It took ms c++ compiler 2 minutes to compile and the exe too 3 mineuts to play it self.
The Intel compiler compiled in 1Min and played it self in 30seconds. This was with just the std. Visual C optimizations for both. The intel compiler was SOOO much faster it was increadable.
The machine was a PII 300 w/ 56 mb of ram.(The fastest IA-32 Processor at the time!)
If these compilers are like those this will kick MAJOR ASS!
"There is no spoon" - Neo, The Matrix
"SPOOOOOOOOON!" - The Tick, The Tick
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.