Actually it's very close to the Ultra II core.
The idea is to be able to keep running during
a cache refill by duplicating decoders and
register files. The ALU isn't much different
from the one I'm running as I type this (;-))
--dave (Solaris and Linux on SPARC, Linux on Intel) c-b
So why would a PC developer want to? They think they
are a single program taking over the machine.
A Unix/Linux developer knows that there may be multiple instances of a given program running on a server, sharing executables and having better locality of reference.
And if the program has a need to do more than one thing at a time, the authors will thread it or
make it run multiple instances.
Imagine a Beowulf cluster of 16 blades, each running a 32-way CPU for 512 processors per shelf. For about 1.5 times the price of 16 uniprocessor Pentiums. (512/16)/(1.5/1) = 21 times the price-performance, and a really small footprint to boot.
The current problem in compuring is that memory speeds are going up far slower than processor speeds, causing huge cache-fill delays. Sun
came up with a simple architecture to keep the
processors running anyway, and it is compatable
with multiprocessing and multithreading:
1. Run decoder A until cache blocks on a read
2. Clear ALU and switch to decoder & register file B
3. Run B until cache blocks on a read...
.. and so on for C-F. then go back to A.
Put two ALUs and two sets of 8 decoder/register sets, so as to use the whole of the current memory interconnect bandwidth.
Given this much raw compute power from the same size (and price-range) silicon, the marketplace will rapidly multi-thread or at least multi-instance their programs. They've already done the latter to run on Beowulf clusters, after all!
I suspect the only things that won't be open in the Open Source sense are:
1, the right to the name "Solaris"
2, the source for stuff Sun deosn't own.
The latter was a stumbling-block when they
made Solaris 8 source widely available under
a lmited liscence a few yeats back. Various
of the contributors said "no way!", and they
had to provide just.o files.
>P>--dave
Sun has an exchange replacement, which
specifically works with the older versions, and has been pushing it as it's easier and cheaper to migrate to than the new exchange (:-))
In my view, that was more bad management than
intentional lock-in. I usually assume stupidity
if it suffices, rather than malice (;-)).
This follows from folks actually trying
to write standards and work to them. I
was on the standards-and-stability team for a
major vendor for some years, trying to live the
motto of "write once, run forever".
Alas,
vendors don't care much these days, so
I tend to think that strong
language standardization (ie, Java and
"write once, debug everywhere") is the
best current push in that space...
Hmmn: My recollection is that people were
shifting off IBM series 3/3X minis
first, then mainframes, after seeing the
possibility (and relative simplicity) of switching
amoung Unixes.
After the BSD/Bell split, there was both
differentiation (which could be used for lockin) and standardization
(for making the marketplace look big, to attract ports). VMS was the big
incompatable vendor in those days. The Unix
folks were't big and powerfull enough to
lock down much.
Then Windows 3.0 came along and
started a new era of lock-in.
I think he's preaching to the business community,
for whom the ability to buy a different brand
of computer for a new lab is a Real Big Thing.
Remember "vendor lock-in"? Used to happen with
IBM mainframes, then Windows, and now, regrettably,
with Unix variants.
The freedom to be able to chose a vendor
is important to businesses and universities,
and in principle to anyone who doesn't want to
be locked to a particular vendor. Such as
Sequent, who sorta doesn't exist any more...
I used to do a ton of porting for
the purpose of unlocking stuff from vendor X
or Y and making it run on "stock Unix", which is
to say, pretty much anywhere. heck,
I still do, on request (;-))
In fact, during the late "structured" and early
"4gl" era, Honeywell tried to set up software
factories. Net result? They couldn't be distinguished from ordinary labs like mine (TSDC).
They then went on to building Unix-like development environments, which worked quite a bit better.
My understanding is that the chips grow/shrink
at the same order of magnitude, as the set
is cooled by the same flow of air/refrigerant.
Misalignment below an order of mangnitude is dealt with by making the pad sizes non-zero. Which
is required by capacitive coupling anyway.
Hmmn, if I put a signal on one particular pair
of points, then wiggle the chip with a micromanipulator, I can rapidly find the
best alignment of the pair. Repeat this
for a second pair and I've located it in two dimensions. Now all the points are aligned
and I can lock it down.
Pretty much the same way one aligns
a glass fibre in it's termination point...
I suspect you're right: they've cut back
on expendatures, and in so doing laid off the
folks (Hi, Fred!) who could have added just
those components as customer-paid
specials...
The Netras where stripped units meant
to be bought in dozen lots by the telcoms,
who in fact bought a **ton** of them.
They resembled nexus.yorku.ca, which
was a SPARC 1+ which I took the video
card out of and shoved in a rack to support
a large dial-in community, many moons ago (;-))
That was, you see, the way to get a small
compute server cheap.
Bruce Perens wrote: Sun is stuck in making a transition from high-margin products to low-margin ones
I think that's true in the low-end-product space, but that isn't where Sun is making money or where
they're putting their effort. The part of the
business that was most successful was servers,
initially just retargeted workstations and
small multiprocessors, and eventually medium
and large multiprocessors.
The opportunity in the server space is
to significantly lower the cost per unit work,
something which I expect
the whole industry to be doing in a few
years.
Right now, Sun and IBM have their first
dual-core chipsets out, in small quantities
and starting with the medium-to-large
server markets. The big cost reduction
will be when they, (and AMD, and probably
SGI), have 8- and 16-way multithreaded chips
out. These deal with the huge mismatch
between CPU and memory speed, and will be
able to saturate a modern memory bus
by running enough threads to keep the ALUs
earning their keep even when individual threads
are blocked waiting on a fetch.
At that time, we'll see something like a
10:1 or perhaps 30:1 jump in price-performance.
Which, I claim, is A Good Thing (;-))
This, in turn, means the competition
will be once again in the server market,
where the middle and large ends are both
high-margin, and a significant jump
in price-perfromance will justify the
margins.
I do eventually expect to see low-end multi-threaded chips, probably in blade or 1U enclosures, for
a relatively high price per unit but with
a very high price-performance offsetting that.
My former employer has a migration
group in Toronto who've done a lot
of VMS-to-Unix ports. They therefor have
unix equivalents of lots of VMS stuff,
at least for Solaris and presumably JDS (SuSE).
You can do the inverse: contract with
a private VAX maintainer/junkyard to keep
your machines running. Of course, everyone
can't do that, as then there's be no spares (;-))
In this case, the java card stores a reasonably
small amount of identifying data, enough for the server to be able to hunt down your state and run it.
As the memory on the card increases, or
if you use a bigger card (e.g., a USB memory stick) you can carry more around with you.
In principle, this could easily be your context in a portable form,
such as a java program... which may be why Sun currently uses a java card for its smart-card (;-))
Slashdot Mirror
--dave (Solaris and Linux on SPARC, Linux on Intel) c-b
Methinks this is one way Sun's improving their quality control (;-))
--dave
A Unix/Linux developer knows that there may be multiple instances of a given program running on a server, sharing executables and having better locality of reference.
And if the program has a need to do more than one thing at a time, the authors will thread it or make it run multiple instances.
Imagine a Beowulf cluster of 16 blades, each running a 32-way CPU for 512 processors per shelf. For about 1.5 times the price of 16 uniprocessor Pentiums. (512/16)/(1.5/1) = 21 times the price-performance, and a really small footprint to boot.
--dave
The current problem in compuring is that memory speeds are going up far slower than processor speeds, causing huge cache-fill delays. Sun came up with a simple architecture to keep the processors running anyway, and it is compatable with multiprocessing and multithreading:
1. Run decoder A until cache blocks on a read
2. Clear ALU and switch to decoder & register file B
3. Run B until cache blocks on a read...
Given this much raw compute power from the same size (and price-range) silicon, the marketplace will rapidly multi-thread or at least multi-instance their programs. They've already done the latter to run on Beowulf clusters, after all!
--dave
1, the right to the name "Solaris"
2, the source for stuff Sun deosn't own.
The latter was a stumbling-block when they made Solaris 8 source widely available under a lmited liscence a few yeats back. Various of the contributors said "no way!", and they had to provide just .o files.
>P>--dave
--dave
This follows from folks actually trying to write standards and work to them. I was on the standards-and-stability team for a major vendor for some years, trying to live the motto of "write once, run forever".
Alas, vendors don't care much these days, so I tend to think that strong language standardization (ie, Java and "write once, debug everywhere") is the best current push in that space...
--dave
After the BSD/Bell split, there was both differentiation (which could be used for lockin) and standardization (for making the marketplace look big, to attract ports). VMS was the big incompatable vendor in those days. The Unix folks were't big and powerfull enough to lock down much.
Then Windows 3.0 came along and started a new era of lock-in.
--dave
Remember "vendor lock-in"? Used to happen with IBM mainframes, then Windows, and now, regrettably, with Unix variants.
The freedom to be able to chose a vendor is important to businesses and universities, and in principle to anyone who doesn't want to be locked to a particular vendor. Such as Sequent, who sorta doesn't exist any more...
I used to do a ton of porting for the purpose of unlocking stuff from vendor X or Y and making it run on "stock Unix", which is to say, pretty much anywhere. heck, I still do, on request (;-))
--dave
--dave
--dave
--dave
--dave
Pretty much the same way one aligns a glass fibre in it's termination point...
--dave
OOPS! That should be
first 35,000 22%
next 70,000 31%
rest 38%
--dave
--dave
They resembled nexus.yorku.ca, which was a SPARC 1+ which I took the video card out of and shoved in a rack to support a large dial-in community, many moons ago (;-)) That was, you see, the way to get a small compute server cheap.
--dave
I think that's true in the low-end-product space, but that isn't where Sun is making money or where they're putting their effort. The part of the business that was most successful was servers, initially just retargeted workstations and small multiprocessors, and eventually medium and large multiprocessors.
The opportunity in the server space is to significantly lower the cost per unit work, something which I expect the whole industry to be doing in a few years.
Right now, Sun and IBM have their first dual-core chipsets out, in small quantities and starting with the medium-to-large server markets. The big cost reduction will be when they, (and AMD, and probably SGI), have 8- and 16-way multithreaded chips out. These deal with the huge mismatch between CPU and memory speed, and will be able to saturate a modern memory bus by running enough threads to keep the ALUs earning their keep even when individual threads are blocked waiting on a fetch.
At that time, we'll see something like a 10:1 or perhaps 30:1 jump in price-performance. Which, I claim, is A Good Thing (;-))
This, in turn, means the competition will be once again in the server market, where the middle and large ends are both high-margin, and a significant jump in price-perfromance will justify the margins.
I do eventually expect to see low-end multi-threaded chips, probably in blade or 1U enclosures, for a relatively high price per unit but with a very high price-performance offsetting that.
--dave
It's a mechanism for adding trace calls to pretty-nearly-arbitrary locations.
Dtrace is a lovely mechanism, and once it's out in production Solaris (and maybe Linux) I'm going to write a new TPS/response-time monitor using it.
--dave
You can do the inverse: contract with a private VAX maintainer/junkyard to keep your machines running. Of course, everyone can't do that, as then there's be no spares (;-))
As the memory on the card increases, or if you use a bigger card (e.g., a USB memory stick) you can carry more around with you. In principle, this could easily be your context in a portable form, such as a java program... which may be why Sun currently uses a java card for its smart-card (;-))
--dave
--dave
--dave