Benchmarking von wissenschaftlichen Python-Bibliotheken: Leistung und Genauigkeit

Es gibt keine einzige „beste“ wissenschaftliche Python-Bibliothek. Die richtige Wahl hängt von Ihrer Aufgabe, Ihrer Datenskala und Ihrer Hardware ab. Die Verwendung von Numpy für GPU-Workloads oder JAX für kleine Datenrahmen im Arbeitsspeicher verschwendet die Leistung. Umgekehrt erhöht das Greifen nach Cupy für einfache Array-Mathematik die Komplexität ohne Nutzen. Das wissenschaftliche Python-Ökosystem hat sich in konkurrierende Bibliotheken fragmentiert, die für unterschiedliche Workloads optimiert sind, und zu verstehen, welche Bibliothek Ihr Problem tatsächlich effizient löst, ist der Engpass, den die meisten Forscher niemals ansprechen.

Dieser Artikel enthält umfassende Benchmark-Daten, in denen NumPy, Scipy, JAX, PyTorch, Cupy, Pandas, Polars, Dask und DuckDB über Array-Operationen, Datenverarbeitung, lineare Algebra, GPU-Beschleunigung, Optimierung, Interpolation und Sonderfunktionen hinweg verglichen werden. Jeder Anspruch wird durch veröffentlichte Timing-Messungen aus realen Benchmarks unterstützt.

Schlüssel zum Mitnehmen

• JAX und PyTorch dominieren die Array-Operationen im Maßstab – Die PyTorch-GPU ist bis zu 50 Mal schneller als numpy für elementweise Operationen bei großen Tensoren, aber Numpy bleibt bei kleinen Arrays aufgrund des geringeren JIT- und Versand-Overheads schneller.
• Polars ist der schnellste Datenrahmen im Arbeitsspeicher – Polars ist 5–30 × schneller als Pandas bei realen Workloads und verwendet einen Bruchteil des Speichers. Dask ist bei kleinen bis mittleren Daten langsamer als Pandas und eignet sich nur für verteilte Workloads außerhalb des Speichers.
• Numpy und Scipy haben die gleiche numerische Präzision – beide verwenden BLAS/LAPACK unter der Haube und erzeugen identische Fließkommaergebnisse. Der Unterschied ist die API-Oberfläche: Scipy bietet spezielle Routinen und eine bessere numerische Stabilität für schlecht konditionierte Matrizen.
• Cupy ist ein praktischer Numpy-Port für GPUs – Cupy bietet numpy-kompatible Arrays mit minimalen Code-Änderungen und liefert 10–100-fache Geschwindigkeiten für große Arrays, verursacht jedoch GPU-Speicherübertragungs-Overhead, der es langsamer macht als numpy für Arrays kleiner als ~ 10.000 Elemente.
• Scipy bleibt der Standard für Optimierungs- und Sonderfunktionen: Kein ernsthafter Konkurrent entspricht seiner Abdeckung von scipy.optimize, scipy.special und scipy.interpolate.

Array-Operationen: Numpy vs JAX gegen PyTorch

Array-Operationen sind das Brot und die Butter des wissenschaftlichen Rechnens – elementweise Mathematik, Matrixmultiplikation, FFTs und Sortierung. Hier machen die GPU-Beschleunigung und die JIT-Kompilation ihren dramatischsten Unterschied.

Elementweise Operationen (1M-Elemente, 100 Iterationen)

Quelle: Vincent Rogers umfassender Benchmark für Numpy/JAX/PyTorch über fünf Operationen hinweg.

Die PyTorch-GPU ist für elementweise Operationen auf großen Tensoren ungefähr 50-fach schneller als numpy. JAX-CPU und GPU landen zu im Wesentlichen identischen Zeiten (~ 0,155 s) für diese Workload, was darauf hindeutet, dass die Arrays nicht groß genug sind, damit der GPU-Pfad die XLA-CPU-Kompilierung übertrifft. Dies bedeutet, dass sich der GPU-Vorteil von JAX hauptsächlich in größeren Maßstäben oder rechenintensiven Operationen manifestiert.

Matrixmultiplikation (2000×2000, 50 Iterationen)

Alle fünf Konfigurationen landen innerhalb von 15% voneinander (3,4–4,0 s). Bei der Matrixmultiplikation sind Leistungsunterschiede zwischen den Bibliotheken minimal. BLAS-Implementierungen und optimierte Kernel dominieren, wodurch die Auswahl der Bibliothek weniger wichtig ist als die Hardware- und BLAS-Konfiguration.

Gradientenberechnung (10.000 Elemente, 20 Iterationen)

Die automatische Differenzierung von PyTorch ist 1000 Mal schneller als das Berechnen von Gradienten über endliche Differenz mit Numpy. Dies ist der Unterschied zwischen analytischer Gradientenberechnung und numerischer Approximation – ein grundlegender architektonischer Vorteil für alle, die Optimierungs- oder umgekehrte Probleme ausführen.

FFT (1M-Elemente, 50 Iterationen)

Die PyTorch-GPU ist für FFT ungefähr 43-fach schneller als Numpy. Die JAX-CPU und die GPU konvergieren erneut zu identischem Timing und bestätigen das Muster, das bei elementweisen Operationen gesehen wird. Die FFT von Numpy ist weiterhin kompetent für reine CPU-Workflows, aber GPU-beschleunigte Bibliotheken dominieren im Maßstab.

Sortieren (1M-Elemente, 50 Iterationen)

Beim Sortieren ist die PyTorch-CPU-Implementierung eindeutig am schwächsten – 9,5 × langsamer als die numpy CPU. Dies ist eine spezifische Implementierungsschwäche im CPU-Sortierpfad von PyTorch, keine grundlegende Einschränkung. Die PyTorch-GPU dominiert die Sortierung (0,054 s), aber die PyTorch-CPU ist ein Ausreißer unter allen getesteten Operationen.

Was wir für Array-Operationen empfehlen

Wenn Ihre Arrays 100.000 Elemente überschreiten und Sie über GPU-Zugriff verfügen, verwenden Sie PyTorch-GPU oder JAX-GPU für die elementweise Mathematik, FFT und Sortierung. Wenn Sie eine Gradientenberechnung benötigen (z. B. zur Optimierung oder Sensitivitätsanalyse), ist PyTorchs AutoDiff um Größenordnungen schneller als die manuelle Finite-Differenz.

Für kleine Arrays oder CPU-Umgebungen bleibt Numpy die einfachste und zuverlässigste Wahl. Die Leistungslücke zwischen numpy- und JIT-kompilierten Bibliotheken ist für Arrays mit ~ 10.000 Elementen vernachlässigbar.

Datenverarbeitung: Pandas gegen Polars vs. Dask vs DuckDB

Dataframe-Operationen dominieren den Daten-Wrangling-Workflow in Scientific Python – Filtern, Gruppieren, Aggregieren und Verknüpfen von tabellarischen Simulationsdaten. Die Landschaft hier hat sich seit 2024 dramatisch verändert.

CSV-Operationen bei 10m-Reihen

Quelle: StatusNeo Benchmark für 10-Zeilen-CSV-Operationen.

Polars ist beim Lesen 2,9 × schneller und beim Schreiben 11,6 × schneller als Pandas auf 10 m-Zeilen-CSV. Dask ist beim Schreiben langsamer als Pandas (46,55 s gegenüber 35,32 s) aufgrund der Partitionierung. Das Lesen von Dask entspricht in etwa der Pandas, was bestätigt, dass der Wert von Dask ausschließlich auf einer nicht speicherinternen Skala liegt.

Filterung in großem Maßstab (9 GB CSV, 67 m Zeilen)

Quelle: Codezentrischer Benchmark mit detaillierter Methodik, einschließlich Kalt-/Hot-Läufe und Speicherprofilierung.

Bei großflächiger Filterung mit 67 m Zeilen und 9 GB Daten verbraucht Polars mit Lazy + Streaming ~ 0,5 GB Spitzenspeicher. Pandas lädt den gesamten Datensatz (~ 14 GB), und DuckDB (eine SQL-Engine) verwendet ~0,3 GB. Polars entspricht fast DuckDB auf heißen Läufen, obwohl DuckDB eine SQL-Datenbank ist – die Lücke wird auf ~ 100 MB Peak-Speicherunterschied reduziert.

Sortiervorgänge

Polars nutzt die Parallelisierung und das Speicherlayout von Arrow, um Beschleunigungen zu liefern. Pandas können bei Sortiervorgängen grundsätzlich nicht übereinstimmen. Single-Thread-Pandas sind ein gut dokumentierter Engpass.

Wann wählen Sie welche DataFrame-Bibliothek

Was wir für die Datenverarbeitung empfehlen

Für die Datenverarbeitung im Arbeitsspeicher Polare verwenden. Die Beschleunigungen (5–30 ×), Speichereinsparungen und Energieeffizienz sind real und dokumentiert. Polars mit Lazy + Streaming entspricht der Ausführungszeit von DuckDB auf heißen Läufen und bewahrt gleichzeitig die ergonomische Pandas-ähnliche Ergonomie.

DASK eignet sich nur für verteilte Workloads außerhalb des Speichers. Wenn Ihr Datensatz in den Speicher passt, ist das DASK langsamer als Polars und oft langsamer als Pandas aufgrund von Partitionierung. Der StatusNeo-Benchmark zeigt das Schreiben von CSV in 46,55 s gegenüber Pandas 35,32 s explizit – Dask ist keine Leistungsoptimierung für In-Memory-Workloads.

Lineare Algebra: numpy vs scipy

In der linearen Algebra teilen sich beide Bibliotheken das gleiche BLAS / LAPACK-Backend, unterscheiden sich jedoch hinsichtlich der API-Oberfläche, der numerischen Stabilität und der speziellen Routinen.

Geteilte Präzision

Sowohl numpy.linalg als auch scipy.linalg verwenden BLAS/LAPACK unter der Haube. Das bedeutet:

• identische Gleitkomma-Präzision (Float32 und Float64)
• identische Ergebnisse für die gleichen Operationen, wenn beide Bibliotheken dieselbe Routine unterstützen
• Kein numerischer Vorteil für grundlegende Operationen inhärent

Leistung nach Array-Größe

Numpy ist schneller für grundlegende Operationen auf kleinen bis mittleren Arrays. Scipy bietet spezielle Routinen an, die Numpy nicht anbietet: Schur-Zerlegungen, LQ-Zerlegungen, polare Zersetzungen, bandförmige Matrixsolver und spärliche iterative Solver (GMRES, BICGSTAB).

Numerische Stabilität

Die scipy.linalg von Scipy behandelt schlecht konditionierte Matrizen mit umfassenderen Zustandsprüfungs- und Fallback-Strategien. Das Submodul scipy.sparse.linalg vermeidet katastrophale Präzisionsverluste für große Sparse-Systeme – eine kritische Unterscheidung für PDE-Solver und Finite-Elemente-Methoden.

Was wir für lineare Algebra empfehlen

Verwenden Sie numpy.linalg für grundlegende Operationen auf kleinen bis mittleren Arrays., bei denen die Geschwindigkeit zählt und die Bedingungsnummern gut sind. Verwenden Sie scipy.linalg, wenn Sie spezielle Zerlegungen, spärliche Solver oder numerische Stabilität für schlecht konditionierte Matrizen benötigen. Sie haben das gleiche BLAS / LAPACK-Backend, sodass Sie sich für die Oberfläche und Sicherheit von API entscheiden, nicht für die Präzision.

GPU-Beschleunigung: Cupy gegen PyTorch gegen Jax

Die GPU-Beschleunigung wird für wissenschaftliche Python immer zentraler. Die drei Hauptoptionen – Cupy (Numpy-kompatible GPU), PyTorch-GPU und JAX-GPU – haben jeweils unterschiedliche Kompromisse.

Array-Größe gegen Leistung

Cupy bietet numpy-kompatible GPU-Arrays mit 10–100 × Speedups für große Arrays. Bei Arrays mit weniger als 10.000 Elementen macht der GPU-Speicherübertragungs-Overhead jedoch Cupy langsamer als numpy CPU. Die Beschleunigung skaliert mit Array-Größe – dies ist ein grundlegender Kompromiss der GPU-Beschleunigung.

Architekturspezifische Leistung

Quelle: ARXIV-Papier, der Cupy vs PyTorch auf der Trichterarchitektur vergleicht.

PyTorch übertrifft Cupy um etwa 20% auf H100-GPUs, mit ähnlicher Leistung auf GH200. Die 10-fache Beschleunigung gegenüber der CPU für große Operationen ist architektonisch konsistent.

Was wir für die GPU-Beschleunigung empfehlen

Wenn Sie vorhandenen Numpy-Code portieren und minimale Änderungen wünschen, verwenden Sie Cupy. Es ist ein Drop-in-Ersatz mit der bekannten numpy Syntax. Wenn Sie die beste rohe GPU-Leistung benötigen und neuen Code erstellen, verwenden Sie PyTorch-GPU für moderne Architekturen. Wenn Sie neben der GPU-Beschleunigung eine automatische Differenzierung benötigen, verwenden Sie JAX-GPU.

Bei Problemen mit weniger als 10.000 Elementen bleiben Sie bei der CPU-Nummern – der GPU-Übertragungsaufwand wird nicht amortisiert.

Optimierung, Sonderfunktionen und Interpolation

Dies ist Scipys unbestrittenes Gebiet. Kein ernsthafter Konkurrent entspricht seiner Berichterstattung.

scipy.optimieren

scipy.optimize bietet eine umfassende Suite: minimize, least_squares, Root-Finding-Methoden (Brent, Newton) und eingeschränkte Optimierung. Die API ist ausgereift, gut dokumentiert und umfassend getestet.

sciPy.Special

scipy.special bietet Bessel-Funktionen, Gamma-Funktionen, Fehlerfunktionen und Dutzende von speziellen mathematischen Funktionen, die für die Computational Science verwendet werden. Diese Routinen sind numerisch optimiert und sowohl in skalaren als auch in vektorisierten Formen verfügbar.

scipy.interpolate

scipy.interpolate bietet interp1d, RegularGridInterpolator, CubicSpline und radiale Basisfunktionsinterpolatoren. Beachten Sie das gut dokumentierte Leistungsproblem: RegularGridInterpolator ist 10–1000× langsamer als frühere Implementierungen für lineare und kubische Interpolationsmodi. Dies ist ein bekanntes Scipy-Problem (Github #18010).

Was wir zur Optimierung und Interpolation empfehlen

scipy verwenden: Bei gleichwertiger Abdeckung gibt es keine praktikable Alternative. Achten Sie bei RegularGridInterpolator auf das Problem der kubischen/linearen Leistung und berücksichtigen Sie Alternativen wie scipy.interpolate.CubicSpline für 1D-Daten oder scipy.interpolate.RBFInterpolator für gestreute Daten, wenn die Leistung kritisch ist.

Loop-basierte Berechnung: NUMBA vs JAX JIT

Python-Schleifen sind bekanntermaßen langsam. Numba und JAX beheben dies durch JIT-Kompilierung, jedoch mit unterschiedlichen Kompromissen.

sequentielle Loop-Leistung

NUMBA liefert 5–15-fache Geschwindigkeitsüberschreitungen für sequentielle Schleifen. Der erste Lauf enthält JIT-Kompilierungs-Overhead (0,1623 s für den ersten Lauf), aber die nachfolgenden Läufe sind schnell (0,0704 s).

vektorisiertes Maximum über 3000 × 3000 Gitter

JAX bietet die beste JIT-kompilierte Leistung (0,0004 s). Das vmap von JAX vermeidet Zwischenarrays und bietet sowohl Geschwindigkeit als auch Speichereffizienz. Numba mit prange liefert 0,0328 s auf einem 3000×3000-Raster – eine 7,7-fache Beschleunigung über Numpy mit Parallelisierung.

Was wir für die Schleifenberechnung empfehlen

• JAX JIT ist die schnellste Option (0,0004 s vs Numpy 0,2535 s) und verwendet vmap, um Zwischenarrays zu vermeiden. Am besten für neue Projekte oder wenn Sie Code umstrukturieren können.
• Numba mit Prange bietet das beste Lesbarkeits-/Leistungsverhältnis (0,0328 s) und kompiliert zu Maschinencode mit minimalen Änderungen des vorhandenen Numpy-Codes. Am besten zum Portieren von vorhandenem schleifenlastigen Code.
• Numpy ist für Loops am einfachsten, aber am langsamsten. Verwenden Sie nach Möglichkeit vektorisierte Operationen; Fällt auf NUMBA zurück, wenn eine Vektorisierung unmöglich ist.

Die zusammengesetzte Entscheidungsmatrix

Das wissenschaftliche Python-Ökosystem ist durch Design fragmentiert. Jede Bibliothek zeichnet sich durch bestimmte Arbeitslasten aus. Verwenden Sie diese Matrix, um das richtige Werkzeug auszuwählen:

Wann wählen Sie X vs Y

numpy vs sciPy

Wählen Sie Numpy für grundlegende Array-Operationen, kleine bis mittlere lineare Algebra und wenn Sie eine möglichst einfache Abhängigkeit benötigen. Wählen Sie scipy, wenn Sie spezielle Löser (Banded Matrices, spärliche iterative Methoden), numerische Stabilität bei schlecht konditionierten Problemen oder Funktionen außerhalb der Numpy-API benötigen.

Polars gegen Pandas

Wählen Sie Polars für alle Datenverarbeitung im Arbeitsspeicher, bei denen Leistung und Speichereffizienz wichtig sind. Wählen Sie Pandas, wenn Sie die Ökosystemkompatibilität benötigen (z. B. eine spezifische Bibliothek, die nur Pandas-Datenrahmen unterstützt) oder mit kleinen bis mittleren Datensätzen arbeiten, bei denen die Geschwindigkeitsdifferenz vernachlässigbar ist.

Cupy vs PyTorch GPU

Wählen Sie Cupy, wenn Sie eine numpy-kompatible Syntax wünschen und vorhandenen Code migrieren. Wählen Sie PyTorch GPU, wenn Sie die beste RAW-Leistung auf moderner NVIDIA-Hardware benötigen und neuen Code erstellen.

Jax gegen Numba

Wählen Sie JAX aus, wenn Sie die schnellstmögliche Leistung benötigen (0,0004 s vs Numba 0,0328 s) und bereit sind, Code um XLA-Zusammenstellung und vmap neu zu strukturieren. Wählen Sie NUMBA, wenn Sie minimale Codeänderungen, gute Lesbarkeit und eine sanftere Lernkurve benötigen.

Speichernutzung und Energieeffizienz

Der Speicher-Fußabdruck ist für die Reproduzierbarkeit und für die Ausführung von Simulationen auf eingeschränkter Hardware wichtig.

• Pandas Lädt ganze Datensätze in den Speicher (~14 GB für 67M Zeilen).
• Polars mit Lazy + Streaming verwendet ~ 0,5 GB Spitzenspeicher für denselben Datensatz.
• DuckDB Verwendet ~0,3 GB Spitzenspeicher, erfordert jedoch SQL-Syntax.

Quelle: Codezentrischer Benchmark mit detaillierter Speicherprofilierung.

Polars verbraucht bei großen Datensätzen ungefähr 8 × weniger Energie als Pandas. Dies ist für nachhaltigkeitsorientierte Forscher und für die rechnerische Effizienz in großem Maßstab konsequent.

Numerische Präzision und Stabilität

Alle Benchmarked-Bibliotheken verwenden Gleitkomma-Arithmetik IEEE 754 mit identischer Präzision. Die Hauptunterscheidung ist die numerische Stabilität – wie gut eine Bibliothek mit schlecht konditionierten Matrizen, nahezu singulären Systemen und Grenzfalleingaben umgeht.

• scipy bietet umfassendere Zustandsprüfungen, Fallback-Strategien und spezialisierte Routinen für numerisch herausfordernde Probleme.
• Numpy delegiert direkt an BLAS/LAPACK, was sich hervorragend für gut konditionierte Probleme eignet, aber weniger defensiv.
• JAX und PyTorch verwenden unterschiedliche Gleitkommakonventionen (JAX ist in vielen Kontexten standardmäßig float32, PyTorch standardmäßig float64). Überprüfen Sie immer die DType-Konsistenz.
• Cuppy spiegelt das Gleitkommaverhalten von Numpy wider, jedoch mit GPU-Beschleunigung.

Für Forschungssimulationen, bei denen numerische Reproduzierbarkeit unerlässlich ist, dokumentieren Sie immer die Gleitkommagenauigkeit und validieren Sie die Ergebnisse in Bibliotheken, wenn möglich.

Was wir empfehlen: Praktische Anleitung

Folgendes würde ich für einen typischen Forschungsworkflow wählen:

1. Array-Operationen und GPU-Beschleunigung: PyTorch-GPU für rohe Geschwindigkeit, JAX-GPU für Autodiff, Cupy für numpy-kompatible GPU ohne Refactoring.
2. Datenverarbeitung: Polars mit Lazy + Streaming für alle Arbeitsabläufe im Arbeitsspeicher. Dask nur für die dezentrale Berechnung außerhalb des Speichers.
3. Lineare Algebra: numpy für grundlegende Operationen; SciPy für spezielle Routinen und numerische Stabilität.
4. Optimierung, Sonderfunktionen, Interpolation: scipy. Es gibt keinen Konkurrenten mit gleicher Deckung.
5. Schleifenberechnung: NUMBA zum Portieren von vorhandenem Code; JAX JIT für neuen Code, bei dem maximale Leistung wichtig ist.

Die richtige Bibliothek hängt von Ihrer spezifischen Aufgabe, Skalierung und Hardware ab. Ich empfehle, die Bibliotheken, die für Ihren Workflow von Bedeutung sind, anhand von repräsentativen Daten vor dem Commit zu vergleichen. Eine 2-stündige Benchmarking-Sitzung kann Monate iterativer Optimierung einsparen.

Verwandte Anleitungen

• Leistungsprofilerstellung und -optimierung für Python-PDE-Solver — Erfahren Sie, wie Sie Python-PDE-Solver verwenden cProfile, Line_Profiler und Numba JIT.
• Benchmark-Suiten für wissenschaftliche Solver: SCIML, DOE Sparse-Solver und ASU Mittelmann — Vergleichen Sie etablierte Solver-Benchmark-Ressourcen über ODE, PDE, spärliche lineare Algebra und Optimierungsdomänen.
• Moose vs Prismen-PF gegen OpenPhase — Führen Sie Computational Materials Science Frameworks für die Phasenfeldsimulation.

Letzte Gedanken

Das wissenschaftliche Python-Ökosystem bietet leistungsstarke Tools, aber keine einzige Bibliothek zeichnet sich durch alles aus. Das Verständnis der Leistungs- und Genauigkeitskompromisse zwischen NumPy, Scipy, Jax, PyTorch, Cupy, Polars, Pandas, Dask und DuckDB ist für ein effizientes wissenschaftliches Rechnen von entscheidender Bedeutung. Prüfen Sie Ihren spezifischen Arbeitsaufwand, messen Sie die tatsächliche Leistung und wählen Sie die Bibliothek aus, die die erforderliche Genauigkeit innerhalb Ihres Rechenbudgets liefert.

Wenn Sie Hilfe bei der Auswahl und Optimierung von wissenschaftlichen Python-Bibliotheken für Ihren spezifischen Forschungsworkflow benötigen, bieten wir Ihnen Beratungsdienstleistungen, die Sie durch die Auswahl von Bibliotheken, Leistungsprofile und Optimierungsstrategien, die auf Ihre Rechenprobleme zugeschnitten sind, unterstützen. Kontaktieren Sie unser Team, um Ihr Projekt zu besprechen.

Referenzen und Quellen

1. Numpy/JAX/PyTorch-Benchmark von Vincent Roger – Umfassender Vergleich über fünf Operationen im kleinen und großen Maßstab mit Hardwarespezifikationen und Methodenhinweisen. Benchmark Quelle
2. Quantecon Numpy/Numba/JAX-Vergleich – Benchmark-Vorlesung zum Vergleich von Numpy, Numba und JAX mit expliziten Timing-Daten für vektorisierte und sequentielle Operationen. Benchmark-Quelle
3. Pythonalchemist Polars/Pandas 2026 Benchmark – Real-Workload-Vergleich zeigt, dass Polars 5–30 × schneller sind als Pandas mit wachsender Lücke, wenn die Daten wachsen. Benchmark-Quelle
4. Codecentric DuckDB/DataFrame Benchmark — 9 GB CSV-Benchmark mit Kalt-/Hot-Läufen, Speicherprofilierung und Polars-Team-Feedback. Benchmark-Quelle
5. StatusNeo Dataframe Battle — CSV-Operationen mit 10 m-Zeile: Polars, Pandas, Dask-Vergleich. Benchmark Quelle
6. JAX-Dokumenten-Benchmarking – Offizielle JAX-Benchmarking-Dokumentation mit genauem Timing auf der GPU. Benchmark-Quelle
7. ArXIV-Papier: Cupy vs PyTorch auf Hopper – GPU-Benchmark Vergleich von Cupy und PyTorch auf H100- und GH200-Architekturen. Benchmark-Quelle
8. CERN-Seminar: Wissenschaftliches Python-Substrat (Ralf Gommers) — Analyse von Leistungsmustern in wissenschaftlichen Python-Bibliotheken in allen Forschungseinrichtungen. Seminarquelle
9. Numpy vs Scipy Lineare Algebra (Github # 23829) – Community-Diskussion über Numpy vs Scipy lineare Algebra-Leistung und -stabilität. GitHub #23829
10. Scipy Regular GridInterpolator Performance (GitHub #18010) – Bekanntes Problem, das kubische/lineare Interpolationsleistungsregression dokumentiert. GitHub #18010
11. Polars Offizieller Vergleich – Offizielle Polars-Dokumentation zum Vergleich von Polars mit Dask, DuckDB und Spark. Polarvergleichsdokumente
12. JAX-Diskussion: „Ist JAX schneller als numpy?“ – GitHub-Diskussion erklärt die eifrige CPU-Overhead und JIT-kompilierte Leistung. JAX GitHub Diskussion
13. SCIPY-Dokumentation — Lineare Algebra — Offizielle Dokumentation für scipy.linalg und scipy.sparse.linalg. scipy.linalg-Dokumente
14. SCIPY-Dokumentation — Sonderfunktionen — Offizielle Dokumentation für scipy.special. Scipy.Special Docs
15. SCIPY-Dokumentation — Interpolation — Offizielle Dokumentation für scipy.interpolate. Scipy.Interpolate Docs