[akka-user] Mixing Akka/Scala with C/C++

1,462 views
Skip to first unread message

Giovanni

unread,
Apr 1, 2012, 9:14:18 PM4/1/12
to akka...@googlegroups.com
Very soon I have to start to build some systems for computer graphics (3D animation).

Computer graphics need a lot of computing power. A lot of mathematical algorithms are involved.

Here is my guess:
  • for real-time processing, maybe a good approach is to use the power of modern GPUs (CUDA, openCL)
  • for massive offline processing, it is better to use a concurrent and scalable system

What do you think? Any other ideas?

In case of using a concurrent/scalable system, I would like to use Akka/Scala.

My questions are:

  • is it possible and easy to integrate some piece of programs written in C/C++ inside Akka/Scala?
  • if yes, how? what is the suggested way?

I am asking this, because probably I need to use openCV library for making some image processing and this library is native in C++. I know that there are some Java wrappers (JavaCV), but I think it is faster to use directly the native library. Also probably I have to use many other libraries written in C/C++ (e.g. openGL) or openCL or CUDA, etc.

My idea is to build the concurrent and scalable structure of the system by using Akka/Scala and then implement some specific parts (actors?) by using specific languages more suitable for the specific tasks.

Any suggestions/advices?

Best regards,

giovanni


Ngoc Dao

unread,
Apr 2, 2012, 10:54:56 PM4/2/12
to Akka User List
You can use JNI, JNA, or ZeroMQ:
http://doc.akka.io/docs/akka/2.0/scala/zeromq.html


On Apr 2, 10:14 am, Giovanni <pino.o...@gmail.com> wrote:
> Very soon I have to start to build some systems for computer graphics (3D
> animation).
>
> Computer graphics need a lot of computing power. A lot of mathematical
> algorithms are involved.
>
> Here is my guess:
>
>    - for real-time processing, maybe a good approach is to use the power of
>    modern GPUs (CUDA, openCL)
>    - for massive offline processing, it is better to use a concurrent and
>    scalable system
>
> What do you think? Any other ideas?
>
> In case of using a concurrent/scalable system, I would like to use
> Akka/Scala.
>
> My questions are:
>
>    - is it possible and easy to integrate some piece of programs written in
>    C/C++ inside Akka/Scala?
>    - if yes, how? what is the suggested way?

cessationoftime

unread,
Apr 2, 2012, 11:29:06 PM4/2/12
to akka...@googlegroups.com
I use nativelibs4java on github for this kind of thing, runs native code and supports Scala

Giovanni

unread,
Apr 3, 2012, 12:23:57 AM4/3/12
to akka...@googlegroups.com
What is the loss of performance by using a solution with Scala + calls to native code libraries (C++), compared to a solution with the full system developed in C++?

Due to the mandatory use of native libraries in C/C++ (e.g. openCV, openGL, openCL), is it reasonable to develop a full system in C++? or is it wiser to develop the system in Scala/Java and make native calls to the C++ libraries, when needed?

I am in this big dilemma for setting up a big computer graphics project.

I think that using C++ for the full system only because it is easier to call the native libraries is not meaningful. I am not expert on C++, but I understand that the development of a good program in C++ is slower and more difficult and the performance gain achieved maybe is not worth the efforts.

Also C++ is quite an old language, while Scala is newer and more oriented to the future.

What do you think? Any wise advice?

Best regards,
giovanni


On Tue, Apr 3, 2012 at 11:29 AM, cessationoftime <cessati...@gmail.com> wrote:
I use nativelibs4java on github for this kind of thing, runs native code and supports Scala

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/5Ja9sour3rgJ.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.


Viktor Klang

unread,
Apr 3, 2012, 10:27:52 AM4/3/12
to akka...@googlegroups.com
I'd recommend doing a prototype in each (C++/Scala).

Cheers,

Raymond Roestenburg

unread,
Apr 8, 2012, 8:24:03 AM4/8/12
to akka...@googlegroups.com
We have been using Scala with C through JNA for quite a long time now (since 2010) and it works very well for us.
We built a Java image library which uses JNA to talk to C libraries. (we do image processing, image recognition, that kind of stuff)
 We kept the image library and it's API as simple as possible. 

We chose to do only the low-level stuff in the C library and everything else in Scala. This worked really well and allowed us to focus on the important things instead of low level machinery (and bugs) everywhere.

Some specific things you need to take care of:
- If your C (or C++ for that matter) code ever crashes, there is nothing much you can recover from, the JVM crashes as well and dumps, unless you write signal handlers for it (not so trivial as it seems), so be careful there. Your C code has to be rock solid.
- Single threaded libraries. We have found that quite often C libs are not thread safe, or do not expect multithreaded usage. We have some third party libraries that require a hardware key to operate, and we had to use mutexes in C to make sure the hardware key only get's used by one thread at a time. libjpeg is also not thread safe, so there we had to do some locking as well in C. So you might have to look at how the libraries you use respond to multithreaded access, and weigh the benefit of fast single threaded libs compared to thread safe java libs. Java API's for for instance JPEG wil eventually use libjpeg anyway.  

Writing a large system in scala and akka is _far_ easier IMHO than writing a large system in C or C++, if you can get away with it. It really depends on how tightly you want to integrate and stay on the low level interfaces, but for large systems, that doesn't sound like a good idea anyway.
 
IMHO, writing good C/C++ systems on a large scale is _very_ hard and takes far more time to get right.

cessationoftime

unread,
Apr 8, 2012, 2:00:31 PM4/8/12
to akka...@googlegroups.com
NativeLibs4Java's Bridj design page says there have been assembler optimizations in Bridj to improve performance over JNA.

"Without these optimizations, BridJ's performance is about the same as JNA in direct mode (without structs, where BridJ is much faster). With the optimizations, BridJ is about 10% slower than pure JNI, that is 5x faster than JNA in direct mode. "

From this we can say that for the best speed use JNI, but for ease of coding use Bridj or perhaps JNA.  How good JNI is vs. straight native I don't know.  If I really had to have speed I would consider the D language.

Giovanni

unread,
Apr 8, 2012, 7:56:09 PM4/8/12
to akka...@googlegroups.com
Hi Raymond,

thanks for your interesting reply.

I also think that "writing good C/C++ systems on a large scale is _very_ hard and takes far more time to get right." That is the reason why I want to use Akka/Scala for the most part of the system and call native libraries only when big computing power is needed (maybe using GPU processing through OpenCL or CUDA) or there is a need to call specific functions (e.g. openCV).

I am also in the field of image processing, image recognition, 3D animation, rendering, etc. However I am a beginner in this area. I recently started to work in an computer animation research center.
May I ask you some more information about what systems are you developing? Maybe my research center could be interested in some collaborations.

Best regards,
giovanni

Raymond Roestenburg

unread,
Apr 11, 2012, 3:34:34 AM4/11/12
to akka...@googlegroups.com
Hi Giovanni,

We are building turn key systems for traffic enforcement, (section speed and point speed enforcement on public roads basically) so it is a combination of hardware and software, the image processing we do is mostly related to recognizing features of vehicles driving on the road, like license plate recognition from still camera's amongst other things.   
Raymond Roestenburg
Reply all
Reply to author
Forward
0 new messages