MPI standard 3 was released in 2011
with no C++ bindings !
my question is how to program distributed computing in C++ without MPI (note we need also OpenMP CUDA Openacc)
is there an alternative to MPI in C++ (not MPI 2.2, boost MPI)?
is MPI built on TCP/IP so i can build my own way using TCP/IP in C++ ?
is there open source binding to MPI 3 for C++ ?
or just you must stick to C GTK+ CUDA OpenMP OpenGL MPI 3
what if you want C++ QT CUDA OpenMP OpenGL + distributed computing API ?
Ubuntu and many Linux distros seeks to replace Xserver with Wayland and MIR both will write special API and layer to create context for OpenGL desktop to replace GLX also GTK+ will has MIR Wayland integeration so on Linux if something changed some people and groups try to fix it try to develop new solution
but MPI 3 C++ binding i don't find a solution to it
The official recommendation is to use the C bindings, for the reasons given in the comments. The only loss of functionality here pertains to exceptions and you won't miss it because no implementation was fault-tolerant in the MPI-2 era anyways.
Boost::MPI is nice but supports very few features (the most popular ones).
Rolling your own C++ wrappers is encouraged. Elemental (libelemental.org) has a nice set that do magic with type inference.
I have some personal interest in developing a new set of C++ bindings but haven't had time to make progress. There's a StackExchange Computational Science post with a detailed discussion to which you might contribute.
Related
I understand there's an openCL C++ API, but I'm having trouble compiling my kernels... do the kernels have to be written in C? And then it's just the host code that's allowed to be written in C++? Or is there some way to write the kernels in C++ that I'm not finding? Specifically, I'm trying to compile my kernels using pyopencl, and it seems to be failing because it's compiling them as C code.
OpenCL C is a subset of C99.
There is also OpenCL C++ (OpenCL 2.1 and OpenCL 2.2 specs) which is a subset of C++14 but it's not implemented by any vendor yet (OpenCL 2.1 partially implemented by Intel but not C++ kernels).
Host code can be written in C,C++,python, etc.
In short you can read about OpenCL on wikipedia. There is a description about each OpenCL version. In pyopencl you can use OpenCL1.2 (as far as I'm aware there isn't support for OpenCL2.0 yet).
More details about OpenCL on Khronos website.
I would add SYCL on ComputeCpp from Codeplay. They have been very active at IWOCL.org promoting the use of single source C++ host and kernel code. SYCL has OpenCL execution model "under the hood". https://en.wikipedia.org/wiki/SYCL. Though Wikipedia has this statement about SYCL: "The open standards SYCL and OpenCL are similar to vendor-specific CUDA from Nvidia." Which cannot be any further from the intent of portable code (not performance portable) of SYCL and OpenCL.
You can find information, news, blogs, videos and resourcs on SYCL on the sycl.tech website.
For reference, there's also Boost.Compute. It doesn't help you with pyopencl, but it addresses many of the issues that pyopencl does, and has some metaprogramming magic that facilitates writing OpenCL kernels in C++.
This SO question (referenced in the Boost.Compute FAQ) also contains a nice discussion of some of the relevant design constraints that OpenCL poses to devs.
This is an old question, and the work to "solve" it has been ongoing for some time...
There is a community-driven C++ for OpenCL kernel language that is implemented by clang Clang C++ for OpenCL and there is a Khronos extension cl_ext_cxx_for_opencl that adds an online compilation of this language to OpenCL drivers too. Arm has just announced the support for this extension. Although it is also possible to compile kernels in this language offline using upstream tools into machine binary, SPIR-V, or any other IR and then load the precompiled code in OpenCL drivers without any extension.
I read that Microsoft is closely working with Nvidia to improve AMP performances.
But my question is: is AMP a CUDA-replace by Microsoft? Or does AMP use CUDA drivers when a NVIDIA CUDA video card is available? Is AMP an openCL substitute?
I'm still pretty confused..
C++ AMP is a library (and as part of it a key language extension was also introduced). Since C++ AMP is an open specification, it can be implemented on any other low level languages. Microsoft’s implementation builds on DirectCompute (and hence on HLSL), but that is completely hidden from you when you are using C++ AMP (which is why C++ AMP can be an open specification; it does not expose DirectX in the API surface). For more on C++ AMP, please follow the resources on the right of our blog (we’ll keep adding to that):
http://blogs.msdn.com/b/nativeconcurrency/
You made a statement about Microsoft working with NVIDIA to improve C++ AMP performance – that is not true. Microsoft has worked with NVIDA and AMD and other partners to create the C++ AMP open specification. Microsoft also work with hardware vendors to make sure that the hardware vendors have stable video card drivers, which are required for any GPU compute technology to work correctly.
You also expressed confusion and threw some terms out. OpenCL is an approach to GPU computing (by Khronos), as is DirectCompute (by Microsoft), as is CUDA (by NVIDIA). These are all separate technologies, each with its own path to the GPU (always via a driver of some sort), each with its own merits, strengths, and disadvantages. One does not replace the other, and one is not universally better than the other. You now also have C++ AMP in that mix, as one more choice, and the same statements apply to that. The choice is yours as to which you decide to use.
C++ AMP is a set of language extentions and APIs to support parallel programming technology including CUDA.
Since Microsoft also has a direct competitor to CUDA ( Direct Compute) and generally has preferred it's own proprietary graphics standards we will have to see what actually ever happens with it.
For Microsoft's view on it see these lectures
I'm a die-hard .NET developer with limited experience in C++. I'm really familiar with how happily interpreted languages (and scripting languages) work cross-platform, but what about C++?
I realize that GCC/GPP and some other compilers sorta work multi-platform with the right compiler flags, and I understand that the STL is normalized between compilers, but what else am I missing? I'll need to do audio in/out, high accuracy timers, and I'll need to do multithreading. I don't think any of these things are supported in the STL, so I'll be needing a cross-platform library of some type, right? Which one should I use?
I'm aiming to support the latest Mac and Windows platforms. This is a shared framework/sdk and won't have a UI. I plan on writing the UI in a native language such as Objective-C/Cocoa and .NET/WPF (both which have excellent native UI support).
So what should my tool chain look like? Should I be using GCC/GPP or MinGW? What other 'libraries' should I integrate that will function cross platform? I'd like to setup my build environment to 'just work' such that I can build a Mac compatible binary and a windows compatible binary (32 bit and 64 bit). How can I do that?
At this point, I'll be writing code for each platform so that I can interop with this my C++ multiplatform framework sdk/api thingy. In windows, I think this will look like a managed DLL, is that right? Any thoughts on how I'll do this on a Mac?
Any suggestions or recommendations?
Thanks for the suggestions,
Brett
1) Your real goal here should be to write portable C++ -- you get portability by keeping your language use clean, not by using a particular compiler.
2) Some of what you want, like audio i/o, is fairly inherently platform dependent. You can, however, cleanly isolate the platform dependencies inside particular modules and conditionally compile a set of platform support files on each platform.
3) Stuff like multithreading can be done in a platform independent manner using standard libraries.
Getting into subjective territory but for a developer used to working with large, do-it-all kind of frameworks like those we find in .NET, QT would probably be your best cross-platform C++ analogy (though I am not a huge fan of it). There you have your threads, XML I/O, localization, sockets, high accuracy timers, GUI building blocks, etc.
[...] and I'll need to do multithreading. I don't think any of these things
are supported in the STL [...]
Just a small thing, but the STL is limited to describing the aggregate containers and generic algorithms of the C++ Standard Library. It is not synonymous, but C++11 has specifications in the standard library for concurrency support. However, popular compilers are still slow to support it fully. You also have boost if you need threads for the time being: http://www.boost.org which is an extremely cross-platform library.
As for building an API that can happily plug in to various environments (.NET, Cocoa, etc), your best, most cross-platform option is actually to expose a C API (you're free to implement it using C++). It'll cause the least headaches this way (no issues with name mangling, trying to interop with complex, user-defined C++ types, etc.).
I recommend you get some practice with building DLLs/shared libraries in C++ as a way to extend .NET and Cocoa applications (ex: C++ module used in objective-C) before you start trying to develop a grand library.
For timing the standard library has <chrono>, which has nanosecond resolution on Mac. Unfortunately it's only got millisecond resolution on Windows as of the VS11 Beta. I'm hoping they fix it without too much delay.
Basically, the title explains it all; I'm looking to make a game in C++ and I want to use multithreading for stuff like the physics engine and keeping the animation smooth on the loading screen. I've seen a few multithreading libraries, but I'm wondering which is best for my application, which will work well on Windows Mac and Linux. Does such a library exist?
You probably want boost::thread or Intels' Thread Building Blocks. I'd recommend TBB but it's not free, I think, so boost::thread for the free option.
If you can use c++0x threads, then use that.
If not, boost::thread is the best free multi-platform library.
My favourite is QThread. Part of Qt library.
Currently my recommendation would be OpenMP (libgomp on g++, IBM XlC++, MSVC++ all support it)
OpenMP offers a simple way of exploiting parallelism without interfering with algorithm design; an OpenMP program compiles and operates correctly in both parallel and serial execution environments. Using OpenMP's directive-based parallelism also simplifies the act of converting existing serial code to efficient parallel code.
See msdn
And GOMP
for starting points
Random quote:
To remain relevant, free software development tools must support emerging technologies. By implementing OpenMP, GOMP provides a simplified syntax tools for creating software targeted at parallel architectures. OpenMP's platform-neutral syntax meshes well with the portability goals of GCC and other GNU projects
Another nice library that includes cross platform threads is poco
Greetings,
I am trying to decide between C and C++ for my robot. I am a 5+ year veteran of Visual Basic.NET, however I'm going with Linux (Ubuntu) on this robot, and there is a compatibility problem between Linux and the .NET Framework. I want to stick with whichever language I choose for all of my projects, so I want to make sure that I choose the most appropriate one for the task.
For reference, I will describe my current robot in progress and what I am going to do with it. I am in the process of building a full-sized R4 Astromech (yep, I'm one of those guys). I have incorporated a PC motherboard with an Intel Core 2 2.1 GHz processor, 1 GB RAM. I will be using a scratch-built parallel interface card to control the drive motors, head motor, as well as a secondary parallel interface card (going to a second parallel port) which all of the sensors (IR, Ultrasonic Ranging, Visual Recognition via webcam, etc.) will be going to. Commands will be given using speech recognition (currently have a VB.NET scratch-built recognition program that I will be adapting to the new language).
Given the specifications and desired goals listed above, would I be better off with C or C++? I greatly appreciate any suggestions that you might have.
Thanks!
Thaskalas
What do you mean by a compatibility problem? Have you looked at Mono? It's an open-source implementation of the .NET libraries. It's geared toward C# not VB.NET but if you're more comfortable in a .NET environment use that. Speed isn't really an issue here as a Core2Duo is plenty fast for what you need to do.
If Mono won't work for you, I'd recommend C++. There are a lot more libraries out there for C++ (or at least, I am familiar with more, e.g. Boost), which can use most C libraries too. There's no real speed penalty for using C++. While using C wouldn't be bad per-se, C++ has some benefits and no drawbacks, so it's probably the better choice.
I would recommend using ROS. It will let you get started with a sophisticated Inter-Process Communications manager, as well as a large library of sophisticated robotics code, including multiple implementations of SLAM and other critical robotics algorithms. ROS also lets you program in multiple languages, including C, C++, and Python, so you aren't stuck with one language or another down the road.
I would also recommend C++ and ROS. In our company we're migrating to it, because there's so many people working on it, expanding it, and adding lots of cool features.
With this, you can forget about implementing most of the basic low-level stuff and start working on what you intend to research.
It's really easy to set up and start developing.
Since you're running Linux on it, I'd recommend a split approach, where you do the lower-level (device interface, where you may need fast performance) stuff in C (or C++), and the higher level stuff in a modern language like C# (using Mono) or Java, or even Python.
Python especially is hugely expressive, has a large set of libraries, and has a pretty straightforward C interface.
Writing your high-level control stuff in a low-level language like C/C++ will get old fast (IMHO). Robots should be fun!
Have you considered D? It's a fairly new language, is compiled to native code and can link directly to C. (The entire C standard library is even available from D, and bindings to the POSIX API are included in the standard library.) Basically all you need to do to use any C library from D is compile it with a C compiler and translate the function prototypes, constant declarations, etc. in the header file.
D is low-level enough that an experimental kernel is written in it, but has modern features like garbage collection (though manual memory management is still permitted), builtin strings and arrays, and more advanced/easier to use template metaprogramming facilities than C++. The biggest disadvantage is lack of a mature toolchain and libraries for enterprise-y things, but for your purposes that probably doesn't matter. BTW, if you need to do a bunch of matrix manipulation and stuff, there's the SciD project, which provides nice templated wrappers over LAPACK and BLAS.
Use C++. You have the space. You can use it "as a better C" to start with.
C++ is a bigger tool bag; why would you not want that!? You need not use all the tools, but with C you'd have no choice. Most importantly with C++ you have the choice of using both C and C++ third-party libraries.