If you ever connected to the Internet before the 2000s, you probably remember that it made a peculiar sound. But despite becoming so familiar, it remained a mystery for most of us. What do these sounds mean?

For one thing, chips have wider registers and can address more memory. In the 80s, you might have used an 8-bit CPU, but now you almost certainly have a 64-bit CPU in your machine. I’m not going to talk about this too much, since I assume you’re familiar with programming a 64-bit machine. In addition to providing more address space, 64-bit mode provides more registers and more consistent floating point results (via the avoidance of pseudo-randomly getting 80-bit precision for 32 and 64 bit operations via x867 floating point). Other things that you’re very likely to be using that were introduced to x86 since the early 80s include paging / virtual memory and floating point.

Hard disks: if you read this, it's pretty much certain you use one or more of the things. They're pretty simple: they basically present a bunch of 512-byte sectors, numbered by an increasing address, also known as the LBA or Logical Block Address. The PC the HD is connected to can read or write data to and from these sectors. Usually, a file system is used that abstracts all those sectors to files and folders.

If you look at an HD from that naive standpoint, you would think the hardware should be pretty simple: all you need is something that connects to a SATA-port which can then position the read/write-head and read or write data from or to the platters. But maybe more is involved: don't hard disks also handle bad block management and SMART attributes, and don't they usually have some cache they must somehow manage?

All that implies there's some intelligence in an hard disk, and intelligence usually implies hackability.

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns on recent CPU
L2 cache reference ........................... 7 ns 14x L1 cache
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs 4X memory
Round trip within same datacenter ...... 500,000 ns = 0.5 ms 20x datacenter roundtrip
Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms 80x memory, 20X SSD
Disk seek ........................... 10,000,000 ns = 10 ms
Read 1 MB sequentially from disk .... 20,000,000 ns = 20 ms
Send packet CA->Netherlands->CA .... 150,000,000 ns = 150 ms
LTO4 tape seek/access time ...... 55.000.000.000 ns = 55 s

The development of caches and caching is one of the most significant events in the history of computing. Virtually every modern CPU core from ultra-low power chips like the ARM Cortex-A5 to the highest-end Intel Core i7 use caches. Even higher-end microcontrollers often have small caches or offer them as options — the performance benefits are too significant to ignore, even in ultra low-power designs.

If you've never had problems keeping your clock synced, you just haven't run enough machines yet. Once you start scaling beyond a certain point, it will become obvious that even elementary timekeeping is no small feat, even with help from tools like ntpd.

In pipelined processors, instruction are fetched, decoded, and executed speculatively, and are not permitted to modify system state until instruction commit. For instructions that modify registers, this is often achieved using register renaming. For stores to memory, speculative stores write into a store queue at execution time and only write into cache after the store instructions have committed.

arduino stuff