Sun's a hardware company, and the pie
they are in is singular, there: dealing
with the memory bottleneck by coming
up with new processor designs that
don't spend all their time sitting in
queue waiting for an I- or D-cache load.
Most of the research is there, because
it's a problem all the chip vendors are
faced with. if they don't do it, they will die.
On the product side, you're mostly
seeing the necessary support a hardware
company needs (Solaris), the languages
(Java, TCL, etc) and the combinations
of software and hardware that lead to
better price-performance in their products (ZFS and flash write caches for
storage performance, cheap).
I see the latter as mostly development and maintenance, which is a,lot easier and cheaper than the research (;-))
It's worth about a 5-times speed improvement if you use it as a write/commit cache. Mind you, no MS
filesystem supports doing so, so it's obviously a bad idea (;-))
More correctly, it means a competitor has
impressive results using SS devices as
a write/commit cache, so we need to write a
misleading paper quick! We'll start on the FUD as soon as we can get this one out...
It's a hacky technology to implement
QOS because folks don't like setting
the QOS bits and protocol in the headers.
Usually because some Microsoft firewall
only allows http on port 80 (;-))
It's the use of it by the famous
"men of good will but little understanding" that is bad, plus of course the use of it by men of ill will.
I was just doing capacity planning involving T5240s, and as a side task compared them to other machines, which included a
32-core Opteron box. The T5 handled
more users and degraded less under (over-)load.
Absolute performance was entirely consistent with 1.2 GHz x 128 threads
versus 3.2 gHz x 32 threads, which
is to say the Opteron was faster initially but slower under load.
Specifically, light-load Opteron performance was about 1.5:1 of the T5, heavy-load the other way around.
Conclusion? it's a tradeoff: you take the horse that does best on your course (;-))
Notably the T5XXX machines, which have
the kind of price-performance that
neither Sun nor IBM have had since
early Power and SPARC.
I recently did a capacity planning
study which involved T5240s, and was
startled by how much they delivered
before the response time started to
creep upwards. Then I compared the
price to M- and p-series boxes and
was actually impressed (;-))
The next generation, the so-called
rock, is, IMHO, something that IBM
could use, either for future SPARCs
or to become part of the Power
designs.
You only need two countries to cooperate,
the one where the victim is and the one
where the seller is. U.S. and Canada is easy, they honor each other's lawsuits and
court orders.
It's probably OK between the U.S. and China or Russia, they have financial relationships they want to retain, so
they'll at least take lawsuits.
It's genuinely hard between us and any country poorer that the spam-senders. We might have to use more than moral suasion (;-))
In theory, companies who call people on the do-not-call registry are subject to fines and lawsuits, as are the call centers they hire to do the work.
In practice, there are leaks: one
company in the U.S. got away with calling
Canadians for a while before they were stopped.
If we had the will to apply the same rules to email as to voice, and the same willingness to work with foreign police forces, we could take the profit margin away from the spammers.
As the grandparent said, attacking someone
with enough money to defend themselves may be a bad thing for someone committing
perjury. Not coming to the court with "clean hands" can affect whether you're heard at all.
Sometime I think the U.S. is drifting back to trial by battle... what should be a charge turns into a lawsuit, and people hire champions (;-))
Viacom objects to having to send YouTube DMCA notices, because they can't keep up. YouTube replies that only Viacom
knows which of their videos are posted with permission (i.e., by their marketing department) and which aren't.
The same applies here: the RIAA now has the unenviable task of distinguishing between their owners' approved content, legitimate content and unapproved copyrighted content, and then
launching an infinity of DMCA takedown notices and/or lawsuits. And only they or their owners can know what's approved copyright content.
I did, and my earnings peaked normally in my late 50s. Turns out half the "new"
stuff is old stuff with new buzzwords, so
catching up and keeping up to the level
implied by my grey hairs was easy.
And if you look at a level lower that the profiler, you find your programs are memory-bound, and getting worse.
That's a big part of the push toward
multithreaded processors.
To paraphrase another commentator, they
make process switches infinitely fast, so
one can keep on using the ALU while your old thread is twiddling its thumbs waiting for a cache-line fill.
Firstly, it's false on the face of it: Ubuntu is
certified on Sun T2000, a 32-thread and Canonical is supporting it.
Secondly. it's the same FUD as we heard from uniprocessor
manufacturers when multiprocessors first came out:
this new "symmetrical multiprocessing" stuff will
never work, it'll bottleneck on locks.
The real problem is that some programs are
indeed badly written. In most cases, you just
run lots of individual instances of them.
Others, for grid, are well-written, and scale
wonderfully.
The ones in the middle are the problem, as
they need to coordinate to some degree, and
don't do that well. It's a research area
in computer science, and one of the
interesting areas is in transactional memory.
That's what the folks at the Multicore Expo
are worried about: Linux itself
is fine, and has been for a while.
Slashdot Mirror
--dave
Sun's a hardware company, and the pie they are in is singular, there: dealing with the memory bottleneck by coming up with new processor designs that don't spend all their time sitting in queue waiting for an I- or D-cache load. Most of the research is there, because it's a problem all the chip vendors are faced with. if they don't do it, they will die.
On the product side, you're mostly seeing the necessary support a hardware company needs (Solaris), the languages (Java, TCL, etc) and the combinations of software and hardware that lead to better price-performance in their products (ZFS and flash write caches for storage performance, cheap). I see the latter as mostly development and maintenance, which is a,lot easier and cheaper than the research (;-))
--dave
It's worth about a 5-times speed improvement if you use it as a write/commit cache. Mind you, no MS filesystem supports doing so, so it's obviously a bad idea (;-))
--dave
More correctly, it means a competitor has impressive results using SS devices as a write/commit cache, so we need to write a misleading paper quick! We'll start on the FUD as soon as we can get this one out...
--dave
It's a hacky technology to implement QOS because folks don't like setting the QOS bits and protocol in the headers. Usually because some Microsoft firewall only allows http on port 80 (;-))
It's the use of it by the famous "men of good will but little understanding" that is bad, plus of course the use of it by men of ill will.
--dave
Hey, that's the formula Paul Stachour used for the value of email, to compare the ARPAnet and a bunch of lower-connectivity private provider's nets.
--dave
I'll mildly disagree re the CMT machines.
I was just doing capacity planning involving T5240s, and as a side task compared them to other machines, which included a 32-core Opteron box. The T5 handled more users and degraded less under (over-)load. Absolute performance was entirely consistent with 1.2 GHz x 128 threads versus 3.2 gHz x 32 threads, which is to say the Opteron was faster initially but slower under load.
Specifically, light-load Opteron performance was about 1.5:1 of the T5, heavy-load the other way around. Conclusion? it's a tradeoff: you take the horse that does best on your course (;-))
--dave
Notably the T5XXX machines, which have the kind of price-performance that neither Sun nor IBM have had since early Power and SPARC.
I recently did a capacity planning study which involved T5240s, and was startled by how much they delivered before the response time started to creep upwards. Then I compared the price to M- and p-series boxes and was actually impressed (;-))
The next generation, the so-called rock, is, IMHO, something that IBM could use, either for future SPARCs or to become part of the Power designs.
--dave
You only need two countries to cooperate, the one where the victim is and the one where the seller is. U.S. and Canada is easy, they honor each other's lawsuits and court orders.
It's probably OK between the U.S. and China or Russia, they have financial relationships they want to retain, so they'll at least take lawsuits.
It's genuinely hard between us and any country poorer that the spam-senders. We might have to use more than moral suasion (;-))
--dave
In theory, companies who call people on the do-not-call registry are subject to fines and lawsuits, as are the call centers they hire to do the work.
In practice, there are leaks: one company in the U.S. got away with calling Canadians for a while before they were stopped.
If we had the will to apply the same rules to email as to voice, and the same willingness to work with foreign police forces, we could take the profit margin away from the spammers.
--dave
As the grandparent said, attacking someone with enough money to defend themselves may be a bad thing for someone committing perjury. Not coming to the court with "clean hands" can affect whether you're heard at all.
Sometime I think the U.S. is drifting back to trial by battle... what should be a charge turns into a lawsuit, and people hire champions (;-))
--dave
Yup, "I swear, under penalty of perjury, that the information in the notification is accurate ..."
And it also reproduces the YouTube vs Viacom debate described at http://www.groklaw.net/article.php?story=20090324125420761
Viacom objects to having to send YouTube DMCA notices, because they can't keep up. YouTube replies that only Viacom knows which of their videos are posted with permission (i.e., by their marketing department) and which aren't.
The same applies here: the RIAA now has the unenviable task of distinguishing between their owners' approved content, legitimate content and unapproved copyrighted content, and then launching an infinity of DMCA takedown notices and/or lawsuits. And only they or their owners can know what's approved copyright content.
--dave (grumpy old performance/capacity guy) c-b
Sequent: it was painful enough NASDAQ publicly ported to Sun.
--dave
We put it on brand-new 486s, and shipped the manuals and CDs with it.
Yes, "thumper" refers to the rabbit. I have a Sun Managed Storage slide somewhere about how data tends to, er, multiply...
--dave
How? Easy: it met their three requirements for a third-party product
That's all it took, plus the hidden criteria, of course: it worked better than SCO.
--dave
Joke ends, you can laugh now...
As an Evil Contractor[TM], I usually find a downturn increase both
--dave
Indeed it does! That was the motivation for my comment on transactional memory.
What I said! --dave
--dave
And if you look at a level lower that the profiler, you find your programs are memory-bound, and getting worse. That's a big part of the push toward multithreaded processors.
To paraphrase another commentator, they make process switches infinitely fast, so one can keep on using the ALU while your old thread is twiddling its thumbs waiting for a cache-line fill.
--dave
Firstly, it's false on the face of it: Ubuntu is certified on Sun T2000, a 32-thread and Canonical is supporting it.
Secondly. it's the same FUD as we heard from uniprocessor manufacturers when multiprocessors first came out: this new "symmetrical multiprocessing" stuff will never work, it'll bottleneck on locks.
The real problem is that some programs are indeed badly written. In most cases, you just run lots of individual instances of them. Others, for grid, are well-written, and scale wonderfully.
The ones in the middle are the problem, as they need to coordinate to some degree, and don't do that well. It's a research area in computer science, and one of the interesting areas is in transactional memory.
That's what the folks at the Multicore Expo are worried about: Linux itself is fine, and has been for a while.
--dave