Hi,

We are working on an appliance like product that is based on OpenBSD.
Recently we found out that our performance critical C++ program is
~2.5 times slower on OpenBSD compared to Ubuntu 20.04.

The program basically just reads data from stdin, does some
transformation of the data, and returns the result on stdout, thus
the program does not perform any further I/O operations nor interacts
with other programs. We extensively use the C++ standard library string
class for manipulation of data.

We started searching for the reason, and eliminated I/O as a factor.
During some experiments we found out that one, perhaps not the only
one, factor is OpenBSD's memory management. To test this assumption we
wrote a simple program that allocates and frees memory in a loop.
Something like:

for (...) {
  void *buffer = malloc(...);
  ...
  free(buffer);
}

We compiled it on OpenBSD with clang
$ /usr/bin/c++ --version
OpenBSD clang version 10.0.1
Target: amd64-unknown-openbsd6.8
Thread model: posix
InstalledDir: /usr/bin

using options '-O3 -DNDEBUG -std=gnu++11' and ran it without memory
junking.

$ time MALLOC_OPTIONS=jj ./memory_allocs --cycles 123456789 --size 1024

real    0m27.218s
user    0m27.220s
sys     0m0.020s

We compiled the same program on Ubuntu 20.04 with g++
$ /usr/bin/c++ --version
c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

using the same options '-O3 -DNDEBUG -std=gnu++11'

$ time ./memory_allocs --cycles 123456789 --size 1024

real    0m1,920s
user    0m1,915s
sys     0m0,004s

Both systems were tested in the same virtualized environment (VSphere),
thus we can assume the "hardware" is the same.

Given the virtual environment, the tests might not be scientifically
the best choice, but they serve the observation well enough. We
actually ruled out virtualization as a cause in other tests.

What other options are there we could try in order to speed the memory
management up?

Also are there any other known areas, for CPU bound processing, where
OpenBSD performs worse than other "common" platforms? 

Cheers,
Marek

Reply via email to