DAXPY outperforms DSCAL in multi-threaded environments
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- c
- Ambito
- performance
Direzione di ricerca
Inizia riproducendo i tempi riportati di dscal e daxpy con OPENBLAS_NUM_THREADS impostato su 1 e 16 su un vettore di lunghezza 80.000. Confronta i percorsi di esecuzione di dscal e daxpy e documenta perché il loro comportamento multithread differisce; il lavoro è completato quando la discrepanza è spiegata e qualsiasi modifica è stata verificata con entrambe le impostazioni dei thread.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C
- Stelle
- 7.6k
- Fork
- 1.7k
- Merge medio
- 1g 3h
- PR unite (30g)
- 42
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di OpenMathLib/OpenBLAS
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
OpenMathLib/OpenBLAS#6029 · 21 commenti ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
OpenMathLib/OpenBLAS#6028 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
OpenMathLib/OpenBLAS#6005 · 21 commenti · 2 reazioni ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
OpenMathLib/OpenBLAS#5930 · 2 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
OpenMathLib/OpenBLAS#5870 · 4 commenti ·
Tutte le issue di OpenMathLib/OpenBLAS
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
zephyrproject-rtos/zephyr#119726 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
api7/lua-resty-saml#63 ·
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
BasedHardware/omi#15320 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 commenti ·