Mel plaçait chaque instruction pour rencontrer la tête de lecture du tambour — et battait l'assembleur

Dans l'essai USENET d'Ed Nather de 1983, « The Story of Mel, a Real Programmer », Mel est le programmeur de Royal McBee Computer Corp., fabricant du LGP-30 et de la plus récente RPC-4000 — des machines à mémoire à tambour bon marché. Mel, qui désapprouvait les compilateurs (« Si un programme ne peut pas réécrire son propre code, à quoi sert-il ? »), avait écrit en hexadécimal brut le programme le plus populaire de l'entreprise : un jeu de blackjack qui remplissait le stand du LGP-30 à chaque salon informatique, tandis que les vendeurs d'IBM restaient plantés à discuter entre eux.

L'art de Mel était le minutage. Sur une machine à tambour, le code ne s'exécute vite que si chaque instruction arrive à la tête de lecture juste au moment où la précédente se termine. Un assembleur optimisant existait pour cela, mais Mel le refusait parce que ses placements étaient imprévisibles et imposeraient des constantes séparées. Connaissant la valeur numérique de chaque code d'opération et attribuant lui-même ses adresses de tambour, il pouvait traiter n'importe quelle instruction comme une constante numérique — récupérer une instruction d'addition antérieure et multiplier par elle.

Il écrivait d'abord les corps des boucles les plus internes afin qu'ils s'emparent des emplacements optimaux du tambour, et plaçait des délais délibérés juste après la tête de lecture pour qu'ils prennent un tour complet — le « plus pessimum ». Nather compara les programmes optimisés à la main de Mel avec le même code passé dans l'assembleur optimisant : « ceux de Mel tournaient toujours plus vite. » L'essai se termine par une demande de modification dans laquelle les ventes voulaient un commutateur de sens permettant aux clients de gagner au blackjack.

Mel rechigna devant la malhonnêteté, puis s'exécuta — mais écrivit le test à l'envers, si bien que le commutateur faisait tricher la machine et gagner à chaque fois. Il déclara que son subconscient était d'une éthique incontrôlable et refusa de corriger, et l'essai de Nather transforma l'épisode en l'un des morceaux de folklore informatique les plus réimprimés.

Écrire d'abord les boucles les plus internes et placer chaque instruction pour rencontrer la tête de lecture exactement à temps — en utilisant les valeurs numériques des codes d'opération comme constantes pour du code automodifiant.

La latence du tambour faisait du placement des instructions la différence entre un code rapide et un code d'une lenteur extrême.

L'assembleur optimisant optimisait le placement mais détruisait le contrôle du programmeur sur celui-ci.

Écrire d'abord les boucles les plus internes permettait au code le plus sollicité de s'emparer des meilleures adresses avant tout le reste.

Le code automodifiant par arithmétique des codes d'opération comme constantes supprimait entièrement les constantes séparées.

La véritable optimisation exploite la physique de la machine, pas la chaîne d'outils : celui qui connaît la valeur numérique de chaque code d'opération peut transformer les constantes en code et le minutage en matériau de conception.

L'essai devint l'un des morceaux de folklore informatique les plus réimprimés, et « pas tout à fait optimal » entra dans le vocabulaire des programmeurs grâce au terme « plus pessimum » forgé par Mel ; la RPC-4000 et Royal McBee elle-même ont depuis longtemps disparu, surtout mémorisées à travers cette histoire.