Compaq announces Beta test for Linux Alpha C compiler
Posted by
ryuzaki0
on from the compaq-invest-in-linux---nice.. dept.
Compaq has announced a public beta test for Linux Alpha C compiler (along with fortran). Press release (thanks to Linux PR) is available here, and here is the link for the software. It's good to see Compaq developing compilers and other applications for Linux. Keep up the good work, compaq!
The questions wasn't "will people pay for this software?"
It was more along the lines of "why does Compaq think this will sell hardware?" This is obviously a marketing move in order to get themselves inbed with the OSS crowd. It makes no sense to target the "I'll spend $500 on a compiler" crowd on linux. If we were into spending money on our software, we'd be running True64 anyhow because although I don't have any numbers to back this up I'm sure it runs oodles faster than Linux on an Alpha.
The entire point of my comment was to point out that Intel is one of the few hardware vendors that has their heads on straight on how to make money from us (nVidia being another). The whole goal should be to sell chips (and motherboards, and complete systems, etc.) and not compilers. I'm no closer to buying a Alpha then an hour ago before I saw this story. On the other hand I've been foaming at the mouth for a Mercede since Intel is throwing support towards projects that are things I care about.
This is not a story about the merits of their new compiler. It's a story about a half assed attempt by Compaq to rally support behind their chip.
This is obviously a marketing move in order to get themselves inbed with the OSS crowd
You don't get it. Not everyone uses an open source OS out of general principle. A lot of linux PC's are used as number crunchers in universities (with commercial compilers), because a free OS means you buy one cheap copy, that can be installed on all machines you have without restrictions, instead of buying a seperate expensive license for each machine with a lot of restrictions. This can save a fortune, and make a lot of things possible with a limited budget. By porting their commercial compiler suite to Alpha linux, Compaq obviously makes their low end Alpha boxes a more interesting option for this segment of the market.
Let us just say that Compaq is a company. So Compaq bought Digital. It so happens that this is something that very much seems to be former Digital employees work. Second of all, the success of Compaq's work these days are hype. Wheather this hype is `let-us-create-yet-another-cool-thing-that-runs-on -linux' or if it is the latest and greatest tune of Intel hardware is not important. In order for Compaq to increase market share today, they have to obide by Linux. Yes, they made this compiler a reality, and such also with a RAID driver. So what? I agree with some previous comments. Why not integrate the code into GCC? Such as how SGI does with it's XFS in a sense. (Yes I know XFS is a filesystem and not a compiler, but it is GPL and will integrate with the Linux kernel)
Yes this is pretty much critisism, and much of it is just plain and sheer paranoia, but still. Let us make Compaq understand that software for Linux is good. And it is even better if we get it in GPL. If this is a step in the direction of getting this compiler's optimization code into GCC and thus making it GPL, I WILL eat my words in public if so desired. But for now, some public synicism should be shown in order to bring it correct.
I do expect to get a lot of comments on this and I will check back and read it all. Just please be at least a bit constructive when arguing with me. I like to learn of new views. GNU is all about sharing information. I shared my views with you, please share yours with me.
-- Wealth is the product of man's capacity to think. -Ayn Rand
I agree. There's very little benefit to this compiler for most of us, I think, unless the optimizations it has are rolled into EGCS. Could a distribution be compiled with it? (Scary thought) The compiler isn't going to help anybody develop any Free software, and it's not going to help me, so why should I cheer?
Then don't. There, does that make you feel better?
I guess the important thing is to realize that all software doesn't need to always benefit everyone in the whole world. Compaq port this to benefit a certain clientele. That group of people, will, no doubt be benefited, and feel genuinely benefited. Everyone else will not be benefited, by something that wasn't intended to benefit them.
Use gcc. And Smile! Because gcc benefits you. But it doesn't benefit everyone.
Optimization today requires that the compiler rerder instructions using internal knowledge of how the processor works, provide branch prediction information, instruction packing into compatible groups
In other words, code scheduling.:)
prefetch and invalidation support
Does EGCS do prefetching? How's it done on the Alpha? On the MIPS it's simply a load to $0, I believe.
code for recovery from speculative execution failure
I'm not sure what you're getting at here. The 21264 is an O-O-O machine. For Merced this sort of thing is going to be critical. And I suppose if you want to use some profile information and optimize for that, this could come into play.
I don't believe EGCS makes use of any profiling. That seems to be a big missing piece.
Superscalar architecture have vastly changed the way that optimization works, and VLIW Merced promises to change it even more.
This is true, but it is amazing how much of a difference the simple "classical" optimizations can make. Things like Common Subexpression Elimination, Loop Invariant Code Motion (both grouped under Partial Redundancy Elimination) and Induction Variable optimizations are important. EGCS only recently got a global CSE optimizer!
--
--
Re:Better SPEC marks at last?
by
arivanov
·
· Score: 2
Quick and ugly test using bytebench:
~$ cc -v Reading specs from/usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/specs gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------- -----:------------ NUMERIC SORT : 271.48 : 6.96 : 2.29 STRING SORT : 24.804 : 11.08 : 1.72 BITFIELD : 6.4238e+07 : 11.02 : 2.30 FP EMULATION : 12.91 : 6.19 : 1.43 FOURIER : 2134.8 : 2.43 : 1.36 ASSIGNMENT : 2.4236 : 9.22 : 2.39 IDEA : 587.56 : 8.99 : 2.67 HUFFMAN : 241.78 : 6.70 : 2.14 NEURAL NET : 3.3857 : 5.44 : 2.29 LU DECOMPOSITION : 112.92 : 5.85 : 4.22 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 8.390 FLOATING-POINT INDEX: 4.259 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== C compiler : gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release) libc : unknown version MEMORY INDEX : 2.114 INTEGER INDEX : 2.079 FLOATING-POINT INDEX: 2.362 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
There are +/- in all integers and strings but there is no definite winner there. There is a huge difference in floating point benches, but what do you expect. Compaq links versus cpml egcs links versus libm which is far from where it should be.
Having a second thought let us see what compaq actually does. Hmmm, it looks like all math functions are redefined for Linux to use their "fast" low precision easily crashing equivalents. Lame...
So now let us see what happens if we go like compaq and use gcc and the compaq math library and the same lame technique:
TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------- -----:------------ NUMERIC SORT : 277.1 : 7.11 : 2.33 STRING SORT : 25.041 : 11.19 : 1.73 BITFIELD : 6.4264e+07 : 11.02 : 2.30 FP EMULATION : 12.935 : 6.21 : 1.43 FOURIER : 13231 : 15.05 : 8.45 ASSIGNMENT : 2.4256 : 9.23 : 2.39 IDEA : 587.65 : 8.99 : 2.67 HUFFMAN : 243.2 : 6.74 : 2.15 NEURAL NET : 4.3012 : 6.91 : 2.91 LU DECOMPOSITION : 114.41 : 5.93 : 4.28 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 8.437 FLOATING-POINT INDEX: 8.510 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== C compiler : gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release) libc : unknown version MEMORY INDEX : 2.121 INTEGER INDEX : 2.094 FLOATING-POINT INDEX: 4.720
Suddenly whe are better then compaq on fourie... And our math is definitely looking better... Hi, hi, hi, hi...
Overall Compaq math library better than libm, some other lib functions as well, but the secret there is most likely called ASM not Compaq-CC.
Anyway, overall this release is good. At least for PR reasons.
-- Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
I didn't see any old stories about the Compaq Smart Array driver for the RAID controllers. The driver is found at: http://www.insync.net/~frantzc/cpqarray.html As a disclaimer, I design disk controller hardware for Compaq, but I haven't personally tried this driver yet. It is in the latest kernels, so a lot of people have access to it already. I don't know how many people are actually using it yet, though. The driver is open source, GPL, and was "blessed" for release by management, but is not officially supported by Compaq. The guy who wrote it and the guy who now maintains it are both employees of Compaq, and we are working on releasing an open version of the hardware spec so that others will have an easier time implementing improvements, or alternate driver implementations.
Remember that this is a BETA release. It would not suprise me if they put the Beta under a more restrictive license to control how far the nastiness gets spread. Compaq wants to see who is using this and how in order to (I would imagine)have a better chance on getting feedback. I woundn't hesitate to start (nicely) prodding them on their intent for the final release, but don't assume that this BETA release is indiciative of the final thing.
I said: I hope that the GCC/EGCS folks download this compiler, compile a bunch of test cases with both it and GCC/EGCS, and then find all the good bits in the final assembler and put those sort of optimizations into GCC/EGCS.
jwb responds: I don't hope for anything of that sort. I believe that such an action would constitute reverse engineering of the Compaq compiler, and would therefore be against the explicit language of the license agreement.
Then I would say, get a third party to download the compiler, agree to the license agreement, compile the test cases, and then send the object files over to the GCC/EGCS folks. Do you really think that just because Compaq happened to implement a certain optimization that nobody else should be permitted to? That's just not right. And don't you think that other commercial compiler authors are looking at their competition's optimizations?
There's nothing immoral about reverse engineering.
Sometimes bugs in the code are only triggered when turning on optimization. Since the DEC compiler does much more optimization, it is possible that it triggered some latent bugs in the code.
Sigh. Unfortunately this method would also be against the license agreement. Remember, the license specifically forbids using the beta compiler for anything besides evaluation and testing.
I never said that the EGCS/GCC folks should not be able to include optimizations that are also included in the Compaq compiler. However they should develop these optimizations from their own effort or by Compaq's willing generosity, not by reverse engineering Compaq's compiler despite the license agreement.
Last, I never said there was anything immoral about reverse engineering. I do believe that violating the license agreement is immoral. Consider the license agreement to be a promise. Compaq is offering us a compiler. They are saying "Here is this compiler. You may have it if you agree to not reverse engineer it." And when you download the compiler, you are saying "Yes Compaq, I promise to not reverse engineer the compiler." Then if you decide to reverse engineer the compiler anyway, you have broken your promise, which I do think is highly immoral.
This might be a chance to get Linux some competitive SPEC scores. I was somewhat dismayed to see EGCS being beaten by up to 30% by Visual C and Intel's compiler.
15-30% improvement on integer code is nice, but the license is very corporate and not Free. Basically you can use the compiler for evaluation only and you cannot redistribute the compiler at all, for money or otherwise.
Personally I will not be using or even evaluating this compiler on my Multia (and that thing need all the optimization it can get).
If I understand it correctly, the license prohibits reverse engineering and disassembling of the software, i.e. of the compiler itself. Does this forbid to disassemble and to do reverse engineering on the *output* of the compiler, i.e. the assembler files and executables produced by the compiler ? I don't think so. If you see somebody doing well, you have a right to try to do as well without cheating.
Sure, you can look at the assembly output, but then you can't use anything you gain from that viewing in another product. Doing so would leave you extremely legally vulnerable - you've been "tainted" by viewing their code.
That's why reverse-engineering is done with a clear-room implementation. However, even that would be illegal with the license agreement. Documenting the specifics of the optimizations and passing them on to a coder is not part of "testing" a compiler.
Replying to myself, here are the offensive part sof the license at their web site
2. GRANT:
Compaq Computer Corporation ("Compaq") grants you the right to use the Software solely for testing and evaluation. The Software shall not be used for any other purpose and you agree to destroy or erase all copies of the Software upon Compaq's release of the code in final form.
You may copy the Software into the local memory or storage device of any number of computers for your testing and evaluation. The number of computers must be identified in the upcoming screen. You may make archival or back-up copies of the Software.
3. COPYRIGHT
The Software is protected by copyright laws and international treaties. Your use of the Software and associated documentation is subject to the applicable copyright laws and the express rights and restrictions of these License Agreement.
4. RESTRICTIONS
You may not rent, lease, or otherwise transfer the Software. You may not make the Software available over the internet or similar networking technology. You may not remove any copyright, trademark, or other proprietary notices from the Software or the media. You may not reverse engineer, decompile, or disassemble the Software, except to the extent Compaq cannot prohibit such acts by law.
Alpha's are superbly suitable for numbercrunching. When you are performing a series of calculations that takes say 100 days, and a comercial compiler can make your code 15% faster, you save two weeks! In that case the decision is easily made.
I hope that the GCC/EGCS folks download this compiler, compile a bunch of test cases with both it and GCC/EGCS, and then find all the good bits in the final assembler and put those sort of optimizations into GCC/EGCS.
I don't hope for anything of that sort. I believe that such an action would constitute reverse engineering of the Compaq compiler, and would therefore be against the explicit language of the license agreement.
Compaq wrote it and they are entitled to whatever licensing terms they want. While I believe that Compaq should contribute their optimiations to the community, I don't believe they should be forced to and in the absence of Compaq's willingness I guess the GNU folks are just going to have to rely on their own formidable genius and cunning to come up with a better optimized compiler.
If your going to ask that, then you could ask why should any company make a C compiler for linux, or any other compiler than Linux already provides - why should borland release C++ Builder for linux, since there's a C compiler out already, and there is KDevelop and a couple GUI builders for GCC as well. The answer is surely simple: These compilers are not the most efficient - Borland's linux C++ compiler already out performs GCC. The sooner companies release their products for linux, the better chance of getting themselves established, unlike the late comers.
I assume they are using GNU libc as the C library for their compiler. If you read/usr/include/libio.h you will discover the following text:
/* Copyright (C) 1991,92,93,94,95,97,98,99 Free Software Foundation, Inc. This file is part of the GNU IO Library. Written by Per Bothner . This library is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. [---standard GPL stuff snipped-----] As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. */
What this means is that if you compile an app with the Compaq compiler, your app is instantly covered by the GPL!!! You can compile non GPLed code with a GNU compiler and use glibc, but you can't compile non-GPLed code with glibc and a non-GNU compiler (such as Compaq's one).
This is why GPL'd libraried are bad, bad, bad (despite RMSs opinions to the contrary).
-- -Erik
--
--This message was written using 73% post-consumer electrons--
Re:Major Licence Problem!!!
by
Trepidity
·
· Score: 2
This is another good example of the vagueness and lack of enforceability rampant in Linux licensing. EGCS, until its recent merger with GCC, was not a "GNU compiler," so it could not take advantage of the exception. However, nobody seemed to pay any attention to that. It's only now, that Compaq makes a compiler, that people care.
However, Compaq has most likely written their own libraries, so the point is moot.
Re:The new EGCS from Cygnus is 20% faster than VC
by
Guy+Harris
·
· Score: 2
But then Compaq's compiler beats intel's pants down on the FP benchmarks.
Compaq's x86 compiler beats Intel's x86 compiler, or Compaq's Alpha compiler beats Intel's Alpha compiler?
(If the answer is "Compaq's Alpha compiler beats Intel's x86 compiler", that should read as "an Alpha system with an XXX MHz 21X64 and a YYY memory subsystem, running code compiled with Compaq's compiler, beat an x86 system with an XXX Mhz Pentium/Pentium Pro/Pentium II/Xeon Warrior Princess and a YYY memory subsystem, running code compiled with Intel's compiler" - crediting that win solely to the compiler requires some evidence to justify it.)
It's not about Linux.. it is all business
by
Dominican
·
· Score: 2
We at times forget that companies like compaq are in business to MAXIMISE profit. One way this can be accomplish by companies of the size of compaq is to try to use as much as possible from one's internal resources (i.e. parts) as long as one can produce them at a competitive price.
When Compaq bought Digital some time back it did so with several purposes. Ignoring all the patents, research teams and support infrastructure and concentrating in manufacturing there are a few things worth noting. By having it's own architecture Compaq can have more control on what it can do. Also the Alpha's have been known to have a good architecture. In particular Compaq had little in terms of the Unix market which traditionally has always carried greater margins than PCs.
Digital also had it's own Unix which compaq can borrow code from.
By offering more support to Linux Compaq is simply trying to position itself as a premiere hardware vendor for the platform. It could also be said that perhaps they have a good understanding of the invaluable asset which is mindshare.
Won't share source unless to their advantage
by
Dominican
·
· Score: 2
Compaq makes a big part of their income, if not most, from selling hardware. Software is mostly a means to an end for them. In this regard they try to use software to try help sales of their equipment.
My feeling is that they are probably testing the waters and see how to best use this technology to their advantage. Unless someone shows them how they will sell more computers by making this open source I think it is unlikely they will change the licensing.
It is also very possible that Linux companies (i.e. Red Hat, Caldera..) will eventually approach Compaq and try to license the technology.
I was under the impression that Compaq owned an entire Unix version. Is this not the case? For some reason I though Compaq made Alphas. If not where do Alpha's come from?
True enough. Don't forget that Compaq really has 3 markets. The x86 desktop market, the x86 server market, and the Alpha Server/Workstation Market.
In the case of Alpha, which this story reports on, Compaq owns Tru64 Unix, which runs on Alpha. It is their commercial Unix aimed at the high-end. At the low end they are starting to seriously support Linux. Primarily in this case by releasing their compiler for Alpha Linux.
Anyways, Compaq has started doing some serious support of Linux, other noteworthy stories include localizing Linux for Asian markets. Also, they've started slowing killing off NT on Alpha.
the software is only available in rpm format, and has primarily been tested under...
Why is that? I must agree that using rpm and deb is great for managing packages which are a PART of a distribution. But I see no point at all in making third party software rpm.. I prefer getting third party softare in distribution independent format(targz or whatever) and installing it in/opt/local (sort of like netscape installer).
They never said it was Open Source. I don't mind honest non-Open-Source nearly as much as I mind says-it's-open-source-but-isn't-really.
Excellent point to remember! By releasing a Linux compiler for the Alpha platform they are "pushing" Linux. That's what's important. Linux is promoted by software, not Open Source.
Open source is important. But not to get people using Linux as a viable platform, at least not always. Open source has it's place. But Compaq has chosen to make a proprietory compiler. This is good for Compaq and good for Linux. Open Source will find it's place other other software.
There are 2 things I like. One is Open Source. The other is software for "alternative" platforms. They both benefit us, and both should be accepted
-Brent --
So many assumptions, so little time...
by
untulis
·
· Score: 2
...That the GEM optimizer is easily integrated into gcc. This is the biggest one. When that optimizer isn't written in C/C++, it makes it a tad harder to work with. Even ignoring bootstrapping, running on other platforms, etc.
...That Compaq/Digital has the ability to release it as source. Maybe there is some third party code as part of the optimizer that they do not have the ability to distribute.
... That the team working on this has the bandwidth to clean this up right away. They are understaffed and overworked as it is...
Do I need to continue? Better start chowing down...
Disclaimer: I'm a Compaq employee who (indirectly) works with GEM. But I do not speak for anyone but myself.
I used to work for Digital, and I met some of the compiler team once. They are very smart people, and their compilers are very efficient and standards compliant to a point.
We have to think about why Compaq bought digital. One reason has to be for Digital's services section, which is one of the best in the world.
Another one has to be for the sheer bulk of tech genius that Digital has. Digital's problem has never been lack of innovation, it was an inability to market these innovations. ( Anyone heard any news of the Itsy? ).
Beleive me, I worked on a product 3 years ago, that still hasn't hit the shelves.
Anyway, Compaq now has a lot of specialist expertise, and it's obviously putting it to good use. We have to respect this. They can't simply buy a multi-billion tech company and start to give away the technologies for free.
Remember that the primary reason that slashdotters cclaim that companies should opensource their technologies is to help them innovate and stabalise. If this is unnecessary, then we don't really have another argument.
I think it's a step in the right direction. We have the people who built the alpha releasing compilers for Linux/Alpha. Sorted.
This is going to allow alot of alpha developers to move from Digital Unix to Linux:)
> They can't simply buy a multi-billion tech company and start to give away the technologies for free.
In general I agree with your post. However, it might be in Compaq's best interest to "give away" a compiler that made Linux way hot on Alpha, since that might influence more Linux users to buy Alpha instead of some other brand.
OTOH, it would be a matter of giving away something they had paid for, and it might even make Alpha/Linux users less likely to upgrade to Alpha/Tru64.
In short, it's a business decision. No harm in us asking for it; they've just got to see where their best interests lie.
I assume this is the GEM compiler we're talking about.
Just why is EGCS so much worse than GEM? Is it because of backend very machine-specific optimizations (code scheduling, for example), or is it simply because EGCS does not support all the (mostly) machine-independent optimizations that GEM does?
The reason I ask is that getting EGCS up to speed with the same optimizations as GEM not only helps it on Alpha, it helps it on other platforms as well.
To phrase the question another way: What is the biggest missing piece in EGCS? Analysis? Optimization? Better machine models?
The claim is that the egcs intermediate representation isn't powerful enough to do lots of optimizations that are standard in the GEM compiler. I believe that the EGCS people are aware of this and are thinking about it.
To answer this question you'd have to understand how CPU architectures have changed in the last ten years. Optimization today requires that the compiler reorder instructions using internal knowledge of how the processor works, provide branch prediction information, instruction packing into compatible groups, prefetch and invalidation support, code for recovery from speculative execution failure, and indication to the CPU of what status register flags will be used in the future so that instruction scheduling can potentially be offloaded to a faster ALU if certain flags can be ignored.
Superscalar architecture have vastly changed the way that optimization works, and VLIW Merced promises to change it even more.
I don't write compilers myself, but I know that there is a lot of research being done in these areas, complete with just as many new patents on those algorithms as you would probably anticipate.
-- LibBT: BitTorrent for C - small - fast - clean (Now Versio
The advantage is that it produces much faster code. My experience with it has been extremely positive. But what would I know, I only ran a few million lines of source through it...
Re:Makes that BSD licence look good
by
BadlandZ
·
· Score: 3
EeeGad!
It'll be a long rocky road for Linux if all of the Linux community had this "Open Source or F--- Off" attitude.
I'm all for the development of open source software, but it's going to be a while before Postges or MySql is up to the speed of Oracle, before KWord is up to Microsoft Word, before Gnumeric is up to Microsoft Excel, before GCC is up to commercial compilers, before KDeveloper is up to Code Fusion, before GnoMoney is up to Quicken, before....
There is a slow shift to open source software, that is clear. But it's not happening overnight, and there will be a place for commercial applications for quite a time to come. If all the "Microsoft Windows" software ran on Linux today, wouldn't you agree that Linux would probably have a more rapidly expanding user base? And, it the end, this would help the development of open source software?
If you notice, GCC is managed now by Cygnus, and without thier commercial products, they wouldn't have two nickels to rub together, much less host the GCC/EGCS web site, cvs site, ftp site, or the staff to help development of the compiler.
Slashdot itself is running on a MySQL database, which, if you were not aware, is NOT open source, it's commercial (to an extent). So, your post has at least been rendered up by a commercial product.
Really, I think the Linux community at large would be best served to get off of it's GPL evanglist soap box. Personally, I find no harsh things to say about the BSD licence, it's a valid licence, and I would rather see people use the BSD licence that "invent" a licence of thier own like Sun, AOL/Netscape, and Apple have done when they say they are supplying an "open source" product.
For Fortran, cross platform could be relevant
by
hawk
·
· Score: 2
If you're using Fortran, you are, most likely, bashing numbers (My dissertation wasn't number crunching, but bashing them into submission:).
This is also in a market where your are *planning* on spending $1k to $2k for your compiler & libraries.
The question isn't, "which is fastest for my platform," but "which is fastest for my budget."
The real question *is* "how does the fastest x86 compiler on the best x86 I can get my paws on compare the the fastest alpha compiler on the fastest alpha I can afford."
Two and a half years ago, our answer to that was Absoft (Nag's compiler generates c, then uses the host c compiler). The difference at the time wasn't the hardware, but that we would have had to buy digital unix to run digital's fortran. Had this compiler been available then, we almost certainly would have gone alpha. (There would also have been political complications if we had been running DU outside of ISU's Vincent system, but my boss had tenure, so . ..)
Anyway, folks don't generally buy the fortran compiler to run on hardware they already have; fortran is a major factor in determining which hardware. No, the answer may not be the same next week:) If we could have waited two weeks to order, we could have had dual 400's rather than dual 333's (which probably would have edged out the alpha). But the money would have expired, so we bought what we could.
doc hawk
epilogue: It turned out that we *really* could have used the 64 bits rather than 32--absoft uses pieces from cray, which bit addresses, meaning that 32 bit addressing limited arrays of derived types to.25gb, and I needed about.4 . ..)
but you don't need the compiler for that
by
hawk
·
· Score: 2
Isn't ths already available in the documentation for the processor? I'd be stunned if digital hasn't disclosed the information to figure out how to keep the processor busy. The question isn't what order is best, but *how* to turn your source into a useful order, which would seem to be the compiler alone.
I'd expect that it is *very* simple. It was already possible to use it on DU to compile, and then run the executables on alpha Linux. From that, I'm going to take a swag that it's not written in Fortran, or it would have been trivial, rather than simple:)
Digital has been writing and selling top-flight Fortran compilers for a *long* time, for assorted platforms. They make substantial revenues from it, and it's not just a way to sell hardware (it didn't come with DU, you paid extra for it).
A c compiler would be another story, it's (for all intents and purposes) part of unix that is necessary for a system. Fortran is necessary for certain uses of systems.
Giving away the code now would be giving away *decades* of expertise. It might ultimately be worth their doing this. Otoh, it precludes a lot of their long term options.
Slashdot Mirror
The questions wasn't "will people pay for this software?"
It was more along the lines of "why does Compaq think this will sell hardware?" This is obviously a marketing move in order to get themselves inbed with the OSS crowd. It makes no sense to target the "I'll spend $500 on a compiler" crowd on linux. If we were into spending money on our software, we'd be running True64 anyhow because although I don't have any numbers to back this up I'm sure it runs oodles faster than Linux on an Alpha.
The entire point of my comment was to point out that Intel is one of the few hardware vendors that has their heads on straight on how to make money from us (nVidia being another). The whole goal should be to sell chips (and motherboards, and complete systems, etc.) and not compilers. I'm no closer to buying a Alpha then an hour ago before I saw this story. On the other hand I've been foaming at the mouth for a Mercede since Intel is throwing support towards projects that are things I care about.
This is not a story about the merits of their new compiler. It's a story about a half assed attempt by Compaq to rally support behind their chip.
Yes this is pretty much critisism, and much of it is just plain and sheer paranoia, but still. Let us make Compaq understand that software for Linux is good. And it is even better if we get it in GPL. If this is a step in the direction of getting this compiler's optimization code into GCC and thus making it GPL, I WILL eat my words in public if so desired. But for now, some public synicism should be shown in order to bring it correct.
I do expect to get a lot of comments on this and I will check back and read it all. Just please be at least a bit constructive when arguing with me. I like to learn of new views. GNU is all about sharing information. I shared my views with you, please share yours with me.
Wealth is the product of man's capacity to think. -Ayn Rand
In other words, code scheduling. :)
prefetch and invalidation support
Does EGCS do prefetching? How's it done on the Alpha? On the MIPS it's simply a load to $0, I believe.
code for recovery from speculative execution failure
I'm not sure what you're getting at here. The 21264 is an O-O-O machine. For Merced this sort of thing is going to be critical. And I suppose if you want to use some profile information and optimize for that, this could come into play.
I don't believe EGCS makes use of any profiling. That seems to be a big missing piece.
Superscalar architecture have vastly changed the way that optimization works, and VLIW Merced promises to change it even more.
This is true, but it is amazing how much of a difference the simple "classical" optimizations can make. Things like Common Subexpression Elimination, Loop Invariant Code Motion (both grouped under Partial Redundancy Elimination) and Induction Variable optimizations are important. EGCS only recently got a global CSE optimizer!
--
Quick and ugly test using bytebench:
/usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/specs - -----:------------
- -----:------------
- -----:------------
~$ cc -v
Reading specs from
gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------
NUMERIC SORT : 271.48 : 6.96 : 2.29
STRING SORT : 24.804 : 11.08 : 1.72
BITFIELD : 6.4238e+07 : 11.02 : 2.30
FP EMULATION : 12.91 : 6.19 : 1.43
FOURIER : 2134.8 : 2.43 : 1.36
ASSIGNMENT : 2.4236 : 9.22 : 2.39
IDEA : 587.56 : 8.99 : 2.67
HUFFMAN : 241.78 : 6.70 : 2.14
NEURAL NET : 3.3857 : 5.44 : 2.29
LU DECOMPOSITION : 112.92 : 5.85 : 4.22
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 8.390
FLOATING-POINT INDEX: 4.259
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
C compiler : gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
libc : unknown version
MEMORY INDEX : 2.114
INTEGER INDEX : 2.079
FLOATING-POINT INDEX: 2.362
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
ccc:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------
NUMERIC SORT : 285.47 : 7.32 : 2.40
STRING SORT : 26.566 : 11.87 : 1.84
BITFIELD : 5.3653e+07 : 9.20 : 1.92
FP EMULATION : 13.576 : 6.51 : 1.50
FOURIER : 12000 : 13.65 : 7.67
ASSIGNMENT : 2.3567 : 8.97 : 2.33
IDEA : 482.21 : 7.38 : 2.19
HUFFMAN : 342.29 : 9.49 : 3.03
NEURAL NET : 7.1348 : 11.46 : 4.82
LU DECOMPOSITION : 172.66 : 8.94 : 6.46
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 8.524
FLOATING-POINT INDEX: 11.184
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
C compiler : ccc (unknown version)
libc : unknown version
MEMORY INDEX : 2.018
INTEGER INDEX : 2.213
FLOATING-POINT INDEX: 6.203
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
There are +/- in all integers and strings but there is no definite winner there. There is a huge difference in floating point benches, but what do you expect. Compaq links versus cpml egcs links versus libm which is far from where it should be.
Having a second thought let us see what compaq actually does. Hmmm, it looks like all math functions are redefined for Linux to use their "fast" low precision easily crashing equivalents. Lame...
So now let us see what happens if we go like compaq and use gcc and the compaq math library and the same lame technique:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------
NUMERIC SORT : 277.1 : 7.11 : 2.33
STRING SORT : 25.041 : 11.19 : 1.73
BITFIELD : 6.4264e+07 : 11.02 : 2.30
FP EMULATION : 12.935 : 6.21 : 1.43
FOURIER : 13231 : 15.05 : 8.45
ASSIGNMENT : 2.4256 : 9.23 : 2.39
IDEA : 587.65 : 8.99 : 2.67
HUFFMAN : 243.2 : 6.74 : 2.15
NEURAL NET : 4.3012 : 6.91 : 2.91
LU DECOMPOSITION : 114.41 : 5.93 : 4.28
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 8.437
FLOATING-POINT INDEX: 8.510
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
C compiler : gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
libc : unknown version
MEMORY INDEX : 2.121
INTEGER INDEX : 2.094
FLOATING-POINT INDEX: 4.720
Suddenly whe are better then compaq on fourie... And our math is definitely looking better... Hi, hi, hi, hi...
Overall Compaq math library better than libm, some other lib functions as well, but the secret there is most likely called ASM not Compaq-CC.
Anyway, overall this release is good. At least for PR reasons.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
I didn't see any old stories about the Compaq Smart Array driver for the RAID controllers. The driver is found at: http://www.insync.net/~frantzc/cpqarray.html As a disclaimer, I design disk controller hardware for Compaq, but I haven't personally tried this driver yet. It is in the latest kernels, so a lot of people have access to it already. I don't know how many people are actually using it yet, though. The driver is open source, GPL, and was "blessed" for release by management, but is not officially supported by Compaq. The guy who wrote it and the guy who now maintains it are both employees of Compaq, and we are working on releasing an open version of the hardware spec so that others will have an easier time implementing improvements, or alternate driver implementations.
--Chris Caudle
Remember that this is a BETA release. It would not suprise me if they put the Beta under a more restrictive license to control how far the nastiness gets spread. Compaq wants to see who is using this and how in order to (I would imagine)have a better chance on getting feedback. I woundn't hesitate to start (nicely) prodding them on their intent for the final release, but don't assume that this BETA release is indiciative of the final thing.
I said: I hope that the GCC/EGCS folks download this compiler, compile a bunch of test cases with both it and GCC/EGCS, and then find all the good bits in the final assembler and put those sort of optimizations into GCC/EGCS.
jwb responds: I don't hope for anything of that sort. I believe that such an action would constitute reverse engineering of the Compaq compiler, and would therefore be against the explicit language of the license agreement.
Then I would say, get a third party to download the compiler, agree to the license agreement, compile the test cases, and then send the object files over to the GCC/EGCS folks. Do you really think that just because Compaq happened to implement a certain optimization that nobody else should be permitted to? That's just not right. And don't you think that other commercial compiler authors are looking at their competition's optimizations?
There's nothing immoral about reverse engineering.
314-15-9265
Sometimes bugs in the code are only triggered when turning on optimization. Since the DEC compiler does much more optimization, it is possible that it triggered some latent bugs in the code.
I never said that the EGCS/GCC folks should not be able to include optimizations that are also included in the Compaq compiler. However they should develop these optimizations from their own effort or by Compaq's willing generosity, not by reverse engineering Compaq's compiler despite the license agreement.
Last, I never said there was anything immoral about reverse engineering. I do believe that violating the license agreement is immoral. Consider the license agreement to be a promise. Compaq is offering us a compiler. They are saying "Here is this compiler. You may have it if you agree to not reverse engineer it." And when you download the compiler, you are saying "Yes Compaq, I promise to not reverse engineer the compiler." Then if you decide to reverse engineer the compiler anyway, you have broken your promise, which I do think is highly immoral.
-jwb
This might be a chance to get Linux some competitive SPEC scores. I was somewhat dismayed to see EGCS being beaten by up to 30% by Visual C and Intel's compiler.
Personally I will not be using or even evaluating this compiler on my Multia (and that thing need all the optimization it can get).
-jwb
Hrm, this seems good and all, but why make their own compiler?
If all they did was create a compiler with Alpha specific optimizations then why not just throw those into gcc?
Intel seems to still know what (OSS) nerds want. Their development on the Mercede compiler with Cygnus is still way ahead in the OSS game.
What this means is that if you compile an app with the Compaq compiler, your app is instantly covered by the GPL!!! You can compile non GPLed code with a GNU compiler and use glibc, but you can't compile non-GPLed code with glibc and a non-GNU compiler (such as Compaq's one).
This is why GPL'd libraried are bad, bad, bad (despite RMSs opinions to the contrary).
-Erik -- --This message was written using 73% post-consumer electrons--
Compaq's x86 compiler beats Intel's x86 compiler, or Compaq's Alpha compiler beats Intel's Alpha compiler?
(If the answer is "Compaq's Alpha compiler beats Intel's x86 compiler", that should read as "an Alpha system with an XXX MHz 21X64 and a YYY memory subsystem, running code compiled with Compaq's compiler, beat an x86 system with an XXX Mhz Pentium/Pentium Pro/Pentium II/Xeon Warrior Princess and a YYY memory subsystem, running code compiled with Intel's compiler" - crediting that win solely to the compiler requires some evidence to justify it.)
We at times forget that companies like compaq are in business to MAXIMISE profit. One way this can be accomplish by companies of the size of compaq is to try to use as much as possible from one's internal resources (i.e. parts) as long as one can produce them at a competitive price.
When Compaq bought Digital some time back it did so with several purposes. Ignoring all the patents, research teams and support infrastructure and concentrating in manufacturing there are a few things worth noting.
By having it's own architecture Compaq can have more control on what it can do. Also the Alpha's have been known to have a good architecture. In particular Compaq had little in terms of the Unix market which traditionally has always carried greater margins than PCs.
Digital also had it's own Unix which compaq can borrow code from.
By offering more support to Linux Compaq is simply trying to position itself as a premiere hardware vendor for the platform. It could also be said that perhaps they have a good understanding of the invaluable asset which is mindshare.
Compaq makes a big part of their income, if not most, from selling hardware. Software is mostly a means to an end for them. In this regard they try to use software to try help sales of their equipment.
My feeling is that they are probably testing the waters and see how to best use this technology to their advantage. Unless someone shows them how they will sell more computers by making this open source I think it is unlikely they will change the licensing.
It is also very possible that Linux companies (i.e. Red Hat, Caldera..) will eventually approach Compaq and try to license the technology.
True enough. Don't forget that Compaq really has 3 markets. The x86 desktop market, the x86 server market, and the Alpha Server/Workstation Market.
In the case of Alpha, which this story reports on, Compaq owns Tru64 Unix, which runs on Alpha. It is their commercial Unix aimed at the high-end. At the low end they are starting to seriously support Linux. Primarily in this case by releasing their compiler for Alpha Linux.
Anyways, Compaq has started doing some serious support of Linux, other noteworthy stories include localizing Linux for Asian markets. Also, they've started slowing killing off NT on Alpha.
=Brent--
the software is only available in rpm format, and has primarily been tested under...
/opt/local (sort of like netscape installer).
Why is that? I must agree that using rpm and deb is great for managing packages which are a PART of a distribution. But I see no point at all in making third party software rpm.. I prefer getting third party softare in distribution independent format(targz or whatever) and installing it in
I don't mind honest non-Open-Source nearly as much as I mind says-it's-open-source-but-isn't-really.
Excellent point to remember! By releasing a Linux compiler for the Alpha platform they are "pushing" Linux. That's what's important. Linux is promoted by software, not Open Source.
Open source is important. But not to get people using Linux as a viable platform, at least not always. Open source has it's place. But Compaq has chosen to make a proprietory compiler. This is good for Compaq and good for Linux. Open Source will find it's place other other software.
There are 2 things I like. One is Open Source. The other is software for "alternative" platforms. They both benefit us, and both should be accepted
-Brent--
...That the GEM optimizer is easily integrated into gcc. This is the biggest one. When that optimizer isn't written in C/C++, it makes it a tad harder to work with. Even ignoring bootstrapping, running on other platforms, etc.
...That Compaq/Digital has the ability to release it as source. Maybe there is some third party code as part of the optimizer that they do not have the ability to distribute.
... That the team working on this has the bandwidth to clean this up right away. They are understaffed and overworked as it is...
Do I need to continue? Better start chowing down...
Disclaimer: I'm a Compaq employee who (indirectly) works with GEM. But I do not speak for anyone but myself.
I used to work for Digital, and I met some of
:)
the compiler team once. They are very smart people, and their compilers are very efficient and standards compliant to a point.
We have to think about why Compaq bought digital. One reason has to be for Digital's services section, which is one of the best in the world.
Another one has to be for the sheer bulk of tech genius that Digital has. Digital's problem has never been lack of innovation, it was an inability to market these innovations. ( Anyone heard any news of the Itsy? ).
Beleive me, I worked on a product 3 years ago, that still hasn't hit the shelves.
Anyway, Compaq now has a lot of specialist expertise, and it's obviously putting it to good use. We have to respect this. They can't simply buy a multi-billion tech company and start to give away the technologies for free.
Remember that the primary reason that slashdotters cclaim that companies should opensource their technologies is to help them innovate and stabalise. If this is unnecessary, then we don't really have another argument.
I think it's a step in the right direction. We have the people who built the alpha releasing compilers for Linux/Alpha. Sorted.
This is going to allow alot of alpha developers to move from Digital Unix to Linux
-- hjw http://puzl.info/
Just why is EGCS so much worse than GEM? Is it because of backend very machine-specific optimizations (code scheduling, for example), or is it simply because EGCS does not support all the (mostly) machine-independent optimizations that GEM does?
The reason I ask is that getting EGCS up to speed with the same optimizations as GEM not only helps it on Alpha, it helps it on other platforms as well.
To phrase the question another way: What is the biggest missing piece in EGCS? Analysis? Optimization? Better machine models?
--
The advantage is that it produces much faster code. My experience with it has been extremely positive. But what would I know, I only ran a few million lines of source through it...
It'll be a long rocky road for Linux if all of the Linux community had this "Open Source or F--- Off" attitude.
I'm all for the development of open source software, but it's going to be a while before Postges or MySql is up to the speed of Oracle, before KWord is up to Microsoft Word, before Gnumeric is up to Microsoft Excel, before GCC is up to commercial compilers, before KDeveloper is up to Code Fusion, before GnoMoney is up to Quicken, before....
There is a slow shift to open source software, that is clear. But it's not happening overnight, and there will be a place for commercial applications for quite a time to come. If all the "Microsoft Windows" software ran on Linux today, wouldn't you agree that Linux would probably have a more rapidly expanding user base? And, it the end, this would help the development of open source software?
If you notice, GCC is managed now by Cygnus, and without thier commercial products, they wouldn't have two nickels to rub together, much less host the GCC/EGCS web site, cvs site, ftp site, or the staff to help development of the compiler.
Slashdot itself is running on a MySQL database, which, if you were not aware, is NOT open source, it's commercial (to an extent). So, your post has at least been rendered up by a commercial product.
Really, I think the Linux community at large would be best served to get off of it's GPL evanglist soap box. Personally, I find no harsh things to say about the BSD licence, it's a valid licence, and I would rather see people use the BSD licence that "invent" a licence of thier own like Sun, AOL/Netscape, and Apple have done when they say they are supplying an "open source" product.
If you're using Fortran, you are, most likely, bashing numbers (My dissertation wasn't number crunching, but bashing them into submission
This is also in a market where your are *planning* on spending $1k to $2k for your compiler & libraries.
The question isn't, "which is fastest for my platform," but "which is fastest for my budget."
The real question *is* "how does the fastest x86 compiler on the best x86 I can get my paws on compare the the fastest alpha compiler on the fastest alpha I can afford."
Two and a half years ago, our answer to that was Absoft (Nag's compiler generates c, then uses the host c compiler). The difference at the time wasn't the hardware, but that we would have had to buy digital unix to run digital's fortran. Had this compiler been available then, we almost certainly would have gone alpha. (There would also have been political complications if we had been running DU outside of ISU's Vincent system, but my boss had tenure, so . .
Anyway, folks don't generally buy the fortran compiler to run on hardware they already have; fortran is a major factor in determining which hardware. No, the answer may not be the same next week
doc hawk
epilogue: It turned out that we *really* could have used the 64 bits rather than 32--absoft uses pieces from cray, which bit addresses, meaning that 32 bit addressing limited arrays of derived types to
Isn't ths already available in the documentation for the processor? I'd be stunned if digital hasn't disclosed the information to figure out how to keep the processor busy. The question isn't what order is best, but *how* to turn your source into a useful order, which would seem to be the compiler alone.
I'd expect that it is *very* simple. It was already possible to use it on DU to compile, and then run the executables on alpha Linux. From that, I'm going to take a swag that it's not written in Fortran, or it would have been trivial, rather than simple :)
Digital has been writing and selling top-flight Fortran compilers for a *long* time, for assorted platforms. They make substantial revenues from it, and it's not just a way to sell hardware (it didn't come with DU, you paid extra for it).
A c compiler would be another story, it's (for all intents and purposes) part of unix that is necessary for a system. Fortran is necessary for certain uses of systems.
Giving away the code now would be giving away *decades* of expertise. It might ultimately be worth their doing this. Otoh, it precludes a lot of their long term options.
I would have sworn when I read the title yesterday that we were talking about Fortran. Never mind. I'll wait for the Fortran release to get excited
Which this isn't :)
Why didn't I notice this until I'd posted 3 comments?
I don't mind honest non-Open-Source nearly as much as I mind says-it's-open-source-but-isn't-really.
Bruce
Bruce Perens.