Milestones

[Frost, Gary]

John, 

Thanks for the feedback. Sorry for the delay following up - I have been
traveling.

Now I want to call this initial 'Sumatra/Aparapi tracer bullet milestone'.
'Reindeer' ;) 

You ask whether we need to use Lambda in this first milestone. We could
obviously skip it, but we have already coded up Aparapi changes to create
OpenCL from byte code created by lambdas, and we intend to (in parallel)
lambdafy Aparapi, so this is not too much of a distraction at this time.
It does imply that we fork the initial code from the 'Project Lambda'
source - unless the lambda/openjdk 8 merge is imminent.

Thanks for the list of suggested other milestones. This is a great list.
I am on vacation for a week or so, but I do plan to pull together this
list of milestones as well as the research items listed in project
'Reindeer' - I wasn't joking!-) on the Sumatra project wiki.

Gary

On 11/13/12 7:03 PM, "John Rose" <john.r.rose at oracle.com> wrote:

>Ah, please ignore the reindeer. That's a corporate trade secret weapon.
>
>Pretend I said "rendered".
>
>-- John  (on my iPhone)
>
>On Nov 13, 2012, at 4:53 PM, John Rose <john.r.rose at oracle.com> wrote:
>
>> On Nov 8, 2012, at 6:18 AM, "Harle, Christophe"
>><christophe.harle at amd.com> wrote:
>> 
>>> This proposed milestone involves moving enough of Aparapi's
>>>implementation down into the Project Lambda enabled JVM to allow Lambda
>>>enabled Aparapi demos/workloads to execute directly (no Aparapi.dll).
>>>Whilst this effort would constrain demos/examples to Aparapi's existing
>>>programming model constraints (parallel primitive arrays only) it would
>>>act as a 'tracer bullet' through the code base, allowing us to
>>>familiarize ourselves with the various major JVM components that we
>>>think will to impacted via a Sumatra implementation.
>> 
>> The "tracer bullet" is good.
>> 
>> Do we really need lambda for a first victory?  I think online code
>>generation, just by itself, even without execution, would be huge.
>> 
>> Other milestones:
>> € First use of CompileBroker to trigger GPU codegen.
>> € First use of C2 IR rendered to GPU code.
>> (Note: Codegen does not imply execution. Could be OptoNoExecute mode.)
>> € First run of GPU code from online generation.
>> € First run of GPU code from (one-off) lambda collection library.
>> € First run of GPU code from (enhanced) standard parallel collection.
>> € First profitable run of ditto.
>> 
>> On the data front:
>> € First use of pointer-chained Java data structure from GPU.
>> € First GC tracing through GPU task data.
>> € First call and return of GPU method with zero copying. (Already
>>done?)  Here, "zero" is any O(#GPUs), which is less than the bulk data
>>size. 
>> 
>> Not sure exactly how to order these.
>> 
>> I am convince that there are about 3 fronts that need roghly
>>simultaneous advance:
>> € code: how to get code into the GPUs. Should be an online hot-spot
>>reindeer by a JIT.
>> € data: how to get data in and out. Should contain managed pointers,
>>but not as many as classic Java data. I.e. flatter with more "little
>>structs".  See Arrays 2.0 and value types.
>> € Libraries: teach parallel collections to generate GPU commands on
>>enabled systems. Translate lambda bodies and loop kernels to GPU code.
>> 
>> Best wishes,
>> ­ John
>