DAXPY outperforms DSCAL in multi-threaded environments
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- c
- Bereich
- performance
Rechercherichtung
Beginne damit, die gemeldeten dscal- und daxpy-Laufzeiten mit OPENBLAS_NUM_THREADS auf 1 und 16 gesetzt für einen Vektor der Länge 80.000 zu reproduzieren. Vergleiche die Ausführungspfade von dscal und daxpy und dokumentiere, warum sich ihr Verhalten bei mehreren Threads unterscheidet; abgeschlossen ist die Aufgabe, wenn die Abweichung erklärt ist und jede Änderung mit beiden Thread-Einstellungen verifiziert wurde.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Issue Description:
I'm observing a significant performance disparity between dscal and daxpy when performing vector-scalar multiplication on an Intel(R) Xeon(R) Platinum 8378C CPU @ 2.80GHz. My code involves the operation y=ax, where x is a vector of length 80,000.
Observed Behavior:
Despite setting the OPENBLAS_NUM_THREADS environment variable to either 1 or 16, the execution time for dscal remains unchanged, indicating no utilization of multiple cores.
However, when I replace dscal with an equivalent operation using daxpy, specifically y=(a−1)x+x (having a loss in precision), I observe a multi-fold performance improvement in the multi-core scenario.
Problem:
Given that dscal and daxpy have very similar computational patterns, I'm seeking to understand why there's such a substantial difference in their multi-core performance. This behavior suggests that dscal is not effectively leveraging the available CPU cores, unlike daxpy.
- Vorherrschende Sprache
- C
- Sterne
- 7.6k
- Forks
- 1.7k
- Ø Merge
- 1 T. 6 Std.
- Gemergte PRs (30 T.)
- 46
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus OpenMathLib/OpenBLAS
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
OpenMathLib/OpenBLAS#6069 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Missing cgroup awarenessOffen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100
OpenMathLib/OpenBLAS#6059 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
OpenMathLib/OpenBLAS#6029 · 21 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
OpenMathLib/OpenBLAS#6028 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
OpenMathLib/OpenBLAS#6005 · 21 Kommentare · 2 Reaktionen ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in OpenMathLib/OpenBLAS
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
trezor/trezor-firmware#7997 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Maintainer antworten meist innerhalb von 1 Tag
-
area/ysql kind/bug priority/medium status/awaiting-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
yugabyte/yugabyte-db#34415 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 78/100
KhronosGroup/OpenCL-Headers#318 ·
-
Build failure: mumbleOffen0.kind: build failure
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
Maintainer antworten meist innerhalb von 1 Tag