Talk:Megahertz myth

Benchmarks

The real myth is this article -- GHz is the primary performance guide even with duo cores since the processors on large multiprocesser computers can only be managed well at a 2:1 ratio. So it takes a quad core to equal the processing speed of two individual computers. And you still might not see much performance boost as software is mostly written to perfom serially. One educator comparing his old single core to his new dual core running at the same rate said it seemed the same, only graphics ran faster. Agreed, certian processor details like processor cycles to complete key instructions have significant performance impact but lacking a table of those, the GHz rate is the only way to buy new computers. —Preceding unsigned comment added by 75.139.220.8 (talk) 11:05, 10 June 2008 (UTC)

Kirk Fraser —Preceding unsigned comment added by 75.139.220.8 (talk) 11:06, 10 June 2008 (UTC)

Really? All the benchmark reports and technical papers discussing large multiprocessor computers have roughly 65 to 80 percent performance improvements for every additional processor. Additionally, just becuase the software is badly designed or not optimised for multicore processors does not mean that multicore processors (or any processor exploiting other methods to achieve high performance) are bad and that GHz is the only factor in performance. Rilak (talk) 06:50, 11 June 2008 (UTC)

How about creating a table that states the number of processor cycles that is required to execute a processor insturction?

Yuhong Bao

Too many variables, just google for some system shootouts. Izzat source enough, or do you want me to dig about in my old mags from 1997? ...dave souza 17:11, 20 January 2006 (UTC)

AMD CPU numbers

It says, "AMD introducing model numbers giving a notional clock speed based on comparative performance to overcome a perceived deficiency in their actual clock speed." yet I have never seen anything official regarding to this. I think this too is a myth created by AMD fanboys, as the only reliable information about this notion that I have heard is that the numbers were created specifically for marketing purposes only and nothing to do with the actual performance of the AthlonXP. —Preceding unsigned comment added by 69.74.48.25 (talk) 18:47, 27 March 2008 (UTC)

Oh, another problem is that my understanding is that Intel actually did research that showed that a longer pipeline and higher clock speed was the way to go. As it wasn't a marketing ploy to get people to buy processors just because of the higher clock speed. —Preceding unsigned comment added by 69.74.48.25 (talk) 18:56, 27 March 2008 (UTC)

It always depends on what benchmarks you use, but in most benchmarks I have seen, the Athlon XP 2000+ actually outperformed the Pentium 4 with 2 GHz. Yes, high clockrates and long pipelinses were the way to go for Intelk at the time they intruduced the Netburst-architechture and I am sure they did some research before they made this decision, but not because of real performance, but because of marketing. Marketing research is also a kind of research. --MrBurns (talk) 20:01, 6 June 2010 (UTC)

POV

Although the article is fairly well written, there does seem to be a slight amount of bias for the PowerPC processors. Perhaps someone could reword it to remove the bias while still maintaining the factuality? Paul Cyr 18:34, 24 January 2006 (UTC)

Exactly! This is written by an old-school Apple Apologist. 73.170.79.95 (talk) 13:37, 7 July 2015 (UTC)

Further detailed factuality added to achieve NPOV. Note that the points made are taken from the linked articles, and the "megahertz myth" keynote can be viewed as a 17.1 Mb movie download from the linked source. ...dave souza 00:47, 26 January 2006 (UTC)

Hi 73.170.79.95, nice to hear you're an old-school Apple Apologist. Really rather of historical interest and of course the processors were by IBM, but the point about comparing different chips by clock speed is timeless. . . dave souza, talk 17:08, 7 July 2015 (UTC)

Cleanup

The section of the history of the myth is far too cluttered. I think the main problem with it is that it gives a blow by blow account of the usage of the term, when it should simply say how the myth started. (comment by Paul Cyr)

Point noted, in my opinion the background is important to understanding the myth, but I'll look at tidying up this section. ....dave souza 19:57, 26 January 2006 (UTC)

title

Why is this article "Hertz myth"? Typing that into google yields "megahertz myth" more often then "Hertz myth". Even "gigahertz myth" is more common.

Because it is not a proper title. Paul Cyr 05:09, 22 April 2006 (UTC)

What is improper about it? It is a marketing term, not a technical one, so the usual metric rules don't apply. ("Gigahertz myth" is identical to "Megahertz myth", not 1000 times worse.) Algr 05:19, 22 April 2006 (UTC)

I do understand what you are saying, and although you are right about it being marketing term, the myth is about hertz in general, megahertz is too specific. In addition to what you said, now that CPUs are in the GHz range, who's to say it shouldn't be changed to Gigahertz Myth? What about when we reach terahertz? The title shouldn't matter based on the current clock speeds. Paul Cyr 07:10, 22 April 2006 (UTC)

-Well, it's like putting Marilyn Monroe's stuff under "Norma Jean". The latter is her real name, but Marilyn/Megahertz is what it says in the movies that everyone remembers.

-Also, no CPU chip was ever measured in just Hertz, they started in the Kilohertz range.

-There is no longer any company that benefits from this myth, so we likely won't hear much more about it.

-Finally, only a few articles ever updated it to gigahertz myth, and they usually mentioned that they did it. The fact that some people did reflexively change it to Gigahertz myth indicates that the public understands that things that apply to Mega automatically apply to Giga too. But if you mention "Hertz myth" out of context, people probably won't recognize it, because they remember "megahertz myth". Algr 14:45, 22 April 2006 (UTC)

I conceed :P Paul Cyr 21:55, 22 April 2006 (UTC)

It seems a fair point that this may be the only place it's called the "Hertz Myth", and unless a citation can be found supporting that naming it would be better to move this page back to "megahertz myth" after proper discussion. If there are any objections the procedure at Wikipedia:Requested moves should be followed...dave souza, talk 15:56, 22 April 2006 (UTC)

Proposed "Irony" Section

To counter the PowerPC bias, perhaps a section or statement should be added regarding apple's change to using Intel processors in place of the PowerPC. 69.68.125.6 (talk) 05:25, 27 November 2007 (UTC)

It's already there: Megahertz myth#The myth becomes counterproductive. .. dave souza, talk 11:52, 27 November 2007 (UTC)

Not any more. The entire section "The myth becomes counterproductive" was deleted in a "removed unreferenced material" edit ([1]). Is there anything that should be restored? --DavidCary (talk) 17:38, 15 June 2013 (UTC)

Performance measurement

It is so lame to have an article like this with no references to actual ways of measuring performance. -69.87.204.26 (talk) 01:06, 4 April 2008 (UTC)

 Fixed. The first paragraph now links to benchmark and computer performance, which in turn link to notable ways of measuring performance. --DavidCary (talk) 17:38, 15 June 2013 (UTC)

Removed a dead link

I removed a dead link to a page at jmusheneaux dot com. It wasn't available on the Internet Archive, and the description wasn't clear what it was. Ken (talk) 03:24, 12 May 2008 (UTC)

About the accuracy of the comparison between the 6502 and 8088

It is stated that a 8088 needs 25 cycles to load the accumulator with an immediate value. I am not sure if this is correct. Looking at datasheets and instruction set lists I'd say a 8088 normally needs 4 cycles to fetch and decode a mov reg8/16, nn instruction, after which either 4 or 8 extra cycles are needed to get the byte or word from memory. This is of course a best case scenario, but even with additional wait states, it should be way below the 25 cycles described in the article. Since the accumulator of the 6502 is 8 bits wide, one should load the 8088 with an 8 bit value as well. In the end, the 6502 is still much faster clock for clock, but not as dramatically as described. At least, that is what I think. Perhaps I overlooked something?

sources: http://www.ousob.com/ng/asm/ng11587.php http://zsmith.co/intel_m.html#mov http://datasheets.chipdb.org/Intel/x86/808x/datashts/8088/231456-006.pdf

GB80CPU (talk) 22:58, 26 June 2013 (UTC)

I just did something about this, but for a different reason (and before visiting this talk page). As I found it today, the article cited 4 clock cycles as the time to execute "LDA #" on the 8088; "LDA #" is a 6502 instruction which does an 8-bit immediate load of the accumulator, so it is most similar to "MOV AL,#" on the 8088, which does an immediate load of the low-order 8 bits of the 16-bit accumulator (called AX) of the 8088. Intel's published instruction timing for that instruction is 4 clock cycles, but there are major, major caveats to those timings. I described these briefly in a "<ref>" comment inserted into the text. The Intel-published instruction timings for the 8086 and 8088 are the timings under the assumption that all bytes of every instruction are loaded into the prefetch queue by the Bus Interface Unit (BIU) before they are needed by the Execution Unit (EU). The BIU in the 8088 has a 4-byte prefetch queue. Since it takes 4 clock cycles to read or write a byte, the only time the BIU can load more bytes into the prefetch queue than the EU takes out in the same time is when the EU takes more than 4 clocks per instruction byte to execute an instruction. The only 8088 instructions that meet this criterion are instructions that access operands in memory (including the stack) or through I/O ports, multiplications, divisions, variable shifts and rotates (e.g. "SHL SI,CL" or "ROR DX,CL"), and control transfers (jumps, calls, s/w interrupts, etc.). (However, any control transfer causes the prefetch queue to be cleared.) The consequence for the 8088 is that in typical programs that are not memory-data-intensive, for most instructions, the number of clock cycles taken to execute each instruction is four times the number of bytes in the instruction. I.e., the instruction will not be in the prefetch queue, so its execution time will be determined by the time taken to fetch it (by the BIU), while the EU is idle for some of that time.

On the 8086, the case assumed for Intel's instruction timings occurred frequently but not persistently. On the 8088, it occurs infrequently, but it is not impossible: a long-executing instruction preceding the "MOV AL,#" instruction may allow the BIU time to fetch both bytes of that instruction (and maybe one or two other bytes) into the prefetch queue, and then the EU can fetch the two bytes from the queue and execute the instruction in only 4 clock cycles. During those 4 clock cycles, the next instruction byte will be fetched into the queue, so that next instruction can begin to execute with no delay. However, it is much more common that only the first byte of the "MOV AL,#" instruction is fetched before the EU starts to execute it, so that 2 more bytes must be fetched before the instruction can complete and the next one begin executing, making the "MOV AL,#" take 8 clock cycles to execute. That is the worst case, and execution in 4 clocks is the best case. There are also possible intermediate cases, since the EU and BIU are loosely coupled. The worst case is by far the most statistically frequent in typical programs.

It might seem like the 8088 is a bad CPU design, and I can't say it's good, but it's not as bad a reflection on the Intel engineers as it appears to be in hindsight from the 2010s (or even the 1990s). The 8088 is a modification of the earlier Intel 8086, which has a 16-bit data bus and so can prefetch two bytes in 4 clock cycles. The 8086 also has a 6-byte prefetch queue. Whereas the prefetch queue in the 8088 is usually empty, the one in the 8086 is usually not empty, and so the 8086 can execute most instructions from the queue and therefore complete their execution within the published clock cycle counts. (Also, Intel admitted that an 8086 will typically take about 10% more clock cycles than the sum of the published instruction timings to execute a given program, and that is not an outright unreasonable estimate [as it is for the 8088].) The goal of the 8088 design was to promptly produce an 8-bit data-bus version of the 8086, sacrificing speed for low system cost, as an 8-bit data bus would make the CPU compatibile with the many available 8-bit peripheral chips and would allow the CPU to be used with smaller, simpler printed circuit boards. (The 8088 successfully met that goal.)

On balance, because of these complicated details, the final conclusion may be that a comparison of short, primitive instructions on the 6502 and 8088 is not a good example to use. However, this microarchitectural difference between the 6502 and the 8088 (or 8086) is an excellent example of the principle by which the megahertz myth is indeed a myth: fundamental differences in what each processor does in a clock cycle make clock cycles not comparable as equivalent units of computational work, across microarchitectures. Since a clock cycle does not represent a constant unit of computing work, the rate of clock cycles, alias the clock frequency, is not a proportionate measure of the speed of computation.

(Any Wikipedian should feel free to use any excerpt from this posting as material for the article itself.)

173.49.107.56 (talk) 10:08, 8 April 2018 (UTC)

Software Red Herring

The article currently over-belabors how poorly designed multithreaded software or single-threaded software can never take full advantage of multicore CPUs so it is not reasonable to say a CPUs speed is somehow proportional to the clock speed time the number of cores. Well, all things being equal, that's EXACTLY what the relative speed of two otherwise similar CPUs actually is. If one has amazingly designed multithreaded software and it's run on a single or dual core CPU it's not going to magically start running faster and vice versa. The inherent capability of the CPU is what is at issue in discussions of the "megahertz myth", not what lipstick covered pig piece of software someone might decide to run (or code) on it. I don't really want to rewrite that section, but I wanted to point that out. 198.81.129.186 (talk) 20:59, 29 December 2015 (UTC)mjd

Modern adaptations of the myth

This entire section needs to be removed, or completely rewritten. Almost all of the concepts conveyed in the section are completely wrong. This is not how multithreading works whatsoever. One thread runs on one core, no amount of instruction scheduling will change that.— Preceding unsigned comment added by 66.69.224.221 (talk) 11:35, 4 January 2016 (UTC)