Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Registers Are Fast and RAM Is Slow

mikeash.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Why Registers Are Fast and RAM Is Slow

#71

Post by brigade »

joosters wrote: post #69
vilda wrote: post #67

Earlier quoted context omitted.

Note that the actual number of registers is considerably different than the number of registers you can access through instruction set. They are used via register renaming and optimizations of complex instructions.

Yes. As other commentors have said, if you are doing out-of-order execution well, the CPU will have many more 'hidden' registers and do register renaming to use them. But this has an interesting interaction with compilers. Say you have a simple function that is going to add 1 to a bunch of variables. In an ARM-like assembly code, this could be written as: LDR r1, [r0, #0] ADD r1, r1, #1 STR r1, [r0, #0] LDR r1, [r0,…

You still need OoOe to execute your second example optimally since you didn't schedule the instructions, which points to why OoOe isn't going away - there are going to be code sequences that the compiler cannot schedule optimally, particularly around branches. Additionally, cache misses are impossible to predict statically, and OoOe helps hide those.

And no one does OoOe without register renaming.

Re: Why Registers Are Fast and RAM Is Slow

#72

Post by solarexplorer »

yan wrote: post #8

For a way more detailed look at memory architectures and implementation, check out Ulrich Drepper's classic paper "What Every Programmer Should Know About Memory"[1] [1] http://www.akkadia.org/drepper/cpumemory.pdf

If you want to buy good book on the topic: "Memory Systems: Cache, DRAM, Disk" by Bruce Jacob, Spencer Ng, David Wang

Re: Why Registers Are Fast and RAM Is Slow

#73

Post by mikeash »

georgecmu wrote: post #22
jff wrote: post #16

Earlier quoted context omitted.

He clearly describes SRAM in the following paragraph, then contrasts it with DRAM in the rest: Registers use an expensive and power-hungry active design. They're continuously powered, and when reading them, this means that their value can be read quickly. Reading a register bit is a matter of activating the right transistor and then waiting a short time for the powerful register hardware to push the read line to the…

Yeah, I did not even recognize this as description of SRAM, thanks for pointing this out. from http://www.differencebetween.net/technology/difference-betwe... Because of its lower price, DRAM has become the mainstream in computer main memory despite being slower and more power hungry compared to SRAM. SRAM memory is still used in a lot of devices where speed is more crucial than capacity. The most prominent use of SR…

I appreciate the discussion around this. I'm not too knowledgeable about hardware, and wasn't sure about this part in particular. I did pass it by a friend who did hardware professionally for a long time, and he ultimately agreed with my assessment. However, I think you've convinced me that I was wrong, and that it's purely about cost, not power consumption. I'll have to see about editing the article accordingly.

Re: Why Registers Are Fast and RAM Is Slow

#74

Post by joosters »

brigade wrote: post #71
joosters wrote: post #69

Earlier quoted context omitted.

Yes. As other commentors have said, if you are doing out-of-order execution well, the CPU will have many more 'hidden' registers and do register renaming to use them. But this has an interesting interaction with compilers. Say you have a simple function that is going to add 1 to a bunch of variables. In an ARM-like assembly code, this could be written as: LDR r1, [r0, #0] ADD r1, r1, #1 STR r1, [r0, #0] LDR r1, [r0,…

You still need OoOe to execute your second example optimally since you didn't schedule the instructions, which points to why OoOe isn't going away - there are going to be code sequences that the compiler cannot schedule optimally, particularly around branches. Additionally, cache misses are impossible to predict statically, and OoOe helps hide those. And no one does OoOe without register renaming.

Yeah, I avoided any other changes to avoid confusing the issue. But any reordering I could have done, the compiler could have done too. Your point about branches is fair though, as the 'active' renamed registers after a branch can only be known at runtime.

Still, I wonder whether some of the features of modern CPUs could be dropped if it wasn't for legacy code. On the other hand, Itanium tried to push the parallelism work onto the compiler and look where that ended up!

Re: Why Registers Are Fast and RAM Is Slow

#75

Post by derleth »

demallien wrote: post #56
yan wrote: post #8

For a way more detailed look at memory architectures and implementation, check out Ulrich Drepper's classic paper "What Every Programmer Should Know About Memory"[1] [1] http://www.akkadia.org/drepper/cpumemory.pdf

Or on a more light-hearted note: http://folklore.org/StoryView.py?project=Macintosh&story=Sou... Which just goes to show, hitting memory is a Bad Thing(tm) even when you're running on a slow(from today's perspective) processor like a 68000.

It wasn't always thus: On the 6502, which the early Apple II machines were built around, it was possible to access RAM at only a one- or two-cycle penalty compared to doing everything in registers and immediate values. This was only the case if you used zero-page memory without indexing, however, so you couldn't have a lot of stuff in RAM without incurring more speed penalties.

http://www.6502.org/tutorials/6502opcodes.html

(Zero-page memory on the 6502 was the memory accessed via addresses with a high byte of 0x00. Since 6502 had sixteen-bit RAM addressing, this meant each page was 256 bytes large, so the zero-page was almost as good as having 256 single-byte registers.)

Re: Why Registers Are Fast and RAM Is Slow

#76

Post by rlu »

It's funny reading this and then remembering that on top of all this, there's paging (i.e. fetching from hard drive).

It's like registers are refrigerators, RAM is like the grocery store around the corner, and Page faults are like the grocery stores in a neighboring town

woooooo memory!

Re: Why Registers Are Fast and RAM Is Slow

#77

Post by NormaHHopson »

raverbashing wrote: post #62
demallien wrote: post #56

Earlier quoted context omitted.

Or on a more light-hearted note: http://folklore.org/StoryView.py?project=Macintosh&story=Sou... Which just goes to show, hitting memory is a Bad Thing(tm) even when you're running on a slow(from today's perspective) processor like a 68000.

Very impressive Doing 22kHz generation on a Macintosh is very close to the limit

my friend's step-sister makes $84/hr on the computer. She has been laid off for nine months but last month her check was $21144 just working on the computer for a few hours. Continue Reading ===================================================http://www.Works23.Com

Re: Why Registers Are Fast and RAM Is Slow

#78

Post by bane »

So what's the state of research in breaking out of the Von Neumann approach and going with a RAM-free architecture where the CPU has m(b)illions of registers you just do everything in? Of course it's expensive, but let's say you have effectively infinite dollars, is this a good idea?

Re: Why Registers Are Fast and RAM Is Slow

#79

Post by grogenaut »

Jebus christ, it's because they're close. Like IN the cpu. Not nuzzled not ON, not NEXT TO.

Hell, if you know and optimize for registers and don't know why they're fast, you should be shot. Otherwise you're using a language that doesn't really give you control over registers why do you care?

Okay okay, I like reading about the blackbird and I know that I know nothing about how it really works other than lots of fuel. Still. Okay, I'm a Hypokrite.

Re: Why Registers Are Fast and RAM Is Slow

#80

Post by grogenaut »

bane wrote: post #78

So what's the state of research in breaking out of the Von Neumann approach and going with a RAM-free architecture where the CPU has m(b)illions of registers you just do everything in? Of course it's expensive, but let's say you have effectively infinite dollars, is this a good idea?

No
Post reply on HN