When using SOL on X86 CPUs we strongly recommend to set the following OMP env var.
export OMP_PROC_BIND=TRUE
| EnvVar | Default | Description |
|---|---|---|
| CC | “gcc” | Path to gcc |
| CXX | “gcc” | Path to g++ |
| COBJCOPY | “objcopy” | Path to objcopy |
| CAR | “ar” | Path to ar |
| CPATH | Used as include paths | |
| C_INCLUDE_PATH | Used as include paths | |
| CPLUS_INCLUDE_PATH | Used as include paths | |
| LIBRARY_PATH | Used as library paths |
Further see OpenMP Environment Variables.
| SOL performance using X86 is really really bad, what can I do? | |
|---|---|
tl;dr; run once: python3 -m sol fix-omp --yesUnfortunately some python packages (e.g., torch or sklearn) ship their own version of libgomp.so. This causes that
the application uses multiple OpenMP runtimes, which can cause a series of
problems. If you don't define OMP_NUM_THREADS, then only the very
first loaded OpenMP runtime runs multi-threaded. Even worse, if you define
OMP_NUM_THREADS, all runtimes run in parallel, but use different
threadpools, so whenever you switch from one to the other, you will have
significant overhead due to swapping the threads. The python3 -m sol
fix-omp --yes command detects conflicting versions of
libgomp.so and replaces them with a symlink to the system's own
version of libgomp.so, so that all libraries use the same
threadpool.
If you need to run this fixing within your script, because you are using a fully
automated process, then you can use:
|