Thread by @michaelbolton

Live-tweeting @LandonNoll's presentation on extreme computation projects.

@landonnoll Learning objectives: "One of the things I emphasize is that science values questions over answers. Dogma gives you answers. To the degree that science gives you answers, they're launching boards for more questions."

@landonnoll On being understood: Someone says "I want a big prime number". A three-storey number 2 is a big prime number. Now he shows us a big prime number that begins with 9s, ends with 9s, and contains a total of 376967 9s. And then, (some of) the digits of the largest known prime.

That's 25 million digits... but this raises a question: how do you KNOW it's prime? How do you PROVE it's prime? The 2018 record for proving a prime by factoring is 250 digits.

The answer lies with the Lucas-Lehmer Mersennse test, which shows a particular property that only prime have. (Details hard to transcribe in this medium, but he walked us through an example for 2**5-1 (31).)

Levels of correctness: Level 0: Sufficient (Example: Web search results); Level 1: Precise (within a certain tolerance, which really means precise enough; example: deep space probes), Level 2: Exact (example: prime numbers; either it's prime or it ain't).

Extreme computation: enormous task, exact correctness is mandatory; length of computation exceeds Mean Time to Failure (failures happen); length of computation exceeds Mean Time to Error (errors are common).

In extreme computation, you cannot blindly trust source code, compilers, assemblers, linkers, libraries, networking, storage, memory, firmware. All of these are fallible. You must be skeptical and test comprehensively.

Agile zones for extreme computation: Communication, Foundation, and Implementation.
Communication in this context requires documentation, source code comments, published results, code releases. Code here must be literate.

The Foundation Zone requires unit testing, anti-regression strategies, checkpoint/restart, measurement, algorithmic elements, logging. As you develop this stuff, you will realize that your documentation is insufficient.

The Implementation Zone involves project logic, performance tuning (important not to write optimally fast code too early), live update (when you realize you can do better -- but you have to go back to Foundation), and log analysis. Change in one zones has implications for others.

In extreme computing projects, @LandonNoll suggests that 70% of your computation time is occupied by testing.

Dilemma: logging and measurement steal time from performance -- so your measurement system has to be measured and your tuning system has to be tuned!

In extreme computing projects (which are typically in a competitive arena), people who want to be *first* often fail because they lose track of the fact that you must be first and *correct* -- and the correctness part takes time.

Extreme computing projects often reveal problems that have lurked in compilers forever without being noticed. Success depends on honouring the desire to test. The people who seem "obnoxious", "pedantic" are the ones who are going to save you. (Falling in love with @landonnoll.)