The main reason the 486 is considered fast relative to the 386 is that it executes twice as many instructions in the same number of cycles. The same thing is true for a Pentium; it executes about twice as many instructions in a given number of cycles as a 486. Therefore, given the same clock speed, a Pentium is twice as fast as a 486, and consequently a 133 MHz 486 class processor (such as the AMD 5x86-133) is not even as fast as a 75 MHz Pentium! That is because Pentium megahertz are “worth” about double what 486 megahertz are worth in terms of instructions completed per cycle. The Pentium II and III are about 50% faster than an equivalent Pentium at a given clock speed because they can execute about that many more instructions in the same number of cycles.
Unfortunately, after the Pentium III, it becomes much more difficult to compare processors on clock speed alone. This is because the different internal architectures make some processors more efficient than others, but these same efficiency differences result in circuitry that is capable of running at different maximum speeds. The less efficient the circuit, the higher the clock speed it can attain, and vice versa. Another difference is that some of the later processors include varying sizes of L2 and L3 cache.
One of the biggest factors in efficiency is the number of stages in the processor’s internal pipeline:
| Processor | Pipeline Depth |
|---|---|
| Pentium III | 10-stage |
| Pentium M/Core | 10-stage |
| Athlon/XP | 10-stage |
| Athlon 64/Phenom/II/FX | 12-stage |
| Core 2/i3/i5/i7 | 14-stage |
| Pentium 4 | 20-stage |
| Pentium 4 Prescott | 31-stage |
| Pentium D | 31-stage |
A deeper pipeline effectively breaks down instructions into smaller microsteps, which allows overall higher clock rates to be achieved using the same silicon technology. However, this also means that overall fewer instructions can be executed in a single cycle as compared to processors with shorter pipelines. This is because, if a branch prediction or speculative execution step fails (which happens fairly frequently inside the processor as it attempts to line up instructions in advance), the entire pipeline has to be flushed and refilled. Thus, if you compared an Intel Core i7 or AMD FX to a Pentium 4 running at the same clock speed, the Core i7 and FX would execute more instructions in the same number of cycles.
Although it is a disadvantage to have a deeper pipeline in terms of instruction efficiency, processors with deeper pipelines can run at higher clock rates on a given manufacturing technology. Thus, even though a deeper pipeline might be less efficient, the higher resulting clock speeds can make up for it. The deeper 20- or 31-stage pipeline in the P4 architecture enabled significantly higher clock speeds to be achieved using the same silicon die process as other chips. As an example, the 0.13-micron process Pentium 4 ran up to 3.4 GHz, whereas the Athlon XP topped out at 2.2 GHz (3200+ model) in the same introduction timeframe. Even though the Pentium 4 executes fewer instructions in each cycle, the overall higher cycling speeds made up for the loss of efficiency; the higher clock speed versus the more efficient processing effectively cancelled each other out.
Unfortunately, the deep pipeline combined with high clock rates did come with a penalty in power consumption, and therefore heat generation as well. Eventually, it was determined that the power penalty was too great, causing Intel to drop back to a more efficient design in its newer Core microarchitecture processors. Rather than solely increase clock rates, performance was increased by combining multiple processors into a single chip, thus improving the effective instruction efficiency even further. This began the push toward multicore processors.
One thing is clear in all of this confusion: Raw clock speed is not a good way to compare chips, unless they are from the same manufacturer, model, and family.
To fairly compare various CPUs at different clock speeds, Intel originally devised a specific series of benchmarks called the Intel Comparative Microprocessor Performance (iCOMP) index. The iCOMP index benchmark was released in original iCOMP, iCOMP 2.0, and iCOMP 3.0 versions.
The iCOMP 2.0 index was derived from several independent benchmarks as an indication of relative processor performance. The benchmarks balance integer with floating-point and multimedia performance.
- Processor Specifications Explained
- Data I/O Bus, Address Bus, And Internal Registers
- Processor Modes: Real Mode
- IA-32 Mode: 32-Bit And Virtual Real
- IA-32e 64-Bit Extension Mode (x64, AMD64, x86-64, EM64T)
- Processor Benchmarks And Comparing Performance
- Processor Efficiency
- Cache Memory
- How Cache Works
- Level 2 And Level 3 Cache
- Cache Performance And Design
- Cache Organization
Shouldn't that be "Foreword?"
Should be 10^2, 10^3, and in the next para, 2^x.
This was very interesting, considering both instructions were supported even by the humble 8086.
These sections seem more or less unchanged, except for the mention of Ivy and Vishera, and i think the CPU-z screenshots are new as well.
This was very interesting, considering both instructions were supported even by the humble 8086.
https://en.wikipedia.org/wiki/X86-64#Older_implementations
Yet at the very least the 80386 supported them:
http://css.csail.mit.edu/6.858/2011/readings/i386/LAHF.htm
So it appears that it was an early-64 bit CPU issue only.
The Prescott introduced 64-bit to the Intel world, not the Core 2. Kind of common knowledge. The Athlon XP had a 36-bit address bus? I don't remember ever seeing that.
Then we go to the misinformation about the 8086/8088 to 386.
In actuality, there were four modes in the 80386. Real, Virtual 86, Protected 286, and Protected 386. Yup, four. And no, Windows 3.0 was not expected to run on an 8088 or 80286, because it DID use Virtual 86, which those processors could not support. You know, the part where they let you go from one DOS task to another. That was in the hardware. And that hardware started with the 80386.
Moreover, the 80286 did NOT have the same instruction set as the 8086. Only in real mode did it. And why do you suppose it was called real mode? Maybe because the addresses were not virtualized? The 80286, as mentioned above, did have virtual addresses in what was called the 80286 Protected Mode. It not only ran Real Mode apps much faster, but when in Protected Mode was very capable of running multitasking Operating Systems, something that could not be done well on the 8086. It also increased the memory bus to 24-bits, albeit still using 64K bit segments.
OS/2 1.x was the best example of an OS using 286 Protected mode, although any software using "Extended Memory" was taking advantage of the greater addressing of the 286, albeit in an inelegant way.
I stopped reading after page three, as it's just discouraging to think people are writing books without being accurate. OK, so we have the author that got it wrong, fair enough, but what about the people who are supposed to error check it. I certainly don't know everything, and I know this stuff, and it's pretty basic. No one caught this? Are you kidding me? The 286 stuff might be a bit far away, but not knowing that x86-64 first appeared in the Prescott line is really difficult to understand, and is very basic. This is made more so because of all the rumors that the processor was made to support it, but Intel was hiding it so as to not undercut the Itanium. In time, it was proven true.
Please, don't spread misinformation. Someone will repeat this stuff, and then someone else will, and it becomes 'fact' despite being wrong. If you publish a book, make a friggin effort! I'm sure I could errors the rest of the way, but it's just too annoying for me to wade through this rubbish.
By the way, the term CPU bus is an ambiguous one. The CPU has multiple buses, and if you used that term with me, I'd wonder which one you were referring to. Find a more accurate term, like PCI-E bus if that's what you are trying to say.
The Prescott introduced 64-bit to the Intel world, not the Core 2. Kind of common knowledge. The Athlon XP had a 36-bit address bus? I don't remember ever seeing that.
Then we go to the misinformation about the 8086/8088 to 386.
In actuality, there were four modes in the 80386. Real, Virtual 86, Protected 286, and Protected 386. Yup, four. And no, Windows 3.0 was not expected to run on an 8088 or 80286, because it DID use Virtual 86, which those processors could not support. You know, the part where they let you go from one DOS task to another. That was in the hardware. And that hardware started with the 80386.
Moreover, the 80286 did NOT have the same instruction set as the 8086. Only in real mode did it. And why do you suppose it was called real mode? Maybe because the addresses were not virtualized? The 80286, as mentioned above, did have virtual addresses in what was called the 80286 Protected Mode. It not only ran Real Mode apps much faster, but when in Protected Mode was very capable of running multitasking Operating Systems, something that could not be done well on the 8086. It also increased the memory bus to 24-bits, albeit still using 64K bit segments.
OS/2 1.x was the best example of an OS using 286 Protected mode, although any software using "Extended Memory" was taking advantage of the greater addressing of the 286, albeit in an inelegant way.
I stopped reading after page three, as it's just discouraging to think people are writing books without being accurate. OK, so we have the author that got it wrong, fair enough, but what about the people who are supposed to error check it. I certainly don't know everything, and I know this stuff, and it's pretty basic. No one caught this? Are you kidding me? The 286 stuff might be a bit far away, but not knowing that x86-64 first appeared in the Prescott line is really difficult to understand, and is very basic. This is made more so because of all the rumors that the processor was made to support it, but Intel was hiding it so as to not undercut the Itanium. In time, it was proven true.
Please, don't spread misinformation. Someone will repeat this stuff, and then someone else will, and it becomes 'fact' despite being wrong. If you publish a book, make a friggin effort! I'm sure I could errors the rest of the way, but it's just too annoying for me to wade through this rubbish.
By the way, the term CPU bus is an ambiguous one. The CPU has multiple buses, and if you used that term with me, I'd wonder which one you were referring to. Find a more accurate term, like PCI-E bus if that's what you are trying to say.