Does Java use the GPU
Locked
 
|
Dear All,
I've been asked a question about selecting a computer: is the speed of the CPU or the GPU more important? In this case the plugins to be executed are very compute intensive and only make images of the results at the end. So the the first thought is CPU. But a colleague suggested that maybe Java is using the GPU for numerics behind the scene. Clearly this could be made to happen by calling a library that finds and uses a GPU on purpose. Is ImageJ doing this explicitly or somehow implicitly, apart from displaying graphics? I think probably not, since using the the FPU on the CPU would be faster than setting up a call to the GPU unless a lot of operations were queued up. Bob -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi Robert
Currently java does not natively use the GPU. However there are many efforts to implement ImageJ/Fiji image processing on the GPU. One of the most mature is CLIJ (https://clij.github.io/). Typically the macro or plugin writer would have to explicitly move the image data from the CPU to the GPU, then make calls to GPU compatible image processing libraries, then move the image back to the CPU when finished. Some newer plugins for ImageJ are using the GPU in this manner. The plugin web page will usually make this clear. So when deciding between trade-offs between GPU or CPU it is a good idea to check all the plugins to be run, and see if they make use of the GPU or not. It is unlikely that current imagej plugins will use the GPU under the hood, without making it clear to the user. Although that could change in the near future as GPU processing becomes more tightly integrated with the ImageJ ecosystem. Brian Brian On Sun, May 9, 2021 at 12:17 PM Robert Dougherty <[hidden email]> wrote: > Dear All, > I've been asked a question about selecting a computer: is the speed of the > CPU or the GPU more important? In this case the plugins to be executed are > very compute intensive and only make images of the results at the end. So > the the first thought is CPU. But a colleague suggested that maybe Java is > using the GPU for numerics behind the scene. Clearly this could be made to > happen by calling a library that finds and uses a GPU on purpose. Is > ImageJ doing this explicitly or somehow implicitly, apart from displaying > graphics? I think probably not, since using the the FPU on the CPU would be > faster than setting up a call to the GPU unless a lot of operations were > queued up. > > Bob > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Brian,Very interesting. Thanks.Bob
On Monday, May 10, 2021, 3:27:21 AM PDT, Brian Northan <[hidden email]> wrote: Hi Robert Currently java does not natively use the GPU. However there are many efforts to implement ImageJ/Fiji image processing on the GPU. One of the most mature is CLIJ (https://clij.github.io/). ...... Brian -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Robert Dougherty
> On May 9, 2021, at 3:13 PM, Robert Dougherty <[hidden email]> wrote:
> > Dear All, > I've been asked a question about selecting a computer: is the speed of the CPU or the GPU more important? In this case the plugins to be executed are very compute intensive and only make images of the results at the end. So the the first thought is CPU. But a colleague suggested that maybe Java is using the GPU for numerics behind the scene. Clearly this could be made to happen by calling a library that finds and uses a GPU on purpose. Is ImageJ doing this explicitly or somehow implicitly, apart from displaying graphics? I think probably not, since using the the FPU on the CPU would be faster than setting up a call to the GPU unless a lot of operations were queued up. The speed of the CPU is more important unless you a using a plugin that uses the GPU. Neither Java or the ImageJ core use the GPU. The easiest way to speed up compute intensive code is to use multi-threading. The Process>Filter>Gaussian Blur command is 4 times slower when I change the number of threads from 8 to 1 in Edit>Options>Memory and Threads. The Plugins>Utilities>Benchmark command in the latest ImageJ daily build (1.53j42) is partially multi-threaded and it outputs a table useful for comparing speeds. Time Computer 1 10.9 MacBook Air (M1, 2020, Native) 2 17.2 iMac Pro (2017) 3 18.1 MacBook Air (M1, 2020, Rosetta) 4 19.8 <<THIS MACHINE>> 5 24.7 27" iMac (Early 2015) 6 29.7 13" MacBook Pro (Late 2015) 7 29.7 15" MacBook Pro (Early 2013) 8 62.3 Acer Aspire laptop (Core i5, 2014) -wayne -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
If resizing images with the java.awt framework is part of the program,
then the GPU matters: the JVM uses graphics card-accelerated computations to resize images. That's about the extent to which the JVM uses GPUs, as far as I know, as has been doing so for about a decade now. The method I have in mind is java.awt.Image.getScaledInstance https://javadoc.scijava.org/Java8/java/awt/Image.html#getScaledInstance-int-int-int- Albert Missatge de Wayne Rasband <[hidden email]> del dia dl., 10 de maig 2021 a les 15:37: > > > On May 9, 2021, at 3:13 PM, Robert Dougherty <[hidden email]> wrote: > > > > Dear All, > > I've been asked a question about selecting a computer: is the speed of the CPU or the GPU more important? In this case the plugins to be executed are very compute intensive and only make images of the results at the end. So the the first thought is CPU. But a colleague suggested that maybe Java is using the GPU for numerics behind the scene. Clearly this could be made to happen by calling a library that finds and uses a GPU on purpose. Is ImageJ doing this explicitly or somehow implicitly, apart from displaying graphics? I think probably not, since using the the FPU on the CPU would be faster than setting up a call to the GPU unless a lot of operations were queued up. > > The speed of the CPU is more important unless you a using a plugin that uses the GPU. Neither Java or the ImageJ core use the GPU. The easiest way to speed up compute intensive code is to use multi-threading. The Process>Filter>Gaussian Blur command is 4 times slower when I change the number of threads from 8 to 1 in Edit>Options>Memory and Threads. > > The Plugins>Utilities>Benchmark command in the latest ImageJ daily build (1.53j42) is partially multi-threaded and it outputs a table useful for comparing speeds. > > Time Computer > 1 10.9 MacBook Air (M1, 2020, Native) > 2 17.2 iMac Pro (2017) > 3 18.1 MacBook Air (M1, 2020, Rosetta) > 4 19.8 <<THIS MACHINE>> > 5 24.7 27" iMac (Early 2015) > 6 29.7 13" MacBook Pro (Late 2015) > 7 29.7 15" MacBook Pro (Early 2013) > 8 62.3 Acer Aspire laptop (Core i5, 2014) > > -wayne > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Wayne Rasband-2
On 10/05/2021 23:33, Wayne Rasband wrote:
On May 9, 2021, at 3:13 PM, Robert Dougherty <[hidden email]><mailto:[hidden email]> wrote: Dear All, I've been asked a question about selecting a computer: is the speed of the CPU or the GPU more important? In this case the plugins to be executed are very compute intensive and only make images of the results at the end. So the the first thought is CPU. But a colleague suggested that maybe Java is using the GPU for numerics behind the scene. Clearly this could be made to happen by calling a library that finds and uses a GPU on purpose. Is ImageJ doing this explicitly or somehow implicitly, apart from displaying graphics? I think probably not, since using the the FPU on the CPU would be faster than setting up a call to the GPU unless a lot of operations were queued up. The speed of the CPU is more important unless you a using a plugin that uses the GPU. Neither Java or the ImageJ core use the GPU. The easiest way to speed up compute intensive code is to use multi-threading. The Process>Filter>Gaussian Blur command is 4 times slower when I change the number of threads from 8 to 1 in Edit>Options>Memory and Threads. To muddy the water even further: RAM speed and parallelism is also important when your operation is not very computationally intensive, but does require a lot of memory access (especially random / non-sequential access). The "memory wall" can inhibit getting full use of CPU threads, because the bottleneck can be getting data to and from RAM rather than doing the calculation. Whether the much faster video RAM on GPGPUs improves the situation is likely to be application specific. In recent work I found not much improvement in speed of a parallelised process on more than c. 10-16 threads, which seems to be a memory issue (16 DIMMs installed) rather than a CPU issue (dual Xeon with 40 CPU threads). https://doi.org/10.1098/rsos.201784 Michael <http://www.cityu.edu.hk/ph> <http://www.cityu.edu.hk/ph> Disclaimer: This email (including any attachments) is for the use of the intended recipient only and may contain confidential information and/or copyright material. If you are not the intended recipient, please notify the sender immediately and delete this email and all copies from your system. Any unauthorized use, disclosure, reproduction, copying, distribution, or other form of unauthorized dissemination of the contents is expressly prohibited. -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |