Still, 5 million Hz is 5 million Hz. I see nothing spectacular in that, and frankly I will see less, just when thinking that in order to run Word 2020 using pictures along text, you will need 5Ghz at least (Os'es are great at eating CPU's), without running anything else. Sounds logic, economic, fair?

The power of these CPU's would never be used at their full power. First they have bugs (1, or 2, but they DO have at least one, but they are cosmetized as "different, new gen out"), Bioses these days DO have some bugs (5-10 at least) otherwise there wouldn't be hardware compatibility problems, Windows has TONS TONS TONS of bugs, programs that are done by gaming companies have TONS (x4)... And so on...

Next thing is why bother doing something to use at max the CPU, when anyway next month a new one, faster would appear? All the software and hardware producers know that, and know that they shouldn't spend money and time to improve something, as long as it works. And finally, the only time when the CPU's would be used nearly max, would be when we can't produce faster CPU's, the limit has been reached. But then again, soon another "PC" would be available, so this mad-crazy-SF "science and efficiency is back" script would never be real.

The first thing to notice is that, for example, when using a text processing program, you never use 32 bit (fully). Actually you are far from this need. When working on a graphics design app, you are using 32 bit (really) only when you are working with graphics (scaling, effects). When doing a sound processor you use 32 bit only when you load/save a file, and perhaps at some effects.

Finally, in the movie making or inside a 3D app, you never use 32 bit for something like AI. Of course, you use bigger precision, but I don't remember a game to act accordingly to 0,00000000... distance precision. More than that tons of decisions are taken in things like if I=0... and if I=1 (Boolean) you don't even use 8 bit (and these things fit nicely on a 32 bit bus reserved)... Only when you calculate geometry or transfer data from CPU to GPU you really use fully the 32bit or wider bus, but the CPU most of the time is not making transfers, or calculating geometry...

Even when 64 bit appears onto the market, the first thing that you get is bigger programs, but very rarely you need to cope with so big numbers.

Conclusion is if nothing changes, the 32/64/128 bit would never bring real increases of performance of more than 20% (commonly 10%), unless we will design better compilers, interpreters, assemblers, that are able to fit and execute more simultaneously operations on a 32/64/128 bus, and fill as much as possible the bus accordingly to the length of numbers and complexity of operations involved, not just let a single operation take the whole 32 bit bus for a split second...

Anyway, I know very well what I am saying. Then, can you prove why 80% of the performance increases where achieved by Mhz raising? Try using a P2 (333 Mhz) at 133 Mhz. There you will see clearly that MMX is not so important, that Quake3 cripples, that your movie compresion goes down, down, and that your wonderfull 3D Anim is taking a whole our to render 1 frame. Not convinced, right? Even if that CPU would be 64 bit it wouldn't change too much.

I didn't say anything about memory addressing. Everyone knows what EMS meaned back in the 80's DOS era: "swithcing pages memory" and it is clearly that it was very slow. Also, I see a very bright future for the Athlon 64, as the integrated memory controller would bring very big performance increases. 512 bit accessing is very normal for the future. What I am saying is that we really have few programs that use 100% 32 bit code, and that everything inside them is using 32 bit precision (to be effective). Let alone 64 bit, at least for the moment.

The CPU is the machine inside the machine that does all. This is the main problem. When you are talking about a GPU, almost every inovation can bring benefits, and, for example, 64 bit color would be usefull in the future, along with higher resolutions. CPU's evolution is much more problematic, and even includes the forgotten part of backward compatibility, which, at a time, gets to create big constraints on the design.

And about the rank, let alone the joke. Is it so hard to prove that so many things are dependent on Mhz these days for the CPU's. I don't think that even a ton of tests (sec to do that) would prove to you and others what a big difference makes the CPU operating frequency, and, to a lesser degree FSB and latency's. Of course a lower CPU could beat a newer one in performance, because of it's design, but in general this is not likely to happend as one CPU's enhancement could overcome one problem.

Quote:


Well, if you knew at least a bit about x86 CPU Cores, you'd see what errors you're making again.

So let's see :
- Branch Prediction
- Branch Target Cache
- Register Extensions and renaming
- Speculative Execution
- SuperScalar Execution
- Out-of-Order Execution
- L1 and L2 Code/Data Caches
- Cache Strategies
- n-way Cache association
- Singe/Double-Precision Integer and Math SIMD
- integrated Integer/Floating Point ALU
- n-layer CPU Designs
- HyperThreading (intel)
- HyperTransport Channels (AMD)
- Integrated Memory Controller
- Pipelining

Above are only a few reasons why a massive factor of today's CPU Design capabilities is NOT derived from Clock alone

AGAIN :
Dig up some Information before making bogus statements!

Quote:


*sigh*
Memory Addressing has always been a Key Factor for moving from old 8 bit Designs to 16/32/64 bit.
It goes hand in hand with the new Designs, and cannot be simply 'left out' when bashing 64, or even 32bit like you did.

Quote:


The correct statement would read :
At this time, we have almost no native 16bit Code remaining in currently designed, or upcoming Software pieces. Apart from the fact that no sane Coder or Compiler will generate 16bit Code in the first place, it is of no use anymore, and implies terrible restrictions (if anyone was masochistic enough to still use them for whatever reason).

Whether each of the 32 bits are all needed all the time, is completely irrelevant.
You can't for instance, deactivate 2 or even 4 Cylinders of a running V8 Engine on the fly, just because you don't need all the horsepower every now and then. They are there, and they will run along, even if they aren't required for isolated strokes.

Feel free to propose your own CPU design, that magically and variably switches from being an 8bit Core upto a 64bit Core a Billion Times a Second.

The Binary System has some fixed rules, in case you haven't noticed, which can't be overcome (except for abusing a free Bit for Status Flagging or alike)

Quote:


*ack*
No, the CPU doesn't do it all. Actually, today's CPU's are more free from "generic processes" than they were ever before, assisted by a myriad of external Logic Chips.
64bit is already availble, albeit only useful for excessive Shader Operations.

I loved your sentence about the "forgotten backward compatibility".
Name any CPU Family apart from the x86, that is still able to execute native Code from its absolutely first design ???
Answer : there is none !

The x86 CPU Design's success is built upon its abolutely unique backwards compatibility!

Quote:


Ehm, you're contradicting yourself there. How can you bash "GHz frenzy" and 32/64bit, while now you claim that MHz is a major factor for today's CPU powers ?!

Anyway, be very careful here....
This wasn't a Joke, but an ample, last warning in your direction.

One more step in the direction you're walking (actually, since the first day you got here), all countermeasures I listed in above Posting will go in effect, without any further Warning. I've given you more than half a dozen warnings, but you continue to fall back into your old scheme.