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.
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.
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.
Compiling a program to bytecode instead of native code enables a certain level of portability, so long a fitting Virtual Machine exists.
But I'm kinda wondering, why delay the compilation? Why not simply compile the byte code when installing an application?
And if that is done, why not adopt it to languages that directly compile to native code? Compile them to an intermediate format, distribute a "JIT" compiler with the installer and compile it on the target machine.
The only thing I can think of is runtime optimization. That's about the only major thing that can't be done at installation time. Thoughts?
Often it is precompiled. Consider, for example, precompiling .NET code with NGEN.
One reason for not precompiling everything would be extensibility. Consider those languages which allow use of reflection to load additional code at runtime.
Some JIT Compilers (Java HotSpot, for example) use type feedback based inlining. They track which types are actually used in the program, and inline function calls based on the assumption that what they saw earlier is what they will see later. In order for this to work, they need to run the program through a number of iterations of its "hot loop" in order to know what types are used.
This optimization is totally unavailable at install time.
The bytecode has been compiled just as well as the C++ code has been compiled.
Also the JIT compiler, i.e. .NET and the Java runtimes are massive and dynamic; And you can't foresee in a program which parts the apps use so you need the entire runtime.
Also one has to realize that a language targeted to a virtual machine has very different design goals than a language targeted to bare metal.
Take C++ vs. Java.
C++ wouldn't work on a VM, In particular a lot of the C++ language design is geared towards RAII.
Java wouldn't work on bare metal for so many reasons. primitive types for one.
EDIT: As delnan points out correctly; JIT and similar technologies, though hugely benificial to bytecode performance, would likely not be available at install time. Also compiling for a VM is very different from compiling to native code.