Vector API "Straw Man" Boxed/Unboxed Vector Instantiation

[elias vasylenko]

Hi, just a quick question here from someone with 0 knowledge of vector
processing trying to follow along out of casual interest... So when you all
talk about cracking lambdas, I've been thinking that you mean something
like the lambda serialisation trick Jinq uses so they can try to parse
streams/lambdas into sensible database queries. Is this somewhat accurate?

I don't think I've seen that approach mentioned here before, and perhaps
there's a reason for that which I'm not grasping, but it seems like a
reasonable fit to me. Lambdas can be compiled into expression trees, and
these can be optimised where possible into vector instructions, right?
Requiring lambdas to be serializable to be able to optimise is a little
restrictive, but I can't see that being much of a problem in this case.

On Thu, 31 Mar 2016 at 00:15 Graves, Ian L <ian.l.graves at intel.com> wrote:

> The question of IR for the HOF components raises some important
> questions.  The mapping and zipping (mapWhere + BinaryOperation)
> functionalities are particularly amenable to supporting user-directed
> vector operations coming from some kind of source.  Doing it with lambdas
> is the most natural way to go about it here, but there are some challenges
> with this approach.  John mentioned "lambda cracking" where we (from my
> understanding) are looking reify the program body inside of a given lambda
> so we can reinterpret/recompile it into low level vector operations (ex.
> CodeSnippets).
>
> One  caveat I can think of is that we would have corner cases in Java
> involving effectful expressions (assignment, ++, +=, for example) that we
> would potentially have to exclude from the Vector domain.  Could this be
> something that we could perform at compile time?  It seems unnatural to let
> something like one's use of "+=" slip through compilation and then cause a
> runtime error, though it's probably fair to say that code is being
> re-evaluated at runtime so all bets are off.  Another issue is how we
> should treat variable capture in this context.  I'm not sure how C# does it
> in general, but for Vectors we may have some issues with other types of
> legal expressions like invocations could crop up.
>
> Incidentally I've been sketching around on an abstract
> interpretation-based approach as an alternative to the cracking problem,
> and my process tends to end up with some IR similar to C#'s Expression
> class.  I think such an approach could work, but wouldn't be as natural as
> pure Java expressions.  The one advantage of abstract interpretation is
> that we can control the instances and operations more easily, and without
> anything as major as lambda cracking.  Perhaps it might be a good stop gap
> measure to build up this approach on an IR that we could pivot to use for
> more general lambda cracking?
>
> The expression trees solution seems like a really neat idea to me and
> something I'd like to talk more about in whichever forum is appropriate
> (not sure if Panama is the place for it).
>
> -- Ian
>
> -----Original Message-----
> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf
> Of John Rose
> Sent: Monday, March 28, 2016 12:58 PM
> To: panama <panama at zeus.net.au>
> Cc: panama-dev at openjdk.java.net
> Subject: Re: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation
>
> On Mar 26, 2016, at 4:45 PM, panama <panama at zeus.net.au> wrote:
> >
> > How can spir-v be leveraged? Could the vector api utilise it? Could
> hotspot support spir-v, in case it wasn't supported by underlying hardware?
>
> The library engines behind Vector could maybe use something like SPIR.
> (And the IR might leak through in interesting ways to some users.)
>
> This relates to my comment that we need a way for the Vector runtime to
> "crack" the lambdas passed to HOF API points like Vector.reduce.  If we had
> the equivalent of C# expression trees, we could treat chains of vector ops
> as queries to be optimized, when executing a terminal operation (such as
> Vector.intoArray or hypothetical Vector.collect).  A vector expression
> could be cooked into some kind of IR, and then instruction-selected into a
> AVX code.
>
> To use SPIR (or maybe even the above approach), we would need a more
> explicit user-cotrolled boundary between the "host" and "offload" parts of
> the computation.  Making an automagic partition between the two, from a
> common bucket of Java execution, is currently science fiction.
>
> — John
>