Sollten Sie Fortran in Rust neu schreiben oder kapseln?

Ein Fortran-Kernel, der seit zwanzig Jahren verlässliche Ergebnisse liefert, wird nicht zu schlechtem Code, nur weil die Anwendung um ihn herum umständlich geworden ist. Hat der Kernel eine schmale Schnittstelle, reproduzierbare Builds und jemanden, der ihn noch diagnostizieren kann, ist eine Kapselung hinter einer modernen Schnittstelle meist die günstigere und sicherere Entscheidung. Die Quellsprache allein ist kein Grund, funktionierende Mathematik neu zu schreiben.

Anders sieht es aus, wenn der alte Kernel die Bereitstellung bestimmt, die Hardwareauswahl blockiert, veränderlichen Zustand verbirgt oder Kenntnisse verlangt, die im Unternehmen nicht mehr vorhanden sind. Dann hat die Bewahrung laufende Kosten. Eine Portierung nach Rust kann günstiger sein als eine weitere Runde mit Spezialcompilern, veralteten Hosts, manuellen Releases und Störungen, die nur ein pensionierter Entwickler versteht. Schwierig ist der Vergleich dieser Kosten, ohne Alter mit einem Mangel zu verwechseln oder frühere Korrektheit als Beweis für künftige Betriebsfähigkeit zu nehmen.

Trennen Sie den Wert des Algorithmus von den Kosten seiner Hülle

Ein bewährter Algorithmus und seine Fortran-Implementierung sind miteinander verbundene Vermögenswerte, aber nicht derselbe Vermögenswert. Gleichungen, Koeffizienten, Konvergenzregeln und akzeptiertes Verhalten an Grenzfällen können erhaltenswert sein, auch wenn Buildsystem und Laufzeitannahmen es nicht sind.

Teams nennen einen Kernel oft "bewährt", wenn sie meinen, dass die Produktion seit Jahren von ihm abhängt. Diese Geschichte zählt, beantwortet aber nur eine Frage: Hat das Gesamtsystem für die tatsächlich eingegangenen Eingaben akzeptable Ergebnisse geliefert? Sie beweist nicht, dass der Code portabel, frei von undefiniertem Verhalten, bei Nebenläufigkeit sicher oder nach dem Weggang des aktuellen Betreuers verständlich ist. Ein langer Betrieb kann Abhängigkeiten sogar verdecken, weil den Kernel in letzter Zeit niemand auf einer sauberen Maschine gebaut hat.

Halten Sie fest, weshalb sich der Kernel zu erhalten lohnt, bevor Sie sich für einen Weg entscheiden. Die nützliche Bestandsaufnahme ist konkret:

• Das mathematische Modell und die vom Geschäft akzeptierte Version
• In der Produktion vorkommende Eingabebereiche, einschließlich ungültiger und degenerierter Fälle
• Geforderte Präzision, Rundungsverhalten und Konvergenztoleranzen
• Laufzeit- und Speichergrenzen, die einen echten Batch oder Request beeinflussen
• Compiler-Flags, verknüpfte Bibliotheken, Datendateien und Initialisierungsreihenfolge

Diese Bestandsaufnahme macht eine wichtige Unterscheidung sichtbar. Numerische Parität bedeutet, dass die neue Ausführung innerhalb einer vereinbarten Toleranz bleibt. Verhaltensparität umfasst auch Fehler, Warnungen, Iterationszahlen, Ausgabereihenfolge, Behandlung von NaN, Timeouts und Seiteneffekte. Eine Portierung kann die erste Definition erfüllen und die Anwendung nach der zweiten beschädigen. Eine Kapsel kann beides bewahren, aber nur, wenn ihre Schnittstelle Darstellung und Lebenszyklus nicht unbemerkt verändert.

Das Alter des Quellcodes gehört weit nach unten in die Entscheidungsakte. Ganz oben stehen die beobachtbaren Pflichten. Wenn sie niemand benennen kann, ist weder die Kapselung noch die Neuentwicklung bereit. Zuerst müssen Sie den Vertrag aus Code und Produktionsbelegen wiederherstellen.

Eine schmale und stabile Schnittstelle spricht für die Kapselung

Kapseln Sie den Kernel, wenn Aufrufer ihn als kleine Menge deterministischer Operationen mit gewöhnlichen numerischen Ein- und Ausgaben beschreiben können. Ein guter Kandidat verhält sich eher wie eine Bibliothek als wie eine Anwendung: unveränderliche Tabellen initialisieren, Arrays und skalare Optionen übergeben, rechnen, Ergebnisse und Status zurückgeben.

Zählen Sie die Schnittstellenpunkte statt der Fortran-Zeilen. Ein Solver mit 300.000 Zeilen und sechs stabilen Operationen kann leichter zu begrenzen sein als eine Routine mit 6.000 Zeilen, die globale Dateien liest, COMMON-Blöcke verändert, Berichte schreibt und eine Benutzeroberfläche zurückruft. Das zweite Programm hat trotz weniger Quellcode eine größere Verhaltensfläche.

Eine Kapsel ist sinnvoll, wenn alle folgenden Bedingungen gelten:

• Ein unterstützter Compiler kann das Binärprogramm auf den vorgesehenen Hosts reproduzieren
• Der Kernel hat Tests oder aufgezeichnete Fälle mit vertrauenswürdigen Ausgaben
• Aufrufe hängen nicht von verborgenem Prozesszustand ab, oder dieser Zustand lässt sich isolieren
• Die Kosten der Datenumwandlung bleiben gegenüber der Rechenzeit klein
• Sicherheitskorrekturen und Diagnosedaten erreichen die Schnittstelle, ohne die Mathematik zu bearbeiten

Die Kapsel sollte Validierung, Speichergrenzen, Versionsangaben, Telemetrie und die Umwandlung zwischen Anwendungstypen und Fortran-Typen übernehmen. Sie sollte nicht vortäuschen, numerisches Verhalten zu reparieren. Eine klare Trennlinie erlaubt Anwendungsentwicklern, den Betrieb zu verbessern, ohne nebenbei den Ergebnisvertrag zu verändern.

Es gibt auch einen nützlichen Organisationstest: Kann ein neuer Entwickler die Bibliothek bauen, ihre Fälle ausführen und einen fehlgeschlagenen Aufruf finden, ohne den ursprünglichen Autor zu fragen? Wenn ja, ist der bewahrte Kernel eine kontrollierte Abhängigkeit. Wenn nein, verdeckt die Kapsel womöglich nur ein verwaistes Programm. Dokumentation allein behebt das nicht. Build und Diagnose müssen auf einer leeren Maschine funktionieren.

Nutzen Sie die C-ABI als kleine, langweilige Naht

Fortran und Rust können über die C-Anwendungsbinärschnittstelle eine verlässliche Grenze teilen, sofern die Fortran-Seite ISO_C_BINDING statt compilerspezifischer Symbolkonventionen nutzt. Die Naht sollte numerische Typen mit fester Breite, explizite Arraylängen, flache Puffer und ganzzahlige Statuscodes offenlegen.

Dieser Fortran-Einstiegspunkt macht das Layout sichtbar:

module kernel_api
  use, intrinsic :: iso_c_binding
  implicit none
contains
  subroutine evaluate(n, x, scale, y, status) bind(C, name="kernel_evaluate")
    integer(c_int), value :: n
    real(c_double), intent(in) :: x(n)
    real(c_double), value :: scale
    real(c_double), intent(out) :: y(n)
    integer(c_int), intent(out) :: status

    if (n < 1 .or. scale <= 0.0_c_double) then
      status = 1_c_int
      return
    end if

    call legacy_evaluate(n, x, scale, y)
    status = 0_c_int
  end subroutine evaluate
end module kernel_api

Die Rust-Seite hält die unsichere Operation in einem kleinen Modul und bietet der übrigen Anwendung eine geprüfte Slice-API:

unsafe extern "C" {
    fn kernel_evaluate(
        n: i32,
        x: *const f64,
        scale: f64,
        y: *mut f64,
        status: *mut i32,
    );
}

pub fn evaluate(x: &[f64], scale: f64) -> Result<Vec<f64>, KernelError> {
    let n = i32::try_from(x.len()).map_err(|_| KernelError::InputTooLarge)?;
    if x.is_empty() || !scale.is_finite() || scale <= 0.0 {
        return Err(KernelError::InvalidInput);
    }

    let mut y = vec![0.0_f64; x.len()];
    let mut status = 0_i32;
    unsafe {
        kernel_evaluate(n, x.as_ptr(), scale, y.as_mut_ptr(), &mut status);
    }

    match status {
        0 => Ok(y),
        code => Err(KernelError::Fortran(code)),
    }
}

Dieser Code ist mit Absicht unspektakulär. An einer Sprachgrenze ist das ein Vorteil. Der Rust Nomicon beschreibt Aufrufe fremder Funktionen als unsafe, weil der Compiler den Vertrag der anderen Sprache nicht prüfen kann. Halten Sie den unsafe-Block klein genug für eine Prüfung und machen Sie jede Vorbedingung vor dem Aufruf sichtbar.

Das Interoperabilitätshandbuch von GNU Fortran erklärt, wie interoperable Prozeduren und Typen über BIND(C) und ISO_C_BINDING abgebildet werden. Folgen Sie diesem Mechanismus, statt sich auf das übliche Name Mangling eines Compilers zu verlassen. Ein mit einem Binäranalysewerkzeug gefundenes exportiertes Symbol belegt den heutigen Build, ist aber keine stabile Schnittstelle für den Compiler von morgen.

Schicken Sie in der ersten Version weder Rust-Structs noch abgeleitete Fortran-Typen, allokierbare Arrays oder sprachspezifische Strings über diese Naht. Flachen Sie die Daten ab. Dokumentieren Sie bei Matrizen Dimensionen, führende Dimension und Speicherreihenfolge. Übergeben Sie Text als Bytepuffer mit expliziter Länge und Kodierungsregel. Langweilige Darstellungen verhindern teure Mehrdeutigkeit.

Verborgener Zustand lässt Kapseln scheitern

Eine Kapsel scheitert, wenn sie ein zustandsbehaftetes Programm wie eine reine Funktion aussehen lässt, ohne den Zustand zu kontrollieren. SAVE-Variablen, COMMON-Blöcke, zwischengespeicherte Arbeitsarrays, Umgebungsvariablen, Unit-Nummern, Dateien im Arbeitsverzeichnis und der Gleitkommamodus können das Ergebnis eines scheinbar identischen Aufrufs ändern.

Nebenläufigkeit deckt diese Täuschung meist zuerst auf. Zwei Webanfragen gelangen gleichzeitig in die Kapsel, beide verändern denselben gespeicherten Arbeitsbereich, und eine Antwort enthält Werte aus den Eingaben der anderen. Ein Mutex kann die Korrektheit wiederherstellen, serialisiert aber auch den Durchsatz. Prozessisolation kann Parallelität auf Kosten von Speicher und Startaufwand erhalten. Keine Option ist automatisch falsch, doch beide gehören in das Kapazitätsmodell.

Auch die Initialisierung bricht häufig. Das ursprüngliche Programm liest vielleicht Koeffizienten, setzt einen Zufallsstartwert oder ruft eine Setup-Routine auf, bevor der numerische Pfad beginnt. Eine Bibliotheksextraktion, die nur die letzte Subroutine exportiert, kann aus nicht initialisiertem Zustand plausible Zahlen liefern. Solche Zahlen sind gefährlicher als ein Absturz, weil die Überwachung sie akzeptieren kann.

Erfassen Sie den vollständigen Lebenszyklus eines Aufrufs:

1. Starten Sie einen frischen Prozess und protokollieren Sie jede geladene Datei, jeden Umgebungswert und jede Bibliothek.
2. Verfolgen Sie die Initialisierung, bis die erste numerische Operation laufen kann.
3. Rufen Sie denselben Fall zweimal auf und vergleichen Sie alle Ausgaben und Statuswerte.
4. Verschachteln Sie zwei verschiedene Fälle und wiederholen Sie sie danach in getrennten Prozessen.
5. Erzwingen Sie ungültige Eingaben, soweit praktikabel einen Allokationsfehler und fehlende Konvergenz.

Diese Folge zeigt, ob der Kernel in einem Dienst mit mehreren Threads leben kann, eine einzelne Worker-Warteschlange braucht oder in isolierte Worker-Prozesse gehört. Sie findet auch Fehlerpfade, die den Prozess mit STOP beenden, auf die Standardausgabe schreiben oder Teilergebnisse zurücklassen. Eine Kapsel kann einen Fehler nicht übersetzen, nachdem die Fortran-Laufzeit ihren Host beendet hat.

Das Arraylayout braucht eine eigene Prüfung. Fortran speichert Arrays spaltenweise; Rust-Bibliotheken nehmen oft zeilenweise Speicherung an. Eine kopierte Matrix kann von den Dimensionen her richtig aussehen und dennoch ihre Transponierte oder eine falsche Schrittweite darstellen. Testen Sie eine nicht quadratische Matrix mit eindeutigen Werten, weil quadratische oder symmetrische Fälle den Fehler verbergen. Wenn Umwandlungskopien den Großteil der Aufrufzeit beanspruchen, sollte die Schnittstelle das native Layout des Kernels akzeptieren, statt für zwei vollständige Speicherdurchläufe zu zahlen.

Beweisen Sie Parität mit produktionsnahen Belegen

Parität braucht einen ausführbaren Vergleich, keine Codeprüfung und keine Handvoll goldener Ausgaben. Führen Sie alten und neuen Pfad mit denselben aufgezeichneten Eingaben aus, erfassen Sie die vollständigen beobachtbaren Ergebnisse und klassifizieren Sie jede Abweichung.

Beginnen Sie mit Produktionsverkehr oder Batch-Datensätzen, nachdem Sie Daten entfernt haben, die nicht in die Testumgebung gehören. Aufzeichnungen enthalten Kombinationen, die synthetische Tests verfehlen: leere neben großen Gruppen, ungewöhnliche Reihenfolgen, veraltete Flags, Werte nahe einer Schwelle und Wiederholungen nach unvollständiger Arbeit. Ergänzen Sie konstruierte Grenz- und Belastungsfälle, aber ersetzen Sie damit keine echten Betriebsformen.

Ein nützliches Prüfprogramm gibt für jeden Aufruf einen solchen Datensatz aus:

{
  "case_id": "settlement-004812",
  "operation": "evaluate",
  "input_digest": "sha256:...",
  "old": {"status": 0, "iterations": 7, "output": [1.25, 3.5]},
  "candidate": {"status": 0, "iterations": 7, "output": [1.25, 3.5]},
  "comparison": {"max_abs": 0.0, "max_rel": 0.0, "accepted": true}
}

Wählen Sie nicht aus Bequemlichkeit ein globales Epsilon. Absolute Toleranz funktioniert nahe null, relative Toleranz bei wachsenden Beträgen, manche Ausgaben brauchen Grenzen aus ihren Einheiten, und exakte Ganzzahlen sowie Statuswerte verlangen Gleichheit. Für NaNs braucht es eine ausdrückliche Regel, weil normale Gleichheit sie anders als endliche Werte behandelt. Das Vorzeichen von null kann zählen, wenn spätere Operationen es untersuchen.

Vergleichen Sie Fehler ebenso sorgfältig wie erfolgreiche Berechnungen. Meldet der alte Pfad nach 40 Iterationen fehlende Konvergenz und gibt der neue die letzte Näherung als Erfolg zurück, können die Arrays ähnlich aussehen, obwohl sich der Vertrag geändert hat. Ist die Ausgabereihenfolge im Quellcode nicht festgelegt, wurde aber jahrelang von nachgelagertem Code vorausgesetzt, macht das Produktionsverhalten diese Reihenfolge bis zur Änderung der Aufrufer zur Migrationspflicht.

Behalten Sie das Prüfprogramm nach dem Release. Es schützt spätere Compiler-Upgrades, Änderungen an Optimierungsflags, Bibliothekswechsel und weitere Rust-Arbeit. CodeHero nutzt einen solchen Paritätstest gegen aufgezeichneten Produktionsverkehr, während die Architektur modernisiert wird, weil eine bestandene Unit-Test-Suite allein gleiches Verhalten an den Rändern eines Altsystems nicht beweist.

Schreiben Sie neu, wenn Eigentumskosten wiederkehren

Portieren Sie den Kernel, wenn sein Erhalt eine wiederkehrende Betriebslast verursacht, die eine Kapsel nicht beseitigen kann. Die stärksten Auslöser betreffen Eigentum und Bereitstellung, nicht den Geschmack bei Programmiersprachen.

Eine Portierung verdient ernsthafte Prüfung, wenn der freigegebene Fortran-Compiler die Zielumgebung nicht unterstützt, der Build von aufgegebenen Bibliotheken abhängt oder jedes Release einen Host verlangt, den das Unternehmen ohnehin ausmustern will. Gleiches gilt, wenn die Produktionsdiagnose an einer undurchsichtigen Binärdatei endet und Fehler nicht mit Eingaben, Phasen oder Ressourcenverbrauch verbunden werden können.

Personal zählt, doch "wir stellen keine Fortran-Entwickler ein" reicht allein nicht. Ein gekapselter stabiler Kernel kann wenig Spracharbeit verlangen. Messen Sie den echten Bedarf: Wie oft ändert sich der Algorithmus, wie viele Störungen brauchen eine Diagnose im Quellcode, wer prüft Compiler-Upgrades, und was geschieht bei Abwesenheit des heutigen Eigentümers? Eine Portierung nur zur Anpassung an die Mehrheitssprache kann viel Geld ausgeben, ohne diese Lasten zu senken.

Häufige Änderungen stärken das Argument. Fügt die Produktarbeit regelmäßig Modellterme hinzu, ändert Konvergenzregeln oder muss der Kernel Request-Abbrüche und strukturierte Fehler unterstützen, überschreitet jede Änderung die Naht. In der Kapsel wächst dann eine Richtlinie, die in die Berechnung gehört. Rust bietet direktes Speichereigentum, explizite Ergebnistypen, kontrollierte Parallelität und Werkzeuge, die ein größerer Teil des Anwendungsteams bedienen kann.

Daneben gibt es ein Sicherheits- und Isolationsargument. Wenn der Kernel nicht vertrauenswürdige Dateien verarbeitet, Indizes ungeprüft verwendet oder im selben Prozess wie ein erreichbarer Dienst läuft, kann Eindämmung schon vor der Portierung nötig sein. Führen Sie ihn während der Neuentwicklung in einem eingeschränkten Worker-Prozess mit Eingabegrenzen aus. Rust reduziert viele Speicherfehler im neu geschriebenen Code, beweist aber nicht die Mathematik, verhindert keine Ressourcenerschöpfung und macht unsichere Fremdbibliotheken nicht sicher.

Eine brauchbare Entscheidungsakte übersetzt wiederkehrende Probleme in jährlichen Entwicklungsaufwand und Infrastrukturkosten. Nehmen Sie Compilerlizenzen, besondere Buildhosts, Releasearbeit, Abhängigkeit bei Störungen, durch Serialisierung brachliegende Kapazität und blockierte Plattformwechsel auf. Erfinden Sie keinen Geldwert für "Modernität". Bewerten Sie Arbeit, die das Unternehmen tatsächlich ausführt.

Compilereinstellungen gehören zum Verhaltensvertrag

Ein Compilerbefehl ist Teil des wirksamen Quellcodes eines Kernels. Optimierungsflags, Gleitkommaoptionen, Zielarchitektur, verknüpfte Mathematikbibliotheken und sogar die Linkreihenfolge können numerische Ergebnisse ändern oder Annahmen sichtbar machen, die ein älterer Build zufällig toleriert hat.

Rekonstruieren Sie den exakten Build, bevor Sie Kapsel oder Portierung bewerten. Sichern Sie Compileridentität und Version, alle Compile- und Linkflags, Präprozessordefinitionen, Bibliotheksversionen und die beim Build verwendeten Umgebungsvariablen. Erfassen Sie Befehle aus dem Buildwerkzeug, statt einen Kommentar aus einem alten Betriebsdokument zu kopieren. Bauen Sie dann in einer sauberen Umgebung neu und vergleichen Sie die Referenzfälle. Weicht schon der saubere Neubau ab, hat das Team vor Beginn der Migration ein Reproduzierbarkeitsproblem.

Aggressive Gleitkommaoptimierung verlangt besondere Vorsicht. Mit freizügigen Mathematikflags kann ein Compiler Operationen neu ordnen, Multiplikation und Addition zusammenziehen, NaNs als unmöglich behandeln oder annehmen, dass das Vorzeichen von null keine Bedeutung hat. Diese Umformungen können schneller sein und zugleich die Konvergenz an einer Schwelle verändern. Entscheidend ist nicht, ob eine Option abstrakt einer strengen Norm folgt. Fragen Sie, ob der Produktionsvertrag die Änderung erlaubt, und beweisen Sie die Antwort mit dem Prüfprogramm.

Externe numerische Bibliotheken gehören ebenfalls in die Akte. Ein Aufruf namens DGEMM kann dieselbe Schnittstelle behalten, während eine andere BLAS-Implementierung Reduktionsreihenfolge, Threading, CPU-Auswahl und Leistung verändert. Innerhalb einer sinnvollen Toleranz ist das meist akzeptabel, kann aber Grenzfälle eines Solvers verändern oder einen Dienst überbelegen, dessen äußere Schicht ebenfalls Threads anlegt. Zeichnen Sie Implementierung und Thread-Einstellungen der Bibliothek zusammen mit jedem Benchmark auf.

Erstellen Sie neben jedem Kandidatenartefakt ein Buildmanifest. Es kann schlicht sein:

kernel_version=2026.08
compiler=gfortran
compiler_version=<captured from build>
compile_flags=<captured from build>
blas_implementation=<name and version>
target_cpu=<declared target>
source_digest=<repository revision>
test_corpus=<immutable corpus revision>

Die spitzen Klammern markieren auszufüllende Felder, keine Erlaubnis für unbekannte Daten. Lassen Sie den Build dieses Manifest automatisch erzeugen und über eine Versionsoperation oder ein Startprotokoll bereitstellen. Ändert sich eine Ausgabe nach der Bereitstellung, können Betreiber erkennen, ob Code, Compiler, Bibliothek oder Eingabekorpus gewechselt hat.

Bei einer Kapsel macht diese Disziplin aus der Fortran-Binärdatei eine verwaltete Komponente statt einer unerklärten Datei, die zwischen Servern kopiert wird. Bei einer Portierung gibt sie Rust-Entwicklern das tatsächliche Verhalten vor, das sie treffen müssen. Rust-Builds brauchen dieselbe Behandlung: Abhängigkeitsversionen sperren, Compilerwerkzeuge aufzeichnen, CPU-Merkmale des Ziels angeben und Leistungsflags von Paritätsflags trennen, bis ihre Wirkung gemessen ist.

Machen Sie bitgenaue Gleichheit nicht zum allgemeinen Ziel. Für einige regulierte Datensätze oder binäre Checkpoints kann sie nötig sein, doch sie kann einen Compiler- und Hardwarepfad auf unbestimmte Zeit einfrieren. Die meisten numerischen Systeme brauchen fachlich oder finanziell sinnvolle Toleranzen sowie exakte Übereinstimmung bei diskreten Entscheidungen. Dokumentieren Sie, welche Ausgaben in welche Kategorie fallen. Ein boolesches Berechtigungsergebnis darf nicht um ein Epsilon abweichen, auch wenn es aus Gleitkommarechnungen stammt.

Ein letzter Fehler ist der Vergleich eines alten konservativen Builds mit einem Kandidaten, der alle verfügbaren Optimierungen nutzt, und die anschließende Zuschreibung an die Sprache. Führen Sie eine Matrix aus, die Implementierung und Compilereinstellungen trennt: ursprüngliche Fortran-Einstellungen, optimierte Fortran-Einstellungen, konservative Rust-Einstellungen und optimierte Rust-Einstellungen. So erkennen Sie, ob die erwartete Ersparnis aus der Portierung, einem Compiler-Upgrade oder einem veränderten numerischen Vertrag stammt.

Hardwarekosten können eine korrekte Kapsel unrentabel machen

Eine Kapsel kann Ergebnisse perfekt bewahren und trotzdem teuer werden, wenn ihr Ausführungsmodell die verfügbare Hardware schlecht ausnutzt. Messen Sie die vollständige Last auf der vorgesehenen Hardware, einschließlich Datenumwandlung, Prozessgrenzen, Speicherbewegung und Warteschlangen.

Nehmen Sie nicht an, Rust sei schneller. Ausgereifte Fortran-Compiler erzeugen hervorragenden numerischen Code, und etablierte Kernel rufen vielleicht schon optimierte BLAS- oder LAPACK-Routinen auf. Eine wörtliche Portierung kann Vektorisierung verlieren, häufiger allokieren oder einen optimierten Bibliotheksaufruf durch eine gewöhnliche Schleife ersetzen. Die Sprachwahl beseitigt weder Speicherbandbreite noch algorithmische Komplexität.

Wirtschaftlicher Druck entsteht meist an anderer Stelle. Ein Kernel ist vielleicht nur für eine alte Architektur gebaut, hängt an einer herstellerspezifischen Laufzeitumgebung oder serialisiert Arbeit durch globalen Zustand. Eventuell kopiert er große Arrays mehrfach für eine neue Serviceschnittstelle. Cloud-Instanzen bleiben dann unausgelastet, während Requests vor einer Rechenspur warten. Diese Systemkosten sind messbar und können eine Portierung rechtfertigen, auch wenn ein einzelner isolierter Fortran-Aufruf schnell bleibt.

Testen Sie repräsentative Verteilungen, nicht einen günstigen Einzelfall. Erfassen Sie mindestens Durchsatz, hohe Latenzperzentile, maximalen residenten Speicher, an der Schnittstelle kopierte Bytes und Wartezeit vor dem serialisierten Bereich. Messen Sie warme und kalte Fälle, wenn die Initialisierung ins Gewicht fällt. Halten Sie Compilerversionen und Flags im Ergebnis fest, damit ein anderer Entwickler es reproduzieren kann.

Prüfen Sie dann die günstigsten Alternativen zur Neuentwicklung. Das Entfernen einer unnötigen Transponierung, ein Pool von Worker-Prozessen, ein Compiler-Update oder der Ersatz einer Dateischnittstelle durch einen Speicherpuffer kann genug Kapazität zurückgewinnen. Gelingt das, hat die Kapsel eine weitere Laufzeit verdient. Blockiert der Kernel weiterhin die ausgewählte Architektur oder einen Beschleunigerpfad, erhält die Portierung eine konkrete Leistungspflicht statt eines unbestimmten Versprechens.

Eine Rust-Portierung sollte Verhalten und nicht Fortran-Syntax erhalten

Eine erfolgreiche Portierung überträgt das Rechenmodell und gibt ihm danach einen Aufbau, den Rust-Entwickler betreuen können. Transliteration bewahrt alte Kontrollflüsse, globale Arrays, Sentinelwerte und Indexgewohnheiten und ergänzt Kämpfe mit dem Borrow Checker. Das Ergebnis ist schwerer zu prüfen als beide Ausgangspunkte.

Frieren Sie den Referenzbuild vor der Bearbeitung ein. Geben Sie ihm reproduzierbare Compilerflags, unveränderliche Testdaten und einen maschinenlesbaren Aufruf. Die Referenz muss nicht schön sein. Sie muss verfügbar bleiben, bis der Ersatz den Produktionsvergleich bestanden hat.

Teilen Sie die Portierung entlang mathematischer Grenzen, die das Prüfprogramm beobachten kann. Geeignete Einheiten sind Vorverarbeitung, Koeffizientenauswahl, eine Solveriteration, Konvergenzprüfung und Ergebnisformatierung. Portieren Sie eine Einheit, rufen Sie sie wenn möglich aus dem bestehenden Pfad auf und vergleichen Sie Zwischenwerte. Damit bleibt eine Abweichung auf eine Phase begrenzt, statt Entwickler zur Prüfung eines vollständigen Solvers zu zwingen.

Treffen Sie numerische Entscheidungen in Rust ausdrücklich. Legen Sie fest, ob Werte f32 oder f64 sind, wie Ganzzahlumwandlungen Überläufe behandeln, welche Reduktionsreihenfolge akzeptiert wird und ob eine zusammengezogene Multiplikation und Addition die Rundung ändern darf. Bewahren Sie zuerst den akzeptierten Algorithmus. Verbessern Sie ihn später in einer getrennt geprüften Änderung mit eigenen Belegen, denn die Mischung aus Sprachmigration und Modellrevision zerstört die saubere Referenz.

Stellen Sie Fehler als typisierte Ergebnisse statt als magische Werte dar, erhalten Sie aber das alte Außenverhalten, bis Aufrufer den neuen Vertrag bewusst übernehmen. Gibt der Fortran-Pfad eine Warnung und eine brauchbare Näherung aus, darf das erste Rust-Release diesen Fall nicht still in einen fatalen Fehler verwandeln. Bessere APIs helfen nur, wenn sich das umgebende System mit ihnen ändert.

Beschränken Sie unsafe Rust auf Fremdsprachengrenzen und geprüfte Bibliotheksaufrufe. Auch reines Rust kann bei einem Indexzugriff panic auslösen, ohne praktische Grenze allokieren oder aus gültigen Gleitkommaoperationen NaNs erzeugen. Setzen Sie Grenzen und melden Sie Fehler an der Serviceschnittstelle zurück. Speichersicherheit löst eine Fehlerklasse, nicht den Betriebsvertrag.

Halten Sie die Entscheidung umkehrbar, bis Belege sie schließen

Das sicherste Programm schiebt die unumkehrbare Wahl hinaus und verbessert dabei beide Optionen. Erstellen Sie zuerst einen reproduzierbaren Fortran-Build und ein Paritätsprüfprogramm. Setzen Sie danach den bestehenden Kernel hinter die Schnittstelle, die Sie auch bei einer anderen Implementierung wünschen würden. Diese Arbeit ist für eine solide Kapsel nötig und bleibt für eine Portierung nützlich.

Führen Sie die gekapselte Version unter repräsentativer Last aus. Nun haben Sie Belege zu Umwandlungskosten, Nebenläufigkeit, Fehlerisolation und betrieblichem Eigentum. Erfüllt sie das Serviceziel und kann das Team den Build pflegen, hören Sie auf. Gutes Fortran zu behalten ist eine technische Entscheidung und kein Mangel an Ehrgeiz.

Verfehlt sie das Ziel, wird dieselbe Schnittstelle zur Grenze des Rust-Ersatzes, und dieselben aufgezeichneten Fälle bewerten jede migrierte Einheit. Stellen Sie nach Möglichkeit mit Schattenvergleich bereit: Führen Sie den Kandidaten aus, ohne dass er die Antwort steuert, protokollieren Sie begrenzte Abweichungen und prüfen Sie Fälle außerhalb der Toleranz. Schützen Sie sensible Eingaben und begrenzen Sie die zusätzliche Rechenlast. Schattenausführung ist eine Testtechnik und keine Erlaubnis zum sorglosen Duplizieren von Daten.

Legen Sie Ausstiegskriterien fest, bevor die Portierung Eigendynamik entwickelt. Sie sollten akzeptierte Parität, Leistung auf den vorgesehenen Hosts, Fehlerverhalten, Betriebsdiagnose und die Entfernung der alten Laufzeitabhängigkeit abdecken. Definieren Sie auch das Rücksetzfenster und die Belege, nach denen die Referenz ausgemustert werden darf. Ohne diese Bedingungen behalten Teams zwei Implementierungen auf unbestimmte Zeit und bezahlen beide Eigentumskosten.

Die Entscheidung lässt sich nun ohne Ideologie treffen. Kapseln Sie, wenn die Berechnung stabil, die Schnittstelle schmal und die Werkzeugkette betreibbar ist. Schreiben Sie neu, wenn wiederkehrende Eigentums- oder Hardwarezwänge mehr kosten als eine gemessene Portierung und das Unternehmen die neue Implementierung gegen die alte beweisen kann. Wenn Sie noch keine der beiden Aussagen belegen können, verwenden Sie den nächsten Entwicklungstag auf das Prüfprogramm und nicht auf die Übersetzung einer Schleife.