I am implementing a sort and stream compaction algorithms in CUDA C. However I have just figured that it is not that simple to implement those algorithms by myself with good performance. Given that I am working with matrices I cannot use CUDPP, so, although I was avoiding it, I will have to work with thrust library(I know nothing of C++).
I have been programing in C, and I really just want to use C++ to work with thrust, so basically I want to know if I can have most of my code in C and then have little bits of C++ code(I am guessing I will have to use the "external" function) but I wanted to be sure if it's feasible in CUDA.
Thanks in advance.
On the host code side, thrust is simple to integrate. Even though you might think that your host side code in any .cu file you compile is C, it is compiled using a C++ compiler anyway (most of CUDA internally relies on C++ features to compile). So you are actually working in C++ now without realizing it.
Yes, might complicate your build process but otherwise works fine. We use it all the time to wrap up some CUDA functions into C++ class which (and this is the REAL kicker) are then wrapped up with JNI for use in Java. If we can do it, you can do it! Have at it!
Related
I just joined a project and there's a bunch of code (which has been written by 4 or 5 different people over the last 5 years). It's all C at this point, but I want to migrate the project to C++ in order to take advantage of OOP.
Step 1 will be to simply leave all the existing code in place and just selectively convert very small pieces of the functionality to be object oriented.
It's my understanding that C can be compiled by C++, but maybe I'm wrong about this.
So, before I invest a whole lot of time in trying to actually do it, am I likely to be able to get the existing C code to compile using C++ relatively easily?
Or, is this likely to involve a massive migration before it will work?
What factors affect the complexity of the task I'm proposing?
So to be clear - I'm not asking how big a project it will be to convert all of the code to objects, functions to methods, etc - but rather, just what I'm likely to face getting the existing C code to compile using the C++ compiler instead of the C compiler.
Thanks in advance - I look forward to any help/guidance you can provide.
EDIT
Sounds like it's really not a good idea. I always thought of c++ as an expansion of C, but it sounds like they're different enough that this is not an advisable path. Ultimately, I wasn't thinking of them as Different Languages, and was hoping that c++ was more backwards compatible with c than it sounds like it is. My initial searching made it look like people had done it to varying degrees of success, but the responses here make me think I should really just consider them to be two different languages. Thanks!
I always thought of c++ as an expansion of C, but it sounds like they're different enough that this is not an advisable path.
C++ is not an expansion of C. They are completely different languages. Compiling C code with C++ is not simply enabling "OO-mode". When you compile anything but trivial C code with a C++ compiler, you are potentially opening yourself up to a world of hurt due to the differences between the two languages.
am I likely to be able to get the existing C code to compile using C++ relatively easily?
Again, you have a fundamental misunderstanding -- C++ is not some extended version of C. They are different languages.
The best course of action is to slowly migrate your code to C++, but using two different compilers. Compile the C code with a C compiler, and compile the C++ code with a C++ compiler. It is not a challenging feat since any modern compiler suite (like GCC and clang) can compile both C and C++ very well.
is this likely to involve a massive migration before it will work?
If you intend to convert your code to C++, then yes.
One thing is worth mentioning: if you are compiling your C code with a C++ compiler, and calling it programming in C++, you're missing the spirit of the C++ development environment. If you're programming in C++, but using C code with very little OO, then what's the point of using C++? Just skip the overhead of OO and code in C. Using a C++ compiler is not some magic process that will instantly make your code better.
I think you should have a look here to get a list of (possible) issues.
What I did in the past for a C to C++ mgration was to leave the C code working as it should (C code compiled with a C compiler) and - in parallel - rewrite the code from scratch in C++.
I’m a native C++ programmer never knew anything about low level C, due to some circumstances I had to use C extensively. The outcome was me catching on a lot of C habits.
Know I’m trying to develop some Computer Vision project using OpenCV, TBB, OpenCL and OpenGL.
The thing is OpenCL is native C, so is TBB I guess not 100% sure about the TBB. As everybody knows C++ is an industrial Language and so Developing in it is a blast(at least for me) but after doing the main Which language should I use research? I’m know more concerned with C/C++ Code MIXING….
So my question is this Should I Develop the whole thing in C (Hard to maintain, expand and develop with) or should I stay with C++. And if I’m staying with C++ can someone plz direct me to a good way, strategy(Book, Tutorial) of mixing C/C++.
Thanks in advance.....
All the technologies you mention have C++ APIs. So if you are already comfortable using that, by all means do so. There does not need to be any mixing of C and C++ in one file, at all.
Only the OpenCL kernels are written in plain (OpenCL-) C. You do not mix the code, but you may have to pass data from your C++ code to your OpenCL kernel. Since you mention you now know both, that should not be a problem.
This C++ faq lite entry should be helpful. Mixing C and CPP
I'm working on a program that renders iterated fractal systems. I wanted to add the functionality where someone could define their own iteration process, and compile that code so that it would run efficiently.
I currently don't know how to do this and would like tips on what to read to learn how to do this.
The main program is written in C++ and I'm familiar with C++. In fact given most of the scenarios I know how to convert it to assembly code that would accomplish the goal, but I don't know how to take the extra step to convert it to machine code. If possible I'd like to dynamically compile the code like how I believe many game system emulators work.
If it is unclear what I'm asking, tell me so I can clarify.
Thanks!
Does the routine to be compiled dynamically need to be in any particular language. If the answer to that question is "Yes, it must be C++" you're probably out of luck. C++ is about the worst possible choice for online recompilation.
Is the dynamic portion of your application (the fractal iterator routine) a major CPU bottleneck? If you can afford using a language that isn't compiled, you can probably save yourself an awful lot of trouble. Lua and JavaScript are both heavily optimized interpreted languages that only run a few times slower than native, compiled code.
If you really need the dynamic functionality to be compiled to machine code, your best bet is probably going to be using clang/llvm. clang is the C/Objective-C front end being developed by Apple (and a few others) to make online, dynamic recompilation perform well. llvm is the backend clang uses to translate from a portable bytecode to native machine code. Be advised that clang does not currently support much of C++, since that's such a difficult language to get right.
Some CPU emulators treat the machine code as if it was byte code and they do a JIT compile, almost as if it was Java. This is very efficient, but it means that the developers need to write a version of the compiler for each CPU their emulator runs on and for each CPU emulated.
That usually means it only works on x86 and is annoying to anyone who would like to use something different.
They could also translate it to LLVM or Java byte code or .Net CIL and then compile it, which would also work.
In your case I am not sure that sort of thing is the best way to go. I think that I would do this by using dynamic libraries. Make a directory that is supposed to contain "plugins" and let the user compile their own. Make your program scan the directory and load each DLL or .so it finds.
Doing it this way means you spend less time writing code compilers and more time actually getting stuff done.
If you can write your dynamic extensions in C (not C++), you might find the Tiny C Compiler to be of use. It's available under the LGPL, it's compatible for Windows and Linux, and it's a small executable (or library) at ~100kb for the preprocessor, compiler, linker and assembler, all of which it does very fast. The downside to that, of course, is that it can't compare to the optimizations you can get with GCC. Another potential downside is that it's X86 only AFAIK.
If you did decide to write assembly, TCC can handle that -- the documentation says it supports a gas-like syntax, and it does support X86 opcodes.
TCC also fully supports ANSI C, and it's nearly fully compliant with C99.
That being said, you could either include TCC as an executable with your application or use libtcc (there's not too much documentation of libtcc online, but it's available in the source package). Either way, you can use tcc to generate dynamic or shared libraries, or executables. If you went the dynamic library route, you would just put in a Render (or whatever) function in it, and dlopen or LoadLibrary on it, and call Render to finally run the user-designed rendering. Alternatively, you could make a standalone executable and popen it, and do all your communication through the standalone's stdin and stdout.
Since you're generating pixels to be displayed on a screen, have you considered using HLSL with dynamic shader compile? That will give you access to SIMD hardware designed for exactly this sort of thing, as well as the dynamic compiler built right into DirectX.
LLVM should be able to do what you want to do. It allows you to form a description of the program you'd like to compile in an object-oriented manner, and then it can compile that program description into native machine code at runtime.
Nanojit is a pretty good example of what you want. It generates machine code from an intermediate langauge. It's C++, and it's small and cross-platform. I haven't used it very extensively, but I enjoyed toying around just for demos.
Spit the code to a file and compile it as a dynamically loaded library, then load it and call it.
Is there are reason why you can't use a GPU-based solutions? This seems to be screaming for one.
I'm writing a graphical application using Objective-C for the front end and C++ for the graphics processing and network communication. I read around on Apple's site looking for a way to link either a .dylib or .so with my C++ code in it to my Xcode project, but nothing seemed to work. I was able to get the project to reference it and link against it, but when I tried to call functions from that .dylib, it was saying that it didn't know what I was trying to do. Does anyone know what is going on here?
I know that Objective-C has all the libraries I would need to do graphics and networking, but I just feel like doing it like this. I haven't done much C++ in a while and I want to learn more Objective-C, so what better way than to use them together?
Thanks,
Robbie
Most of the projects I work on have an ObjC frontend and C++ backend. If you're dealing exclusively with functions, then Dave Gamble's name mangle fix is correct, but if you're dealing with more complex situations, where you need to deal with both ObjC and C++ objects, your best bet is to wrap the C++ objects in ObjC objects. Using opaque references (which is a very fancy way of saying void*), you can actually hand around C++ objects in ObjC and vice versa. I have some sample code that may be helpful.
That said, for graphics you're probably going to take a serious performance hit doing custom C++ rather than using Core Image and the related frameworks. Core Image and the other graphics frameworks are highly optimized for the Mac, and you're very unlikely to do better with hand-rolled C++ (or even very well-written C++ that isn't specifically for the Mac). As you move to 10.6 and grand central dispatch, the performance difference is going to be even more notable because you'll lose all the parallelization advances that you would get for free otherwise. This has nothing to do with ObjC; Core Image is C. You can call it from C++ all you like. I just recommend against custom graphics processing on Mac in any language unless you need portability or you have the expertise necessary to beat Core Image.
You're going to hit one obstacle in the form of what's called "name mangling". C++ stores function names in a way not compatible with Obj-C.
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
One way around this is to implement a set of simple C functions which call the C++ functions. It'll be a good challenge to keep the number of C functions as low as possible! You'll end up with a nice compact interface! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
extern "C" int function_name(char *blob,int number, double foo) {...}
This disables the standard name-mangling.
Build a header file with the prototypes for all these functions that you can share with your objective C code.
You won't be able to pass classes around in the same way (because your ObjC code can't use them), but you'll be able to pass pointers (although you might have to lie about the types a little).
I have some code which I need to code in C++ due to heavy reliance on templates. I want to call this code from MATLAB: basically, I need to pass some parameters to the C++ code, and have the C++ code return a matrix to MATLAB. I have heard this is possible with something called a MEX file which I am still looking into. However I am not sure what is supported in these MEX files. Is all of C++ (e.g. STL and Boost) supported? How difficult is it?
EDIT: I don't need any shared libraries, just header-only stuff like shared_ptr.
Have a look at the MEX-files Guide, especially Section 25–27 for C++.
The basic STL/Boost data structures should work, but threading with Boost could be a problem.
cout will not work as expected in C++, mexPrintf has to be used instead.
It's certainly possible to write C++ MEX files which use STL and boost. In general, you should be able to do anything you please inside a C++ MEX file. The main practical restriction is that MATLAB already ships with a bunch of libraries, so if you're using one of the boost pieces that needs a shared library (some are header-only), you'll need to match the version you compile against with that shipping with MATLAB.
For instance, MATLAB R2009b ships with boost 1.36 (you can tell by looking at the names of the libraries in <matlabroot>/bin/<arch>).
The C++ files are actually compiled by an external compiler. Use mex -setup to select which one (here is a list of supported compilers). Therefore, you shouldn't have too many weird things happen, nor should you be too restricted by what you can do.
I did some MEX stuff last year, and my memory is a bit rusty, but you do need to construct MATLAB arrays using MEX functions. I found the MATLAB documentation adequate, and the whole experience not too painful.
STL is definitely supported. Boost probably yet. The point is as long you have your STL and BOOST deployed on your computer, you should be good to go.