CFV: Project Trinity
doug.simon at oracle.com
Mon Apr 24 09:09:27 UTC 2017
> On 24 Apr 2017, at 10:50, Volker Simonis <volker.simonis at gmail.com> wrote:
> On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon <doug.simon at oracle.com> wrote:
>>> On 21 Apr 2017, at 23:54, Christian Thalinger <cthalinger at twitter.com> wrote:
>>>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan <karthik.ganesan at oracle.com> wrote:
>>>> Hi Christian,
>>>> Thanks for your interest. This question was brought up previously in the discussion email thread for this project:
>>>> Project Sumatra was aimed at translation of Java byte code to execute on
>>>> GPU, which was an ambitious goal and a challenging task to take up. In this
>>>> project, we aim to come up with APIs targeting the most common Analytics
>>>> operations that can be readily offloaded to accelerators transparently. Most
>>>> of the information needed for offload to the accelerator is expected to be
>>>> readily provided by the API semantics and there by, simplifying the need to
>>>> do tedious byte code analysis.
>>> I disagree. The first paragraph on the Sumatra project page says:
>>> "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.”
>>> while you state:
>>> "This Project would explore enhanced execution of bulk
>>> aggregate calculations over Streams through offloading
>>> calculations to hardware accelerators.”
>>> It’s the same thing. I just don’t see the need to spin up yet-another OpenJDK project that aims at the same goal.
>> Maybe this is just a discrepancy between the officially stated aims. I understood Sumatra to be about *automatic* offloading work for existing APIs (such as the Streams API) to a GPU where as Trinity seems to be more about designing an explicit API for GPU offloading.
> So if this is about a explicit API for GPU offloading, will this be a
> Java implementation/wrapper for already existing C/C++ APIs like
> CUDA/OpenCL. Designing a completely new, Java-specific API seems to be
> not very promising to me.
Karthik, maybe you could discuss the differences/similarities between Trinity and the Arapapi project (https://github.com/aparapi/aparapi).
More information about the discuss