Heterogenous computing using OpenCl Vs java - java

Java and OpenCL both support Heterogeneous Computing; systems with multiple architecture working cooperatively in parallel(Task and data parallel ).
portability is the main goal in both the cases, and both have achieved this goal to a large extent. In fact still OpenCl cannot be run on FPGAs and DSPs, as the tools are not available. JVM can be developed for GPUs FPGA, ARM etc.
Both generate intermediate code.
Despite so many similarities why and when should one prefer OpenCL over Java for Heterogeneous Computing?
EDITED
Please be specific to my question: Despite so many similarities why and when should one prefer OpenCL over Java for Heterogeneous Computing? Why at all I chose OpenCL instead of Java?
If you say openCl has better performance then my immediate question will be why it is so(since both generate intermediate code that need to be converted into binaries for specific h/w).

OpenCL is normally used for processing large amounts of parallel operations(calculations etc). This is where OpenCL thrives and the throughput of your program is really increased by it.
Java is a general purpose language for writing applications running on various platforms/devices.
They have a different purpose as tools but you can use OpenCL from your Java program using JOCL. I also used a tool from AMD called Aparapi. because I wanted my application to carry out some calculations, a job that my ASUS AMD 6970 card seemed to get done faster than my 6 core AMD 1090T Phenom Black Edition.
Just for you to know what Aparapi is(taken from the google code site):
Aparapi allows Java developers to take advantage of the compute power
of GPU and APU devices by executing data parallel code fragments on
the GPU rather than being confined to the local CPU. It does this by
converting Java bytecode to OpenCL at runtime and executing on the
GPU, if for any reason Aparapi can't execute on the GPU it will
execute in a Java thread pool.
Despite so many similarities why and when should one prefer OpenCL
over Java for Heterogeneous Computing?
One would choose OpenCL for parallel processing tasks that would otherwise take a lot of time to be executed on the CPU. The disadvantage in this case would be the extra heat and power consumption costs. Bear also in mind that some tasks would execute faster on a CPU. It all depends on the application that most of the time would require trials on both types of chips in order to decide which one does the job best.
Why at all I chose OpenCL instead of Java?
One would choose OpenCL over Java for parallel processing oriented tasks. OpenCL is a tool built for this purpose. OpenCL is not something you would use for building enterprise or desktop applications. Java is a programming language for almost any domain running on many platforms. If one would know that using OpenCL would save them 24 hours of calculations over Java; of course Java would be sidelined and OpenCL would be the way to go or simply OpenCL could be used through a Java application.
If you say openCl has better performance then my immediate question
will be why it is so(since both generate intermediate code that need
to be converted into binaries for specific h/w).
It has better performance on specific applications since GPU have more cores than a CPU. Their frequency though is quite low so this means that they are better on parallel tasks rather than sequential. You have to bear in mind that OpenCL is used for basic calculations and not for building full flavor applications...at least as far as I know.

Related

Java use GPU for calculating with BigInteger

I'm currently working on a project which involves allot of calculating with quiet large numbers which is why I use BigInteger. But obviously my application is really slow.
I don't know allot about GPUs, but I heard that they can be used to calculate larger numbers much more faster. So I wonder if there is a way to give the "heavy number calculations" to the GPU and speed up my application this way.
You can check #Parallel annotation provided by this lib:
https://code.google.com/archive/p/java-gpu/
There's a Java binding for OpenCL, which is the standard API for doing non-graphics GPU computation. If your computer doesn't support OpenCL, you could also use OpenGL to do calculations with a fragment shader, though that's a bit more awkward.
You'll need to rewrite your calculations in a specialized language, though: OpenCL's variant of C, or OpenGL's shading language. You can't just offload your Java code to a GPU, because GPUs don't understand Java bytecode. And there's no built-in equivalent to BigInteger in either OpenCL or OpenGL.
Keep in mind that GPUs are designed for a specific kind of workload: running the same code simultaneously on many different data items. GPUs don't magically make math faster. Using OpenCL/OpenGL is only likely to help if your calculations can be split up into many parallel tasks, all running the same code at the same time.
Point is: java bytecode is executed via the JVM. Which runs ... on your ordinary processors.
So, theoretically, a JVM implementation would be free to "outsource" certain computations to GPU hardware; but to my knowledge; there is no JVM doing that as of now.
Of course, there is room for using JNI in order to connect CPU and GPU world, like the javacl project mentioned in the other answer.
In any case, you might turn here for further reading.

OpenCV (JavaCV) vs OpenCV (C/C++ interfaces)

I am just wondering whether there would be a significant speed performance advantage relatively on a given set of machines when using JavaCV as opposed to the C/C++ implementation of OpenCV.
Please correct me if I am wrong, but my understanding is that the c/c++ implementation of opencv is closer to the machine where as the Java implementation of OpenCV, JavaC, would have a slight speed performance disadvantage (in milliseconds) as there would be a virtual machine converting your source code to bytecode which then gets converted to machine code. Whereas, with c/c++, it gets converted straight to machine code and thus doesn't carry that intermediary step of the virtual machine overhead.
Please don't kill me here if I made mistakes; I am just learning and would welcome constructive criticism.
Thank you
I'd like to add a couple of things to #ejbs's answer.
First of all, you concerned 2 separate issues:
Java vs. C++ performance
OpenCV vs JavaCV
Java vs. C++ performance is a long, long story. On one hand, C++ programs are compiled to a highly optimized native code. They start quickly and run fast all the time without pausing for garbage collection or other VM duties (as Java do). On other hand, once compiled, program in C++ can't change, no matter on what machine they are run, while Java bytecode is compiled "just-in-time" and is always optimized for processor architecture they run on. In modern world, with so many different devices (and processor architectures) this may be really significant. Moreover, some JVMs (e.g. Oracle Hotspot) can optimize even the code that is already compiled to native code! VM collect data about program execution and from time to time tries to rewrite code in such a way that it is optimized for this specific execution. So in such complicated circumstances the only real way to compare performance of implementations in different programming languages is to just run them and see the result.
OpenCV vs. JavaCV is another story. First you need to understand stack of technologies behind these libraries.
OpenCV was originally created in 1999 in Intel research labs and was written in C. Since that time, it changed the maintainer several times, became open source and reached 3rd version (upcoming release). At the moment, core of the library is written in C++ with popular interface in Python and a number of wrappers in other programming languages.
JavaCV is one of such wrappers. So in most cases when you run program with JavaCV you actually use OpenCV too, just call it via another interface. But JavaCV provides more than just one-to-one wrapper around OpenCV. In fact, it bundles the whole number of image processing libraries, including FFmpeg, OpenKinect and others. (Note, that in C++ you can bind these libraries too).
So, in general it doesn't matter what you are using - OpenCV or JavaCV, you will get just about same performance. It more depends on your main task - is it Java or C++ which is better suited for your needs.
There's one more important point about performance. Using OpenCV (directly or via wrapper) you will sometimes find that OpenCV functions overcome other implementations by several orders. This is because of heavy use of low-level optimizations in its core. For example, OpenCV's filter2D function is SIMD-accelerated and thus can process several sets of data in parallel. And when it comes to computer vision, such optimizations of common functions may easily lead to significant speedup.
JavaCV interfaces to OpenCV, so when you call something OpenCV related there would be some overhead but in general most of the heavy work will still be on the C++ side and therefore there won't be a very large performance penalty.
You would have to do performance benchmarks to find out more.
PS. I'm pretty new here but I'm rather sure that this is not a suitable question for StackOverflow.
i would like to add a few more insights on java as an interface to c++ libraries...
A)developing:
1)while java may be easier to manage large scale projects and compiles extremely fast, it is very very hard, and next to impossible to debug native code from java...
when code crush on native side...or memory leaks( something that happens a lot... ) you feel kind of helpless...
2)unless you build the bindings yourself( not an easy task even with using swig or whatever... ) you are dependent on the good will/health/time of the bindings builder....
so in this case i would prefer the official "desktop java " bindings over javacv...
B)performance.
1) while bindings may be optimized( memory transfer using neobuffer ) as in the javacv case there is still a very very small jni overhead for each native function call -
this is meaningless in our case since most opencv functions consume X100000++ cpu cycles compared to this jni overhead...
2) The BIG-PROBLEM ---- stop the world GARBAGE COLLECTIOR( GC )
java uses a garbage collector that halts all cpu's threads making it UNSUITABLE for REAL-TIME application's , there are work-around's iv'e heard of like redesigning your app not to produce garbage, use a spaciel gc, or use realtime java( cost money... ) they all seem to be extra-work( and all you wanted is a nice easy path to opencv.... )
conclusion - if you want to create a professional real time app - then go with c++
unless you have a huge modular project to manage - just stick with c++ and precompiled headers( make things compile faster... )
while java is a pleasure to work with , when it comes to native binding's HELL breaks loose...i know iv'e been there....

Suitable replacement for java to develop a cross-platform application

I've always used java for developing cross platform applications, however, this time java can not solve my problem. The problem is, I have to develop an application which is computationally expensive. More precisely, in my application there is a simulation which is a little too heavy. I made a java prototype app but it's not fast enough and I have some lag in my simulation so I started to think to switch to c++.
My application has a GUI and I was wondering if I want to switch to c++ for a cross platform application, what should I do with GUI?
My questions are:
If I use Qt framework, is my application going to be significantly faster?
If I deploy my jar file to native os executable (.exe, .app, etc) is my application going to be significantly faster?
p.s. Mac OSx, Windows and Ubuntu are target platforms for my software.
This Article may Help You, I Face the same questions a couple of years ago. I decided to stick with Java for my own programming experience, since I'm not that good in C++ and my project was to be honest, very simple. As you know, Java is a very spread / wide around the world, tons of docs and libraries ready for you to use, Qt is faster, but you will need to get your hands dirty to do the job. If performance is your goal, Go Qt. Or redesign your application to hava Java/Swing GUI and C++ programs server side. Anyways here's the link.
http://turing.iimas.unam.mx/~elena/PDI-Lic/qt-vs-java-whitepaper.pdf
Java/Swing may be appropriate for certain projects, especially those without GUIs
or with limited GUI functionality. C++/Qt is an overall superior solution, particularly for GUI applications.
Using C++ instead of Java improves CPU performance, sometimes as much as 10-30%. However using multiple threads also increases the amount of CPU you have available. Given using multiple threads didn't help, I suspect your bottleneck is not in CPU and switching language is unlikely to help.
Where C can help is in programming graphics cards, e.g. CUDA. You can get dramatically faster results for certain types of problems using a high performance processing card. http://www.nvidia.co.uk/object/cuda_home_new_uk.html There are JOCL libraries to use CUDA from Java, but the code which does the real work is in a C-like language.
I suggest you determine where your bottle neck really is as switching to C++ will not increase the size of your cache, your memory bandwidth, IO bandwidth or the size of your main memory.

Java on GPU: Complete Method directly on GPUin plain Java

Firstly: Is it possible to use Java and let it (partly) run on or use GPUs?
And if it's possible, is it possible to use the normal Java syntax and not using special cuda or opencl syntax?
I want just take my coded java source and let it run with the smallest changes possible on GPUs.
I would greatly appreciate code samples.
Consider Aparapi http://aparapi.github.io/. It attempts to convert bytecode to OpenCL at runtime. So you can code for your GPU in pure Java.
Full disclosure, I am the Aparapi lead developer.
The Rootbeer GPU Compiler supports running arbitrary Java code on the GPU. It is more full featured than Aparapi. Rootbeer supports arbirary object graphs of any type.
It was just released open source on my github account:
https://github.com/pcpratts/rootbeer1
There are several Java bindings to CUDA and OpenCL (jcuda.org, jocl.org, something else also called jocl) but these are all just ways to get CUDA or OpenCL code running on the GPU via Java and require you to write your code specifically for that. I don't think there is an easy way to run an arbitrary multi-threaded Java program on the GPU with just minor changes to the code.
What does your Java program do that you want to run on the GPU?
You have to take into account that the architecture of a GPU is quite different than that of a CPU; cores on a GPU are not general-purpose cores that can do anything and work independently, as in an Intel x86 CPU. To really take advantage of the specific SIMD architecture of a GPU, your code has to be written with that architecture in mind.
TornadoVM is a plug-in to OpenJDK that allows programmers to automatically run Java programs on heterogeneous hardware. TornadoVM currently targets OpenCL-compatible devices and it runs on multi-core CPUs, GPUs (NVIDIA and AMD), Intel integrated GPUs, and Intel FPGAs.
Take a look here: https://github.com/beehive-lab/TornadoVM
Have a look on http://code.google.com/p/java-gpu/.
It compiles pure java code into kernels, with only using annotations.

Which programming language for compute-intensive trading portfolio simulation?

I am building a trading portfolio management system that is responsible for production, optimization, and simulation of non-high frequency trading portfolios (dealing with 1min or 3min bars of data, not tick data).
I plan on employing Amazon web services to take on the entire load of the application.
I have four choices that I am considering as language.
Java
C++
C#
Python
Here is the scope of the extremes of the project scope. This isn't how it will be, maybe ever, but it's within the scope of the requirements:
Weekly simulation of 10,000,000 trading systems.
(Each trading system is expected to have its own data mining methods, including feature selection algorithms which are extremely computationally-expensive. Imagine 500-5000 features using wrappers. These are not run often by any means, but it's still a consideration)
Real-time production of portfolio w/ 100,000 trading strategies
Taking in 1 min or 3 min data from every stock/futures market around the globe (approx 100,000)
Portfolio optimization of portfolios with up to 100,000 strategies. (rather intensive algorithm)
Speed is a concern, but I believe that Java can handle the load.
I just want to make sure that Java CAN handle the above requirements comfortably. I don't want to do the project in C++, but I will if it's required.
The reason C# is on there is because I thought it was a good alternative to Java, even though I don't like Windows at all and would prefer Java if all things are the same.
Python - I've read somethings on PyPy and pyscho that claim python can be optimized with JIT compiling to run at near C-like speeds... That's pretty much the only reason it is on this list, besides that fact that Python is a great language and would probably be the most enjoyable language to code in, which is not a factor at all for this project, but a perk.
To sum up:
real time production
weekly simulations of a large number of systems
weekly/monthly optimizations of portfolios
large numbers of connections to collect data from
There is no dealing with millisecond or even second based trades. The only consideration is if Java can possibly deal with this kind of load when spread out of a necessary amount of EC2 servers.
Thank you guys so much for your wisdom.
Pick the language you are most familiar with. If you know them all equally and speed is a real concern, pick C.
While I am a huge fan of Python and personaly I'm not a great lover of Java, in this case I have to concede that Java is the right way to go.
For many projects Python's performance just isn't a problem, but in your case even minor performance penalties will add up extremely quickly. I know this isn't a real-time simulation, but even for batch processing it's still a factor to take into consideration. If it turns out the load is too big for one virtual server, an implementation that's twice as fast will halve your virtual server costs.
For many projects I'd also argue that Python will allow you to develop a solution faster, but here I'm not sure that would be the case. Java has world-class development tools and top-drawer enterprise grade frameworks for parallell processing and cross-server deployment and while Python has solutions in this area, Java clearly has the edge. You also have architectural options with Java that Python can't match, such as Javaspaces.
I would argue that C and C++ impose too much of a development overhead for a project like this. They're viable inthat if you are very familiar with those languages I'm sure it would be doable, but other than the potential for higher performance, they have nothing else to bring to the table.
C# is just a rewrite of Java. That's not a bad thing if you're a Windows developer and if you prefer Windows I'd use C# rather than Java, but if you don't care about Windows there's no reason to care about C#.
I would pick Java for this task. In terms of RAM, the difference between Java and C++ is that in Java, each Object has an overhead of 8 Bytes (using the Sun 32-bit JVM or the Sun 64-bit JVM with compressed pointers). So if you have millions of objects flying around, this can make a difference. In terms of speed, Java and C++ are almost equal at that scale.
So the more important thing for me is the development time. If you make a mistake in C++, you get a segmentation fault (and sometimes you don't even get that), while in Java you get a nice Exception with a stack trace. I have always preferred this.
In C++ you can have collections of primitive types, which Java hasn't. You would have to use external libraries to get them.
If you have real-time requirements, the Java garbage collector may be a nuisance, since it takes some minutes to collect a 20 GB heap, even on machines with 24 cores. But if you don't create too many temporary objects during runtime, that should be fine, too. It's just that your program can make that garbage collection pause whenever you don't expect it.
Why only one language for your system? If I were you, I will build the entire system in Python, but C or C++ will be used for performance-critical components. In this way, you will have a very flexible and extendable system with fast-enough performance. You can find even tools to generate wrappers automatically (e.g. SWIG, Cython). Python and C/C++/Java/Fortran are not competing each other; they are complementing.
Write it in your preferred language. To me that sounds like python. When you start running the system you can profile it and see where the bottlenecks are. Once you do some basic optimisations if it's still not acceptable you can rewrite portions in C.
A consideration could be writing this in iron python to take advantage of the clr and dlr in .net. Then you can leverage .net 4 and parallel extensions. If anything will give you performance increases it'll be some flavour of threading which .net does extremely well.
Edit:
Just wanted to make this part clear. From the description, it sounds like parallel processing / multithreading is where the majority of the performance gains are going to come from.
It is useful to look at the inner loop of your numerical code. After all you will spend most of your CPU-time inside this loop.
If the inner loop is a matrix operation, then I suggest python and scipy, but of the inner loop if not a matrix operation, then I would worry about python being slow. (Or maybe I would wrap c++ in python using swig or boost::python)
The benefit of python is that it is easy to debug, and you save a lot of time by not having to compile all the time. This is especially useful for a project where you spend a lot of time programming deep internals.
I would go with pypy. If not, http://lolcode.com/.

Categories

Resources