I'm looking for some way of using the number-crunching ability of a GPU (with Java perhaps?) in addition to using the multiple cores that the target machine has. I will be working on implementing (at present) the A* Algorithm but in the future I hope to replace it with a Genetic Algorithm of sorts. I've looked at Project Fortress but as I'm building my GUI in JavaFX, I'd prefer not to stray too far from a JVM.
Of course, should no feasible solution be available, I will migrate to the easiest solution to implement.
If you're interested in HPC with GPUs then perhaps you can look jCuda. This provides Java bindings for CUDA, along with access to CUDA FFT, CUDA BLAS and CUDA DPP. I haven't seen any performance reports on this library so I can't guarantee it will be very good.
Beyond that, I'm not really sure. If you're interested in doing this type of stuff as an educational exercise then Java should be good enough, but if you have a serious need for HPC then you're probably going to want to implement in C and use the Java Native Interface to communicate with it.
Morten Nobel Joergensen has a blog post showing how to create a Mandelbrot Set using JOGL - Java Bindings for OpenGL
However if you want generic computing, rather than graphics, then you'd be after the Java bindings for OpenCL, from which you can chose from JOCL, or JOCL or JavaCL.
Wikipedia's page shows how OpenCL can be used to compute a fast fourier transform.
Parallel Colt might be of interest.
Have a look at JPPF, it is a very nice and mature open source Java grid computing environment
Related
I'm implementing an algorithm for pathfinding that is a variant of A* (HPA*) but with a triangulated search space. I've been making a Java application and have written a good amount of code, but I recently found a C++ library that already takes care of the triangulations for the project. I have several options but I'm not sure what I should do: convert the library to Java or integrate the C++ code into my Java library. I could also rewrite my code in C++ but I'm not very familiar with the language.
This application tests the performance of an algorithm for a paper I'm writing so it doesn't need to be portable. What do you think my best option is?
If you really want to call C++ code from Java, read up on the Java Native Interface (JNI) coding conventions.
But generally, unless you have an extremely good reason to cross languages, it's more trouble than it's worth. How complicated is the triangulation code? If it's less than a few hundred lines, I'd suggest reimplementing; if it's more than a few thousand, using a library may be justified but you should probably check whether there's a Java library available or if someone has already written the appropriate JNI glue code.
I'm searching for a rich 2d multimedia framework that's meant to be used with the JVM
There's SDL and SFML for C and C++.
I've used Pygame with Python. It's very productive.
XNA is great, too.
What about the JVM ? I know that there's a wrapper around SDL http://sdljava.sourceforge.net/ but since the last entry on the homepages newsfeed dates back to 2005 it doesn't feel particularly alive.
Basically what I'm looking for is a hardware accelerated 2d canvas for the JVM that is backed with a neat framework.
I know that C, C++ and even Python (to some extent) can be considered low-level languages. Java on the other hand abstracts over the hardware. Therefore what I'm searching for is not it's "natural territory". Nevertheless http://lwjgl.org/ is a great example of what is possible in Java.
Googling brought up this interesting project http://libgdx.badlogicgames.com/ . Have you used it ? Do you know alternatives ? Please note: I'd like to use Scala, not Java. Therefore the stress on JVM and not just Java.
Have you already looked at JavaFX 2.0?
Rendering engine is based on prism, which supports hardware and software rendering (this means it will use either DirectX or OpenGL or Java 2D depending on what's available). You can find more information about it's architecture here:
JavaFX Architecture and Framework
It uses Scene Graph in order to define things you want to render. Here you can find small introduction:
Working with the JavaFX Scene Graph
Scalafx project provides Scala bindings for JavaFX 2.0.
If you want something that works use http://lwjgl.org/ from scala.
I'm a complete newbie in the computer vision world and recently I implemented some examples using OpenCV with Java. I'm impressed with the potential this area has and wish to continue learning more.
I learned that OpenCV is written in C++ and while Java has a wrapper (JavaCV) I understood that the applications in Java are slower than in C++ and most enterprise application are written in C++.
My question is this: I have few years of experience in Java and I feel very comfortable to write any application with it; would it be smart to move to C++ to learn CV or should I stick with Java and use its wrapper.
Computer vision is a demanding area - and while it is true that you'd best stay with what you know, and move to opencv only if performance is needed, another truth is that you'll need to go deep into mathematics, pointers and algorithms to learn and build a good computer vision app. And to do that in Java can be more cumbersome than learning c++.
So, if all you want to do is to apply a filter over an image for some school project - go for Java. But if you want to stay more with OpenCV, to learn vision algorithms or to write your own, my strong suggestion is to learn C++ - isn't that scary!
A reason to write native code is flexibility - you'll want to do all kind of tricks that are difficult or performance-killers in Java.
Shortly speaking, learning C++ is much simpler than computer vision. And OpenCV is not just a library you want to call to do some processing out there. It's bleeding edge technology - you'll want to understand it, to hack into it, to build over it, to go through the code, much more than call someJNIfunc();
And if you do so, please be aware that OpenCV offers two interfaces - one for C and one for C++. And while they offer the same functionality, the C++ one is much like Java - with automatic memory management and more sweeties. You can refer to this post to see the differences
I suggest sticking with what you're comfortable with for now. Only switch to C++ when you find that it doesn't expose certain APIs you want or performance actually becomes a problem. Right now, you're in the learning phase.
JavaCV uses a wrapper called JavaCPP to call OpenCV from Java programs. JavaCPP automatically generates temporary native libraries that form a bridge used by JNI to let Java programs call the OpenCV native libraries.
The solution is elegant and it works well, but is quite finicky about installing just the right versions and having classpaths set correctly. You can get a glimpse of the difficulties people face at the JavaCV discussion forum, and at http://code.google.com/p/javacv/wiki/Windows7AndOpenCV.
I got this working with OpenCV-2.3.1 on XP, Windows 7, and Ubuntu 10.11, and still it took me several days to get it all updated to OpenCV-2.4.2. ffmpeg is especially tricky to get right across all platforms.
There is little or no speed overhead if you are using Java for high level program control because image objects and list-based data structures are maintained on the native side through pointers. One pitfall is knowing who is responsible for releasing allocated memory, so be prepared for VM crashes with complicated programs.
There is a bit overhead in transferring data objects to the Java side. I find that it takes about 1 microsecond to copy a keypoint location into a Java-side Point object. This doesn't sound like much but in a real-time application with thousands of keypoints it can make a difference. We also copy JavaCV IplImage objects to Java through ByteBuffers. This takes a millisecond or less so is quite feasible for real-time use.
In our case, we have a substantial body of Java code to leverage against OpenCV. And Java's garbage collection makes many things much much easier. I are satisfied that the overhead of learning JavaCV has been well worth it.
I found it necessary to build the project in Eclipse and compile JavaCV from source instead of using javacv.jar. (You'll need the other .jar files though.) This lets you examine exceptions to track down library version and classpath errors. And the JavaCV source is needed to understand how JavaCV exposes the OpenCV API.
How much time is spent in the OpenCV library and how much time is spend in your program? If your program entirely in C++ it cannot reduce the time spent in your program (outside the library) to less than nothing. e.g. if you spend 99% of your time in the library, using C++ cannot make it more than 1% faster.
For simple programs, Java and C++ doesn't make any significant difference in speed. But for a large code with lot of computational complexity, C++ turns out to be faster.
Wrappers do have a problem of overhead. But this will be negligible for a small program. If you write a complex code in Java, it wont be easy to rewrite it into C++. This is because of the large no of functions available in Java which will be so much different from C++.
Whether you should use Java or C++ for OpenCV depends on your motive.
If you seriously want to lean OpenCV and work on some big projects , I suggest you to move on to C++. But if you are looking for having just some fun with OpenCV, it will be better to stick to what you know.
Among C++ or Java, better use C++. I have almost no experience in Java, but the reason I would recommend C++ is its common usage among ML&CV libraries.
One of the best solution of powerful and flexible computer vision application may be next sequence:
training a model using flexible Python and popular machine learning libraries;
storing pre-trained weights;
rewriting the best model architechture to C++ using OpenCV library with useful, but not extensive Mat class or compiling to C++ ML model;
compiling with definite specification of your device processor.
Advances of this solution are application work speed, code safety, development speed and compatibility with many devices.
Moreover, Python Tensorflow and other models could be loaded to C++, e.g. PyTorch.
Besides, it is much more easier to get help from CV community with the C++ OpenCV code.
Disadvantages are tons of development problems and development speed (which may not be omitted with Java), sometimes strictful flexibility limits of OpenCV lib, and many others you may not think of at the beginning.
For the program idea I have, it requires that the software be written in one binary that is executeable by all major desktop platforms, meaning it needs an interpreted language or a language within a JVM. Either is fine with me, but the programming language has to balance power & simplicity (e.g. Python)
I know of wxPython but I have read that it's support on Mac OS X is fairly limited
Java sounds good & it looks good but it seems almost too difficult to program in
Any help?
I used Python with wxPython for quite a while and found it very easy to use. I now use Java with both Swing and SWT.
I prefer Java but that's just a personal preference so you shouldn't let that sway you.
I didn't find the transition from Python to Java that difficult. In terms of GUI, they both have the layout manager paradigm - the managers are different but not so different you'll have trouble switching.
Java has an absolute huge class library to the point where you probably don't need to write your own version of anything, just string together the components. I never really got that deep into Python but it may well be similar. One thing I did notice is that all the really good stuff I used in Python (e.g., s[-4:-1]) could still be done quite easily in Java. Both languages were a step up from C where I had to manage strings with my own libraries.
If you think wxPython is limited on MacOS, you should try Java. I run my Java code on Windows, Linux and other UNIXes without compatibility problems. Sadly, not Mac, so I can't really advise you there.
My advice, pick a smallish project - do it in both Python and Java - see how it runs on all the platforms you're interested in.
Python with PyQt or the eventually-to-be-equivalent-but-gratis PySide seems the way to go -- after all, few languages are easier to program in than Java (which you consider "almost too difficult to program in"), Python is one of those few, Qt arguably the best cross-platform GUI toolkit in any language, and PyQt (now, but GPL or for-$$$) or PySide (eventually, gratis even if you want to close-source your own code) are powerful interfaces between Python and Qt.
You can use any of languages targeting JVM, e.g. Jython (Python impl) and JRuby (Ruby impl).
You can try using Qt bindings for Python, Qt seems to support many of Mac OSX specifics.
Consider Tcl/Tk. I'm not sure how you define "one binary that is executeable [sic] by all major desktop platforms" but Tcl probably meets this as well as java, and likely better than any other scripting language.
Using the tcl packaging technology of starkits you can either a) create a single file that can be run on any platform that has an appropriate runtime engine (and they are available for all major and many minor platforms), or you can package that platform-specific runtime engine and and cross-platform starkit into a single file executable for each platform.
The starkit technology is something other languages should aspire to. What you get is a complete, fully functional virtual file system within a single file. This lets you easily package up sound files, dll/.so files (which must be copied to disk for obvious (?) reasons), images, data, etc along with your executable code.
Tk, the graphical library, is very mature and has really good support on all platforms. Some people think it looks dated but those impressions are usually based on information that is at least 5 years old. Modern Tk looks quite good. For some examples see the tkdocs website. I's not clear whether you're more concerned with eye candy or functionality, but if it's functionality you're interested in then Tk is something to seriously consider.
Most agree that Tcl is an aquired taste but those that use it professionally usually swear by it. I've been doing wxPython programming the last several months and would switch back to tcl/tk in a heartbeat if given the opportunity.
You could use Groovy to work around the Java complexities.
Still you'll need good foundations of Swing.
While the learning curve may be steep, the trade of of not having to completely re-write the whole application again for the next platform will be a good reward.
Bear in mind, that even though it is cross platform, you should consider different platforms still have different idioms ( e.g. Copy/Past in Windows is ctrl+v, ctrl+v while in Mac it is cmd+c, cmd+v )
I work on a program that has to run on Windows, Linux and OS X (and OS X is my development platform), and wxPython is what we use.
If I had a chance to start again, I'd probably go with PyQT (based on advice from friends), but wxPython will get the job done.
I think wxPython is pretty good, though I am not sure what you mean by "support on Mac OS X is fairly limited" but I have been porting a wxPython app (www.mockupscreens.com) to Mac and it wasn't that difficult with few tweaks e.g. some UI elements may not come up as you expected, as wxPython uses native UI elements, which can be an advanatage or disadvantage based on your requirements.
Other good option is PyQT which will give you consistent look on all platforms.
Java seems better for what you want.
Well what about the web application in Javascript?
How about SWT
Cross Platform
Native Look and feel
Huge community
Constantly maintained/upgraded ( IBM backed )
Atleast one mega successful cross platform project
I would suggest going the wxPython route, I know that wxWidgets (which is what wxPython is using) can be made to have great looking Mac apps (look at PgAdmin3 from postgresql). While PgAdmin3 is not done in python, it was done with wxWidgets and looks fine on a mac.
I use three cross-platform tools regularly: Realbasic from Realsoftware which is what Visual Basic v6 would have been if allowed to grow; Revolution from Runrev which is what Hypercard would have been if allowed to survive (and its neat using a scripting language whose syntax is basically English); and finally, Delphi Prism with Mono.
All are quite mature and yet expanding at a great rate. For instance, Revolution is just introducing a web-application feature to its language that is really easy to use.
Is it possible that anyone has a link to a graph class/library that I can use to produce a graph in Java?
Thanks for any help!
My top choice would be JGraph as others have suggested; I am using JGraph5 because it is better documented than the newer alternative, JGraphX. EDIT: JGraphX turns out to be the far superior version, despite the lack of documentation. It's not that hard to figure out.
JGraph
Demonstration app
Feature list
Licensing agreement
Other alternatives I've researched:
JGraphT
"JGraphT is a free Java graph library that provides mathematical graph-theory objects and algorithms...complete source code included, under the terms of the GNU Lesser General Public License." (http://jgrapht.sourceforge.net/)
Main project repository
Example visualizations
JUNG - Java Universal Network/Graph Framework
Main project repository
yEd Graph Editor
Implementation of yFiles library
Demonstration Java applet
About yEd
Saves graphs in GraphML format
I used JGraph as a visualizer for networks of nodes/topologies at my previous job, it's not half bad once you get past the architecture (it's a big state machine if I recall correctly).
Visual graph: JFreeChart
You may also wish to consider the Google Charts API, if you can make web service requests.
A really good alternative is to used the Google Charts API. Platform independent, easy to use, and fast processing (done on Google Server side)
graphviz would be my choice. It's not Java, but still terrific and easy to use.
There is a Java component that works with dot to generate graphs. I've used it - very nice, indeed.
I would recommend JGraphT. I used it to create multi-leveled graphs in my dissertation and as the base of a GPS Routing Software, understanding what is going on I found a bit of a mind bender, but once looking at how the algorithms package works I found it quite easy to implement A*/D* heuristic algorithms. For working out the distance between nodes on the graph I'd also recommend looking at the Haversine function, if that's your thing.