Posted
by
Hemos
on Tuesday March 23, 1999 @03:32AM
from the good-press-coeverage dept.

phlebas writes "Cnet news has an article about how "Compaq Computer sees Linux as a way to increase sales of its Alpha microprocessor, and the company is trying to encourage other Linux distributors besides Red Hat to support the chip." They ar also plannig to "soon introduce new pricing geared to encourage Linux users to "step up" from Intel to Alpha chips." Maybe after all i'll be able to get one those in my lifetime " I think it's pretty clear that Linux is the way for Compaq's to really push the Alpha-let's hope they actually do it.

And the R&D money they save can become a capital investment in chip fabricators. Intel has the big chip fab investments today, which is why they have such a price/performance ratio. If Compaq sinks money into chip fabs, and does it well, they can again drop the price of an Alpha

Didn't Digital sell their fabs to Intel? I suppose that gives them a nice clean slate to build fabs for the next generation of 2xx64 chips, but I thought they wanted to be out of the production business.

Besides, Samsung makes Alphas, and though they might not be on the NASDAQ, Samsung is _huuuuuge_..

DEC sold its fabs to intel (using the lawsuit as a bargaining tool) because it was not cost effective to run wafer fabs for low volume high margin production and it got their bottom line in shape for sale to Compaq. Both Sun and HP outsource their chip production very effectively.

Conventional wisdom says you have to be IBM sized to run your own fabs. There are rumors that Compaq wants its own fab - they want to be IBM's size - but the best way to do that would be to pick up a state of the art chip manufacturer such as AMD, rather than build their own from sctratch.

The best place for Linux based alphas right now is as low end single function servers where the market has historically been NT/Netware for real and perceived cost reasons. For example many dedicated Unix customers use NT or Novell for print services because the hardware was cheap even if the OS license price was ridiculously high for the functionality received. An Alpha with Linux can replace two to four x86 NT print servers for the price of one two two servers and its more reliable as well. In the ISP market Linux/Apache/Alpha makes a great high capacity web server. When the Customer needs a High performance database as well then the ISP rolls out the 14 processor Digital Unix/Oracle solution.

Let's forget about legacy code. We do molecular simulations, and all our code is f90. DEC's f90 is the only reason we haven't switched our Alpha workstations to Linux. We haven't seen a good, native f90 compiler for Alpha Linux as of yet other than DEC's. We know our codes run about 4 times faster on our 21164 Alpha-based workstations than on a Pentium II, III, or whatever. And we are just drooling over the 21264 Alphas...

We keep our fingers crossed that DEC will port f90 to Linux, but I think they will be reluctant to give up their DEC Unix license fees. However, with Compaq pushing Linux on its low-end alphas, it might not be too long before they see some benefits on high end workstations.

Comparing a new Intel to an old Alpha? Not very fair is it? Try comparing the 21264 to a PIII and you'll think different. Just bought a 500mhz alpha + mobo for $450. Even under emulation on NT, it runs faster than a Pro 200mhz. I/O is night and day (150% faster). This isn't even with native apps or 64-bit code. Goodbye Intel...Hello Alpha.

In the Bad Old Days, "big iron" vendors wrote OSs mostly for the purpose of selling their iron. The margin on such an OS is low (perhaps negative), but the tie-in value is high.

The problem with this is that you have to spend a tremendous R&D budget "keeping up with the Joneses". If you don't, you're selling a second-rate OS and thus a second-rate platform. Realize that this is R&D _just to tread water_, not to gain share.

This problem is made worse by the fact that Linux is already ported to Alphas. The "Joneses" have a tremendous R&D budget, measured in terms of engineering hours as opposed to dollars. Compaq is likely unable to keep Digital Unix up with Linux.

The worst part is that, if they keep developing Digital Unix to compete with Linux on their own platform, they split the application base. Some shops won't be able to afford to port to two Alpha platforms. The application base splits, the user base splits, and you again lose market share.

Pushing Linux is the perfect solution for Compaq. Sure, they lose their OS revenue. They also drop a huge R&D budget, merge the Alpha Unix user base into one critical mass, and assure them that they will have a state-of-the-art OS, regardless of Compaq's corporate decisions. They can also direct their attention to selling _hardware_ versus _hardware and OS_. The OS will take care of itself. They also drop the price of an Alpha to the point where people can seriously consider putting it on their desktop _and_ their backend servers.

They can still sell support contracts at a higher rate than any other support organization, because they have the Name and because they sell the hardware. They can produce new hardware drivers cheap, by pre-releasing specs to select groups of users. And the R&D money they save can become a capital investment in chip fabricators. Intel has the big chip fab investments today, which is why they have such a price/performance ratio. If Compaq sinks money into chip fabs, and does it well, they can again drop the price of an Alpha. They can increase sales volume and margin simultaneously.

In short, Compaq loses a direct source of revenue by pushing Linux. They also lose a lot of indirect costs and market share, and stand to make more profit in other ways by pushing Linux. Trust me, the dollar signs say that they're doing the right thing.

"Compaq is realizing how much time and $$ Digital poured into the Alpha. Giving up on that would be pissing money down the toilet."

Actually this is a common economic misconception. An economist would say this is a sunk cost. It is money that has already been spent and cannot be recovered, and therefore it should not be a factor in considering future investments. The MBA's at Compaq surely know this. The point is that Compaq will only continue putting money into Alpha if they think they can make a profit on it (technically, if the project has a positive net present value: the discounted value of future income minus cost.)

sorry, i'm waxing pedantic just to prove to myself that i actually learned something when i tortured myself with all those econ classes.

people dont buy alphas blindly (at least lets hope not). lots of people buy alphas for linux. intel helped cygnus optimize gcc for intel. those looking for compiler performance will know this. it speaks louder than trying to sell the dec compiler for linux (somehow i suspect thats what you want to do) another compiler is a hard sell on very GNUish platforms. do the same thing, youll recover the costs in selling alphas alot faster than in sales of your super optimizing compiler.

You likely will need massive memory and IO bandwidth to complement an insanely fast CPU...I can fantasize about an Alpha in an Octane or an Origin, that would be a complete screamer...

There was an article on The Register yesterday about upcoming Compaq Alpha building blocks -- modular system components that would make a real Origin-killer (bandwidth out the gazoo!! Have a look at this [theregister.co.uk]

Thats ounds good, right? Why don't they do it? Alpha is an "open" architecture, supposedly. If they don't make BeOS for the G3 because Apple wont release the G3 specs, will Compaq release the Alpha system specs to Be? Is there an interest in Be/Alpha or am I mistaken?

Might it really have something to do with Intels "investment" in Be? It's far easier to forgive your enemy after you get even with him.

I doubt a high-end free fortran is in the forseeable future (but hopefully I'm wrong).

In applications for which Fortran is appropriate, performance tends to count. When we bought the dual PII linux box last year, we paid about $10k for the box, and another $1k for absoft fortran (a cray derivative), imsl, and a set of multiprocesor libraries. Had there been a free alternative, we probably still would have bought this over a 10% difference in performance--and it's much more than that. Also, we need F90 features, and could have used F95 (there's places that i have to write several lines of F90 to duplicate F95 features, and I'd kill for true arrays of pointers).

Then again, what we *really* want is Digital Fortran for Linux. It sounds like they're working on it in house, but haven't decided whether to go ahead. Had it been available, we probably wouldn't have even looked at any of the alternatives.

/flamebait{} Open source meant absolutely nothing to us in this decision. We took linux for it's stability (ok, and I probably wouldn't have agreed to work for him if it meant I had to use NT:) Not that I could, anyway; he's across campus from me, and I ssh into his machine from mine).

We needed the most bang for the bucks he'd been budgetted, and on a stable system. The choices came down to linux x86, alpha linux (too risky a year ago), and alpha DU. Given the prices that month, the x86 with linux was the best choice. Though it's a pity we couldn't have waited another month (the money would have gone *poof*), as we had to take 333's since a dual MB for 100mhz wasn't out yet:(

And for the record, we're tickled pink with Absoft. The tech support is spectacular; usually by the next day, and frequently the same day if we write in the morning. I even got a message back from they're tech support after I posted a question (thought it was general F90) in comp.languages.fortran. The real kicker: their tech support gets back to us every time faster than NAG sales ever got back [I've been told since then that NAG tech support is also faster than NAG sales. I have no idea how you stay in business that way.

I doubt it. By embracing Linux, they gain a shot at the home market which would never pay for a DU license. It allows them to break into a whole new market.

For people who need servers, though, they'll still be able to sell DU licenses, because DU does have some features that Linux lacks. For example, Digital's Fortran compiler is a lot better than g77. That's still important for people who need to support lots of legacy code.

So they gain in the home market, without hurting their server market too much. Well worth it.

Also worth noting is that Alphas have been available with NT for years now. Embracing NT probably dropped more DU licenses than Linux would, and NT doesn't gain you much of anything on the home front.

With Intel running very quickly into the x86 architectural brick wall, and Merced proving to be the CPU equivalent of Winbloze 2.000, I think Alphas have a good chance of regaining some market share, at least server side. Especially since they run Linux faster than anything Intel has put out so far.

This company has some *KILLER* Alpha boxen, they have enough horsepower to blow away *ANY* PII,PIII box on the market. And the kicker is, that they use industr standard peripherals! Standard PCI Video cards, SCSI controllers, standard DIMMS, standard USB stuff... My Alpha board is very similar to my fiance's ASUS P2B Intel based board.

Now I think you should check on that CPU fan thing though. Mine has a honking HUGE fan on it! And, well... All CPU's use IRQ's, it's just up to the BIOS/Operating System, as to how they are implemented. You are correct in that my board assignes an IRQ to a slot though, not a peripheral.

> the company is trying to encourage other Linux distributors besides Red Hat to support the chip.

I was a little surprised when I read this so I checked SuSE, PHT and Caldera but no, it really seems like only Debian and RedHat supports the Alpha. Or is there specialised Alpha distributions hiding somewhere?

From the specs I've seen, if Compaq wants to "help" Linux the best thing they could do would be to donate some time to gcc on Alpha. Everything I've seen shows Digital Unix (oh errr I mean "Tru64 Unix") cc being up to twice as fast as gcc. Getting a fast box is somewhat useless if the compiler throughs away even a quarter of your performance.

AFAIK, Digital Unix is based on the original UNIX tree, meaning Compaq is probably paying a signficiant amount of money per copy of Digital Unix in license fees to the current holder(s) of the UNIX source.

If memory serves, SGI gave these costs as one of the reasons for sponsering Linux/MIPS development.

I believe that they make their money from selling the alpha processor and not the operating system, so in effect, they don't care which operating system you use, if it encourages you to buy an alpha processor.

Beg your pardon? I'm using Netscape 4.51 on an Alpha running Linux right now. Not sure what you mean by a "usable browser", because this is what darn near everyone else is using. It helps if you have the required DEC libraries sitting around (like on Digital Unix media), but there are always ways to get around that.

What you are saying would be true if the year were 1995 or 1996. The compiler issue is exactly why I put off buying an Alpha until within the last year. With the progress egcs has made, number crunching code on the Alpha really flies - and it's still not fully optimized! Compaq donated their math library to the Linux community (check www.alphalinux.org for the link to it), which provides at least twice the floating point performance as the GNU libm. I'm using it on almost every math-intense software on my system right now. The only directly Linux on the Alpha platform has is straight ahead. Things are only going to get better, especially in light of the speculated failures of Intel products (Merced).

Well, I'm in the opposite boat (prefer Linux over BSD), but was involved in the BSD world (NetBSD/FreeBSD) for several years alongside Linux.

My system is a PWS 500 with both SRM and AlphaBIOS installed, though the hardware is of course only supported by AlphaBIOS. Here's my understanding of the free BSD "situation" when it comes to Alphas:

There are some copyright issues with CMU which have "tied up" the NetBSD alpha port. I only say this because I witnessed a short "flamefest" on the FreeBSD-axp list in which some NetBSD folks cried foul about some code used, and threatened to call their lawyer friends at CMU about it. What I speak is true - look it up on Dejanews if you care to. I also believe this is the reason OpenBSD "abandoned" their alpha port, see their page for more details.

I think that copyright issue is the one major hinderance to free BSD on the alpha platform. I am, however, very pleased to see the FreeBSD port moving along, and planning to add support for ARC/AlphaBIOS firmware this year. Having worked in a predominately SysV environment for a few years now, I doubt I'd be happy going back to BSD - but I still am very happy to see FreeBSD's progress.

Totally agree with you there. Marketing will make or break the Alpha architecture, regardless of technological superiourity. The wise consumer will purchase an Alpha no matter what the marketing department spews, but how will that wise consumer know of the technology available unless a good marketing team presents it to him or her? Check out www.alphalinux.org - it's a group dedicated to seeing Linux on the Alpha platform continue into the future.

If you're the same "cjs" I know from elsewhere, maybe you can clear this one up about NetBSD. As I posted in a previous comment, I/think/ the NetBSD alpha port is held up by various copyright "issues" involving CMU - this is why the OpenBSD alpha port is supposibly dead. I do remember a blitzkrieg of flamage on the FreeBSD-axp list a while back when the FBSD crew used source code from NBSD without asking, and two or three people threatened to "call our lawyer friends at CMU" on the issue. What's the real story on this?

Sure, you can find one at http://www.alphalinux.org/ or follow these instructions.

Compile a kernel with UFS support and mount your Digital Unix 4.x media. You need the following files: /etc/sia/[matrix.conf & siainitgood] /etc/svc.conf /sbin/loader /usr/shlib/* All you do is copy these files into the same locations on your Linux filesystem, and you're ready to run Digital Unix 4.x binaries.

I am very pragmatic about platform support - I believe in using the right tool for the job. It sounds like you're looking for mainly gaming support and performance, which I'm sure a Celeron can accomidate. Me, I do numerical analyses and large matrix operations that would probably gag any x86 (and believe me, I've tried). Everything is about location, location, location. The market target for Alpha systems is not really the home user per se, but it may become as speeds increase (~1200Mhz by the end of the year) and prices drop.

Thats ounds good, right? Why don't they do it? Alpha is an "open" architecture, supposedly. If they don't make BeOS for the G3 because Apple wont release the G3 specs, will Compaq release the Alpha system specs to Be? Is there an interest in Be/Alpha or am I mistaken?

Might it really have something to do with Intels "investment" in Be?

I doubt it. Alpha systems are mainly used for research and as servers; BeOS is intended for personal use for people doing multimedia-related design. There just isn't any overlap. As far as Be is concerned, there is no market for an Alpha port of BeOS.

If Alphas actually do start showing up on desktops in quantity, then this will probably change. I know *I'd* like one.

The use of "code" as a synonym for program seems to be popular with hard core engineers and programmers. When people talk about "codes", they are often referring to programs that do heavy duty number crunching, such as hydrodynamics, finite element analysis, weather prediction. Often in association with fortran programs that run on Crays or other "real computers".

I have an AS200 4/233, 8MB TGA card, 96MB ram and a bunch of drives, running RH 5.2 and kernel 2.2.3. It makes a fine server, though not as fast as a comprably priced Intel box. Apache is repsonsive and samba is tolerable.

As a workstation it sucks; the only stable web browser I know of is the KDE browser. I did run it for a while, but KDE is a dog on alpha.

Installation was also a pain... without comp.os.linux.alpha I'd have never gotten past the initial install issues and X configuration.

I'd say if you have an Alpha sitting around or you can get one for next to nothing, do it. I wouldn't recommend spending a lot of money on a machine as your workstation unless you need the computational power and are prepared to write or modify applications so they will run. Don't expect it to be easy.

DU helps them in the short term because it gets them in the door for the big unix-based datacenter market (along with Sun, HP, IBM), but if a couple years Linux/Alpha can get them in there, I don't see much of a future for Tru64.

Apparently Compaq is treating the VMS community like a redheaded stepchild. Unlike DEC, Compaq will probably much quicker to drop their legacy base when it suits them.--

I've never seen an alpha in my life. I've heard various (all good) things about them... from what I've heard they are THE BOMB. Anyone who has one, can they point me to a good link for info on the hardware?

The things I heard that really struck me as cool is the lack of CPU fan and the lack of IRQs (devices are referred to by slot?).--Paranoid

I'd avoid these; they're UDB boxen (also known as Multias, when running Windows NT), which have a 21066, not a 21064 in them. The memory controller built into the 21066 is quite slow (about 1/2 to 1/3 the performance of a 486) so though the CPU itself will perform like a P166 when running out of the first-level cache, the overall feel is more like a P100.

You're better off with an AS200 or something like that, if you're looking in this price range. If you want something with modern performance, however, you'll need to get a 21164 running at a reasonably high speed (433 MHz or above).

There are some copyright issues with CMU which have "tied up" the NetBSD alpha port. I only say this because I witnessed a short "flamefest" on the FreeBSD-axp list in which some NetBSD folks cried foul about some code used, and threatened to call their lawyer friends at CMU about it. What I speak is true - look it up on Dejanews if you care to.

Well, that's quite a misrepresentation. If you check out the thread starting with this [freebsd.org] thread, you'll see that though it is indeed a flamefest, it was merely over the lack of a proper copyright notice on a file taken from NetBSD, and with that notice added, the problem was resolved.

I also believe this is the reason OpenBSD "abandoned" their alpha port, see their page for more details.

They don't appear to claim on their web page that their port is `abandoned,' though it is admittedly well behind the NetBSD port these days in terms of functionality.

I think that copyright issue is the one major hinderance to free BSD on the alpha platform.

No, there are no copyright issues at this time. Please don't spread FUD.

"FUD", excuse me? The future of FreeBSD/axp was in jeopardy because of this "FUD" you refer to.

Look, I've been subscribed to port-alpha@netbsd.org for years, and port-alpha@freebsd.org since it started. I've been heavily involved in the NetBSD/alpha port, and was acting portmaster for it at one point. I think I know whereof I speak.

You, on the other hand, not only cannot come up with any record of messages that back up your statements, but can't even get the name of the FreeBSD mailing list or port right! (It's the "alpha" port and mailing list, not "axp".)

So unless you can come up with something more than argument by unsubstantiated assertion, I think we can lay this to rest.

Compaq is realizing how much time and $$ Digital poured into the Alpha. Giving up on that would be pissing money down the toilet. But Compaq also knows how to move computers: Make them fast, reliable and affordable. Linux does these things.

I believe you are wrong. Where can they make the profit? Digital, er, Compaq has to pay *huge* license fees to sell Digital Unix. They even have to pay license fees on the PROMs they have to ship for booting DU (the SRM console).. when they sell NT (or Linux) they can ship the ARC PROMs instead which is cheaper.Look at the price difference between the two alternatives: DU with SRM console, Linux with ARC console. Now tell me where they make their huge profit?Better to rip it away and sell them cheaper. Hell, if DEC had aggresively pushed Alpha workstations with Linux (in my country) a couple of years back I guarantee we had been an Alpha workstation company now, instead of Sun/SGI..TA

You're really right about the compiler performance issues. Code compiled with gcc on Alpha machines is ridiculously slow--there is a need for some REAL work on optimization. Since most of what's in a Linux installation is compiled using gcc, an Alpha Linux installation tends to crawl as well. The horrible consequence of all this is that many people wanting to use their alpha boxes for intense floating-point calculations end up installing Windows NT--a criminal thing to have to do with such nice machines.

Alpha is the fastest, and will remain so until at least midway thru 2003, in Q4 99' they will have a 1.2 Gz chip coming out. Gartner Group just put out a piece detailing all the UNIX/PC harware plans thru 2003, and Alpha is ahead at every checkpoint. If YOU want 64 bit that flies NOW, why fart around? Sure DUNIX makes em' more money, but it costs more too, if they can sell MORE chips because of Linux, believe me they will Compaq + Dec are HARDWARE outfits with services NOT software outfits. If I was running an IT shop or a medium+ internet shop I'd ONLY spend money on Alpha + Linux + Oracle, everything else be damned.

CPU Micromart (www.cpumicromart.com) is selling 166MHz Alphas for $100. 32MB of (required) parity RAM is about another $90. The machine comes with a built-in network card, floppy, External SCSI controller, PCI riser and 256-color VGA video. It takes a standard PC monitor and a PS-2 keyboard and mouse, none of which are included.

I don't work for these people, but I did just order one of these boxes. I know a few people who use them for Linux and speak highly of them. And you can't beat the price.

Yeah, they're not real speedy. I plan to use it to use it as a development platform for web and db-server stuff, and to dig around inside of Linux. I hear that they're fine for this sort of thing. There's another company on the east coast selling Multias for a lot more money, actually, and when I called to ask about this they said that they're configuring them and selling them as fault-tolerant web servers. They claim people are pretty happy with them.

I tested one of the 1st of 4 alpha xp1000 ev6 pre-production systems last year under Linux. I think I was the only person who did, because everyone else used digital unix or NT. It was, by far, the fastest Linux system I've ever used. I have another ev6 system coming in this week.

That would be nice, as DU has a few nice features that could blend very well into a Linux setup. The most important thing for Compaq to do, though, and the thing that will help them to compete with Merced, is to work with Cygnus to get their compiler technology for Alphas into the hands of developers. DEC's compilers kick much in the way of ass on the Alpha platform, and the GNU compilers can't reasonably compete (except on cost, where I will always favor a GNU compiler over a $3K/yr. DEC C++ license, thank you very much).

IMNSHO, Compaq/Digital will _HAVE_ to make their compilers available reasonably if they ever want to see Alpha take off. I'd spend $200 or so for a C/C++ compiler suite from Digital for an alpha, but I'd also like that compiler suite to be able to target, say, OpenBSD/Alpha.

I have to admit that I am biased (in large part due to my employer). I would not consider a dual PII generally a good multiprocessor for numerically intensive codes. This has nothing to do with Intel or Linux, or g77/pgf77/absoft, etc.

What I have found on my codes is that small (actually tiny) problems run well on pentia. But reasonable research sized problems cause it to huff and puff. Machines like the alpha or the R10k (and R12k) kick serious butt on the larger problem sizes. What is just insanely cool is to watch your code (efficiently) use all 32 processors, and get something like a 28-30x speedup.

But, as I said, I am biased.

Back to fortran. Jeff Templon has an excellent page [uga.edu] on Linux and Fortran. Better is the big [fortranlib.com] fortran link page. This is really a nice resource and is a nice intro to the general Fortran Market [fortran.com] setup by Walt Brainerd. I strongly advise visiting this site if you need to think Fortran.

Ok, now some thoughts. Craig Burley and crew have done a positively bang up job on g77. It is IMO a useful productive research tool... with a caveat or two.

First, it really is just a front end to the gcc back end, so there are many... gcc-isms... floating about.

Second, while optimization is OK, it is generally tied to the gcc optimization, which has traditionally not been very good. The egcs [cygnus.com] project has had a much better track record on getting real optimization into the compiler. Folks, if your runs can take years, 5% DOES matter. Optimization on pentia is not just -O, you need things like

-O3 -malign-double -malign-functions=2 -funroll-loops -ffast-math

among others for decent performance.

Third, and most important for me, it (nor egcs) knows nothing whatsoever about multiprocessing.

In short, g77 and egcs in general are awesome tools. But unless you work on small problems, they are not suitable. You will need some better tools, and that involves passing over some money in this case.

I like the Portland Group [pgroup.com] tools, though the KAI [kai.com] tools are effectively identical to what you use on big supers like Origins. Unfortunately, I do not think KAI supports Linux any longer. Maybe we can all write them a nice letter on how they could drop support for some underused platform for computation (some come to mind here:-) ) in favor of Linux. Market size and all that.

As the author of the referant article wrote, most fortran users want all the speed they can get, so you need to look at what your code spends the most time doing, and figure out if it is doing it the right and most efficient way, or if your system is correctly designed for speed, or if you are hitting one area of your system really hard, and thus causing a bottleneck. In short, if you need to design for speed, start out with a workstation design, and not a PC design. You likely will need massive memory and IO bandwidth to complement an insanely fast CPU. Putting an Alpha into a PC architecture should be considered a capital crime. It makes much more sense to put it into something like a DS20, a T3E or some other design (I can fantasize about an Alpha in an Octane or an Origin, that would be a complete screamer... a memory and IO bus capable of feeding the processor at its full speed... shudder).

The language and its implementation are important, but so is the fundamental system design. You need to avoid bottlenecks everywhere.

Research, ISPs and Education - all superb markets for Alpha - they're clued, they generally run Linux already and price/performance isn't as much as an issue as performance alone (Alpha price/performance *ratio* isn't as good as Intel, IMHO - think Irish Guiness vs. Special Brew Lager and you're someway there...)

I suggested that strategy to my former employer, but they didn't follow it, continued to (try to) sell on price/performance and went bust about three months after I left, having sold five machines.

Amen to that, my alhpa running linux is still pretty snappy but the dec compiler blows gcc out of the water. egcs with Haifa on is an improvment but I still don't think it is as good as the Dec compiler.

In grad school I did some analysis on this subject and there is probably a 30% difference on average between -O5 output from the dec compiler and the best egcs can make.

Without a compiler, the alpha is a fairly uninteresting system. Intel chips, PowerPC chips and Sparcs can out perform it but with a good compiler it can hang with anybody.

Any IT manager worth their salt is going to get the system that best solves their problem.

this "vendor's stepchild architecture" happens to be the best platform for doing hardcore computational biology and high-throughput bioinformatics. Sun? too slow. HP? no software. SGI? good but expensive and I don't need floating point performance. Linux? cool and has potential but I want a system that can handle 12GB RAM.

I'm a huge fan of Digital Unix on alpha. Fast, easy to maintain/admin and not super expensive. I've bought $1M+ worth of their stuff for my group every year for the past several years.

It's all relative though. I know my systems are going to be replaced frequently as faster systems come on the market. Who knows what kind of systems I'll be using a year or two from now...I'll go with the best stuff available at the time. You raise a valid point though-- If I was planning on larger scale purchases with longer expected service times I'd really want to be sure of Compaq's support for the platform. That said though, the more Merced gets delayed, the better Alpha looks.

That 25% is based on better compilers - the gap disappears when running DU compiled code on alpha linux.

There's nothing to stop Compaq releasing their compilers for alpha linux though, which is a win for them because they can still make money selling good compilers, without all of the R&D involved in writing the entire OS.

When I can get the kind of price/performance out of an Alpha that I can get out of a Celeron 300A at 500MHz, I'll sign up.

So far, the only cheap Alphas I see going around are those old clunky "It's almost as fast as my near-dead P100" things... possibly a neat way to explore the architecture for cheap, but not quite in the same league in terms of bang:buck ratio as what's out there in the x86 world now.

I'm no fan of the PC platform -- hell, I'm getting mighty tired of it, having used PCs since 1981 -- but you can't beat the kind of volume that the x86 moves for creating good honest market pressure. Commodity hardware is a good thing.

I've always known code as a collective noun: "Our code is poorly commented, but it sure is fast." But I have seen the term codes used occasionally in a way that appears awkward to me, as in this quote.

I would have said "We know our code runs about..." and thought it more natural. Where does this usage of codes stem from? One generally associates the term "codes" with, for example, a series of cryptographic codes; and "code" as program code.

Mostly what I do (image manipulation, some rudementary data analysis, and development) uses flat-out integer and small matrix performance 80 or 90% of the time, and is more or less I/O bound over CPU for the majority of tasks.

Yes, the tool-fit is vastly more important that overall performance, and at least in my (fairly common) case, x86 is a win. Don't get me wrong, I'll be excited to see the Alpha descend into the mass market, but it's certainly not there yet.

Digital Unix runs around 25% faster than Linux on the same hardware depending on the job, and Digital Unix CC compiler produces much faster and more optimized code than GCC. So there is reasons for companys and universities to run DU instead of Linux, especialy if you do heavy computing, like research, simulution, math, etc.

True, there wheres the big volumes and money is, in the Windows NT workstation/server market segment. Dont get me wrong on this, I'm a 100% unix guy, but these are the hard facts. If they want to stay alive they need to drop the prices and push it as cheap Windows NT workstaion alternative. To sell huge amounts of Alpha boxes they need to push it as a good alternative to Intel workstation. And that brings the prices on the motherboards and chips down so we homeusers can aford to buy a Alpha too. "volume", "cheap" and "advertising" is the key words here.

Yes, Compaq now owns Digital and, therefor Digital Unix. Promoting GNU/Linux could be seen as cutting their own throats on that front. However, Compaq doesn't see the same kind of markup on Unix as it does on hardware, and would rather do hardware anyway.

Promoting GNU/Linux to the point that new installations go there instead of to other 'nix's helps Compaq get back to what the really want to do anyway. Ultimately, they downsize the software part of the business and keep a smaller coding force on hand to continue 'nix development for GNU/Linux solutions.

As for finding Alpha systems cheap,look at places like WebAuction (run by Micro/PC/MAC Warehouse) for deals. I picked up an Alpha box from them for $350, added 4.6GB HD, 24X CD-ROM, 128MB additional RAM, 17" Monitor, 56K/V90 external Dava/Voice/Fax modem, NT4 Workstation, MS Office Pro, and the Alpha firmware for a total cost under $2500 by shopping the web and local computer shows.

There are two specialized versions out there: DLD and Stampede, plus SuSE did, on March 20th at CeBIT in Europe, hand out version 6.1 Beta for Alpha, with an intended commercial release in May. Additionally, all it takes for kernel support is a simple kernel recompilation, as described in the appropriate HOWTOs. This has been in effect since 2.1.xxx. Versions 2.2.0 and 2.2.1 do not require patches for it to work, although 2.2.2 does. Additionally, several of the later 2.0.xx kernels will work on an Alpha with the appropriate patch.

The main advantage of the Alpha over the x86 is speed. One reason why DUX is better than Linux on the Alpha is because of the reasonably powerful compilers available for DUX. Compaq can really show their support of Linux by making a complete development environment available...

In the next week I am sure everyone will see exactly what Compaq is doing with the Alpha.

Alpha is not just a Compaq/Digital thing, it is a superscaler open industry standard 64-Bit RISC based architecture that is engineered by Compaq and manufactured in volume by Samsung Electronics, Mitsubishi, and their *subsidiaries*.

Some of the best advancements might happen much further awawy from Compaq itself.

A lot of the Alpha push is not only from Compaq but the subsidiaries of Samsung and Mitsubishi.

Samsung makes CPU's, they sell them to API (Alpha Processor, Inc.) that is owned by Samsung. API makes OEM motherboards for the Alpha, and Samsung sells OEM processors. Not only does Samsung do this but Mitsubishi does too, and a few other vendors as well.

Digital made and sold OEM products also, so when Digital merged with Compaq they contnued these products but they not seem to have the focus to sell a lot of OEM. Thus the Alpha OEM market will be done by others.

What I find even more annoying is that I have a Alpha 233 and A PII 233 running exactly the same software (Redhat 5.2, EGCS 1.1.1 etc.) and with essentially the same memory and disk space and the PII can usually compile something in half the time of the Alpha.

If Intel is funding Cygnus to optimize for KNI and Merced why can't Compaq do the same for Alpha?

Also, take a look at the IBM Power3. It's used in one of their new RS/6000 workstations (rather than a PowerPC), which is reviewed in UNIX World/Performance Computing. I think it had something like 4x the FLOPS of a PII while running at half the clock rate.