Hennessy and Patterson

Ostensibly one of the most widely used books for studying computer architecture so I had a look, and... WTF? Possible future CPU designers are being fed with tripe like this?

http://i62.tinypic.com/xakqr.png

Despite all the focus on MIPS and performance, it is suspiciously missing any real benchmarks of MIPS processors.

They have an interesting definition of a "desktop computer":
http://i60.tinypic.com/4lq2j7.png

"Heineken and Pilsner" would be a better name for this book, as its authors appear to be as knowledgeable about real-world computer architecture as drunken fools.

Never trust 3rd party research. Always test everything yourself.

What book do you recommend then?

>>1
All of the information on real world microprocessors in H&P becomes outdated before it's put to press. This is especially obvious if you're reading an older edition. Fortunately, H&P is really just an introductory text so, outdated performance observations aside, there isn't a lot of room for demagoguery.

Hennessy does have a well known anti-Intel bias that shows up in most of his newer writings. It seems to me that he has never gotten over the fact that MIPS failed to take over the world, and now that he is no longer close to the industry the textbooks are one of the few outlets he has for his bile.

>>1

http://i62.tinypic.com/xakqr.png

The assertion that avoiding rep on the x86 is universally good for performance is obviously bogus.

However, this benchmark comparison is futile because the textbook doesn't care to mention which CPU was used for the test. Sure rep movs on a Nehalem will be pretty fast but the authors could have been using a 386 for all you know. Also the text implies that their load/store code was manually unrolled; the sample code that was used for benchmarking is not.

>>1
Cuuudderr! It's really you! I scanned the old /prog/ db five times to see if someone had copy pasted your post!

>>1
Shalom!

MIPS is mediocre at best and RISC is a futile design philosophy, but that has never stopped dusty academics from circlejerkoing before....

>>4
In some ways MIPS did "take over the world", mostly in unbranded Chinese devices like digital picture frames, tablets, and media players. Many routers and set-top-boxes too. Not because of performance, but because it's a cheap small core that just about any ASIC designer can put in an SoC after reading e.g. the P&H book. I would bet most of the MIPS-compatible cores out there are not actually licensed from MIPS...

>>5
On the 8086/8 and the rest of the cacheless x86 (up to the '386), REP MOVS is the fastest - all it has to do is a bus cycle to read it in, and then the cycles after that are all spent in reading/writing the data to be moved. Any other way would be slower since most of the bus bandwidth would be spent on instruction fetches.

For the 486 and Pentium I found this:

http://computer-programming-forum.com/46-asm/5157e945c6bac0ef.htm

Which shows that REP MOVS does get beaten by 38% by an unrolled loop on an Am486DX4-120 and 23% by going through the FPU on a P90 (could this be the "third version" H&P mention?), but on the 33MHz 486 it's still the fastest. No sign of that 200% difference though.

Sure rep movs on a Nehalem will be pretty fast but the authors could have been using a 386 for all you know.

Leaving aside the fact that REP MOVS was fastest on the 386, the only period in which there was significant gains from avoiding it would be in the 486 ~ Pentium era, so it would be absolutely insane to be talking about this - except perhaps as a historical point - in the fourth edition of a book released in 2012.

Or maybe they just benchmarked a ridiculously tiny copy - akin to seeing how long it takes to use a car to travel 5 meters and comparing it to walking.

I'm tempted to get out the old 386, 486, and PMMX and do some real testing with the same code I used for the above...

>>9
Shalom!

IS THAT REALLY YOU CUDDER-SAMA
OH HOW I MISSED YOU

SHAAAAALOOOOOOOOMMMMM Cudder-chan!!

>>12
so how's ADHD med working for you?

*fartz in joy*

Corporate whores. Keep insulting academia because you're too dumb for math higher than calculus. Nice intel propaganda here, how much they paid you? Don't worry, intel won't be able to keep up in the quantum world. Nanotechnology is not the future, quantum is.

>>9

Leaving aside the fact that REP MOVS was fastest on the 386

Which is a good point to make, actually.

the only period in which there was significant gains from avoiding it would be in the 486 ~ Pentium era, so it would be absolutely insane to be talking about this - except perhaps as a historical point - in the fourth edition of a book released in 2012.

The first edition of H&P was published in late 1990 so it's conceivable they did indeed run the test on a 486 originally and never bothered to revisit it (knowing, perhaps, that doing so would undermine their original argument).

>>1
Use a different picture hosting service next time, Cudder-san. Tinypic won't work if Javashit is disabled.

>>17

implying Cudder isn't an Intel-JS shill

Maybe H&P didn't completely make up everything, since I think I found the resluts they used, along with the code:

http://now.cs.berkeley.edu/Td/bcopy.html

Indeed, as I suspect, the 200% improvement is only achievable on specific combinations of P5 processors and chipsets, and completely disappeared with the P6; there's 2 486 results there too, in which REP MOVS has only a <10% loss over the others. This makes me really want to get those old machines out to see if I can reproduce these results...

Trying their code on my Nehalem, the huge 64x unrolled loop is within 1% of the non-unrolled loop (sometimes faster, sometimes slower - probably the same considering measurement noise), while going through the FPU is basically identical to using MMX (not surprisingly, they both move 8 bytes at a time.) In other words, nothing magic about their code.

Interestingly, using SSE2 non-temporal moves maintains the same speed regardless of size (not surprising since it bypasses the cache), and with huge sizes is the fastest by <10% again, but that's a bit like cheating in that the difference quickly vanishes if we need to access the data that was copied (very common situation) - the cache misses that were avoided during the copy just appear later.

>>17
It works just fine with curl.

>>19
Shalom!

>>19
haha, bcopy

>>18
That was a truly epic meme /b/ro!

>>19
I share the sentiment with >>17. Imgur is fine if you wan to keep the image forever.

These days I am using http://webmup.com/, 'cause "Webm is master race!"

>>19

Interestingly, using SSE2 non-temporal moves maintains the same speed regardless of size (not surprising since it bypasses the cache), and with huge sizes is the fastest by <10% again, but that's a bit like cheating in that the difference quickly vanishes if we need to access the data that was copied (very common situation) - the cache misses that were avoided during the copy just appear later.

To be fair it's also possible you'd not need to access the data that was just copied (I think framebuffers are the canonical example, but hardware with high bandwidth requirements and no DMA engine is sort of uncommon these days).

>>8
The success of x86 in personal computers was largely historical accident. I'm sure if RISC architectures had decades of mass-market commercial pressure to drive performance improvements, they'd be in the same position that x86 hardware is in now.

>>25

The success of white man was largely historical accident. I'm sure if niggers had decades of evolutionary pressure to drive performance improvements, they'd be in the same position that white man is in now.

>>26

The success of the G-d's Chosen People was largely historical accident. I'm sure if Gentiles were chosen by G-d to drive performance improvements, they'd be in the same position that the Jews are in now.

>>26-27
Making racist variants of my argument is not a counterargument, my friend(s).

>>28

You argument is phallacious. In other words your argument is a phallus.

>>29

My peepee is hard right now

>>24
15GB/s is good for nearly 600FPS of 24-bit 4096x2160 uncompressed video. Framebuffers don't need anywhere near that amount of bandwidth.

25

In that case the RISCs would've slowly evolved toward something with the complexity of x86 once they realised that the new bottleneck was memory bandwidth and not instruction decode/execute. Just look at all the instructions ARM have been adding, Thumb mode, etc.

Also got a chance to do this test on the Pentium MMX 200 (P54C), and it's different again from the P5s benchmarked above:

http://i58.tinypic.com/2jfjd3t.png

The MMX and FPU on this one is bloody fast at small sizes - we do see it beating REP MOVSD by ~2x - but using the registers, an unrolled loop using the registers (2x and 64x), and REP MOVSD are essentially identical in performance despite the unrolled loop being extremely cache-bloating. It looks like MOVSB/MOVSW haven't been optimised yet as they are definitely moving half and quarter as much data as MOVSD.

This is why CISC has so much potential. Complex instructions don't get slower, they get faster over time and give hardware designers more room to optimise with each new microarchitecture and make existing software faster. RISC is a dumb, overly simplistic, and ridiculously shortsighted design decision by people who don't understand the laws of physics.

I think all the claims of P&H have been thoroughly debunked now, unless anyone has a Sandy Bridge or newer and wants to test?

>>31
What do you think about the OpenRISC 1200? Are there any free (as in freedom) CPU designs out there that aren't shit (by your standards)?

Hey /prog/ people,
long time no see.
Is Cudder-san still alive?

>>31
Cudder-san, is this you?

>>31

This is why CISC has so much potential. Complex instructions don't get slower, they get faster over time and give hardware designers more room to optimise with each new microarchitecture and make existing software faster. RISC is a dumb, overly simplistic, and ridiculously shortsighted design decision by people who don't understand the laws of physics.

RISC benefits from the same hardware advances that CISC does. The x86 benefits more because it was further behind to start with. Historic RISC designs have been able to defer implementing features that the x86 had earlier but that's not really a strong argument for the x86 per se.

http://dis.4chan.org/read/prog/1374577564
http://en.wikipedia.org/w/index.php?title=Cannonlake&action=history
Look at the date Cudder posted that thread, and what the wiki page was renamed to. Coincidence?

>>35
So? Cudder is not the only semi company stiff who posts here.

>>32
OpenRISC is just another MIPS clone (complete with branch delay slot!) with some even more stupid design decisions like defaulting to big-endian and an Asm syntax where every single goddamn instruction has a mnemonic starting with "l" or "l.". WTF.

>>34
The difference is that it's much harder to, when the hardware makes it possible to implement more complex operations, recognise a series of simple instructions and recombine them into one op for the dedicated hardware unit than it is to split up a complex instruction into simpler uops when dedicated hardware units are not available. And the multiple simple instructions take more space in cache and memory bandwidth to fetch.

A good example of this is an integer division instruction. x86 has had one ever since the 8086, and while it was slow (it's still faster than a manual shift-subtract loop if you don't know the divisor), software could use it whenever it wanted to divide, and its performance was increased a huge amount throughout the years as newer models came out. Many RISCs started out without any divide instruction, because it didn't fit the definition of "simple" and hardware at the time couldn't do divides in 1 clock cycle. Software had to either call a divide function in a library or inline a shift-sub loop.

At some point they figured out how to make faster division hardware and added instructions for it, which means no gain in performance at all for software that inlined a division loop or statically linked in a library containing one, while those that could benefit from an updated library will still take the extra call/return overhead. Attempting to recognise the nearly infinite possibilities of instruction sequences to implement a divide loop and send that to the hardware divider would take far more complex circuitry than if they had a divide instruction that just internally expanded to the equivalent shift-sub loop on CPUs without fast divide hardware, and there's no way to recover the cost of fetching those instructions. (This is what the 8086's DIV did.) It took ARM seven revisions to add an integer divide, and it's still considered "optional". Maybe this is OK for small embedded cores but it's absolutely idiotic for something intended to do more computation and be general-purpose.

>>37
Shalom!

>>37
That's actually one of your best arguments for CISC yet.

>>37
What do you think about m68k?