To isolate the problem, I got the concurrent.futures completely out of the
picture, and used a (cloud) Linux VM (Ubuntu 18:04). Then I encountered the
same initial problem: The kernel dies unexpectedly if n_run>1. See branch
omp file tsp_compute_2.py - compiled with '$ pythran -DUSE_XSIMD -fopenmp
-march=native tsp_compute.py'.
Then I extracted the Python code from the notebook into a plain Python file
run.py (branch omp). To go as vanilla as possible. If I run it with
n_run=1, no pb, but with n_run=2 error: 'Segmentation fault (core dumped)'
Any idea ? Are my omp directives faulty ?
Grateful for any tip !
On Mon, Dec 10, 2018 at 5:48 PM Olivier Borderies <
olivier.borderies@xxxxxxxxx> wrote:
A few feedbacks:
you're pointing at an obsolete pythran.cfg as base reference which leads
to a few unnecessary lines. It's usually not needed to customize all
fields, only the one you change. In your case
[compiler]
cflags=-std=c++11 -fno-math-errno -w -I/usr/local/opt/llvm/include #
not quite sure why you need that though
ldflags=-L/usr/local/opt/llvm/lib # added
CC=/usr/local/opt/llvm/bin/clang # added
CXX=/usr/local/opt/llvm/bin/clang++ # added
should be enough
Indeed I used the .pythranrc above and it worked just fine.
I also removed the "-I/usr/local/opt/llvm/include" flag, which I read from
the "brew info llvm" was better to add...
Concerning your #pythran export, a quick look at the call site makes me
think you could use a numpy array instead of a list, thus saving extra
conversion time.
I'll do that but since the lists are small and the conversion takes place
only once, it cannot really impact the perf.
I'm curious about the openmp crash... I'll try to reproduce it on Linux.
To help document my pb with omp on macOS, I added the *omp* branch to the
repo. It contains a slight modification to tsp_compute.py. I compile as
said in the README.
And this time it fails at run time, with the msg in the notebook. No
kernel dying anymore, probably because I wrap the calls in
concurrent.futures. If I remove the omp directives, no pb but no speedup.
*Surprisingly only on the first run* (with omp) I saw the following error
msg in the notebook server console:
[I 17:27:55.045 NotebookApp] Adapting to protocol v5.1 for kernel
8449ebc2-10be-4f4b-947c-9a528166ff01
python(12453,0x7fffdebc43c0) malloc: *** error for object 0x7fb68102b600:
pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
