OpenMathLib / OpenMathLib/OpenBLAS
Make ICOPY_OPERATION threaded?
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 7.6k
- Forks
- 1.7k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 42
Description
In some multi-threaded versions of OpenBLAS, the ICOPY_OPERATION (packing for A) seems to take 6-13X more time than the actual KERNEL_OPERATION(s). Is it possible to make this operation multi-threaded?
/* Copy local region of A into workspace */
START_RPCC();
ICOPY_OPERATION(min_l, min_i, a, lda, ls, m_from, sa);
STOP_RPCC(copy_A);
48.09% pt_main_thread libomp.so [.] bool __kmp_wait_template<kmp_flag_64<false, true>, true, false, true>(kmp_info*, kmp_flag_64<false, true>*, void*)
18.23% pt_main_thread libgomp.so.1.0.0 [.] do_wait
9.01% pt_main_thread libopenblasp-r0.3.27.dev.so [.] sbgemm_incopy_POWER10
2.85% pt_main_thread libopenblasp-r0.3.27.dev.so [.] sbgemm_kernel_POWER10
1.33% pt_main_thread libopenblasp-r0.3.27.dev.so [.] inner_thread
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the ICOPY_OPERATION call in the shown packing path and reviewing the supplied profiling data for sbgemm_incopy_POWER10, thread waits, and KERNEL_OPERATION. Determine whether the packing operation can be threaded without conflicting with the existing parallel work; done means a validated approach with benchmark evidence showing the packing bottleneck is addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100