> That was between 20 to 50% clock increaseIn other words,
>you would be comparing 2.8 and 3.2 GHz
>with 3.8 and 4.2 GHz! Really not different?
No, not that different. Sure, jumps in clockspeed have reduced as we got more models -I mean, we have how many actual models ? 2,2.2,2.4,2.6,2.8,3.0,3.2,3.4, most in both 400, 533 and 800 MHz fsb's, as Celerons, P4s and P4EE's, with and without HT, SSE3,... there has go to be over 30 different variants if not more. In the old days you'd just have Pentium 75 (low end, like celeron), 90/100 mainstream, and 120/133 high end. So obviously the difference between mainstream and a one-step faster cpu would be bigger. But if you look at the product range and its pricing curve, you wouldnt see much if any difference. I would say 2.8 is mainstream now, which is 20% slower (clock) than the "normal" high end the 3.4C/E, and the uber/ultra EE would add another 10%performance (L3 cache). That is pretty much identical to the Pentium 100 being 20% slower than the 120, and the 133 adding a bit on top. You do realize the Pentium 133 was more expensive than the Pentium 4 3.4 EE when it was launched ? $935, 10 years ago.
Here is a good link for you:
<A HREF="http://www-ra.phys.utas.edu.au/~dr_legge/chip_prc.html" target="_new">http://www-ra.phys.utas.edu.au/~dr_legge/chip_prc.html</A>
>Please explain. I really fail to see the solid 50%
>performance increase there
I fail to see a solid 50% performance increase between a Pentium 100 and a 133 as well. And 30% would be more or less the difference between a 2 GHz A64 3000+ (mainstream) and a 2.4 GHz Athlon 64 FX or between a 2.8 GHz P4C and a 3.4 GHz EE.
>Maya. MATLAB. Visual C++. PhotoShop. Oops, you only asked
>one example...
Found no benchies for Matlab, but I really can't consider it a typical app either even if it would somehow reach anywhere near 100% speedup.
<A HREF="http://www.gamepc.com/labs/view_content.asp?id=wsapps&page=5" target="_new">Maya</A>: <b>39%</b> increase going from 1 to 2 (otherwise identical) Athlon 2100+'s.
<A HREF="http://www.gamepc.com/labs/view_content.asp?id=wsapps&page=7" target="_new">]C++ </A> a solid <b> 7% </b> improvement.
<A HREF="http://www.gamepc.com/labs/view_content.asp?id=thunderk7x&page=5" target="_new"> Photoshop 7 </A> impressive <b>14%</b> speedup.
Oops, I only asked for one indeed. None of your examples even seem to reach my optimistic 50% number.
> And you -can- do that twice as fast with twice as many
>people.
Not if you don't have twice as many dictionnaries and twice as many queries to run as well. And not if one of the searches depends upon the result of the other.
> I'm not saying it will be easy, but programmers will have
>to take advantage of multi-threading sooner or later. It's
>inevitable that future processors will be multi-core,
>multi-HT. It costs too many transistors to get another 5%
>of linear performance increase.
I don't disagree with you actually, its just not a silver bullet, and horizontal scaling (SMT, CMP,.) just can't replace vertical (clock/IPC) scaling for every problem. It also shifts the burden from hardware design/manufacturing to software design, something that rarely pays off. They should go hand in hand. A dual core 1.7 GHz willamette would be a poor substitute (performance wise, desktop workloads) for a 3.4+ GHz P4.
>If you've ever worked on a big project, you'd also know
>that making everybody work twice as fast (or efficient) has
>its limits too. At one point, better soon, you have to
>double the number of employees.
Doubling the timetable is a much more efficient solution
>Currently processors are still one-man companies
Not really, they have multiple execution units, and its already hard to write code to use those efficiently.
> 2.4 GHz Xeons still have a nice price and come with
>Hyper-Threading. On optimized software it will run faster
>than a 4.0 GHz.
Precious few, if any apps would. You might get twice the throughput running two (or 4) instances of SETI client, but for anything more complex, or speed and not throughput oriented, it won't be better. Don't forget you are not doubling memory bandwith (in fact, in your example you would decrease it by 75%/ cpu !), you are not reducing memory or cache latency either. Opteron is an exception where memory bandwith would scale with the number of cpu's but only using NUMA aware OS+apps, and even then you are increasing latency.
>I was talking about the future, not the past. It's clear to
>me that single-core technology has reached a wall.Sure,
>they'll still have 4.0 GHz by 2005, but nothing really
>spectacular.
Spectacular like what ? Like going from 100 to 200 MHz in two years ? Or 1.5 to 3 Ghz in 2 years ? Or 3 to 4 Ghz in one year ?
If there is any wall we are hitting, its not potential single threaded performance increases, but a thermal wall, and guess what, a dual core chip will roughly consume twice as much as a single core chip.
Obviously, we will see multicore chips in the future, but for somewhat other reasons as what you imply: smaller processes finally give us cores small enough to economically produce several of them in one chip (<200mm²). That used to be impossible. just like HT, it will help especially running several programs or process simultaneously, but it won't speed up most things by more than 30%.
A very interesting quote and link in this context:
For over a decade prophets have voiced the contention that the organization of a single computer has reached its limits and that truly significant advances can be made only by interconnection of a multiplicity of computers in such a manner as to permit co-operative solution...The nature of this overhead (in parallelism) appears to be sequential so that it is unlikely to be amenable to parallel processing techniques.
This is a quote by Gene Amdahl from <b>1967</b>.
<A HREF="http://home.wlu.edu/~whaleyt/classes/parallel/topics/amdahl.html" target="_new">Amdahl's law </A>
= The views stated herein are my personal views, and not necessarily the views of my wife. =