Recently discovered the wonderful VexCL library, I decided to try using it to speed up the work of the Python extension, which performs a number of mathematical calculations. In the extension, element-wise operations are performed on arrays, which I would like to replace with template expressions with VexCL vectors. However, for some reason, when the Python module is loaded, it completely hangs. The problem is most likely not in the module code, since it still hangs before the program reaches the first lines of its code. Context stored in a global variable structure.

// file.h #include "vexcl/devlist.hpp" struct Config { bool use_vexcl; vex::Context vexcl_ctx; Config(); }; extern Config config; void init_config(); //file.cpp #include <iostream> #include "config.h" using namespace std; Config::Config() : use_vexcl(true) , vexcl_ctx(vex::Filter::Any && vex::Filter::DoublePrecision) { cout << "Config constructor with VexCL" << endl; if (!vexcl_ctx) throw std::runtime_error("No VexCL devices available"); } Config config; void init_config() { cout << "Init config..." << endl; config = Config(); }

The init_config() function is executed in the extension immediately after all #include . However, the program execution flow does not reach it either ("Init config ..." is not displayed). If you comment out all the code using VexCL, execution does not stop.

Is this related to VexCL, or with some logical errors in my code? How can I fix this (and is it possible at all)?

PS It is worth noting that the Python extension module is essentially a dll library. Used OpenCL backend to VexCL.

It was tested on Windows 8.1, Python 3.4 was used and the compiler from Microsoft Visual C ++ 10.0. The project is organized in such a way that the above code is part of a library, statically linked with the extension.

  • Oh .... Well, there may be a lot of options, if openCL is used, I personally met with strange situations when everything costs, but the openCL software does not see the device at all. And this is when working with openCL directly. And you have two more gaskets, more room for problems. You need to look at the debugger ... - Vladimir Martyanov
  • I use VexCL to create Python extensions (using boost.python), and there are no such problems. In your code, you initialize the context twice: the first time in the Config() constructor, which is called when you create the global config object, the second time inside the init_config() function. Those. Hangup most likely occurs during the first initialization. Does the same VexCL code work on your machine outside of the Python module? - ddemidov
  • @ddemidov Initially, I didn’t have such a double initialization, but somewhere I read that global variables in dll files are not initialized (I thought the problem was this). Anyway, without init_config() the same thing happens. Wrappers for c ++ classes I describe in Cython. Outside the Pyoton module, everything is fine (I tried on two machines). - Doctor Lemman
  • In this case, there are no more ideas. I have no experience with cython, but try to look at this project: github.com/gregvw/chebyshev-gpu , there a bunch of vexcl-cython worked. - ddemidov
  • @ddemidov Thanks for the help! In this project, the context is initialized as a field of a class whose object is created during the execution of the Cython wrapper's constructor for this class and is stored in its associated structure, i.e. stored and initialized in the local scope. In my case, it is created when a global variable is initialized, that is, logically, as if when a module is loaded, but the program hangs on this place. If you transfer the initialization to the local scope, for example, to declare the config in init_config() , then everything works as it should. I can not understand why this is ... - Doctor Lemman September

1 answer 1

To avoid a hang, you need to remove context initialization from the global scope. For example, you can declare and initialize the config in init_config() and return it to the calling code, or declare the field vexcl_ctx as vex::Context* and create an object in dynamic memory in the function init_config() .

As soon as context initialization occurs in the global scope, the interpreter hangs when the extension module is loaded. Other global objects are initialized and work as expected. I did not understand the reason for this behavior, I will be grateful if someone explains.