Java and GPU … are we nearly there yet?

Ғылым және технология

This sessions discusses recent (and proposed) JDK features that (will) offer new Java GPGPU (general-purpose GPU) collaboration opportunities.
Presented by Gary Frost - Architect (Java Platform Group - Oracle) during the JVM Language Summit 2023 (Santa Clara CA).
Project Babylon ➱ inside.java/tag/babylon
Make sure to check the • JVM Language Summit 2023 playlist.
Tags: #Java #GPU #JVMLS #OpenJDK #GPGPU

Пікірлер: 13

  • @Rope257
    @Rope25711 ай бұрын

    Very happy to see some work in this direction. There have been a bunch of API's I played around with but having a proper set of JDK features for this would be amazing.

  • @MrXv007
    @MrXv0079 ай бұрын

    The first question that was asked by someone from the audience is what i have on my mind too. The way Gary Frost describes moving data in and out of the GPU based on automatic code analysis supposes that the whole calculation is one single operation with multiple steps. The data is uploaded to the GPU, calculated trough multiple kernel calls, result downloaded, and data on the GPU discarded. What if i have a scenario that accumulates calculations over a longer time period, and never normally does need to move data out of GPU, as it always reuses the already uploaded data. So its not a single operation, but the data resides on the GPU for longer time. When needed, on demand, some of the relevant data is read back from the GPU. But only rarely. It cannot be automatically determined after a kernel call, which data should be read back, which data is temporary, as that is the result of user actions. One kernel only updates data residing on the GPU, so from that point there is no result to read back. It will be different code running at different time that actually reads some of the data back. I've used Aparapi, sometimes it was better to run the kernel on the CPU instead of the GPU, because the latency of data transfer was less, even if the computation on the GPU was faster.

  • @DaniilBubnov
    @DaniilBubnov11 ай бұрын

    Quite interesting presentation, highlights a topic not widely discussed. I liked the historic overview of the evolution how java approached the heterogeneous environment and there is obviously good progress! I wonder what comes next🙂

  • @VincentGroenewold
    @VincentGroenewold11 ай бұрын

    Thanks, very interesting and very much needed. :)

  • @java

    @java

    11 ай бұрын

    Glad you enjoyed it!

  • @chamanbhenga
    @chamanbhenga11 ай бұрын

    Which JEP(s) cover the "Code Reflection" used by HAT?

  • @delabassee

    @delabassee

    11 ай бұрын

    There's no JEP yet but more information will soon be published including the JVMLS Code Reflection session.

  • @javadeveloper9442
    @javadeveloper944211 ай бұрын

    And it would be helpful to make the calculation on GPU

  • @RuiLopesFR
    @RuiLopesFR11 ай бұрын

    What about leaning on WebGPU initiative and linking against Dawn (Google implementation)? This would allow Java to use standard cross-platform GPU API

  • @javadeveloper9442
    @javadeveloper944211 ай бұрын

    I am very interested with this

  • @StefanReich
    @StefanReich10 ай бұрын

    5:50 It would be #1 in 2006, not 2012. But still, impressive :)

  • @nesdi6653
    @nesdi6653Ай бұрын

    data

  • @user-kb8bi2kl1n
    @user-kb8bi2kl1n11 ай бұрын

    First comment

Келесі