Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Intel

Cygnus & Intel Donate ia32 gcc ia32 Backend 74

Posted by CmdrTaco from the better-compilers-are-always-nice dept.
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.
This discussion has been archived. No new comments can be posted.

Cygnus & Intel Donate ia32 gcc ia32 Backend More

Cygnus & Intel Donate ia32 gcc ia32 Backend

Comments Filter:
  • It turns one conditional branch into two.
    Christopher A. Bohn
  • 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.
  • If I write standards compliant C/C++/FORTRAN/Ada code it doesn't matter what compiler I use.

    Hahahahahahahahaha. Oh, thanks for the laugh. No compiler is standards compliant. If you have do any multi-platform programming you will find this out.
  • 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/ [amd.com] for example.
  • But this is usually better code, because the number of instructions executed dynamically is less if the loop is entered (which is probably the case). The while loop requires two branches in the loop (back-to-top and condition-check) which the do-while requires only one (condition-check/exit-loop).

    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

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

  • 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
  • I'm not that happy to read, that the K7 will have a slow cache as well... (I really hope I misread that!).


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

  • ...I hate pressing "tab" when trying to indent in a text input field...


    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?
  • as far as i know, gcc is still one of the best compilers out there. i've heard that it produces the fastest code out there. plus, you still can't beat free.

  • Re:How fast is GCC these days (Score:5)

    by Mr Z ( 6791 ) on Monday June 21, 1999 @07:23AM (#1840754) Homepage Journal

    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:

    • EGCS is still not widely deployed, and so there isn't alot of feedback available for tuning it.
    • EGCS is still a work-in-progress, and many new bits are being added. It'll be awhile before they're all well-adjusted to work together. (Optimizations are NOT as linearly independent of each other as many would wish.)
    • The SparcWorks compiler still has a few other features that are missing from EGCS, such as cache-based optimization. These can really help certain classes of programs.
    • Finally, the benchmarks will always be skewed if we only consider SPEC. The Sun compilers are very much SPEC-oriented compilers, from what I've seen. While Sun may have a large lead on SPEC benchmarks, the real-world difference is quite a bit smaller, I'm sure.

    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

    --
  • Umm, Sun's C compiler kicks the hell out of gcc, at least on SPARC architecture (recent). It's faster, and produces much smaller binaries, especially in regards to C++ (ugh) programs.

  • Re:Cool... but what about AMD? (Score:3)

    by Mr Z ( 6791 ) on Monday June 21, 1999 @07:11AM (#1840756) Homepage Journal

    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 [cygnus.com] and ask what's up.

    --Joe

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

  • 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 [cygnus.com] for the complete scoop, as I'm sure I don't have my facts 100% straight (although I have them close).

    --Joe

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

    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...
  • Will this be integrated with egcs also? I thought it had officially replaced gcc. I use it exclusively now...
  • I haven't done much benchmarking myself, but I know some people who have, on serious code. The simple answer is that it's pretty decent for x86. gcc was pretty poor on RISC architectures (both much slower to compile the code, and the resulting code was less efficient too) though egcs is much better on the RISC side. Most admin/guru type people I know consider gcc to be a not particularly efficient compiler, but very cool for being damn portable.

    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 [sun.com]. 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.

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

  • As of the upcoming 2.95 release [cygnus.com], ecgs == gcc. One and the same. Since the new backend won't be integrated before 2.95 comes out, that pretty much answers the question.

    You might have also noticed that the link heads to a machine called egcs... 8-)

  • 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
  • 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

  • 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

    --
  • Well yes, but the point is that Intel wants linux (And bsd as well) to run better on the PII/PIII and one way to do this is the pay cygnus to improve GCC. Now they have to release the source ofcourse.

    So the "Donate" language is just PR. PR can be an important part of these things. Hell this whole thing makes me think well of Intel.
  • 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
  • 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.


    But why would Sun want to make their compilers work with Linux? It seems to me that they would want to encourage people to use Solaris by making their compilers for Solaris and other Sun OS's only.
  • 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.
  • > 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.
  • 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're right of course about x86 Linux/BSD workstations being an important wedge against the small, but high-profit, marketshare RISC Unix workstations still have. (That occurred to me about 2 seconds after I pressed Submit!)

    Still, I would guess that Intel had it's engineering resources over at Microsoft and Borland optimizing their Windows compilers before the Pentium II even shipped. Maybe they're all done now, so they can start work on GCC!


    --

  • Re:gcc? (Score:1)

    by hadron ( 139 )
    The patch is against egcs, as you would know if you read the page that was linked to.

    Furthermore, gcc2.9 will be based on the egcs source tree, so it's accurate to refer to egcs as gcc.

  • 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
  • Anyone think code from the pgcc [goof.com] fork will get re-integrated into gcc 3.0? IIRC, it does include some support for AMD processors, too.
    Christopher A. Bohn
  • 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 [trimaran.org]
    a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
  • Anyone else notice the nifty little side-effect in the following optimization?


    * Recognition of certain forms of loop-carried post-decrement. Primarily,

    while (a--) { /* nothing dependant on a */ }
    becomes
    if (a) do { ... } while (--a);

    which removes a temporary and is friendlier to the register allocator.
  • Hmm, I read on their web-site that the PII backend is 28% faster than M$ VisualC++ and compares with the Intel Proton compiler. So, gcc is now the fastest x86 compiler on the planet

    ...although that appears to be the GCC-based compiler Cygnus sells; those changes aren't yet in the main GCC code base, if I read the announcement correctly.

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

  • I don't know much about the relative speed, but I do know that the Sun compiler (Sun Workshop Pro 4.2) is always getting stuff wrong. I have to turn off incremental linking (one of its "features") just to get it to work some of the time.

    I have to use this dog every day.

    I'd much rather have something that actually does the job properly, rather than have something faster that gets it wrong.

    I'm looking forward to the day when we switch to gcc (still stuck with SUNWSpro for legacy reasons).
  • 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
  • Yup. a has the wrong value after the loop (off-by-one bug).

    This is ok as long as a is dead after the loop. If not, an extra decrement will have to be generated.

    This is a great example of how tricky optimization can be.

  • Gcc sucks for ia32, it was designed for register-rich architectures like vax or m68k.

    In fact, gcc is probably worse than the vendor compilers on all architectures, except those where it _is_ the vendor compiler.

    Gcc wins on portability, features, and price, while not doing "too bad" on speed.
  • FWIW, this is corrected later in the thread
    containing that announcement. The compiler
    actually does the right thing, just the post
    was incorrect.
  • 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.
    Hmmm, AMD et al. may not be as big as Intel, but they're not exactly tiny, either. I think you'll find that they could afford to fund stuff like this if they really wanted to. Perhaps Intel just have more creative marketing strategists... Also remember that the Open Source OSes tend to be seen primarily as server systems at the moment, and until now AMD haven't really been aiming for that end of the market. Of course, the K7 changes all that, so maybe we'll see something interesting from them soon.

  • Re:pgcc? (Score:1)

    by Daa ( 9883 )
    Much of the code from pgcc is already integrated into EGCS , but some of the code is not mergable as it breaks EGCS for all non-x86 processors. Pgcc is derived from a demo compiler hack Intel did a number of years ago - and they did not care if the hack broke the compiler on non-x86 platforms.

    Intel did the same thing in their i960 toolchain - started with the gnutoolset and hacked a non-portable version for the i960 out of it

  • I believe Cygnus is doing a port to ia64 for Intel as well. However, they are not allowed to release it before Intel release the full spec for the processor.

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

Slashdot Top Deals

Your own mileage may vary.

Close