Re: [QUESTION] Execute OpenMP Application on Rump Kernel?

  • From: Antti Kantee <pooka@xxxxxx>
  • To: rumpkernel-users@xxxxxxxxxxxxx
  • Date: Mon, 17 Aug 2015 11:57:24 +0000

On 17/08/15 08:24, Vincent Schwarzer wrote:

Nobody knows (yet ;). I'm not intimately familiar with how OpenMP works,
and it's been almost 10 years since I last ran into it at all, but I guess
what you describe could work.

What, specifically, do you want to accomplish? Using a Rumprun unikernel
as the runtime for an OpenMP node on the cloud, or something else?


I want to run different established performance benchmarking tools (e.g.
STREAM) and real world applications used in web application stacks on
Rumprun unikernel. At the end I want to compare the measurement results of
these tools/applications to other platforms (e.g. OSv,Linux Native, Docker,
...) for a recommendation matrix for what kind of workload which platform
is most suitable in a cloud/backend application context. Many of these
application I want to use are utilizing OpenMP to fork new threads for each
core and join the results at the end.

What does OpenMP use for transport on the cloud? sockets?

What do you expect to be dominating factor in your benchmark? (e.g. data transfer, guest bootstrap overhead, ...)?

I assume that you have to fetch the sources of the compiler that you're
using and crosscompile libgomp first. I also assume that libgomp is tied
to the compiler version, so not sure how much we can automate that, unless
we provide a default compiler (which has sort of been an explicit no-no in
our design so far -- you should be able to use any compiler you want to
build rump kernels).


What is the difference between x86_64-rumprun-netbsd-gcc in the app-tools
folder and my standard gcc (4.9) on my system which can compile OpenMP
applications, when there is no complier supplied by rumprun itself?

The C compiler frontend does essentially two things:
1) compiles C for the correct target architecture
2) sets the correct paths and defaults for headers/libs/cppmacros for the target system

So, we want "1" as-is, but "2" we need to adjust to be correct for our use with the wrappers. You can't use libgomp from your system (*) because it's compiled against your system. It's the same reason that you can't use pretty much any system-interfacing library on another system, even though they might share the same "1".

*) ok, you might, if your system is NetBSD, but I'd assume the gcc versions need to match too.

IOW, I still think you need to get gcc 4.9 sources and crosscompile libgomp for Rumprun from there. If that works, we can think further about how to "productize" the availability of libgomp for Rumprun.

Other related posts: