5

With the framework rootbeer is GPU programming for Java possible.

Which Java code should be used for rootbeer and which code should better run in the Java VM self?

Or other: which code produce more overhead and it make no sense?

Horcrux7
  • 23,758
  • 21
  • 98
  • 156
  • Are you asking what kind of algorithms in general make sense to be executed on the GPU? – Bart Aug 12 '12 at 18:13
  • I don't know if this is in any way relevant for you, but brute forcing passwords (cryptography) is one area where the tuning of GPUs for the required kind of operations for this kind of thing is used to gain a time advantage. – G. Bach Aug 12 '12 at 18:32
  • 2
    My question is specific to rootbeer and not for general GPU programming. – Horcrux7 Aug 12 '12 at 18:35

4 Answers4

3

It's a bit of a silly thing to say, but the obvious answer would be "for problems at which a GPU is better than a CPU". Modern GPU's have in excess of a thousand cores, but comparatively little memory, so in general, this means stuff that lends itself well to parallelization and doesn't take too much memory.

G. Bach mentioned brute-force attacks against crypto stuff in the comments, that's a good example. Scientific simulations are another good example, in fact, a few years ago a few research institutions (notably NASA) had clusters of Playstation 3's running simulations. Wikipedia's article on GPGPU computing lists several applications of the technology.

Barend
  • 17,296
  • 2
  • 61
  • 80
3

In addition to the other answers: There are also some Java-Features that are not supported to translate by rootbeer jet.

  1. native methods
  2. reflection
  3. dynamic method invocation
  4. sleeping while inside a monitor.
  5. garbage collection(!)

You should avoid code with these features used.

Updates for Rootbeer are in production to provide garbage collection and other missing Java features.

Simulant
  • 19,190
  • 8
  • 63
  • 98
  • The first 4 points are clear. If I understand the problem with GC then the code should only include static methods or singleton. Is this right? There should be no frequently object allocation because the objects can't be garbage? – Horcrux7 Aug 13 '12 at 20:02
  • GC is on the way to be added. Until this is finished you should recycle Objects instead of setting the references to `null` and create a new Object. Or you use code with a constant or just increasing number of Objects. – Simulant Aug 29 '12 at 22:06
  • You can use dynamic memory allocation, but there is no garbage collection. So if you run out of memory on the GPU, an OutOfMemoryError is bubbled up to the CPU. – pcpratts Apr 03 '13 at 20:59
  • Any idea where the library is now? – HaydenKai Aug 24 '17 at 23:22
2

To get speedups with GPUs, you want to have lots of computation per data element because data transfer is so slow. You usually want 2 or 3 nested for loops running on the GPU with at least a 1000 threads.

pcpratts
  • 388
  • 3
  • 6
1

One of the limitations of current GPU is that it can load one simple method to every core and execute it at once. General purpose CPUs can load more code and data and do them independently.

There is vector style code which might be faster on a GPU and I can see it being an option one day, but most code (by volume if not by processing power) will be on CPUs.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130