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).
This is half of the picture. Because Sun is the high-end Unix market, and can easily manage to stay ahead of Linux in this market. Sun compilers on Linux means good compilers for Sparc with on popular OS. This means less Solaris sales, but more Sparc sales. Even if they provided compilers for i386, this would mean that more people using Linux than say Windows NT, because of good compilers not justifying the switch. Now compare the upgrade path "program compiled on Linux with Sun compiler -> program compiled on Solaris with Sun compiler" to "program compiled on Windows NT with Zortech (or whatever) -> program compiled on Solaris with Sun compiler". In one case you need to learn a whole OS.
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.
Yes, pgcc is a big leap. Getting sick of the decrease of performance because of gcc 2.7.2 -> egcs 1.1.2 transition I played around with it.
:-(.
Much faster code, *BUT* some code generation bugs (NetBDS kernels made with pgcc won't boot and some userland tools gave me strange errors) I didn't ivestigate that further and went back to egcs 1.1.2
AFAIK egcs 1.2 has/will have K6 optimization flags. I'll wait and see...
The K6-III is really great. ATM the fast 256kB L2+large but slow L3 cache is the best solution in the med-cost area of x86 CPUs. (Better than the small but fast Celeron cache or the big but slow P-II/III cache.)
I'm not that happy to read, that the K7 will have a slow cache as well... (I really hope I misread that!).
Spare a thought for the poor people that
have had to use Sun's F90 compiler.
Last time I tried to use it, I got
'illegal instruction' errors with a very
small (i.e. 200 line) program!!!
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)
EngrBohn is correct. The GPL requires you to make sources available to whoever you make the binaries available to. The GPL does not require anyone to release sources to the world in general unless binaries are made available to the world in general.
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
BTW:
IIRC Nocroft's C compiler produced about 20% faster code last time I've checked it (on an ARM610). I doubt that much has changed since then...
I heard from several guys (chess game programmers, who really need the fastest binaries) that MS Visual C can produce binaries more than 3 times faster than egcs. Will this ever be different?
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.
This is all cool.. But I use an AMD processor. Does anyone know if there are going to be any AMD specific tweaks to gcc?
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?
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
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
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)
Check out pgcc http://gcc.ml.org/
The AMD K6-3 is a great chip BTW.
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.
But this datasheet is about code fusion, intel extensions made to egcs by Cygnus. It reports 2x speed improvement versus the normal egcs. But since it's GPL'd it should be freely available. And yet it can only be bought on cd-rom. Why?
good to see our fearless leader hasn't lost his touch :-)
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
So I guess its ok to say Intel "donated" the IA32 backend to the GCC/ECGS project.