Benchmark-Suiten für wissenschaftliche Löser: SCIML, DOE Sparse Solver und ASU Mittelmann

Benchmarking ist wichtig, wenn Forscher numerische Solver, maschinelle Lernmodelle, spärliche lineare Algebra-Bibliotheken oder Optimierungssoftware vergleichen müssen. Ein Solver, der sich auf einer Gleichung, Matrix, Toleranz oder Hardware-Plattform gut abschneidet, kann sich unter anderen Bedingungen sehr unterschiedlich verhalten.

Ein nützlicher Benchmark sollte wiederholbare Problemdefinitionen, konsistente Genauigkeitsmessungen, kontrollierte Rechenumgebungen und transparente Berichte liefern. Es sollte auch mit der Art der bewerteten Software übereinstimmen. Ein ODE-Integrator, ein neuronaler Operator, ein spärlicher direkter Solver und ein PDE-beschränkter Optimierer lösen nicht das gleiche Problem und sollten nicht durch dieselbe Testsuite verglichen werden.

Die wissenschaftliche Rechenlandschaft umfasst mehrere wichtige Benchmark-Ressourcen. ScimlBenchmarks konzentriert sich auf die Effizienz der Differentialgleichung. Pdebench bietet Datensätze und Evaluierungsaufgaben für wissenschaftliches maschinelles Lernen. HPCG stellt spärliche, speicherintensive Workloads auf Hochleistungscomputern dar. Suitesparse liefert Matrizen aus realen Anwendungen. Die ASU Mittelmann Collection unterstützt Vergleiche von Optimierungssoftware, einschließlich PDE-beschränkter Probleme.

Warum Solver-Benchmarks klare Kategorien benötigen

Das Wort Solver kann verschiedene Arten von Software beschreiben. Ein Zeitintegrator rückt eine ODE oder halbdiskretisierte PDE vor. Ein spärlicher linearer Solver berechnet die Lösung eines Matrixsystems. Ein neuronaler Operator nähert sich der Zuordnung zwischen PDE-Eingängen und -Ausgängen. Ein Optimierungslöser minimiert ein Ziel und erfüllt gleichzeitig die Einschränkungen.

Diese Tools erfordern unterschiedliche Bewertungskriterien. Zeitintegratoren werden üblicherweise durch Fehler-, Laufzeit- und Funktionsbewertungen verglichen. Spärliche Solver erfordern Matrixsammlungen, Speichermessungen, Iterationszahlen und Skalierungsergebnisse. Wissenschaftliche ML-Modelle benötigen Schulungs- und Inferenzmetriken, Generalisierungstests und Vergleiche mit numerischen Referenzlösungen.

Eine Benchmark-Suite ist nur dann nützlich, wenn ihre Problemklasse dem Zweck des Solvers entspricht.

Wichtige Benchmark-Familien

Klärung nicht verifizierter Benchmark-Namen

Informelle Projektnotizen und generierte Forschungsentwürfe beziehen sich manchmal auf Suiten, die als „HIMAS“ oder „Scibase“ bezeichnet werden. Diese Namen sollten ohne eine genaue Veröffentlichung, ein Repository oder eine institutionelle Quelle nicht als etablierte wissenschaftliche Solver-Benchmarks behandelt werden.

Bei der Erörterung der Sparse-Solver-Bewertung ist es sicherer, auf die tatsächlich verwendete Ressource wie HPCG, Suitesparse oder einen dokumentierten Vergleich mit PETSC, Trilinos, Hypre oder Superlu zu verweisen.

PETSC, Trilinos, Hypre und Superlu sind Solver-Bibliotheken und nicht eine kombinierte Benchmark-Suite. Die Forscher können sie mit denselben Matrizen oder PDE-Workloads vergleichen, das Testprotokoll muss jedoch separat definiert werden.

Scimlbenchmarks

scimlbenchmarks bietet reproduzierbare Vergleiche für Differentialgleichungsalgorithmen. Seine Abdeckung umfasst nicht steife und steife Oden, stochastische Differentialgleichungen, differential-algebraische Gleichungen, Randwertprobleme und ausgewählte PDE-Systeme nach räumlicher Diskretisierung.

Das zentrale Bewertungswerkzeug ist das Arbeitspräzisionsdiagramm. Jeder Solver wird mit mehreren Toleranzeinstellungen oder numerischen Konfigurationen ausgeführt. Der gemessene Fehler wird gegen Rechenkosten wie Ausführungszeit, Anzahl der rechten Auswertungen oder eine andere Arbeitsmetrik aufgetragen.

Ein Solver, der näher am unteren linken Bereich des Diagramms erscheint, liefert im Allgemeinen einen geringeren Fehler bei niedrigeren Kosten. Kein einziger Punkt ist ausreichend, da sich die Ranglisten des Solvers ändern können, wenn sich die angeforderte Genauigkeit ändert.

Welche Arbeitspräzisionsdiagramme zeigen

Angenommen, der Solver A ist bei losen Toleranzen schneller, wird aber ineffizient, wenn eine hohe Genauigkeit erforderlich ist. Solver B hat möglicherweise höhere Einrichtungskosten, skaliert jedoch besser, wenn die Toleranz strenger wird. Ein einzelner Laufzeitvergleich würde diese Unterscheidung verbergen.

Die Analyse der Arbeitsgenauigkeit macht den Kompromiss zwischen Genauigkeit und Kosten sichtbar. Es ist besonders nützlich für adaptive Zeitintegratoren, da ihre Schrittzählungen und Funktionsbewertungen von der angeforderten Toleranz abhängen.

sprachübergreifende Vergleiche

SCIML-Benchmark-Sammlungen können Algorithmen umfassen, auf die über verschiedene Software-Ökosysteme zugegriffen wird. Das sprachübergreifende Testen erfordert Sorgfalt, da Wrapper-Overhead, Kompilierung, Speicherzuweisung, Solver-Standardeinstellungen und Fehlerkontrolldefinitionen das Ergebnis beeinflussen können.

Ein fairer Vergleich sollte äquivalente Gleichungen, Anfangsbedingungen, Toleranzen, Ausgabezeiten, Jacobi-Informationen und Stoppkriterien verwenden.

Pdebench für wissenschaftliches maschinelles Lernen

pdebench wurde für maschinelles Lernen entwickelt, an denen PDE-basierte physikalische Systeme beteiligt sind. Es bietet Code, Datensätze, Basismodelle und Bewertungswerkzeuge zum Vergleichen erlernter Surrogate über mehrere Gleichungsfamilien hinweg.

Die zugehörigen Datensätze umfassen Probleme wie Advektion, Burger-Gleichung, Diffusionsreaktionssysteme, Diffusionssorption, komprimierbare Navier-Stokes-Gleichungen, Darcy-Fluss und Flachwasser-Gleichungen.

Die Forscher können die bereitgestellten Daten verwenden, um Fourier-Neuraloperatoren, Faltungsnetzwerke, autoregressive Modelle und andere wissenschaftliche ML-Ansätze zu bewerten, ohne unabhängig jeden Simulationsdatensatz zu generieren.

Was pdebench misst

Die Bewertung eines gelernten PDE-Modells erfordert mehr als einen einzelnen mittleren Quadratfehler. Nützliche Messungen können sein:

• Fehler in einzelnen Zeitschritten
• Rollout-Stabilität mit langem Horizont
• Verstöße gegen das Naturschutzrecht
• Leistung bei nicht sichtbaren Parameterwerten
• Fehler in der Nähe von Grenzen oder scharfen Steigungen
• Schulungs- und Inferenzkosten
• Speicherverbrauch

Der numerische Simulator zur Erstellung eines Trainingsdatensatzes und des gelernten Modells, das sich seiner Ausgabe annähert, führen unterschiedliche Aufgaben aus. Schulungskosten, Datenerzeugungskosten und Inferenzkosten sollten daher separat ausgewiesen werden.

Verwandte SCIML-Datenressourcen

Benchmark-Daten für die PDE-basierte wissenschaftliche ML-Forschung sind auch über die SCIML-Benchmark-Sammlung der Universität Stuttgart auf Darus verfügbar.

Zusätzliche Benchmark-Ausgaben und experimentelle Vergleiche finden Sie unter benchmarks.sciml.ai. Die Forscher sollten die genaue Datensatzversion, das Repository-Commit und die Softwareumgebung aufzeichnen, die in jedem Experiment verwendet wird.

HPCG zur HPC-Systemauswertung

Der High Performance Conjugate Gradients Benchmark wurde als Ergänzung zu High Performance Linpack erstellt. HPL betont dichte lineare Algebra, während HPCG rechnerische und Speicherzugriffsmuster verwendet, die vielen spärlichen wissenschaftlichen Anwendungen näher kommen.

HPCG konstruiert ein mit einem dreidimensionalen Modellproblem verbundenes Sparse-System und wendet Operationen wie die spärliche Matrix-Vektor-Multiplikation, Vektoraktualisierungen, Punktprodukte und Multigrid-vorkonjugierte Gradienten-Iterationen an.

Der Benchmark legt Grenzen in Bezug auf Speicherbandbreite, Kommunikation, Synchronisation und Datenbewegung fest. Diese Faktoren dominieren häufig große spärliche Simulationen, selbst wenn eine Maschine eine sehr hohe theoretische Gleitkommaleistung aufweist.

Was HPCG nicht misst

HPCG sollte nicht als vollständiges Ranking aller spärlichen linearen Löser behandelt werden. Es verwendet einen bestimmten Benchmark-Algorithmus und eine Problemstruktur. Eine Bibliothek, die für unsymmetrische Matrizen, spärliche Direktfaktorisierung, unbestimmte Systeme oder anwendungsspezifische Vorkonditionierung ausgelegt ist, kann durch ein HPCG-Ergebnis nicht fair dargestellt werden.

HPCG ist am nützlichsten zum Vergleichen von Computersystemen oder Implementierungen der vorgeschriebenen Arbeitslast. Eine breitere Löserbewertung erfordert mehrere Matrizen und Problemklassen.

SuiteParse-Matrix-Sammlung

Die Suitesparse-Matrix-Sammlung enthält spärliche Matrizen, die aus realen Anwendungen stammen. Die Sammlung war zuvor als Spärliche Matrix-Sammlung der University of Florida bekannt.

Seine Matrizen stellen Probleme aus der rechnerischen Fluiddynamik, der Strukturanalyse, der Schaltungssimulation, der Optimierung, der Elektromagnetik, der Graphenanalyse und vielen anderen Bereichen dar.

Diese Vielfalt macht SuiteSparse zum Testen nützlich:

• Spärliche direkte Faktorisierung
• Krylov iterative Methoden
• Vorkonditionierer
• Matrix-Neuordnung
• Diagrammpartitionierung
• GPU-Spärliche Kernel
• Speicher- und Speicherformate

Warum echte Matrizen wichtig sind

Eine synthetische Matrix kann eine ausgewählte Größe oder einen Sparsitätsgrad reproduzieren, während sie die strukturellen Eigenschaften fehlen, die ein reales System erschweren. Das Ausfüllen während der Faktorisierung, der Diagonaldominanz, der Symmetrie, der Konditionierung, der Blockstruktur und der Graphenkonnektivität kann das Solver-Verhalten beeinflussen.

Eine gute Suitesparse-Studie sollte nicht nur Matrizen auswählen, die eine Methode bevorzugen. Der Testsatz sollte die Zielanwendung darstellen und klare Ein- und Ausschlussregeln enthalten.

Solver-Bibliotheken und Benchmark-Daten

PETSC, Trilinos, Hypre und Superlu werden häufig im wissenschaftlichen Rechnen verwendet, bieten jedoch unterschiedliche Fähigkeiten.

• PETSC Liefert verteilte Vektoren, Matrizen, Krylov-Methoden, nichtlineare Solver, Zeitintegratoren und Schnittstellen zu externen Paketen.
• Trilinos Enthält Pakete für spärliche Algebra, iterative Methoden, Vorkonditionierung, direkte Solver, nichtlineare Systeme und Multiphysik-Workflows.
• Hypre konzentriert sich auf skalierbare iterative Solver und Multigrid-Vorkonditionierer für große parallele Systeme.
• Superlu bietet eine spärliche LU-Faktorisierung für sequentielle, Multithread- und verteilte Umgebungen.

Ein glaubwürdiger Vergleich sollte äquivalente Matrixformate, Stopptoleranzen, Vorkonditionierereinstellungen, Präzision, Hardwarezuordnung und Konvergenzdefinitionen verwenden.

ASU Mittelmann Benchmarks

Hans Mittelmanns ASU-Benchmark-Site sammelt Testprobleme und Leistungsvergleiche für Optimierungssoftware.

Die breitere Website umfasst mehrere Optimierungskategorien. Die PDE-beschränkte Optimierungssammlung umfasst vollständig diskretisierte elliptische und parabolische Kontrollprobleme, die als AMPL-Modelle dargestellt werden.

Diese Probleme können an nichtlineare Optimierungslöser übermittelt werden, die Ampl unterstützen. Sie sind nützlich, um zu untersuchen, wie Optimierer mit großen Systemen umgehen, in denen die Entscheidungsvariablen und -beschränkungen aus einer diskretisierten PDE entstehen.

Welche PDE-beschränkten Optimierungsmaßnahmen

Ein PDE-beschränkter Optimierungs-Benchmark kann mehr als die Geschwindigkeit der PDE-Lösung bewerten. Es kann auch testen:

• Zielfunktionsreduzierung
• Einschränkung Zufriedenheit
• Optimalität erster Ordnung
• Robustheit gegenüber anfänglichen Vermutungen
• Derivative und hessische Handhabung
• Speichernutzung
• Skalierung, wenn die Diskretisierung verfeinert wird

Diese Tests ersetzen keine normalen PDE- oder spärlichen linearen Solver-Benchmarks. Sie bewerten den kompletten Optimierungs-Workflow.

So wählen Sie den richtigen Benchmark

Entwerfen eines fairen Solver-Vergleichs

Jeder Solver sollte das gleiche mathematische Problem erhalten. Dies umfasst die gleiche Domäne, Mesh, Koeffizienten, Anfangsbedingungen, Randbedingungen, Endzeit und angeforderte Ausgabe.

Wenn Algorithmen unterschiedliche interne Darstellungen verwenden, sollte sich der Vergleich auf ein gemeinsames externes Genauigkeitsmaß konzentrieren. Ein schnelles Ergebnis ist nicht nützlich, wenn es den Zielfehler nicht erfüllt.

Der Benchmark-Bericht sollte aufzeichnen:

• Solver- und Abhängigkeitsversionen
• Compiler- und Optimierungseinstellungen
• CPU-, GPU-, Speicher- und Netzwerkinformationen
• Thread- und Prozesszählungen
• Präzision und Datentyp
• Toleranzen und Stoppbedingungen
• Vorkonditionierungen und Matrix-Neuordnungen
• Aufwärm- und Kompilierungsbehandlung
• Anzahl wiederholter Läufe
• Fehler- und Fehlerdefinitionen

Verwenden Sie mehrere Genauigkeitsstufen

Ein Benchmark, der mit einer Toleranz durchgeführt wird, kann einen irreführenden Gewinner hervorbringen. Einige Methoden haben einen geringen Overhead und funktionieren gut, wenn die Genauigkeitsanforderungen locker sind. Andere werden mit strengeren Toleranzen wettbewerbsfähiger.

Für Zeitintegratoren sollten mehrere relative und absolute Toleranzkombinationen getestet werden. Für iterative lineare Löser sollten Forscher Restdefinitionen melden und untersuchen, ob die Reduktion der algebraischen Residuum dem tatsächlichen Lösungsfehler entspricht.

Arbeitspräzisionsdiagramme, Leistungsprofile und Konvergenzdiagramme liefern mehr Informationen als eine einzelne Timing-Tabelle.

Messen Sie die Einrichtung und die Kosten für wiederholte Lösung

Solver-Kosten enthalten oft mehrere Komponenten:

• Matrixbaugruppe
• Vorkonditionierer-Konstruktion
• Symbolische Faktorisierung
• Numerische Faktorisierung
• Individuelle Lösungszeit
• Datenübertragung
• Ausgabe und Nachbearbeitung

Eine direkte Methode kann hohe anfängliche Faktorisierungskosten verursachen, löst jedoch zusätzliche rechte Seiten schnell. Eine iterative Methode hat möglicherweise niedrigere Einrichtungskosten, erfordert jedoch für jede Lösung viele Iterationen.

Benchmark-Berichte sollten die einmalige Einrichtung von der wiederholten Lösung trennen.

Häufige Benchmarking-Fehler

Ein häufiger Fehler ist der Vergleich von Ergebnissen, die auf verschiedenen Netzen oder mit unterschiedlichen Fehlerzielen generiert wurden. Eine schnellere Berechnung eines gröberen Problems zeigt nicht, dass ein Solver effizienter ist.

Andere häufige Fehler sind:

• Runtime melden ohne Fehler melden
• Auswahl nur günstiger Matrizen
• Verwenden verschiedener Stoppbedingungen
• Ignorieren fehlgeschlagener oder nicht konvergenter Läufe
• Kombinieren von Kompilierung mit Ausführung für nur eine Sprache
• Vergleich von CPU und GPU läuft ohne die Kosten für die Datenübertragung zu dokumentieren
• Verwenden von HPCG zur Bewertung eines nicht verwandten neuronalen PDE-Modells
• Verwenden von Pdebench als Ersatz für spärliches Matrix-Benchmarking
• Nur der schnellste Lauf statt wiederholter Messungen melden
• Fehler beim Veröffentlichen von Skripten und Konfigurationen

A Practical Benchmark Workflow

1. Definieren Sie das wissenschaftliche Problem und den Zielanwendungsfall.
2. Wählen Sie eine Benchmark-Ressource aus, die der Solver-Klasse entspricht.
3. Wählen Sie repräsentative Instanzen, bevor Sie die Löser ausführen.
4. Definieren Sie allgemeine Fehler-, Konvergenz- und Ausfallkriterien.
5. Nehmen Sie Software- und Hardwareumgebungen auf.
6. Testen Sie mehrere Toleranzen, Matrixgrößen oder Netzauflösungen.
7. Separate Einrichtungs-, Lösungs- und Datenübertragungskosten.
8. Wiederholen Sie die Läufe und melden Sie statistische Variationen.
9. Überprüfen Sie Genauigkeit, Robustheit, Speicher und Skalierbarkeit gemeinsam.
10. Veröffentlichen Sie Skripte, Konfigurationsdateien und Rohergebnisse.

Verwandte Anleitungen

• Performance-Profiling und -optimierung für Python-PDE-Solver – Erfahren Sie, wie Sie Laufzeit- und Speicherengpässe identifizieren, bevor Sie Implementierungen vergleichen.
• Mesh-Qualitäts- und Konvergenzstudien: Ein Hands-on-Guide – Überprüfen Sie die Netzverfeinerung und Konvergenzmethoden für faire PDE-Vergleiche.
• Verifikation vs. Validierung in wissenschaftlichen Simulationen — Verstehen Sie, wie sich die numerische Korrektheit unterscheidet aus Übereinstimmung mit physikalischen Beobachtungen.

Schlussfolgerung

Wissenschaftliche Solver-Benchmarks dienen unterschiedlichen Zwecken. ScimlBenchmarks vergleicht Differentialgleichungsalgorithmen durch Fehler und Rechenarbeit. Pdebench bietet standardisierte wissenschaftliche ML-Datensätze und -aufgaben. HPCG misst die Leistung von HPC-Systemen bei einer repräsentativen spärlichen Arbeitslast. SuiteSparse unterstützt umfassende Tests von Sparse-Matrix-Algorithmen unter Verwendung realer Anwendungsdaten. ASU Mittelmann bietet etablierte Optimierungstestprobleme, einschließlich PDE-beschränkter Modelle.

Diese Ressourcen sollten nicht als austauschbar behandelt werden. Der richtige Benchmark hängt davon ab, ob das Ziel ein Zeitintegrator, ein gelernter Ersatz, ein spärlicher linearer Solver, eine Hardwareplattform oder ein Optimierungspaket ist.

Ein glaubwürdiger Benchmark meldet Genauigkeit, Laufzeit, Speicher, Ausfälle, Solver-Einstellungen und Hardwaredetails. Es verwendet identische Probleminstanzen und testet mehr als eine Toleranz oder Auflösung. Ziel ist es nicht nur, den schnellsten Lauf zu identifizieren, sondern zu bestimmen, welche Methode die erforderliche Genauigkeit und Zuverlässigkeit für die beabsichtigte wissenschaftliche Arbeitsbelastung liefert.