Mel platzierte jede Anweisung so, dass sie den Lesekopf der Trommel traf – und schlug den Assembler

In Ed Nathers USENET-Essay „The Story of Mel, a Real Programmer“ von 1983 ist Mel der Programmierer bei der Royal McBee Computer Corp., dem Hersteller des LGP-30 und der neueren RPC-4000 – billiger Maschinen mit Trommelspeicher. Mel, der Compiler ablehnte („If a program can't rewrite its own code, what good is it?“), hatte das beliebteste Programm des Unternehmens in rohem Hexadezimal geschrieben: ein Blackjack-Spiel, das auf jeder Computermesse den LGP-30-Stand füllte, während IBM-Vertreter herumstanden und miteinander redeten.

Mels Handwerk war das Timing. Auf einer Trommelmaschine läuft Code nur dann schnell, wenn jede Anweisung genau dann am Lesekopf ankommt, wenn die vorherige endet. Dafür gab es einen optimierenden Assembler, doch Mel lehnte ihn ab, weil seine Platzierungen unvorhersehbar waren und getrennte Konstanten erzwingen würden. Da er den numerischen Wert jedes Operationscodes kannte und seine eigenen Trommeladressen vergab, konnte er jede Anweisung als numerische Konstante behandeln – eine frühere Additionsanweisung aufgreifen und mit ihr multiplizieren.

Er schrieb die Rümpfe der innersten Schleifen zuerst, damit sie die optimalen Trommelplätze belegten, und setzte absichtliche Verzögerungen direkt hinter den Lesekopf, sodass sie eine volle Umdrehung brauchten – das „most pessimum“. Nather verglich Mels von Hand optimierte Programme mit demselben Code, der durch den optimierenden Assembler lief: „Mel's always ran faster.“ Der Essay endet mit einem Change Request, in dem der Vertrieb einen Umschalter verlangte, mit dem Kunden beim Blackjack gewinnen konnten.

Mel sträubte sich gegen die Unehrlichkeit, gab dann nach – schrieb den Test aber verkehrt herum, sodass der Schalter die Maschine betrügen und jedes Mal gewinnen ließ. Er erklärte, sein Unterbewusstsein sei unkontrollierbar ethisch, und weigerte sich, das zu korrigieren, und Nathers Essay machte die Episode zu einem der am häufigsten nachgedruckten Stücke der Informatik-Folklore.

Schreibe die innersten Schleifen zuerst und platziere jede Anweisung so, dass sie den Lesekopf genau rechtzeitig trifft – unter Verwendung der numerischen Werte der Opcodes als Konstanten für selbstmodifizierenden Code.

Die Trommellatenz machte die Anweisungsplatzierung zum Unterschied zwischen schnellem und quälend langsamem Code.

Der optimierende Assembler optimierte die Platzierung, zerstörte aber die Kontrolle des Programmierers darüber.

Die innersten Schleifen zuerst zu schreiben ließ den heißesten Code die besten Adressen belegen, bevor alles andere kam.

Selbstmodifizierender Code durch Arithmetik mit Opcodes als Konstanten beseitigte getrennte Konstanten vollständig.

Echte Optimierung nutzt die Physik der Maschine, nicht die Toolchain: Wer den numerischen Wert jedes Opcodes kennt, kann Konstanten in Code und Timing in ein Entwurfsmaterial verwandeln.

Der Essay wurde zu einem der am häufigsten nachgedruckten Stücke der Informatik-Folklore, und „not quite optimum“ gelangte durch Mels Wortschöpfung „most pessimum“ in den Wortschatz der Programmierer; die RPC-4000 und Royal McBee selbst sind längst verschwunden und werden vor allem durch diese Geschichte erinnert.