Inquiry and Suggestions Regarding OpenBLAS Code Flow with OpenMP
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 20/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- c
- 領域
- hpc, performance
調査の方向性
まず、driver/level3/level3_thread.c の gemm_driver と、driver/others/blas_server_omp.c の exec_blas および inner_thread を追跡します。キューのパーティション数より少ない OpenMP スレッド数で報告されたデッドロックを再現し、その後、ロック処理とビジーウェイトの経路を比較します。完了の条件は、確認済みの説明と、範囲が明確な同期処理の変更またはドキュメントによる対応が得られることです。
索引モデルが issue の本文から書いたものです。
説明
Hello,
I've been delving into the OpenBLAS codebase, specifically focusing on the gemm_driver function in level3_thread.c with the #USE_OPENMP=1 flag enabled. I've come across a section in the code where a lock is used in the Pthreads and Win32 backend before initializing and assigning the blasqueue. The lock is released only after the exec_blas call is completed.
My current understanding is :
- In the case of Pthreads The thread pool is initialized (POSIX), and when a BLAS call is made, the thread pool is utilized to execute it, after which the threads go back to sleep. The use of locks ensures that only one exec_blas call can be executed at a time.
- If I use a thread pool with
No_of_threads < nthreads(number of queue partitions) defined in level3_thread.c, I encounter a deadlock within the inner_threads function. - There seems to be significant busy-waiting (NOP) inside the inner_thread function call for thread synchronization.
I have a few questions and want to seek suggestions from the community:
-
I noticed that OpenMP locking mechanisms like omp_set_lock are not used, and instead, busy-waiting is implemented inside the exec_blas function in blas_server_omp.c using max_parallel_number. Could you please provide insights into this choice?
-
The inner_thread function appears to encounter deadlock when used with fewer threads. I tested this in OpenMP by creating a parallel region inside exec_blas in line 437 - blas_server_omp.c with a fixed number of threads less than nthreads. Could you shed some light on the reasons behind this behavior?
-
Considering the busy-waiting in the code, have there been considerations for putting threads to sleep or employing other synchronization methods to enhance efficiency?
I would appreciate clarification on these points.
- 主要言語
- C
- スター
- 7.6k
- フォーク
- 1.7k
- 平均マージ
- 1日 3時間
- マージ済み PR(30日)
- 42
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
OpenMathLib/OpenBLAS のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
OpenMathLib/OpenBLAS#6029 · コメント 21 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
OpenMathLib/OpenBLAS#6028 · コメント 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
OpenMathLib/OpenBLAS#6005 · コメント 21 件 · リアクション 2 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
OpenMathLib/OpenBLAS#5930 · コメント 2 件 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
OpenMathLib/OpenBLAS#5870 · コメント 4 件 ·
OpenMathLib/OpenBLAS の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
zephyrproject-rtos/zephyr#119726 ·
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
BasedHardware/omi#15320 ·
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
FujiNetWIFI/fujinet-firmware#1649 · コメント 2 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
HarbourMasters/Shipwright#7229 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
riscv-software-src/riscv-isa-sim#2435 · コメント 1 件 ·