Posted by
Hemos
on from the conjecture-or-convinced dept.
vmircea writes "If you think clock speed is the most important measure of a processor, IBM's Bernie Meyerson wants you to reconsider. Meyerson, who heads research and development efforts for Big Blue's semiconductor group, says processor chip speed is old news. Go to ZDNet for the interview."
Same old
by
Anonymous Coward
·
· Score: 5, Informative
Sounds like the same thing AMD has been trying to convince people of for the past 5 years, while Intel has been lengthening their processor pipelines to ramp up clockspeed while effectively lowering instructions per clock. Unfortunately no one bought it when AMD was saying it, so they had to come out with their PR naming system. Let's hope that at least IBM and their significantly bigger clout can change the picture. It seems like Intel's getting on board too, it seems there are rumblings of them moving their notebook M processors to the desktop as things have gone to hell when transitioning to 90nm fabrication. (In terms of power dissipation)
Clock speed DOES have more meaning for RISC processors. You can judge their performance more or less by the change in clock speed from a prior chip with the same instruction set. However modern RISC processors are not entirely RISC, they contain coprocessors which have instructions which definitely take more than one cycle to complete. Granted the instruction that ships the data off to them should still only require one instruction, and later it should only take one instruction to get it back, so it becomes just a matter of redefinition of terms.
Of course, differences in parallelism, fetch and store speed and so on will make a big difference. The number of functional units and how rapidly you can actually stuff them, the penalty for a bad branch prediction on processors with OoO execution and other factors still have just as much to do with performance as clock rate.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:Seems IBM is embracing open standards
by
AKAImBatman
·
· Score: 2, Informative
Seems IBM is embracing open standards
It also seems that IBM is a few years late in that respect. (See: IEEE Standard 1754-1994)
If they succeed it doesn't bode well for the x86 architecture, which seems to be a victim of it's own success. They seem to be trapped into just adding faster clocks instead of changing the architecture.
As much as I can't believe I'm defending the Intel architecture, Intel *has* been modifying their chip design. Out of order instructions, Superscalar execution, instruction pipelining, branch prediction, etc. are all in the current classes of Pentium processors. There are two reasons, however, that these don't affect Intel processors as much as other architectures:
1. The awful Intel instruction set was created as part of a quick "stop-gap" product called the 8088 (and later the 8086). Intel had planned to redesign the thing, but got trapped when IBM used it for PCs. This has led to more crappy instructions being bolted on for 32 bit support. This instruction set has made it somewhat difficult for Intel to use traditional performance enhancements. (e.g. A common block of instructions don't quite fit the superscalar block, resulting in lost performance gains.)
2. Intel tunes their chips for video games. Sorry folks, you've all been asking for single threaded performance. Well, single threaded performance is what you've got. The Intel chips will outdo every other architecture on Quake III. Just start praying that your servers don't need to multitask more than 20 or so concurrent threads.
Check your cooling
by
Trigun
·
· Score: 2, Informative
The processor shouldn't just lock up like that. Perhaps the heavy load is overheating it?
Re:Poeple still want more ghz...
by
xplosiv
·
· Score: 2, Informative
Actually, the rating means how fast the AMD XP cpu is compared with the original Athlon series, not the speed of the P4 counterpart it can compete with. You can read more about the XP rating in the AMD press releases when they first introduced it, search their site or use google.
Not exactly. Using SMP helps in other ways. The OS/resources need managing and when his application is using CPU 1 at 95-100% CPU 0 is hugging curves and taking names at about 30% doing memory and disk management, etc. He is having lock-ups because he has one cpu. More RAM, faster disks, more CPUs will help him out. While the application may not be able to make use of multiple threads (hypothetically, it very well might be able to) the system as a whole sure could use multiple thread execution. HT is not the answer as they both rely on the same cache and also similar parts of the same CPU.
SPECfpBase2000 and SPECintBase2000 cover almost everything usefull you can do with a computer. Btw the problem with FPGA's is that gate reconstruction times are so slow that you REALLY have to be doing a lot of something for it to make sense, like compressing an entire movie, and even then you might be able to do 90+% of the speed by using assembly and vector ops. Add to that the fact that FPGA's have a limited number of rewrite cycles and generally uses different fab processes and it gets to be pretty stupid for most applications.
-- There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Most FPGAs are RAM-based. Reconfigure as much as you want. This includes every Xilinx FPGA made. And there are some Xilinx Spartan II parts under $10. Pretty cool!
There are only a few FPGAs which use any sort of non-volatile memory (Actel's Pro-Asic being one). Those would have a limited life.
-- "-1 Troll" is the apparently the same as "-1 I disagree with you."
Re-programmable
by
The+Conductor
·
· Score: 4, Informative
There is a trade-off between speed, reliability, cost, and re-programmability.
SRAM types
Are re-programmable but require a rather slow serial load at boot-up. Reliability in embedded systems leaves something to be deisired since any brownout-induced glitch can create errors that are even worse (harder to recover from) than software glitches because wired logic doesn't have anything equivalent to code checksums or interrupt vectors. Well-paid FPGA designers are versed in the arcane art of self-verifying logic.
EEPROM types
Come alive at boot up and are much more resistant to glitches. Their performance, however, is slow. And you have limited (100,000 maybe) rewrite cycles.
Anti-fuse types
are made by Actel. They have the highest performance and best density. They come alive at boot up and are dead-nuts reliable under the worst of conditions; for example, properly qualified, they can survive the cosmic radiation in spacecraft that would leave other types toasted. The big drawback: the anti-fuse process, which works by melting diodes into short-circuits, is not eraseable.
Desktop systems (say, an add-on FPGA card) would be best served by SRAM types, since you already have a processor that requires gluttinous gobs of puritanically clean DC power. Basement hardware hackers would be better served by EEPROM or anitfuse types (depending on performance requirements), since they don't require super-expensive exotic design software.
Re:How CONVENIENT.
by
blamanj
·
· Score: 3, Informative
Re:Power is not for PC
by
rve
·
· Score: 3, Informative
It's not the programming language Java perse, but the writing in an interpreted language for an application server sitting on top of a virtual machine sitting on top of the operating system's HAL sitting on top of the hardware as opposed to writing a natively compiled app for the HAL as we did before.
But you're right, I'm not an enterprise Java developer.
Re:Power is not for PC
by
rve
·
· Score: 2, Informative
This doesn't really concern us because we spend far less time tracking down dangling pointers and memory leaks now.
That isnt really an issue for COBOL programmers hehe:)
Slashdot Mirror
Sounds like the same thing AMD has been trying to convince people of for the past 5 years, while Intel has been lengthening their processor pipelines to ramp up clockspeed while effectively lowering instructions per clock. Unfortunately no one bought it when AMD was saying it, so they had to come out with their PR naming system. Let's hope that at least IBM and their significantly bigger clout can change the picture. It seems like Intel's getting on board too, it seems there are rumblings of them moving their notebook M processors to the desktop as things have gone to hell when transitioning to 90nm fabrication. (In terms of power dissipation)
> What other applications besides games really tax the CPU right now?
as a developer i want compilation to be a quick as possible.
also i make heavy use of vmware, which needs as much grunt as it can get.
nostrils
Granted, it's not an average application, but I do consider myself to be an average joe, so there you go. :-)
There are many applications, like software defined radios and televisions, that require huge amounts of number crunching.
Mea navis aericumbens anguillis abundat
Of course, differences in parallelism, fetch and store speed and so on will make a big difference. The number of functional units and how rapidly you can actually stuff them, the penalty for a bad branch prediction on processors with OoO execution and other factors still have just as much to do with performance as clock rate.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Seems IBM is embracing open standards
It also seems that IBM is a few years late in that respect. (See: IEEE Standard 1754-1994)
If they succeed it doesn't bode well for the x86 architecture, which seems to be a victim of it's own success. They seem to be trapped into just adding faster clocks instead of changing the architecture.
As much as I can't believe I'm defending the Intel architecture, Intel *has* been modifying their chip design. Out of order instructions, Superscalar execution, instruction pipelining, branch prediction, etc. are all in the current classes of Pentium processors. There are two reasons, however, that these don't affect Intel processors as much as other architectures:
1. The awful Intel instruction set was created as part of a quick "stop-gap" product called the 8088 (and later the 8086). Intel had planned to redesign the thing, but got trapped when IBM used it for PCs. This has led to more crappy instructions being bolted on for 32 bit support. This instruction set has made it somewhat difficult for Intel to use traditional performance enhancements. (e.g. A common block of instructions don't quite fit the superscalar block, resulting in lost performance gains.)
2. Intel tunes their chips for video games. Sorry folks, you've all been asking for single threaded performance. Well, single threaded performance is what you've got. The Intel chips will outdo every other architecture on Quake III. Just start praying that your servers don't need to multitask more than 20 or so concurrent threads.
Javascript + Nintendo DSi = DSiCade
The processor shouldn't just lock up like that. Perhaps the heavy load is overheating it?
Actually, the rating means how fast the AMD XP cpu is compared with the original Athlon series, not the speed of the P4 counterpart it can compete with. You can read more about the XP rating in the AMD press releases when they first introduced it, search their site or use google.
Not exactly. Using SMP helps in other ways. The OS/resources need managing and when his application is using CPU 1 at 95-100% CPU 0 is hugging curves and taking names at about 30% doing memory and disk management, etc. He is having lock-ups because he has one cpu. More RAM, faster disks, more CPUs will help him out. While the application may not be able to make use of multiple threads (hypothetically, it very well might be able to) the system as a whole sure could use multiple thread execution. HT is not the answer as they both rely on the same cache and also similar parts of the same CPU.
SPECfpBase2000 and SPECintBase2000 cover almost everything usefull you can do with a computer. Btw the problem with FPGA's is that gate reconstruction times are so slow that you REALLY have to be doing a lot of something for it to make sense, like compressing an entire movie, and even then you might be able to do 90+% of the speed by using assembly and vector ops. Add to that the fact that FPGA's have a limited number of rewrite cycles and generally uses different fab processes and it gets to be pretty stupid for most applications.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Most FPGAs are RAM-based. Reconfigure as much as you want. This includes every Xilinx FPGA made. And there are some Xilinx Spartan II parts under $10. Pretty cool!
There are only a few FPGAs which use any sort of non-volatile memory (Actel's Pro-Asic being one). Those would have a limited life.
"-1 Troll" is the apparently the same as "-1 I disagree with you."
There is a trade-off between speed, reliability, cost, and re-programmability.
SRAM types
Are re-programmable but require a rather slow serial load at boot-up. Reliability in embedded systems leaves something to be deisired since any brownout-induced glitch can create errors that are even worse (harder to recover from) than software glitches because wired logic doesn't have anything equivalent to code checksums or interrupt vectors. Well-paid FPGA designers are versed in the arcane art of self-verifying logic.
EEPROM types
Come alive at boot up and are much more resistant to glitches. Their performance, however, is slow. And you have limited (100,000 maybe) rewrite cycles.
Anti-fuse types
are made by Actel. They have the highest performance and best density. They come alive at boot up and are dead-nuts reliable under the worst of conditions; for example, properly qualified, they can survive the cosmic radiation in spacecraft that would leave other types toasted. The big drawback: the anti-fuse process, which works by melting diodes into short-circuits, is not eraseable.
Desktop systems (say, an add-on FPGA card) would be best served by SRAM types, since you already have a processor that requires gluttinous gobs of puritanically clean DC power. Basement hardware hackers would be better served by EEPROM or anitfuse types (depending on performance requirements), since they don't require super-expensive exotic design software.
Ummm. This isn't about Apple, it's about the semiconductor industry. As a matter of fact, Intel started saying the same thing a few months ago, and AMD has been making similar claims for years.
It's not the programming language Java perse, but the writing in an interpreted language for an application server sitting on top of a virtual machine sitting on top of the operating system's HAL sitting on top of the hardware as opposed to writing a natively compiled app for the HAL as we did before.
But you're right, I'm not an enterprise Java developer.
This doesn't really concern us because we spend far less time tracking down dangling pointers and memory leaks now.
:)
That isnt really an issue for COBOL programmers hehe