[Beowulf] SGI and Sun: In Memoriam

[Lux, James P]

> Personally, I don't think there's anything wrong with 
> domain-specific processors. Cell, ARM, Sparc T2's, etc all 
> have a certain market which they are suited to and work well 
> in, but are pooly suited for workloads outside that market. 
> There's no point in burning massive amounts of die space on 
> floating point units in a processor that's going to be doing 
> SQL searches, and similarly not a whole lot of point burning 
> space on hardware crypto acceleration for desktop chips, 
> where pure software implementations are fast enough in nearly 
> all situations. Whether a different ISA is required for each 
> chip is more debatable. 

There are applications (DSP) where deterministic execution speed is nice.
There are applications where Harvard architecture is nice.

Those may be niche cases, and a sufficiently fast commodity x86, warts and all, might be better than an expensive tailored chip.  In my own work, which these days is quite embedded, I maintain that we shouldn't be trying to make the OS hard-real-time, and that hard RT stuff should be done in dedicated hardware (perhaps reprogrammable, FPGA), with the soft RT OS just managing things, and get "reliability" in a " not missing the schedule or dropping an interrupt" sense by plenty of reserve CPU capacity.

While Intel is doing their best to 
> make x86 work in everything from low-power cellphone chips to 
> GPUs, all indications are that it's not really working out 
> for them. Whether this is the fault of the x86 instruction 
> set, which is notoriously complicated to deal with, 

But at least the assembler is still source code compatible with your code for an 8080. The substantial investment you made in writing 8080 code back in 1980 hasn't been lost.<grin> heck, for all I know, the latest processors still have a virtual-8086 mode. A quick check of the March 2009 Intel software developer manual indicates that indeed, they do.  So that 8086 code I wrote back in the early 80s could conceivably run without recompiling. (If I could figure out how to read the 8" floppy it's stored on.)


or 
> whether it's simply trying to cover too much ground with one 
> ISA it hard to say, since noone else has (AFAIK) tried it. 
> It's basically the standard tradeoff between economies of 
> scale and efficiency - if chip A is only half as efficient by 
> some useful metric as chip B, but can be produced in 
> sufficient scale such that it only costs a third as much to 
> buy, then it'll win.
> 
> Finally, I wouldn't agree that Sparc is proprietary in any 
> way. In fact, it's about the most open architecture I know 
> of. It's a fully open royalty-free standard (though I did a 
> quick search to make sure, and apparently there's a one-off 
> $99 "admin fee" if you want to use the SPARC trademark, but 
> that's it), with multiple independant implementations. I can 
> even download a GPL'd Verilog version and use it as an 
> embedded processor in an FPGA if I want, without paying a cent.

Indeed. We're using the (free) LEON core (which implements the SPARC v8) at JPL. And there's SPARC 7s at Mars and the Moon. I don't know if there's any x86s in deep space (defined as farther than the moon or 2E6 km, depending on who you talk to). Other popular processors in space are various MIPS processors and the PPC.


Jim Lux