Well, you didn't say if you had DMA enabled for the ATA drives or not. It doesn't come that way out of the box, and I have no idea if Dell does the right thing or not. The program you use to investigate this is "hdparm", and you should be able to find a HOWTO which discusses it.
However, DMA mode is only the half of it. The amount of memory you have and the ability of your OS to properly manage it is the other half of it.
ATA already has features which don't "bog the CPU"
and "cripple the user interface". Your criticism is 5 years old; a few OSes (like Linux) have this fully
implemented.
Of course, the OS can also cripple the user interface during heavy disk access, SCSI or ATA.
You can be obnoxious ("verbal gymnastics", how polite) or you can hold a conversation. I see you've made your choice. But I would strongly disagree with your claim that this is a "discussion".
There's an excellent reason to GPL goverment-funded
work: some researchers don't want to do the work otherwise. That's why the PITAC report endorsed
giving individual PIs the power to decide what license to use.
Your comment doesn't fit the text of the article. AMD clearly is seeking a fast simulator for the x86-64 instruction set. Whether Transmeta licenses LDT or not is a separate issue. And whether or not you think Transmeta's technology is new or not, it certainly is a dandy way to build a fast simulator for an x86-related instruction set.
There's no reason why Transmeta sledgehammer compatible chips are a long way off. First off, the simulator chip could be completely sledgehammer compatible, albeit a bit slow on actual 64-bit operations, since the Transmeta chips apparently currently have 32-bit ALUs. Second, extending the Transmeta chips to have 64-bit ALUs probably isn't that expensive. The MIPS guys have reported how much complexity it added to the R4000... it wasn't bad.
There are many real workloads that can use more than 4 units. Many numerical programs, for example. SMT is a great way of running these programs really fast while doing as good as several current CPUs on workloads which can't use as many functional units.
The Tera MTA requires a compiler to multi-thread all processes. You only get 1 functional unit (and huge latencies == terrible speed) if your program can't be transformed by the compiler.
SMT, in contrast, can work on programs which can't be multi-threaded by a compiler. It works on "instruction level parallelism" (ILP). This is a much finer grain than parallelism that a compiler can find and exploit with another thread.
From reading the datasheet, the IXP1200 has nothing to do with SMT.
And you don't need a new benchmark for multi-threaded processors; current benchmarks generally cover both single process performance and workloads. For workstations, these benchmarks are SPEC2000 and SPECrate2000...
5 years ago roughly what you describe was already being implemented by someone as a research project. So I don't know why you were pissed, it's been a known idea for quite a while.
Just because benchmarks are single threaded doesn't mean that they can't benefit from multiple execution units. Typical chips today (Pentium III, Alpha) have a lot more than 1 exectuion unit, and get a benefit from it most of the time.
The benefit of SMT over N smaller cpus is flexability: A program that can use the entire chip at once is damn fast, or several programs can share it.
CPlant has 2400 nodes in New Mexico and something like 500 nodes in California. These are Alphas, so for floating point computations, they're 2x as fast as x86 cpus.
Incyte has 3,000 cpus in their genomics cluster. It runs embarrassingly parallel computations, but they're still parallel.
Your problem doesn't need a fancy solution. Copy the database to all the local hard drives, and use them from there. When you change the database, recopy it. If "rarely" is "rarely enough", that simple solution will get you there.
From your name, it sounds like you're doing gene sequence searches. Lots of people do it that way.
Try being precise for once, and you'll understand that the bill that Al Gore sponsored in Congress created something very specific, with a particular name... now, what was that name?
Many leases don't let you have waterbeds because of floor loading issues. Now, think for a minute about the floor loading of a CRAY YMP C90. Hint: I've never seen one installed on a 2nd floor. They're mostly in basements.
Well, you didn't say if you had DMA enabled for the ATA drives or not. It doesn't come that way out of the box, and I have no idea if Dell does the right thing or not. The program you use to investigate this is "hdparm", and you should be able to find a HOWTO which discusses it.
However, DMA mode is only the half of it. The amount of memory you have and the ability of your OS to properly manage it is the other half of it.
Well, actually, I was thinking about VM policy
issues, but yeah, using the BIOS is a sure way
to shoot yoursel fin the foot.
ATA already has features which don't "bog the CPU"
and "cripple the user interface". Your criticism is 5 years old; a few OSes (like Linux) have this fully
implemented.
Of course, the OS can also cripple the user interface during heavy disk access, SCSI or ATA.
You can be obnoxious ("verbal gymnastics", how polite) or you can hold a conversation. I see you've made your choice. But I would strongly disagree with your claim that this is a "discussion".
Have a bad day.
Nope, I didn't assume that.
Yes, I see that "available" has multiple definitions. That was my point. Thank you
for agreeing.
Now for the word "use": You can "use" GPLed code without GPLing your code. For example, you can use gcc to compile a commercial program.
Keep it up, you'll eventually get it!
Funny how you assume everyone shares your
definition of "make their code available" and
"be able to use it".
GPLed code is available and can be used. BSD
code is available and can be used.
You must have been asleep for all those years
that people were arguing about "Free Software"
and "Open Source".
There's an excellent reason to GPL goverment-funded
work: some researchers don't want to do the work otherwise. That's why the PITAC report endorsed
giving individual PIs the power to decide what license to use.
Typical... of the lame marketing back-seat-driving
that was the most memorable feature of the OS/2,
Amiga, and Atari ST communities.
Perl is a Swiss Army Chainsaw, not a Swiss Army Knife.
When VA first went "underwater", I posted a
"Ask Slashdot" when we were going to get the "Meditations on Sudden Poverty" essay.
Too bad they never print any *interesting* Ask Slashdots...
Your comment doesn't fit the text of the article. AMD clearly is seeking a fast simulator for the x86-64 instruction set. Whether Transmeta licenses LDT or not is a separate issue. And whether or not you think Transmeta's technology is new or not, it certainly is a dandy way to build a fast simulator for an x86-related instruction set.
There's no reason why Transmeta sledgehammer compatible chips are a long way off. First off, the simulator chip could be completely sledgehammer compatible, albeit a bit slow on actual 64-bit operations, since the Transmeta chips apparently currently have 32-bit ALUs. Second, extending the Transmeta chips to have 64-bit ALUs probably isn't that expensive. The MIPS guys have reported how much complexity it added to the R4000... it wasn't bad.
There are many real workloads that can use more than 4 units. Many numerical programs, for example. SMT is a great way of running these programs really fast while doing as good as several current CPUs on workloads which can't use as many functional units.
Latency to main memory is only one of many problems you're trying to solve. The Tera MTA solves only that problem; SMT solves more.
If you think it looks cool, you're the only person on the planet who does. It made me retch the first time I saw it.
The Tera MTA requires a compiler to multi-thread all processes. You only get 1 functional unit (and huge latencies == terrible speed) if your program can't be transformed by the compiler.
SMT, in contrast, can work on programs which can't be multi-threaded by a compiler. It works on "instruction level parallelism" (ILP). This is a much finer grain than parallelism that a compiler can find and exploit with another thread.
From reading the datasheet, the IXP1200 has nothing to do with SMT.
And you don't need a new benchmark for multi-threaded processors; current benchmarks generally cover both single process performance and workloads. For workstations, these benchmarks are SPEC2000 and SPECrate2000...
5 years ago roughly what you describe was already being implemented by someone as a research project. So I don't know why you were pissed, it's been a known idea for quite a while.
Just because benchmarks are single threaded doesn't mean that they can't benefit from multiple execution units. Typical chips today (Pentium III, Alpha) have a lot more than 1 exectuion unit, and get a benefit from it most of the time.
The benefit of SMT over N smaller cpus is flexability: A program that can use the entire chip at once is damn fast, or several programs can share it.
CPlant has 2400 nodes in New Mexico and something like 500 nodes in California. These are Alphas, so for floating point computations, they're 2x as fast as x86 cpus.
Incyte has 3,000 cpus in their genomics cluster. It runs embarrassingly parallel computations, but they're still parallel.
Aren't you pointing out your ego problem? RMS didn't say the words you'd like to put in his mouth.
Your problem doesn't need a fancy solution. Copy the database to all the local hard drives, and use them from there. When you change the database, recopy it. If "rarely" is "rarely enough", that simple solution will get you there.
From your name, it sounds like you're doing gene sequence searches. Lots of people do it that way.
Al Gore was in school when ARPANet was created.
Try being precise for once, and you'll understand that the bill that Al Gore sponsored in Congress created something very specific, with a particular name... now, what was that name?
That's the cover letter being quoted, not the report.
Unfortunately, the cover letter wasn't subject to the same review process that the report was.
Many leases don't let you have waterbeds because of floor loading issues. Now, think for a minute about the floor loading of a CRAY YMP C90. Hint: I've never seen one installed on a 2nd floor. They're mostly in basements.