Alpaka: Visual Studio 2017 15.9 (regression): OpenMP not working in variadic templates

[BenjaminW3]

[BenjaminW3]

Our internal sanity check is triggered saying: The OpenMP 2.0 runtime did not use the number of threads that had been required!

[sbastrakov]

This is just a guess, ofc the reason may be completely unrelated.

Strictly speaking, the failing check actually does not always have to hold. According to the spec (page 9 in the internal numbering, paragraph from line 28), in case the requested number in the #pragma omp parallel num_threads(...) exceeds the number available on the system, the behaviour is implementation-defined. So it is possible the CI system (or due to our configuration) does not provide enough resources and this check fails.

[BenjaminW3]

Yes, I know that this is possible. Therefore we added the check because the result would be invalid in case the runtime used a different number of threads.
I was able to reproduce this locally and added a check for omp_in_parallel which always returns false for both OpenMP 2.0 backends. So there seems to be something wrong with the Windows OpenMP build.

[sbastrakov]

@BenjaminW3 sure, I see the point of that. But what if due to some unfortunate configuration we request more threads than the system supports (dunno, have a hard time imagining that myself).

Btw maybe add info about the requested and actual number of threads to the exception message?

[ax3l]

Yes, the situation in travis: more physical cores (N>2) "visible" than accessible (2). Could confuse OpenMP startup. Maybe we just export OMP_NUM_THREADS to e.g. 2?

[sbastrakov]

Don't we do it already? iirc that's the standard travis recommendation for OpenMP-enabled codes.

Edit: I meant not that I'm sure we do it already (currently I don't know that), but I'm sure we should do it.

[BenjaminW3]

@sbastrakov found the reason and reported it to microsoft: https://developercommunity.visualstudio.com/content/problem/426580/c-variadic-template-function-incorrectly-interacts.html

[ax3l]

Can you please update the PR description with the known failing/working VS versions as long as we still know them? :)

[sbastrakov]

For now I only know that the bug is present in VS 15.9.3 (my version), but not present in VS 15.8.6. However, I do not currenty have access to VS 15.8.6 and only know my mini-app works there, but alpaka was not tested.

[sbastrakov]

Update: the latest version 15.9.5 also has this buggy behaviour.

[ax3l]

Hm, upstream MSVC does not seem to have decent test coverage, from what it bugs out in releases during the last years.

[sbastrakov]

Now I'm a bit puzzled. The tech support suggested removing /permissive- flag (enabled by default since VS 15.5) as a workaround and for my mini-app this does indeed make it work properly. It seems to me we set this flag here.

However, here is the puzzling part. After configuring alpaka on my machine this flag is somehow already disabled (don't understand why, guess I am missing smth simple). But the problem is still present anyways even with disabled flag. Although, again, for the mini-app disabling removes the effect.

[BenjaminW3]

Could all the @ComputationalRadiationPhysics/alpaka-developers who have a microsoft account please upvote this issue?

[BenjaminW3]

"A fix for this issue has been internally implemented and is being prepared for release. We’ll update you once it becomes available for download."

So it will finally be fixed in one of the next VS updates!

[sbastrakov]

Let's hope. Thanks for info @BenjaminW3

[sbastrakov]

They just updated the status to "A fix for this issue is now available in preview release. Try out the fix by installing the most recent preview from https://visualstudio.microsoft.com/vs/preview/."
Haven't tried it yet.