Bug 1119469 - OpenBLAS pthread flavour disables OpenMP entirely for everything it gets linked in
OpenBLAS pthread flavour disables OpenMP entirely for everything it gets link...
Status: NEW
: 1119655 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Other
Leap 15.0
x86-64 Other
: P5 - None : Major (vote)
: ---
Assigned To: Dmitry Roshchin
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-12-13 22:42 UTC by Jehferson Mello
Modified: 2019-02-26 22:34 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jehferson Mello 2018-12-13 22:42:17 UTC
TL;DR:

ISSUE: Linking libopenblas_pthreads.so.0 disables OpenMP for the whole application
PROPOSED FIX: Version bump to 0.3.4 (from science/)
TEST: Code snippet below
SCOPE: package libopenblas_pthreads0 version 0.2.20-lp150.5.14-x86_64

DETAILED:

I've been chasing a really nasty bug in our applications at work where, following a switchover from Ubuntu to OpenSUSE, a bunch of our code which was supposed to be accelerated through OpenMP was running on a single thread.

After much pain, I've pinpointed the problem in libopenblas_pthreads.so.0.
If that library gets linked in, OpenMP just gets disabled for the entire application. 

In my attempts to chase down a proper fix, I've found the science/openblas project which builds version 0.3.4 instead of 0.2.20
In that version the problem is just not there so for a temporary fix I've just provided it through our internal repository for custom packages, but the problem is live on upstream.

In our case we're not even using OpenBLAS directly, instead it gets brought in through OpenCV which explicitly links against that particular flavour. I've seen a couple complaints on google regarding Gimp performance on Leap and would wager this could be part of it, as it also uses OpenCV. 

My suggested fix is bumping the OpenBLAS version to 0.3.4, as it seems to be a drop-in replacement. If that is not possible, I'm happy to bang my head against this a little more to see if I can find where this is happening. I've had this before with a different library and it was flat out defining "inline omp_get_num_procs(){return 1;}" if it thought OpenMP wasn't present so I'm guessing it's some form of this somewhere.

The code I've been using to test this is quite simple:

########################

#include "omp.h"
#include <iostream>

int main(void)
{

    std::cout << "OpenMPTest: omp_get_num_procs()   -> " << omp_get_num_procs() << std::endl;
    std::cout << "OpenMPTest: omp_get_num_threads() -> " << omp_get_num_threads() << std::endl;
    std::cout << "OpenMPTest: omp_get_max_threads() -> " << omp_get_max_threads() << std::endl;
}

#######################

And I'm building it through cmake (tested with both gcc7 and clang5)

#######################

cmake_minimum_required(VERSION 3.11)

project(OpenMPTest CXX)

find_package(OpenMP)

add_executable(${PROJECT_NAME} "test.cpp")

target_compile_features(${PROJECT_NAME} PUBLIC cxx_std_14)

target_link_libraries(${PROJECT_NAME} OpenMP::OpenMP_CXX)

find_package(OpenBLAS)
target_link_libraries(${PROJECT_NAME} ${OpenBLAS_LIBRARIES})

#######################


Tweaking the OpenBLAS link to point to specific flavours and switching versions will turn the problem "on or off" depending on whether you are linking the bad version on the main repos.


I've detailed some of my exploration and findings on a thread on the forums and am happy to clarify details as needed:

https://forums.opensuse.org/showthread.php/534152-OpenBLAS-(-openblas_pthreads0-)-disables-OpenMP-for-whatever-it-s-linked-into
Comment 1 Lutz Labusch 2018-12-18 12:13:31 UTC
*** Bug 1119655 has been marked as a duplicate of this bug. ***
Comment 2 Jehferson Mello 2019-02-26 22:34:25 UTC
Any updates on the status of this issue?