How several OpenMP compilers create threads? I think that this may depend on concrete compiler (GCC, ICPC and Visual C++). But maybe they use some libraries like pthread..?
Most of the implementations use pthreads, since the pthreads library is on Linux and Windows. This simplifies the implementation, since they don't have to change the implementation depending on the operating system. The one implementation (of course) that differs is Microsoft. Since they only support Windows, they use the Window's threading APIs. At least on Linux, you can check for yourself what threading model is being used, by using nm on the OpenMP run time library and seeing what the external dependencies are.
Related
This is a a question in my head for some years, I am using OCaml under windows, when I build each OCaml distribution version, I need a C compiler, either MSVC or MingGW, and I have to do it under Cygwin.
When I have my OCaml in hand, and when I need to compile my codes, I also need the c linker that I used for compiling my OCaml..for me it's very strange. Why OCaml can't auto bootstrap with an elder version of OCaml instead of some C compiler?
The OCaml toolchain relies on external tools to assemble and link binaries. The latter is probably more important than assembler, as assemblers are more or less stable. But linkers are usually deeply integrated with an operating system and differ each version. Bundling them will increase support burden and make OCaml programs less portable and the whole OCaml distribution more fragile. So, depending on assembler/linker abstraction is sort of a sweet point, that minimizes dependencies and support burden and maximizes portability.
Other languages, usually, follow the same approach. Even those that depend on LLVM, as LLVM actually uses the GNU toolchain linker underneath the hood.
For building OCaml itself, the C compiler is absolutely necessary. The OCaml itself is not written entirely in OCaml. In fact, OCaml runtime is written in pure C, e.g., garbage collector. Also, many functions, especially that define system interface (e.g., Unix) are also written in C. The sloccount tool gives us a rough estimate, that 15% of OCaml source code (45,000 LOC) is written in C.
The OCaml bytecode interpreter is written in C - see the description in the OCaml README here.
ivg's answer says it all, but I'll just give a quick tip for Windows 10 users.
I always recommend that Windows 10 users use Ubuntu on Windows 10. You'll then have access to a fully-fledged Unix environment instead of Cygwin, which include (among other things) a built-in C tool chain.
I'd only use Windows to develop if I intend to release on Windows, which I rarely do. Even then, I'd prefer to use a cross-compiler and use Windows only for testing.
I am working on an MPI application for scientific computing. I am working on our distribution process, and it raise the question of the version of the MPI.
I read at some places on the net that MPI should be built with the same compiler suite as the application, but nothing really explaining why.
So I wonder what defines a version of MPI, once it has been compiled? Is it just the version of the source package, or is it the version of the source package plus the compiler suite and its version that has been used to compile MPI?
The version of the MPI implantation is an absolute must. A typical example being an type having changed between versions.
You should also compile all involved libraries - particularly MPI - with the same compiler version. A typical example are compiler-specific libraries. One compiler replaces a call to memcpy with a built-in optimized version. If you try to link with a different compiler, that doesn't provide that optimized function in it's library, you get a linker error. System libraries are usually fine, but for highly optimized builds as well as C++ codes, these kinds of library ABI (application binary interface) incompatibilities are common and very painful.
I am writing a pintool gathering metrics in a subset of applications routines(some among them, are generated by the compiler).
The goal is to get the execution time of those routines.
Below is a set of attempts I already gave:
Of course doing it with pin is a bad idea because of the Virtual Machine overhead.
gcc option -finstrument-functions does not scope the OpenMP functions it generates.
LD_PRELOAD does not work with OpenMP functions which are statically linked.
Maybe if pin allowed to dump statically instrumented assembly, we could avoid the virtual environment overhead, but as far as I know it isn't possible.
I know about Maqao instrumentation tool which do not use virtual environment, but I want to avoid using too many frameworks or translating my pintool into maqao lua script.
I guess I am left with manual binary instrumentation, but if anybody has a better solution, the help will be appreciated.
If you just want the results - use a comprehensive measurement infrastructure that supports OpenMP such as Intel VTune, Extrae/Paraver, Score-P. This will provide you profiling or tracing information about the OpenMP regions.
If you want to implement the measurement yourself, you can use the underlying source-to-source transformation tool Opari. You could also use the much cleaner OpenMP tools interface (OMPT), but AFAIK it is not widely supported yet. You might have some luck with recent Intel OpenMP runtimes.
I'm installing mingw-w64 on Windows and there are two options: win32 threads and posix threads. I know what is the difference between win32 threads and pthreads but I don't understand what is the difference between these two options. I doubt that if I will choose posix threads it will prevent me from calling WinAPI functions like CreateThread.
It seems that this option specify which threading API will be used by some program or library, but by what? By GCC, libstdc++ or by something else?
I found this:
Whats the difference between thread_posixs and thread_win32 in gcc port of windows?
In short, for this version of mingw, the threads-posix release will use the posix API and allow the use of std::thread, and the threads-win32 will use the win32 API, and disable the std::thread part of the standard.
Ok, if I will select win32 threads then std::thread will be unavailable but win32 threads will still be used. But used by what?
GCC comes with a compiler runtime library (libgcc) which it uses for (among other things) providing a low-level OS abstraction for multithreading related functionality in the languages it supports. The most relevant example is libstdc++'s C++11 <thread>, <mutex>, and <future>, which do not have a complete implementation when GCC is built with its internal Win32 threading model. MinGW-w64 provides a winpthreads (a pthreads implementation on top of the Win32 multithreading API) which GCC can then link in to enable all the fancy features.
I must stress this option does not forbid you to write any code you want (it has absolutely NO influence on what API you can call in your code). It only reflects what GCC's runtime libraries (libgcc/libstdc++/...) use for their functionality. The caveat quoted by #James has nothing to do with GCC's internal threading model, but rather with Microsoft's CRT implementation.
To summarize:
posix: enable C++11/C11 multithreading features. Makes libgcc depend on libwinpthreads, so that even if you don't directly call pthreads API, you'll be distributing the winpthreads DLL. There's nothing wrong with distributing one more DLL with your application.
win32: No C++11 multithreading features.
Neither have influence on any user code calling Win32 APIs or pthreads APIs. You can always use both.
Parts of the GCC runtime (the exception handling, in particular) are dependent on the threading model being used. So, if you're using the version of the runtime that was built with POSIX threads, but decide to create threads in your own code with the Win32 APIs, you're likely to have problems at some point.
Even if you're using the Win32 threading version of the runtime you probably shouldn't be calling the Win32 APIs directly. Quoting from the MinGW FAQ:
As MinGW uses the standard Microsoft C runtime library which comes with Windows, you should be careful and use the correct function to generate a new thread. In particular, the CreateThread function will not setup the stack correctly for the C runtime library. You should use _beginthreadex instead, which is (almost) completely compatible with CreateThread.
Note that it is now possible to use some of C++11 std::thread in the win32 threading mode. These header-only adapters worked out of the box for me:
https://github.com/meganz/mingw-std-threads
From the revision history it looks like there is some recent attempt to make this a part of the mingw64 runtime.
#rubenvb answer is fully correct, use the mingw posix compiler if you want to use std::thread, std::mutex, etc. For everybody who is using CMake, here is an example:
set(CMAKE_CXX_STANDARD 17) # or 20 if you want..
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(THREADS_PREFER_PTHREAD_FLAG ON)
set(TOOLCHAIN_PREFIX x86_64-w64-mingw32)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc-posix)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g++-posix)
set(CMAKE_RC_COMPILER ${TOOLCHAIN_PREFIX}-windres)
set(CMAKE_FIND_ROOT_PATH
/usr/${TOOLCHAIN_PREFIX}
)
Ideal for cross-compiling Linux apps to Windows.
Hint: For people who are using GTK3 and want to cross-compile their GTK application to Windows. You maybe want to download the Mingw Windows GTK bundle, downloaded and packaged from msys2.org so you don't need to: https://gitlab.melroy.org/melroy/gtk-3-bundle-for-windows
Does openMP have a runtime (like .NET CLR on top of operating system) or just a compiler?
OpenMP doesn't really have, or need, anything like the .NET CLR. Compilers typically produce code which uses one or other of the approaches to threading already installed on the platform. There are also a few environment variables which OpenMP programs may want to use, but that hardly constitues a run-time system either.
I've never come across an OpenMP compiler which needed a separate installation of a run time system or anything like one.
EDIT: An OpenMP installation also needs to provide functions such as omp_get_thread_num which are usually packaged in a library of some sort.