When you sue someone, you have to state a reason. If you can't at least BS "emotional distress" the judge will generally throw it out before trial for "failure to state a claim upon which relief can be granted". Suits like this generally fall into a few categories:
1) Breach of Contract
From the sound of things, there's no contract to be breached.
2) Breach of Loyalty
If you willfully act against the interest of the company while you are employed, they can get damages. About the only way I can imagine that quitting your job would qualify is if you deliberately plan ahead of time (while you're still employed) to quit at a particularly inopportune time. Planning ahead of time to quit the day you get back from an expensive training program might qualify, because you're supposed to be going to that training for the company's benefit. Planning in advance to quit a customer-facing position in the middle of something in a way that would embarrass the company might also qualify.
3) Statutory obligations
If there's a law covering your job that states certain obligations that will be broken by the manner in which you quit your job, they may be able to sue for this if you don't meet those requirements. This generally only applies to licensed professionals.
4) stealing and breaking things
This doesn't really apply to quitting, but such accusations are not uncommon when someone leaves a job on bad terms. Failing to record the root password does *not* qualify as breaking things, unless you deliberately changed it to something secret before you left. It may mean you were lousy at your job, but all they can do about that is fire you.
Modern CPUs have sufficiently complex decoder units at the front of sufficiently deep pipelines that the programmer-visible ISA has very little impact on the performance-critical aspects of the architecture. You need look no further than the vast architectural difference between AMD and Intel, or even Intel and Intel (P4 vs. Core) for the proof.
So, we'll keep using x86 in this market because it's what we've been using. We need *some* ISA, and now that the ISA itself is largely decoupled from the underlying implementation, there's very little incentive to change it.
My father is an attorney, and he once told me that you never ask a question you don't already know the answer to, unless the answer cannot possibly hurt you. There are a few possible answers here:
1) I don't know.
If he doesn't know, he's not an expert on MediaSentry.
2) None.
At this point you enter into evidence a copy of The Mythical Man-Month or some similar tome, and quote figures on bugs per lines of code. You have now discredited him.
3) Lots, for example...
This will go over *great* with a jury.
This guy claims that the hard drive provided must be the wrong hard drive because it doesn't show any evidence of file sharing whatsoever, and MediaSentry claims there was file sharing. Maybe it's a bug in MediaSentry.
I should have put more emphasis on top-tier. All the top-tier vendors sell Linux workstations, and the hardware in their mid-range consumer boxes is generally similar or identical to what they put in the low-end engineering workstations. They actually have engineering relationships with Linux vendors and employ developers to fix up the drivers if they have problems.
Outside of the top-tier OEMs that actually sell boxes with Linux preloaded, all bets are off.
A few months ago, I bought a new box, from parts. I thought I knew what I was doing. I inadvertently bought an Asus M2V board with an Attansic L1 gigabit chip on it. One thing led to another, and now I'm spending a lot of time fixing the vendor driver for upstream submission. It's certainly educational, but I wouldn't recommend it for newbies.
I don't question that you can do a better job of finding compatible parts than an OEM that doesn't care about Linux (and most of them don't), but I know a lot of Linux professionals like myself who have made similar mistakes, so I don't want to lead a newbie down that path.
So, to clarify my earlier recommendation, buy from a company that sells Linux, even if you're going to be buying a Windows box to dual-boot. The odds are much better that way that stuff will work with Linux, especially if you're not entirely sure what to be looking for otherwise.
Hardware: 1) A CPU with hardware virtualization will greatly expand your options for using Windows and Linux together on the same box. Any Intel Core chip or AMD Socket AM2 chip will work.
and
2) Anything from a top-tier OEM is going to be much easier to make Linux work on than something you pieced together yourself.
and
3) Spend your money on RAM, not CPU.
Distro: a) Ubuntu, as it benefits from the vast repositories of Debian software, but is better targeted for your use case.
or
b) Fedora Core, as it benefits from the vast repositories of RPM software. For out-of-distro software, you're more likely to find RPM downloads than.deb downloads, so with Fedora you'll be less likely to have to compile software yourself. The downside of Fedora is that older versions aren't supported for very long.
If having to do a major upgrade every year to be able to keep getting updates scares you, use Ubuntu. If having to compile your own software scares you, Fedora might be better, and Gentoo is definitely out.
There are plenty of other perfectly valid choices, but Ubuntu and Fedora Core are the obvious first two to mention for someone who's probably going to be spending a little time searching Google and browsing the user forums.
"...longer in wavelength than x-rays but shorter than microwaves..."
Well, they've just described upwards of 99% of the electromagnetic radiation emitted by the sun. And while it is certainly true that this is shorter than the microwaves that cook your food (well, this is slashdot, I should say *most* people's food), it is still within the range considered to be microwave radiation:
With PCIe, you can have x16 slots that don't have 16 lanes committed to them, and this can be configured in an appropriately featureful BIOS. So you could plug in 4 x16 cards, and reconfigure the bandwidth to them without opening the case, but you'd have a maximum of two cards running at x16 speed. Apple already has something like this going on in their Mac Pro workstations.
With some subtle variation, the cube farm can be transformed from a soulless cell block into something that actually improves productivity. If you organize each functional team's cubes around their own central open areas, communication between team members will improve significantly.
For a long time, I had a computer that had an impatient BIOS and a lazy CD-ROM drive. The drive would take much, much longer to spin up than the BIOS would wait for data. If you booted up the system with the CD in the drive, the CD would spin up at poweron, then spin down immediately after reaching full speed with no requests pending, and when the BIOS got around to checking it for boot media, it would time out before it finished spinning up again and started reading. The window of opportunity for inserting the CD and having it be recognized was only about a second long. I found that if I inserted the CD right after the BIOS reported the results of scanning the primary IDE channel, while it was scanning the secondary IDE channel, it almost always got to the "scan CD-ROM boot sector" phase right as the drive was hitting full speed, and I could boot from the CD.
Although it is shrouded in carefully constructed legal formalism, the judge's anger is veiled quite thinly. My favorite excerpts from the ruling:
Page 40:
We must first note that the Office of the Chief Executive has itself been created, with its powers, by the Constitution. There are no hereditary Kings in America and no powers not created by the Constitution. So all "inherent powers" must derive from that Constitution.
Translation:
"Good morning children. Today we're going to talk about the Constitution. Can anyone tell me what makes the United States different from a monarchy?"
Page 41:
Indeed, since Ex Parte Milligan, we have been taught that the "Constitution of the United States is a law for rulers and people, equally in war and in peace. . .." Ex Parte Milligan, 71 U.S. (4 Wall.) 2, 120 (1866).
Translation:
"Since 1866, every law student has been taught that the constitution applies to everyone at all times. You went to law school, right? How can you even argue this with a straight face?"
Statistical analysis of the correlation between living under high-tension power lines and childhood leukemia based on distance discovered that the rate of fall-off with distance from the power lines is far too slow to correspond to any natural phenomenon. In other words, living under power lines tends to increase the risk of childhood leukemia, but not because of the power lines. Think about it. You tend to see high-tension lines near industrial areas, which also tend to be high in various forms of carcinogenic pollution, and they're usually hidden away around rich neighborhoods whose residents can better afford preventative health care that keeps their children's immune systems stronger.
watch those beta electron emitters
on
Halving Half Lives
·
· Score: 2, Interesting
Note that beta electron emitters actually get a longer half-life out of this process, not a shorter one. It only shortens the half-life of alpha emitters and beta positron emitters. On the plus side, the main hazardous electron beta emitter that we care about is Tritium, which already has a very short half-life.
In fact, the effect on beta electron emitters could turn out to be even more useful. Using this effect to dispose of alpha emitters is a problem because the decay process emits heat, but you could use the same phenomenon to preserve your 12-year-half-life tritium, since you're suppressing the process that would be heating it up.
Serial modems implemented a standard and had to be bit-perfect or fail. Graphics companies have been known to patent their bugs upon discovering that they made things faster at the expense of a little bit of correctness, but things still looked "good enough". In the graphics world, performance trumps correctness, until the next game comes out that uses your slightly-broken feature in a new way and looks really ugly (or freezes your system), and then you need to push out a new driver. You can't do that nearly as easily if it's in firmware.
By the way, I'm not complaining about how graphics companies write their drivers. I think it's generally the right thing to do, and the poster's suggestion would break that model.
Actually, I'd like it if hardware was *less* smart. Driver bugs are much easier to diagnose and fix than firmware bugs, and the fixes are easier to apply.
The real problem with video drivers is software patents. The graphics vendors have to be paranoiacally secretive about how their cards work, because they're all violating thousands of patents that should never have been granted in the first place. If you want to fix this situation, call your congresscritter.
If you think nuclear power is a radiological hazard, take a closer look at coal. If you could magically (with no cost or energy input) extract all the uranium from coal and power a nuclear reactor with it, the amount of energy released would be on the same order of magnitude. (Of course, this varies by coal vein.) Coal-burning power plants release a huge amount of radioactive material into the atmosphere, far more than nuclear plants do.
Hey, you're letting IBM off easy. IBM is a huge company with many product groups that have little interaction with each other, even though their products end up being used together routinely. They will test an extremely complex system of separately-sold hardware and software components with precisely one combination of firmware and driver levels, and they will repeat this process periodically as the components change, so if you buy all the parts at once, everything works fine, but if you buy them at different times (with different firmware levels) things will break in bizarre ways.
To IBM's credit, if you *do* deploy things exactly the way they tested, it works flawlessly, but this is impractical for all but the largest (read: richest) customers.
This isn't new. Hyperthreading puts a performance hit on software RAID 5 as well, but the impact isn't nearly as noticeable. The problem is that shared caches do poorly with the kind of workload that RAID 5 imposes on a system. HPC users have been disabling HyperThreading for years for the same reason. The higher degree of separation between execution threads on a multicore chip magnifies the problem several times.
They might be able to improve the dynamic cache sharing policy with a microcode update, but they should probably also work with OS vendors to optimize their RAID 5 drivers to be friendlier to chips with dynamically shared caches.
We got a call once from a customer who was trying to figure out why their Linux server kept rebooting. We looked at the logs, and sure enough, a few times a week, usually around 9 a.m. or 1 p.m., the system would gracefully shut down, as if someone had typed "reboot" or "shutdown -r now", and start back up again without fsck or any error. They weren't running any clustering or management software that should be auto-rebooting, or anything in cron, and there was nothing in root's bash history. At the time of these reboots, there were no users logged in to the system. There was no data corruption or substantial negative impact other than the intranet web server being down for a couple of minutes, but they were worried that this was a symptom of a more serious problem.
After a bit of pondering, I figured it out.
Does the server boot into X, or stop at a text login?
Text login
And is it plugged into a KVM, or does it have its own keyboard, mouse, and monitor?
It's on a KVM
What else is plugged into that KVM?
A mysql server and our domain controller.
What time does your Windows administrator come in to work?
He's here right now, should I get him on the line?
No, that's okay, but am I right that he gets in to work around 9:00 and gets back from lunch around 1:00?
I guess so, usually.
What does he do to log into the domain controller?
He switched displays, saw the "press ctrl-alt-del to log in", and burst out laughing.
One time a customer called in because the techs at her company (she was in purchasing) couldn't install the boxed version of our product due to a known bug. We had an updated version available as a 4 CD ISO download, but no corresponding boxed version. They had a modem link, so this was going to take a very long time. Recall that this woman is in purchasing, and often deals with suppliers who send out catalogs as huge image-filled PDFs, which do not do well over a shared modem link. Reciting the line she had used so often before, she said, and I quote verbatim:
"Can you just print them out and mail them?"
We calculated that in base64 using standard fixed width resolution, this would take 833 REAMS of paper.
The trick is finding the right electrolyte. For Aluminum, it was Cryolyte. For Titanium, it turns out to be a mix of Titanium and Calcium oxides. Interestingly, it looks like the current prevailing method of pulling the oxygen out of Titanium is similar to the method used for Aluminum before the electrolyte method was discovered.
Someone more knowledgeable than I am please correct/elaborate, but isn't this essentially the same process that turned aluminum from a rare and barely-usable metal into a ubiquitous industrial material?
I suspect that the Cell's design is not as elegant (from a programmer's POV) as it could have been, only because it was not designed with an elegant software model in mind. I don't think it is a good idea to design a software model around a CPU. It is much wiser to design the CPU around an established model. In this vein, I don't see the cell as a truly revolutionary processor because, like every other processor in existence, it is optimized for the algorithmic software model. A truly innovative design would have embraced a non-algorithmic, reactive, synchronous model, thereby killing two birds with one stone: solving the current software reliability crisis while leaving other processors in dust in terms of performance.
I've read this a dozen times, and can't figure out what the hell you're talking about.
Anyway, as so many other people have pointed out, if 99% of your CPU cycles are spent doing matrix multiplication, and you can make matrix multiplication go 5 times faster with some assembly optimization, your application is now almost 5X faster, without touching 99% of your code. This really happens in scientific computation. It's the extremely friendly end of the spectrum of Amdahl's Law, and is why reusable libraries are very good.
Slashdot Mirror
[IANAL]
When you sue someone, you have to state a reason. If you can't at least BS "emotional distress" the judge will generally throw it out before trial for "failure to state a claim upon which relief can be granted". Suits like this generally fall into a few categories:
1) Breach of Contract
From the sound of things, there's no contract to be breached.
2) Breach of Loyalty
If you willfully act against the interest of the company while you are employed, they can get damages. About the only way I can imagine that quitting your job would qualify is if you deliberately plan ahead of time (while you're still employed) to quit at a particularly inopportune time. Planning ahead of time to quit the day you get back from an expensive training program might qualify, because you're supposed to be going to that training for the company's benefit. Planning in advance to quit a customer-facing position in the middle of something in a way that would embarrass the company might also qualify.
3) Statutory obligations
If there's a law covering your job that states certain obligations that will be broken by the manner in which you quit your job, they may be able to sue for this if you don't meet those requirements. This generally only applies to licensed professionals.
4) stealing and breaking things
This doesn't really apply to quitting, but such accusations are not uncommon when someone leaves a job on bad terms. Failing to record the root password does *not* qualify as breaking things, unless you deliberately changed it to something secret before you left. It may mean you were lousy at your job, but all they can do about that is fire you.
[/IANAL]
...unless I can install an ssh client on it.
Modern CPUs have sufficiently complex decoder units at the front of sufficiently deep pipelines that the programmer-visible ISA has very little impact on the performance-critical aspects of the architecture. You need look no further than the vast architectural difference between AMD and Intel, or even Intel and Intel (P4 vs. Core) for the proof.
So, we'll keep using x86 in this market because it's what we've been using. We need *some* ISA, and now that the ISA itself is largely decoupled from the underlying implementation, there's very little incentive to change it.
My father is an attorney, and he once told me that you never ask a question you don't already know the answer to, unless the answer cannot possibly hurt you. There are a few possible answers here:
1) I don't know.
If he doesn't know, he's not an expert on MediaSentry.
2) None.
At this point you enter into evidence a copy of The Mythical Man-Month or some similar tome, and quote figures on bugs per lines of code. You have now discredited him.
3) Lots, for example...
This will go over *great* with a jury.
This guy claims that the hard drive provided must be the wrong hard drive because it doesn't show any evidence of file sharing whatsoever, and MediaSentry claims there was file sharing. Maybe it's a bug in MediaSentry.
I should have put more emphasis on top-tier. All the top-tier vendors sell Linux workstations, and the hardware in their mid-range consumer boxes is generally similar or identical to what they put in the low-end engineering workstations. They actually have engineering relationships with Linux vendors and employ developers to fix up the drivers if they have problems.
Outside of the top-tier OEMs that actually sell boxes with Linux preloaded, all bets are off.
A few months ago, I bought a new box, from parts. I thought I knew what I was doing. I inadvertently bought an Asus M2V board with an Attansic L1 gigabit chip on it. One thing led to another, and now I'm spending a lot of time fixing the vendor driver for upstream submission. It's certainly educational, but I wouldn't recommend it for newbies.
I don't question that you can do a better job of finding compatible parts than an OEM that doesn't care about Linux (and most of them don't), but I know a lot of Linux professionals like myself who have made similar mistakes, so I don't want to lead a newbie down that path.
So, to clarify my earlier recommendation, buy from a company that sells Linux, even if you're going to be buying a Windows box to dual-boot. The odds are much better that way that stuff will work with Linux, especially if you're not entirely sure what to be looking for otherwise.
Hardware:
.deb downloads, so with Fedora you'll be less likely to have to compile software yourself. The downside of Fedora is that older versions aren't supported for very long.
1) A CPU with hardware virtualization will greatly expand your options for using Windows and Linux together on the same box. Any Intel Core chip or AMD Socket AM2 chip will work.
and
2) Anything from a top-tier OEM is going to be much easier to make Linux work on than something you pieced together yourself.
and
3) Spend your money on RAM, not CPU.
Distro:
a) Ubuntu, as it benefits from the vast repositories of Debian software, but is better targeted for your use case.
or
b) Fedora Core, as it benefits from the vast repositories of RPM software. For out-of-distro software, you're more likely to find RPM downloads than
If having to do a major upgrade every year to be able to keep getting updates scares you, use Ubuntu. If having to compile your own software scares you, Fedora might be better, and Gentoo is definitely out.
There are plenty of other perfectly valid choices, but Ubuntu and Fedora Core are the obvious first two to mention for someone who's probably going to be spending a little time searching Google and browsing the user forums.
"...longer in wavelength than x-rays but shorter than microwaves..."
Well, they've just described upwards of 99% of the electromagnetic radiation emitted by the sun. And while it is certainly true that this is shorter than the microwaves that cook your food (well, this is slashdot, I should say *most* people's food), it is still within the range considered to be microwave radiation:
http://en.wikipedia.org/wiki/Light_spectrum
With PCIe, you can have x16 slots that don't have 16 lanes committed to them, and this can be configured in an appropriately featureful BIOS. So you could plug in 4 x16 cards, and reconfigure the bandwidth to them without opening the case, but you'd have a maximum of two cards running at x16 speed. Apple already has something like this going on in their Mac Pro workstations.
With some subtle variation, the cube farm can be transformed from a soulless cell block into something that actually improves productivity. If you organize each functional team's cubes around their own central open areas, communication between team members will improve significantly.
For a long time, I had a computer that had an impatient BIOS and a lazy CD-ROM drive. The drive would take much, much longer to spin up than the BIOS would wait for data. If you booted up the system with the CD in the drive, the CD would spin up at poweron, then spin down immediately after reaching full speed with no requests pending, and when the BIOS got around to checking it for boot media, it would time out before it finished spinning up again and started reading. The window of opportunity for inserting the CD and having it be recognized was only about a second long. I found that if I inserted the CD right after the BIOS reported the results of scanning the primary IDE channel, while it was scanning the secondary IDE channel, it almost always got to the "scan CD-ROM boot sector" phase right as the drive was hitting full speed, and I could boot from the CD.
Page 40:
Translation:
"Good morning children. Today we're going to talk about the Constitution. Can anyone tell me what makes the United States different from a monarchy?"
Page 41:
Translation:
"Since 1866, every law student has been taught that the constitution applies to everyone at all times. You went to law school, right? How can you even argue this with a straight face?"
Statistical analysis of the correlation between living under high-tension power lines and childhood leukemia based on distance discovered that the rate of fall-off with distance from the power lines is far too slow to correspond to any natural phenomenon. In other words, living under power lines tends to increase the risk of childhood leukemia, but not because of the power lines. Think about it. You tend to see high-tension lines near industrial areas, which also tend to be high in various forms of carcinogenic pollution, and they're usually hidden away around rich neighborhoods whose residents can better afford preventative health care that keeps their children's immune systems stronger.
Note that beta electron emitters actually get a longer half-life out of this process, not a shorter one. It only shortens the half-life of alpha emitters and beta positron emitters. On the plus side, the main hazardous electron beta emitter that we care about is Tritium, which already has a very short half-life.
In fact, the effect on beta electron emitters could turn out to be even more useful. Using this effect to dispose of alpha emitters is a problem because the decay process emits heat, but you could use the same phenomenon to preserve your 12-year-half-life tritium, since you're suppressing the process that would be heating it up.
Serial modems implemented a standard and had to be bit-perfect or fail. Graphics companies have been known to patent their bugs upon discovering that they made things faster at the expense of a little bit of correctness, but things still looked "good enough". In the graphics world, performance trumps correctness, until the next game comes out that uses your slightly-broken feature in a new way and looks really ugly (or freezes your system), and then you need to push out a new driver. You can't do that nearly as easily if it's in firmware.
By the way, I'm not complaining about how graphics companies write their drivers. I think it's generally the right thing to do, and the poster's suggestion would break that model.
Actually, I'd like it if hardware was *less* smart. Driver bugs are much easier to diagnose and fix than firmware bugs, and the fixes are easier to apply.
The real problem with video drivers is software patents. The graphics vendors have to be paranoiacally secretive about how their cards work, because they're all violating thousands of patents that should never have been granted in the first place. If you want to fix this situation, call your congresscritter.
If you think nuclear power is a radiological hazard, take a closer look at coal. If you could magically (with no cost or energy input) extract all the uranium from coal and power a nuclear reactor with it, the amount of energy released would be on the same order of magnitude. (Of course, this varies by coal vein.) Coal-burning power plants release a huge amount of radioactive material into the atmosphere, far more than nuclear plants do.
while (1)
{
expected_phenomena = simulate(current_theory);
observed_phenomena = look_for_similar(expected_phenomena);
current_theory.refine(expected_phenomena, observed_phenomena);
}
Hey, you're letting IBM off easy. IBM is a huge company with many product groups that have little interaction with each other, even though their products end up being used together routinely. They will test an extremely complex system of separately-sold hardware and software components with precisely one combination of firmware and driver levels, and they will repeat this process periodically as the components change, so if you buy all the parts at once, everything works fine, but if you buy them at different times (with different firmware levels) things will break in bizarre ways.
To IBM's credit, if you *do* deploy things exactly the way they tested, it works flawlessly, but this is impractical for all but the largest (read: richest) customers.
This isn't new. Hyperthreading puts a performance hit on software RAID 5 as well, but the impact isn't nearly as noticeable. The problem is that shared caches do poorly with the kind of workload that RAID 5 imposes on a system. HPC users have been disabling HyperThreading for years for the same reason. The higher degree of separation between execution threads on a multicore chip magnifies the problem several times.
They might be able to improve the dynamic cache sharing policy with a microcode update, but they should probably also work with OS vendors to optimize their RAID 5 drivers to be friendlier to chips with dynamically shared caches.
We got a call once from a customer who was trying to figure out why their Linux server kept rebooting. We looked at the logs, and sure enough, a few times a week, usually around 9 a.m. or 1 p.m., the system would gracefully shut down, as if someone had typed "reboot" or "shutdown -r now", and start back up again without fsck or any error. They weren't running any clustering or management software that should be auto-rebooting, or anything in cron, and there was nothing in root's bash history. At the time of these reboots, there were no users logged in to the system. There was no data corruption or substantial negative impact other than the intranet web server being down for a couple of minutes, but they were worried that this was a symptom of a more serious problem.
After a bit of pondering, I figured it out.
Does the server boot into X, or stop at a text login?
Text login
And is it plugged into a KVM, or does it have its own keyboard, mouse, and monitor?
It's on a KVM
What else is plugged into that KVM?
A mysql server and our domain controller.
What time does your Windows administrator come in to work?
He's here right now, should I get him on the line?
No, that's okay, but am I right that he gets in to work around 9:00 and gets back from lunch around 1:00?
I guess so, usually.
What does he do to log into the domain controller?
He switched displays, saw the "press ctrl-alt-del to log in", and burst out laughing.
One time a customer called in because the techs at her company (she was in purchasing) couldn't install the boxed version of our product due to a known bug. We had an updated version available as a 4 CD ISO download, but no corresponding boxed version. They had a modem link, so this was going to take a very long time. Recall that this woman is in purchasing, and often deals with suppliers who send out catalogs as huge image-filled PDFs, which do not do well over a shared modem link. Reciting the line she had used so often before, she said, and I quote verbatim:
"Can you just print them out and mail them?"
We calculated that in base64 using standard fixed width resolution, this would take 833 REAMS of paper.
...about those RDMA-enabled ethernet cards?
Hey, give *me* a bit of credit. Now that I had time to look it up...
o cess
http://en.wikipedia.org/wiki/Hall-H%C3%A9roult_pr
The trick is finding the right electrolyte. For Aluminum, it was Cryolyte. For Titanium, it turns out to be a mix of Titanium and Calcium oxides. Interestingly, it looks like the current prevailing method of pulling the oxygen out of Titanium is similar to the method used for Aluminum before the electrolyte method was discovered.
Someone more knowledgeable than I am please correct/elaborate, but isn't this essentially the same process that turned aluminum from a rare and barely-usable metal into a ubiquitous industrial material?
I suspect that the Cell's design is not as elegant (from a programmer's POV) as it could have been, only because it was not designed with an elegant software model in mind. I don't think it is a good idea to design a software model around a CPU. It is much wiser to design the CPU around an established model. In this vein, I don't see the cell as a truly revolutionary processor because, like every other processor in existence, it is optimized for the algorithmic software model. A truly innovative design would have embraced a non-algorithmic, reactive, synchronous model, thereby killing two birds with one stone: solving the current software reliability crisis while leaving other processors in dust in terms of performance.
I've read this a dozen times, and can't figure out what the hell you're talking about.
Anyway, as so many other people have pointed out, if 99% of your CPU cycles are spent doing matrix multiplication, and you can make matrix multiplication go 5 times faster with some assembly optimization, your application is now almost 5X faster, without touching 99% of your code. This really happens in scientific computation. It's the extremely friendly end of the spectrum of Amdahl's Law, and is why reusable libraries are very good.