Remix.run Logo
The Hardware Knowledge That Every Programmer Should Know(needoneapp.medium.com)
22 points by ksec 2 days ago | 8 comments
signa11 2 days ago | parent | next [-]

wowzaaa

``` Note: I’ve followed the rules you provided for translation. Let me know if there’s anything else I can help with! Here is the translation of the Markdown content from Simplified Chinese to English: ```

aa-jv 2 days ago | parent [-]

I'm conflicted on this. On the one hand, its great to read more Chinese-originated articles. On the other hand, we're in the valley now folks, and there's not much hope of escaping.

joz1-k a day ago | parent | prev | next [-]

Nice article, but it was probably heavily machine-translated with little human intervention. There is a message that says "Code Language: JavaScript" all over the place, but the code examples are actually in Rust, and the last (unnecessary) one is in C++.

HSO a day ago | parent | prev | next [-]

To me, there is nothing that can beat CSAPP on this topic.

[1] R. E. Bryant and D. R. O’Hallaron. Computer Systems: A Programmer’s Perspective. Prentice Hall, 3rd edition, 2015.

It´s a shame that the last edition is from ten years ago, although to be fair I actually only read the 2nd and only skimmed the 3rd one. Still, would be nice to get an update using ARM.

Panzerschrek a day ago | parent | prev | next [-]

This is for me a basic knowledge for writing really-performant code. But I am surprised, that out-of-order execution isn't mentioned. And this approach is a big deal in modern CPUs.

foreigner 2 days ago | parent | prev [-]

Also important to know that if you're accessing disk, database, or network those are so slow that this stuff probably doesn't matter.

generichuman 2 days ago | parent | next [-]

Keep in mind there _may_ be a negative feedback loop there.

If you're building your software in a way that won't be able to perform better with superior disk/db/network performance, then it isn't worthwhile to ever upgrade to a more performant disk/db/network.

If it is possible, make sure your software will actually be faster on a faster disk rather than just testing on a slow disk and thinking "well we're I/O bound anyway, so no need to improve perf".

Panzerschrek a day ago | parent | prev [-]

This is a common fallacy. Yes, accessing disk or network is slow, but you still can perform CPU work while waiting on I/O and it may be beneficial to perform CPU work fast, in order to be able for example to serve a lot of network connections.