Compaq just happened to acquire the Alpha architecture along with Digital, they're not really behind it.
Yes, they are. They have 3 reasons: Linux, Tru64 and OpenVMS. And they have done more already for Linux than Digital ever did. They ported their commercial math library to Linux, their Fortran and C compilers, and now they even provide Netscape on Alpha/Linux for downloading (that's what I'm typing on now).
Without future NT versions, there's even less incentive for Compaq to pour more money into Alpha development.
Nonsense. Compaq dropped Alpha/NT because they discovered it doesn't sell well, and they don't need it to market Alpha successfully anymore.
Don't forget either about Alpha Processor Inc. (www.alphaprocessor.com)), the Samsung division who exists only to provide Alpha motherboards running Linux.
I'd also love to see FreeBSD use AlphaBIOS for its bootstrap instead of SRM. I don't want to use the SRM console!
Why not? SRM is the only one supported by Compaq now.
Incidentally, neither Linux nor FreeBSD boot from AlphaBIOS, and never will... Linux does boot from MILO, a freeware console written for systems without SRM. MILO itself boots from AlphaBIOS (it can also boot from SRM, or directly from flash on a few systems). However once it is running, it completely replaces AlphaBIOS.
Ugh. AlphaBIOS is nice, and why is only Linux supporting it (NT does too)??
AlphaBIOS is history, just like AlphaNT. The current release probably won't be upgraded for newer hardware. MILO itself isn't available on many newer systems, and without MILO, AlphaBIOS is useless (unless you are still running NT).
But if you want to port FreeBSD so it can boot from MILO, chances are there are a few out there who could use it.
I don't know about Mandrake's plans, but there is still room for optimization. Just as all x86 processors are not alike, all Alphas are not the same. For example, all 21164a and later Alpha processors support byte/word extensions, yielding somewhat smaller and faster binaries that won't run on earlier processors.
Redhat's distribution is targetted for all Alpha processors. I've considered recompiling it all for my 164SX. The X server alone shrunk by about 30% when I recompiled it with BWX.
Yes, umm, at least as much so as other "RISC" cpu's... the RISC/CISC terminology is actually obsolete.
64-bit?
Yes. Alpha CPUs have always had 64-bit virtual addressing. Physical addressing varies... newer EV67 Alphas can address 44 bits of physical memory.
In what areas (/applications) does an Alpha beat an x86?
The Alpha has superior floating point, higher memory bandwidth, and more registers than an x86. It handles all applications well but really shines on FP. It's excellent at certain large database applications due to the 64-bit address space (you can do things like mmap a 50GB file, if you like).
Note that UltraSPARC has many of the same advantages of x86.
If you're so curious, why not go to www.testdrive.compaq.com and try one for yourself? You'll get a free 30-day trial account, and can test/benchmark your own applications on a 4-CPU Alpha ES40, if you like.
(Note: I have no affiliation whatsoever with Compaq or Alpha Processor.)
I didn't say "unreasonable"... although there is hard evidence that some applications benefit considerably from page coloring on the 21164.
Linus is correct in saying that the 21164 is one of the last architectures to use a direct-mapped L1 cache. That alone may make it not worthwhile for the kernel distribution. Making it a kernel option may be viable... I admit I don't know enough about VM internals to attempt it.
Interesting notes about page coloring... I didn't know FreeBSD had this capability.
Linus has stated that he probably will never add page coloring to the Linux kernel. Apparently he doesn't believe it will benefit enough architectures to be worthwhile.
On an Alpha 21164 many binaries run faster on Tru64 Unix than on Linux. Static linking rules out differences in the compilers or libraries. Page coloring (a feature of Tru64) is almost certainly the reason.
Slashdot Mirror
Compaq just happened to acquire the Alpha architecture along with Digital, they're not really behind it.
Yes, they are. They have 3 reasons: Linux, Tru64 and OpenVMS. And they have done more already for Linux than Digital ever did. They ported their commercial math library to Linux, their Fortran and C compilers, and now they even provide Netscape on Alpha/Linux for downloading (that's what I'm typing on now).
Without future NT versions, there's even less incentive for Compaq to pour more money into Alpha development.
Nonsense. Compaq dropped Alpha/NT because they discovered it doesn't sell well, and they don't need it to market Alpha successfully anymore.
Don't forget either about Alpha Processor Inc. (www.alphaprocessor.com)), the Samsung division who exists only to provide Alpha motherboards running Linux.
I'd also love to see FreeBSD use AlphaBIOS for its bootstrap instead of SRM. I don't want to use the SRM console!
Why not? SRM is the only one supported by Compaq now.
Incidentally, neither Linux nor FreeBSD boot from AlphaBIOS, and never will... Linux does boot from MILO, a freeware console written for systems without SRM. MILO itself boots from AlphaBIOS (it can also boot from SRM, or directly from flash on a few systems). However once it is running, it completely replaces AlphaBIOS.
Ugh. AlphaBIOS is nice, and why is only Linux supporting it (NT does too)??
AlphaBIOS is history, just like AlphaNT. The current release probably won't be upgraded for newer hardware. MILO itself isn't available on many newer systems, and without MILO, AlphaBIOS is useless (unless you are still running NT).
But if you want to port FreeBSD so it can boot from MILO, chances are there are a few out there who could use it.
I don't know about Mandrake's plans, but there is still room for optimization. Just as all x86 processors are not alike, all Alphas are not the same. For example, all 21164a and later Alpha processors support byte/word extensions, yielding somewhat smaller and faster binaries that won't run on earlier processors.
Redhat's distribution is targetted for all Alpha processors. I've considered recompiling it all for my 164SX. The X server alone shrunk by about 30% when I recompiled it with BWX.
Are Alpha's RISC?
Yes, umm, at least as much so as other "RISC" cpu's... the RISC/CISC terminology is actually obsolete.
64-bit?
Yes. Alpha CPUs have always had 64-bit virtual addressing. Physical addressing varies... newer EV67 Alphas can address 44 bits of physical memory.
In what areas (/applications) does an Alpha beat an x86?
The Alpha has superior floating point, higher memory bandwidth, and more registers than an x86. It handles all applications well but really shines on FP. It's excellent at certain large database applications due to the 64-bit address space (you can do things like mmap a 50GB file, if you like).
Note that UltraSPARC has many of the same advantages of x86.
If you're so curious, why not go to www.testdrive.compaq.com and try one for yourself? You'll get a free 30-day trial account, and can test/benchmark your own applications on a 4-CPU Alpha ES40, if you like.
(Note: I have no affiliation whatsoever with Compaq or Alpha Processor.)
I didn't say "unreasonable"... although there is hard evidence that some applications benefit considerably from page coloring on the 21164.
Linus is correct in saying that the 21164 is one of the last architectures to use a direct-mapped L1 cache. That alone may make it not worthwhile for the kernel distribution. Making it a kernel option may be viable... I admit I don't know enough about VM internals to attempt it.
Interesting notes about page coloring... I didn't know FreeBSD had this capability.
Linus has stated that he probably will never add page coloring to the Linux kernel. Apparently he doesn't believe it will benefit enough architectures to be worthwhile.
On an Alpha 21164 many binaries run faster on Tru64 Unix than on Linux. Static linking rules out differences in the compilers or libraries. Page coloring (a feature of Tru64) is almost certainly the reason.
At last I feel compelled to go try FreeBSD...