CFV: Project Trinity

[Volker Simonis]

On Mon, Apr 24, 2017 at 5:00 PM, Karthik Ganesan
<karthik.ganesan at oracle.com> wrote:
> I would like to thank Paul Sandoz, Christian Thalinger, Doug Simon, Mario
> Torre and Volker Simonis for their support and the insightful questions.
>
> What we are proposing to do as part of this project is complementary to
> existing efforts that enable offload to GPUs like Sumatra, AparAPI etc.
> These existing projects provide implementations translating existing Java
> API via Bytecodes to GPU language. Trinity extends these efforts and takes
> it one step further by readily providing the building blocks for programmers
> to construct complex bulk data/stream based algorithms in Java that can be
> easily offloaded by these existing projects. While having a route to offload
> to hardware accelerators is useful, but making it easier for programmers to
> leverage will take it one step closer to adoption.
>
> Projects like Sumatra and AparAPI use the the Stream ForEach() method to
> show case offloads. Trinity will offer more such methods with richer
> functionality, making it easier for these existing projects to leverage and
> deliver hardware capabilities to be readily consumed by programmers. Unlike
> the existing Streams API, the library for this new API is envisioned to have
> a stronger focus on performance, a dedicated implementation that will be
> offload friendly and cover more functions that are relevant to this domain
> of programmers.
>
> Also, please note that Trinity casts a wider a net when it comes to
> accelerators, not just GPUs/APUs. These accelerators can include Analytics
> accelerators like DAX, SIMD units on general purpose cores, FPGA based
> accelerators for bulk aggregate operations, GPUs and whatever more the
> future holds in terms of heterogeneous computing for bulk data processing.
>

This certainly sounds very ambitious! I'm not an expert in this area,
but I don't think there's even a good C/C++ API which covers this
broad range of "accelerators". What we should certainly avoid is
providing an API which only works with accelerator XXX of vendor YYY.
If the goal of this project is to eventually provide a standard Java
API, it should at least support a wide range of available
"accelerators" which, to repeat my self, makes it quite ambitious.

That said, how is this new library supposed to work? Will it be mainly
implemented in Java with various native C/C++ back-ends or do you plan
to still use VM (aka. HotSpot) support via intrinsics and various
other sorts of JIT compiler optimizations? As far as I understood now,
you'll plan to go for the first approach without HotSpot support,
right? In that case, Trinity would certainly be a good candidate for
using the new JNI work done in project Panama.

> Inspired by the existing Streams API that brings succinct functional
> programming to Java using lambdas, this project will try to retain such rich
> features, significantly simplifying programming in Java for the performance
> oriented developers focusing on bulk data processing.
>
> Regards,
>
> Karthik
>
>
>
> On 4/24/2017 4:09 AM, Doug Simon wrote:
>>>
>>> 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.
>>
>> I agree.
>>
>> Karthik, maybe you could discuss the differences/similarities between
>> Trinity and the Arapapi project (https://github.com/aparapi/aparapi).
>>
>> -Doug
>
>