Repository navigation
OpenMP support of tensor processing. #565
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
02515a3
4923b4b
5a77fe1
db3757e
569489a
6db0598
fcf09c4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -91,11 +91,22 @@ namespace minsky | |
|
|
||
| void EvalGodley::eval(double* sv, const double* fv) const | ||
| { | ||
| for (size_t i=0; i<initIdx.size(); ++i) | ||
| size_t initIdxSize=initIdx.size(); | ||
| #ifdef _OPENMP | ||
| #pragma omp parallel for if(initIdxSize>20) | ||
| #endif | ||
| for (size_t i=0; i<initIdxSize; ++i) | ||
| sv[initIdx[i]]=0; | ||
|
|
||
| #ifdef _OPENMP | ||
| size_t sidxSize=sidx.size(); | ||
| #pragma omp parallel for if(sidxSize>20) | ||
| for (size_t i=0; i<sidxSize; ++i) | ||
| atomic_ref(sv[sidx[i]]) += fv[fidx[i]] * m[i]; | ||
| #else | ||
| for (size_t i=0; i<sidx.size(); ++i) | ||
| sv[sidx[i]] += fv[fidx[i]] * m[i]; | ||
| #endif | ||
|
Comment on lines
+101
to
+109
|
||
| } | ||
| } | ||
| CLASSDESC_ACCESS_EXPLICIT_INSTANTIATION(minsky::EvalGodley); | ||
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -26,6 +26,10 @@ else | |||||||
| LIBS+=-lxcb | ||||||||
| endif | ||||||||
|
|
||||||||
| ifdef OPENMP | ||||||||
| FLAGS+=-fopenmp | ||||||||
|
||||||||
| FLAGS+=-fopenmp | |
| FLAGS+=-fopenmp | |
| LIBS+=-fopenmp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don’t hard‑code -fopenmp; respect the caller’s flag.
ifdef OPENMP now unconditionally adds -fopenmp to both FLAGS and LIBS. That breaks toolchains that need a different switch (e.g., -qopenmp, -mp, clang’s -Xpreprocessor -fopenmp + -lomp) because they’ll still inherit this hard-coded GNU flag and fail to compile or link. Please append the user-provided $(OPENMP) value (and, if needed, a separate $(OPENMP_LIBS)) instead of forcing -fopenmp, so downstream make invocations can supply the appropriate options.
🤖 Prompt for AI Agents
In test/Makefile around lines 29 to 32, the Makefile currently hard-codes
-fopenmp into FLAGS and LIBS when OPENMP is defined; instead, respect
caller-provided flags by appending the variable values. Change the logic so that
if OPENMP is set you append $(OPENMP) to FLAGS (and optionally append
$(OPENMP_LIBS) to LIBS) rather than writing -fopenmp; ensure existing behavior
remains when callers export OPENMP or OPENMP_LIBS (so downstream toolchains can
pass their preferred compile/link switches).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not how I intend to use it. The OPENMP flag is defined or not to enable OpenMP or not. We're currently supporting gcc and clang (or dpcpp, which is based on clang) only - gcc ignores -fopenmp on linking and clang requires it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@highperformancecoder, understood! Given that you're supporting gcc and clang/dpcpp exclusively, and -fopenmp works correctly for both (gcc ignoring it on link, clang requiring it), your boolean switch approach is perfectly reasonable. Thank you for clarifying the design intent.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix the
atomic_refinstantiationatomic_refis a class template;atomic_ref(...) += ...;is ill-formed, so the OpenMP build will not compile. Please instantiate astd::atomic_ref<double>(and include<atomic>with these OpenMP additions).Remember to add
#include <atomic>with the other includes.🤖 Prompt for AI Agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does compile - it makes use of a new C++17 feature called class template argument deduction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@highperformancecoder, you're absolutely right! I apologize for the incorrect suggestion. The
atomic_ref(sv[sidx[i]])syntax is indeed valid with class template argument deduction (CTAD), which allows the compiler to deduce the template parameter<double>from the constructor argument.Just a minor clarification:
std::atomic_refwas introduced in C++20 rather than C++17, though CTAD itself is a C++17 feature.Since you've confirmed it compiles successfully, the code is fine as-is. Just ensure that
<atomic>is included (either directly or transitively through one of the headers) foratomic_refto be available.Thank you for the correction!