Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Cites distance and cost/power as reasons why "RAM is slow, registers are fast", not a mention of differences between SRAM and (S)DRAM.

Not worth reading.



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 appropriate state.


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 SRAM is in the cache memory of processors where speed is very essential, and the low power consumption translates to less heat that needs to be dissipated.

In any case, SRAM can be more power hungry that DRAM (per bit) but it can also be vastly less. SRAM power consumption is not at all driven by the fact that registers are "continuously powered". Accessing SRAM is the power hungry operation, but powering requirements otherwise are negligible. If anything, it's the DRAM that requires constant powering (refreshing).


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.


Agreed. Completely misses on-die caches for instance. Article might have been accurate in the 6502 days, but not today.


> Agreed. Completely misses on-die caches for instance.

Absolutely, except for the part where he mentions them

> If you're really lucky and the value is in L1 cache, it'll only take a few cycles.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: