As the MIPS, ARM, and 68030 hardware and users are somewhat rarer, those ports are likely to continue to be in some respects somewhat more experimental. (Mind you, if Corel Computers is planning to use ARM/Linux in shipping product, it can't be too unstable, and I also hear good reports concerning the stability of the 68K versions. And someone who would try a 68K install is probably more knowledgeable than the average IA-32 user...)
The PPC ports are fairly prolific, with both monolithic and microkernelled versions of Linux.
Other even more obscure ports include the Fujitsu AP1000+, for supercomputing applications and probably others. One I'm somewhat interested in is the Sun 3 port, to Sun's 68K-based systems.
There's even VAXlinux, a port to Digital's VAX architecture. This is probably not terribly cost effective, as the annual power bill for a VAX might outweigh the cost of an Intel PC of equivalent computing power, but the idea is pretty cool...
Linux on DOS Card on Mac is another unusual option.
There is increasing support for High Performance Computing using Linux. One common approch is that of SMP (Symmetric Multi-Processing), documented at Linux Parallel Processing HOWTO, Linux SMP (Symmetric MultiProcessing).
The The Athlon Linux Project is seeking to help people tune their Linux distributions to run faster on AMD Athlon CPUs. This includes using agcc - GCC Tuned for Athlon See also AMD Athlon Processor Technical Documents
An April Fools article described Linux N/64 for the $200 Nintendo 64; it was quite believable as an N/64 has nearly enough hardware to do the job. Bump 2MB of RAM up to 16MB, put in an Ethernet chip and a port, put in a video chip that's nicely supported by XFree86 (S3V?), and you've got enough hardware for an X-Terminal. (A keyboard connector might also be necessary.) This should still have a price tag under $350, if sold in reasonable quantity. Sounds like a decently functional Network Computer to me; I'd buy one.
The Sony Playstation has hardware very similar to that on the N/64; turning either into a "Network Computer" ought to be equally feasible from a technical standpoint.
What I'd really like to see is a relatively cheap (under $1000?) MIPS-based motherboard configured to handle multiple MIPS CPUs. Preferred specs:
Accepts 2, 4, or 8 CPUs
Price points: $500 would likely be acceptable for a 2-CPU board, $1000 for an 8-CPU board
Onboard SCSI
PCI bus
I'm not sure what to suggest for a memory architecture...
Even with a $1000 motherboard, populating it with 8 MIPS 4300's would be cheap and it seems likely that this would be substantially more powerful than any Intel offering involving less than 4 processors.
This could really help to popularize Linux SMP ...
Itsy - a tiny ARM-Based computer
This isn't a directly Linux-related link; the IDT/WinChip is a Socket 7-compatible CPU that resembles the Cyrix/AMD "Pentium clones." It is targetted at low cost and low power applications, as the CPU is a low voltage chip to be priced at under $100 for one with performance on the order of a "Pentium 200."
I suspect that it may not be of tremendous interest in the marketplace, perhaps being too late to sell many units.
Loosely, an "open" hardware platform; VIA has released some free specs for a laptop platform based on their IA-32-compatible CPU.
The value of the "MMX" instruction approach popularized by Intel has been pretty limited so far. Since these "do-lots-of integer ops" instructions require doing "register spills" of floating point registers when one switches to MMX execution, this limits somewhat the performance benefits available from using MMX instructions on a multitasking system.
Far more important is that actually using MMX instructions requires that you be very nearly coding in assembly language in order to recognize instruction patterns that might be sped up by replacing them by an MMX instruction.
As a result of that, as well as the consideration that CPUs and assemblers don't universally support the MMX instructions, the usefulness of MMX on Linux has been, thus far, fairly limited. This has not hindered other vendors from coming out with MMX-like technologies such as AMD with 3DNow!.
The most likely sorts of candidates for substantial speedups would include:
XFree86 Drivers
Unfortunately, attempts at portability discourage MMX use, as XFree86 these days supports many platforms, a number of compilers, and multiple architectures.
The "Version 4" release modularizes XFree86, which could perhaps make it easier to manage MMX optimizations. Real Soon Now. Some efforts to do MMX and 3DNow! tuning have been done, but it's still pretty preliminary.
Graphics Libraries
This would be a most likely candidate for possible improvement; one might have both a /usr/lib/libXwhatever.so.1 and /usr/lib/libXwhateverMMX.so.1.2.3 , and link the preferable one to /usr/lib/libXwhatever.so.
Nobody seems to have written any such libraries yet.
Modify GCC to generate MMX instructions when it encounters suitable C code.
Unfortunately, this is a really hard problem, and thus highly unlikely to happen. GCC would have to recognize very particular sorts of iterative structures. Programmers are unlikely to generate suitable code without writing the code very specifically to be "caught" by the "MMX optimizer." It probably makes more sense to push such code out to a library as previously described.
There are some opportunities to use MMX code within the kernel.
<mingo@valerie.inf.elte.hu> MOLNAR Ingo wrote:
The latest 2.1 RAID driver uses MMX if available to do RAID5 checksumming. Heres a sneak-preview :) from the boot messages of a 350MHz PII:
md driver 0.51.2 MAX_MD_DEV=16, MAX_REAL=12
linear personality registered
raid0 personality registered
raid1 personality registered
raid5 personality registered
raid5: measuring checksumming speed
raid5: using high-speed MMX checksum routine
pII_mmx : 882.086 MB/sec
p5_mmx : 854.925 MB/sec
8regs : 599.638 MB/sec
32regs : 377.721 MB/sec
using fastest function: pII_mmx (862.086 MB/sec) |
It's about 50 percent faster than the fastest `integer' routine. Context switching cost is fortunately not a problem here as the buffers checksummed are guaranteed to be large enough.
So MMX does make sense but it's pretty hard to code for it and it's certainly not quite useful in GCC I think, as mixing integer and MMX instructions seems to be a loss in most cases, even on a PII (Even if there is no FPU used).
Say often if not always it's cheaper to spill a register to the stack than to an MMX register ... ugh. (when i tried to mix integer and MMX instructions to get even faster checksums, i got worse performance than the integer-only function ...)
Certain applications, particularly related to computer music and video (such as mplayer require mass calculations that are amenable to the use of MMX-like technology.
Cryptographic tools, particularly for cracking ciphers, need to do "en masse" integer calculations which MMX and other DSP-like processors can make faster. The clients for Distributed.Net have hand-tuned engines that have been written to take advantage of some of these extensions.