I love this Scale of the Universe graphic. It allows you to compare the sizes of objects in the universe from atoms to galaxies. I got to thinking about how different professions work with objects at different scales and how these professions use very different tools. A particle physicist’s tool is a particle accelerator, a chemist’s tools are beakers and burners, a wood cutter’s tool is an axe, a pilot’s tool is an airplane, a astrophysicist’s tool is a telescope.

In software we do not deal with physical objects in space. Length is not a good metric for discussing programming - rather time is the key measurement. Latency is one of the most descriptive ways of classifying systems. As with length, software latencies must be compared on a logarithmic scale. They vary by orders of magnitude from nanoseconds (10^-9, one billionth of a second) to hours (10⁵, hundreds of thousands of seconds).

A nanosecond is one clock cycle on a 1 Ghz processor. An L1 cache hit in the can be done in just 3 clock cycles, L2 in 14. DRAM is about 500 nanoseconds away. Node can respond to a HTTP request in less than a millisecond. A disk read can take several milliseconds (or worse!). Round trip ping time from coast-to-coast in the United States is 60 milliseconds. A movie download can take hours. Rendering can take days.

The “software stack” is implementations of programming platforms at different order of magnitude in latency. At the nanosecond layer we’ve chosen (largely) the x86_64 CPU instruction set. At the microsecond layer we’ve chosen (largely) Linux and C. At the millisecond layer we have several choices of dynamic programming languages.

For different goals you choose different software. If you want to make a web server quickly, Node.js on your laptop is a good choice (Darwin, X86_64). For running Node in production switching out the microsecond layer for SmartOS would be an astute choice. If however, you are building an app for Android your stack would be ARM, Linux, and Java.

Software engineers are spread through these ranges of latency. They often have a spread of latencies at which they deal with - which basically corresponds to which platforms they have access to. A web developer often will never step beyond dynamic languages - milliseconds. Building Node (a web developer’s platform) I never was forced to think in terms of a specific CPU architecture but implementing some parts in C were necessary to interface with the operating system. Kernel engineers must touch sensitive code that requires knowledge what is happening on the CPU, bus, and peripherals.

By reaching into the software stack one achieves more and more control of the system. From the browser, to POSIX, to device drivers.

People at the different layers often do not understand each other. From the slower looking at the faster - they appear to be twiggy bit twiddlers prematurely optimizing everything. From the faster to the slower - they look like lazy lumbering sloths willing to sacrifice unthinkable amounts of time for ease of programming experience.