CFV: Project Trinity

Volker Simonis volker.simonis at gmail.com
Mon Apr 24 08:50:45 UTC 2017


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.

> -Doug


More information about the discuss mailing list