# How to tell if igraph was compiled with OpenMP?

**URL:** <https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702>\
**Category:** Usage\
**Created:** [12 November 2023 22:23 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702 "2023-11-12T22:23:07Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![bernaljg](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/bernaljg/32/1012_2.png) [@bernaljg](https://igraph.discourse.group/u/bernaljg)\
**Post date:** [12 November 2023 22:23 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/1 "2023-11-12T22:23:07Z")

</div>

Hi! Is there a way to tell if my igraph installation has OpenMP enabled?

It seems like changing the OMP\_NUM\_THREADS variable doesn’t change the performance of the personalized\_pagerank function so I think it is not enabled but I would like to be sure!

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [12 November 2023 22:42 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/2 "2023-11-12T22:42:07Z")

</div>

In general, no.

Instructions for compiling the C library with OpenMP are here: [igraph Reference Manual](https://igraph.org/c/html/latest/igraph-Installation.html)

If you tell us what programming language you are using igraph from and how you installed it, we might be able to give some information.

---

<div class="post-metadata">

**Author:** ![bernaljg](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/bernaljg/32/1012_2.png) [@bernaljg](https://igraph.discourse.group/u/bernaljg)\
**Post date:** [12 November 2023 23:03 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/3 "2023-11-12T23:03:10Z")

</div>

I’m using python in a Linux machine and I installed igraph yesterday using pip. I am using the latest version 0.11.2.

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [12 November 2023 23:25 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/4 "2023-11-12T23:25:28Z")

</div>

@tamas, do you have any comments on this? I though that the PyPI distribution was compiled with OpenMP, but it does indeed seem to use a single thread on my machine.

---

<div class="post-metadata">

**Author:** ![tamas](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/tamas/32/1261_2.png) [@tamas](https://igraph.discourse.group/u/tamas)\
**Post date:** [13 November 2023 16:18 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/5 "2023-11-13T16:18:27Z")

</div>

In theory they are built with OpenMP support, judging from the build logs on Github Actions (see [here](https://github.com/igraph/python-igraph/actions/runs/6498927404/job/17651242201)). Drilling down to the “Build wheels (manylinux)” part it seems like OpenMP should be enabled (the build logs display `OpenMP: yes`). Also, by examining `_igraph.abi3.so` within the downloaded wheel using `ldd`, it seems like it _is_ linking to the OpenMP library, which is vendored within the wheel itself as `igraph.libs/libgomp-a34b3233.so.1.0.0`.

So, all seems good to me. I only have a four-core Linux machine around to test things with, so I did this:

```auto
import igraph
g = igraph.Graph.GRG(1000000, 0.0025)
x = g.pagerank()

```

and watched the CPU usage during the calculation. With `OMP_NUM_THREADS=4`, the CPU usage went up to more than 270% during the PageRank calculation. During the graph generation it hovered stably at 100% as the GRG graph generation runs on a single thread only. So it seems to me that OpenMP is working.

---

<div class="post-metadata">

**Author:** ![bernaljg](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/bernaljg/32/1012_2.png) [@bernaljg](https://igraph.discourse.group/u/bernaljg)\
**Post date:** [13 November 2023 20:04 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/6 "2023-11-13T20:04:10Z")

</div>

Thanks so much for the answer!

I followed your process @tamas and it does seem like igraph OpenMP is working according to the OMP\_NUM\_THREADS variable.

After using the quick script below it seems like when changing OMP\_NUM\_THREADS from 1 to 128 the CPU usage looks drastically different but they both took an average of 2.35s per run. Is this to be expected?

```auto
import igraph
from tqdm import tqdm

g = igraph.Graph.GRG(1000000, 0.0025)
for i in tqdm(range(10)):
    x = g.pagerank()

```

---

<div class="post-metadata">

**Author:** ![tamas](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/tamas/32/1261_2.png) [@tamas](https://igraph.discourse.group/u/tamas)\
**Post date:** [13 November 2023 20:30 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/7 "2023-11-13T20:30:31Z")

</div>

Most likely reasons:

1. the code is dominated by the generation of the GRG graph and not by the call to `pagerank()`
2. PRPACK contains multiple implementations of the algorithm and it decides between them based on some criteria that I haven’t dived into in the source code. Not all the implementations are parallelized by OpenMP so you might not even be hitting the part of PRPACK that is parallelized.
3. setup of OpenMP threads and the coordination between them might cost more than what you gain with parallelization at this graph size

---

<div class="post-metadata">

**Author:** ![bernaljg](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/bernaljg/32/1012_2.png) [@bernaljg](https://igraph.discourse.group/u/bernaljg)\
**Post date:** [13 November 2023 20:37 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/8 "2023-11-13T20:37:45Z")

</div>

It does seem to be parallelized since it is using multiple CPUs so the most likely culprit is #3.

Thanks so much!

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [13 November 2023 23:04 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/9 "2023-11-13T23:04:23Z")

</div>

An extreme number of threads is not going to be productive. Try using only a few. I see a very clear improvement with 4 threads.

A good benchmark graph is `igraph.Graph.Kautz(7,7)`.

@tamas On macOS / arm64 I only see a single thread working when using the PyPI version. When I use the MacPorts version and enable OpenMP for it, I see 4 threads. Are you sure something’s not wrong with the macOS PyPI version?

---

<div class="post-metadata">

**Author:** ![tamas](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/tamas/32/1261_2.png) [@tamas](https://igraph.discourse.group/u/tamas)\
**Post date:** [13 November 2023 23:35 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/10 "2023-11-13T23:35:13Z")

</div>

You are right, `arm64` wheels seem to be compiled without OpenMP. I strongly suspect that this is due to the fact that `arm64` wheels are cross–compiled with `cibuildwheel`; maybe the build environment is not ready for OpenMP? I can compile igraph with OpenMP just fine on my Mac if I do it natively.

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [14 November 2023 17:18 UTC](https://igraph.discourse.group/t/how-to-tell-if-igraph-was-compiled-with-openmp/1702/11 "2023-11-14T17:18:36Z")

</div>

GitHub is launching native Apple Silicon runners next year. Let’s wait until then to fix this.
