[rescue] sparc10 cpu - what to do.

Sandwich Maker adh at an.bradford.ma.us
Fri Dec 16 15:55:57 CST 2016

" From: Dave McGuire <mcguire at neurotica.com>
" On 12/16/2016 02:31 PM, Patrick Giagnocavo wrote:
" > My personal opinion: what helped to kill SPARC was interpreted
" > languages like Perl, where the code to be executed was far larger than
" > could fit in cache.
" > 
" > When running a compiled program, the smaller caches of SPARC didn't
" > matter as much. But with Perl, Python etc. having such a large
" > footprint, the x86 CPUs with more L2 cache gained an advantage.
" > 
" > Not sure if anyone agrees with that? It is my naive, non-OS-developer viewpoint.
"   I'm not sure I can agree with that.  First, most SPARCs had much
" larger caches than x86 implementations of the same era.  Second, there
" wasn't much that higher-end SPARCs couldn't do faster than higher-end
" x86 implementations.  There were the crappy SPARCs, like the IIi and
" IIe, but they don't count in my book. ;)
"   What really helped to kill SPARCs, assuming they've actually been
" killed (I've seen no formal announcement of their discontinuance), is
" PeeCee fanboys.

the triumph of the marketplace -- best doesn't win; popular wins.  and
popular affects scale, which drives price, and price is an easy sell.
quality - however you measure it - is more nebulous.

pa-risc is gone.  alpha is gone.  mips is radically retargeted.  if
sparc goes, power may be the only alternative performance chip left.
itanium?  i was at hp when the first gen was launching [disastrously]
and i understand why hp threw in with intel, but i predicted then that
intel would eat hp's lunch, and it seems to be coming to pass.
Andrew Hay                                  the genius nature
internet rambler                            is to see what all have seen
adh at an.bradford.ma.us                       and think what none thought

More information about the rescue mailing list