Dmitri Bogdanovs utl::random ist diese Woche als stille Show HN auf Hacker News gelandet — ein Single-Header-Modul in C++17, geschrieben während einer Arbeit zur stochastischen Wärmeleitung. Wer über die Benchmarks hinausliest, findet ein echtes Argument: std::random_device ist ein Single Point of Failure in jedem C++-Projekt, das darauf angewiesen ist — und fast niemand zeichnet das in den Abhängigkeitsgraphen ein.

←TODAY: utl::random liefert Romu, SplitMix, Xoshiro256++ und ChaCha20 als Drop-in-Ersatz für std::mt19937 mit deterministischer Cross-Compiler-Ausgabe.
→3012: Computational Design ohne PRNG-Abhängigkeitsgraph wird so gelesen wie unsignierte Executables heute — als veraltet.
Fulcrum: Die Bibliothek ist klein. Die Disziplin, zu fragen «woher kommt diese Zahl», ist das Ganze.

Die Abhängigkeit, die du nicht gezeichnet hast

Der C++-Standard lässt std::random_device stillschweigend auf einen deterministischen PRNG zurückfallen, wenn keine Hardware-Entropiequelle verfügbar ist — und lässt es darüber lügen. Die entropy()-Methode, die diesen Fallback kennzeichnen sollte, ist implementierungsdefiniert und liefert auf jeder Plattform andere Werte. Bogdanovs Ersatz mischt std::random_device mit Thread-ID-Hashes, Lesezugriffen auf die monotone Uhr und anderen CPU-Zustand-Samples. Nicht kryptografisch, aber quasi garantiert, dass sich die Zahlen zwischen Durchläufen ändern.

Die zweite versteckte Kante ist Reproduzierbarkeit. std::mt19937 ist portierbar, aber die meisten Verteilungen darauf nicht: std::uniform_real_distribution erzeugt unterschiedliche Sequenzen auf MSVC und libstdc++ aus demselben Seed. Für Monte-Carlo-Arbeit — Tageslichtanalyse, Akustik, stochastische Tragwerksanalyse, Belegungsmodellierung — liefert derselbe Code auf zwei Laptops zwei unterschiedliche numerische Ergebnisse. Die meisten Teams entdecken das an dem Tag, an dem ein Junior eine Verifikationsberechnung auf einem anderen OS erneut durchführt.

Wo das auf dem Arbeitstisch landet

Wenn dein Büro Radiance-Tageslichtanalysen, Karamba-Wahrscheinlichkeitslastanalysen, GHPython-Formfindung mit stochastischem Seeding oder Differenzialprivacy-Rauschen auf Belegungssensoren durchführt, vertraust du auf einen PRNG, dem du nie einen Namen gegeben hast. Xoshiro256++ — die neue Vorgabe in utl::random — überbietet std::mt19937 und besteht härtere statistische Tests. Die ChaCha8/12/20-Familie im gleichen Header liefert kryptografische Sicherheit für alles, das Benutzer sehen.

Atelier: Die PAZ Grasshopper↔Archicad Library nutzt deterministische Zufälligkeit für Fassadenvariationsstudien — gleiches Seed, gleiche Fassade, auf jeder Maschine im Büro. Diese Eigenschaft hält nur, wenn Generator und Verteilung beide reproduzierbar sind. Die Methode zu lehren zwingt das Team, die Zahl verteidigen zu können — nicht nur zu produzieren.

Hack: Dieser Hack zeigt dir, wie du den gleichen Monte-Carlo-Draw zweimal auf zwei Compilern durchführst und bit-identische Zahlen erhältst. Domain: Workflow. Ersetze std::random_device durch einen Mixed-Entropy-Seed und nutze die Compiler-stabilen Verteilungen in utl.

#include "UTL/random.hpp"
using namespace utl::random;

PRNG rng(entropy());                  // gemischte Quellen, nicht nur random_device
double u = uniform_double(0.0, 1.0);  // U[0,1), identisch auf MSVC + clang
double n = normal_double(0.0, 1.0);   // N(0,1), deterministisch über Toolchains

Führe diesen Block auf Windows MSVC und Linux clang mit einem festen Seed aus. Die Zahlen stimmen überein. Das äquivalente std::uniform_real_distribution nicht. Das ist die ganze Lektion — und der Grund, warum ein Verifizierungsbericht die Toolchain pinnen muss, nicht nur den Seed.

Die Systemslektüre

NVIDIA CUDA 13.3, auch diese Woche veröffentlicht, sitzt auf der anderen Seite der gleichen Kante. Tile-Programmierung bringt High-Level-GPU-Kernel; cuRAND auf diesen Kerneln ist ein anderer PRNG mit eigener Reproduzierbarkeitsgarantie. Eine Tageslichtanalyse, die CPU und GPU kreuzt, ohne dass jemand benannt hat, welcher Generator welche Schleife besitzt — genau die stille Topologie, die dieser Schreibtisch lesen soll. Die 2074-Rezertifizierungssaison lehrte hart: Single Points of Failure sind still, bis sie nicht mehr sind. Zeichne diese Woche deinen realen PRNG-Abhängigkeitsgraphen — nicht das Architektur-Diagramm, den Abhängigkeitsgraphen.

PAZ Fazit

Ersetze std::random_device oder std::mt19937 in Verifizierungsberechnungen durch utl::random, und dokumentiere den Generatorname in der Methode neben dem Seed. Die Bibliothek ist klein; die Disziplin zu fragen, woher die Zahl kommt, ist das Ganze.

Quellen & Weiterführendes

• Primär: UTL / module_random.md — Dmitri Bogdanov
• Vertiefung: NVIDIA CUDA 13.3 — Tile-Programmierung in C++