This is a general principle of software/hardware design that Ciro feels holds wide applicability.

The most extreme case of this is of course the integrated circuit itself, in which it is essentially impossible (?) to observe the specific value of some indidual wire at some point.

Somewhat on the other extreme, we have high level programming languages running on top of an operating system: at this point, you can just GDB step debug your program, print the value of any variable/memory location, and fully understand anything that you want. Provided that you manage to easily reach that point of interest.

And for anything in between we have various intermediate levels of complication. The most notable perhaps being developing the operating system itself. At this level, you can't so easily step debug (although techniques do exist). For early boot or bootloaders for example, you might want to use JTAG for example on real hardware.

In parallel to this, there is also another very important pair of closely linked tradeoffs:

Emulation also has another potential downside: unless you are very careful at implementing things correctly, your model might not be representative of the real thing. Also, there may be important tradeoffs between how much the model looks like the real thing, and how fast it runs. For example, QEMU's use of binary translation allows it to run orders of magnitude faster than gem5. However, you are unable to make any predictions about system performance with QEMU, since you are not modelling key elements like the cache or CPU pipeline.

Instrumentation is another technique that has can be considered to achieve greater observability.

Instrumentation basically means adding loggers/print statements to certain points of interest of your hardware/software.

Instrumentation tends to slow execution down a bit, but way less than emulation.

The downside is that if the instrumentation does not provide you the data you need to debug, there's not much you can do, you will need to modify it, i.e. you don't get full visibility from instrumention.

This is unlike emulation that provides full observability.

The term loosely refers to certain layers of the computer abstraction layers hierarchy, usually high level hardware internals like CPU pipeline, caching and the memory system. Basically exactly what gem5 models.

Some of the earlier computers of the 20th centure were analog computers, not digital.

At some point analog died however, and "computer" basically by default started meaning just "digital computer".

As of the 2010's and forward, with the limit of Moore's law and the rise of machine learning, people have started looking again into analog computing as a possile way forward. A key insight is that huge floating point precision is not that crucial in many deep learning applications, e.g. many new digital designs have tried 16-bit floating point as opposed to the more traditional 32-bit minium. Some papers are even looking into 8-bit: dl.acm.org/doi/10.5555/3327757.3327866

As an example, the Lightmatter company was trying to implement silicon photonics-based matrix multiplication.

A general intuition behind this type of development is that the human brain, the holy grail of machine learning, is itself an analog computer.

Bought: 2018, 2021.

Seems to work OK. But you're fighting the symptom, and it will eventually come back.

Unsurprisingly the term "computer" became a synonym for this from the 1960s onwards!

The interface is a bit annoying, but the tool is really cool.

100 cycles of matrixprod:man stress-ng gives the list of possible --cpu-method. It documents matrixprod as:

If you don't specify the --cpu-method it apparently loops through every method one by one.

Limit time to 1s instead of limiting cycles:

This section is about companies that were primarily started as computer makers.

For companies that make integrated circuits, see also: Section "Semiconductor company".

Was a direct tech predecessor to the iPhone.