Vector API Latest Draft Spec

[Graves, Ian L]

All,

I have just pushed the latest draft spec of the Vector API.  This spec is based on discussions both on and off Panama as it relates to an idiomatic Vector API in the Java style.  This work dates back to John's straw man[1], but focuses on the "concrete" functionality of the Vector API.  The higher order aspects of the API have been handed off to the exploration in the expression language work.  As such this iteration of the Vector API is more concrete, like you'd see in the Intel Intrinsics Library, but platform independent.  This draft spec is a functional implementation, but the functionality is emulated in pure Java.  This is intended for usability studies without regarding performance.  Lane types for Byte, Short, Int, Long, Float, and Double for shapes of 128, 256, and 512 bits are supported.  The API is structured around ideas on using interfaces for richer API's[2].  You'll notice that this spec is quite a bit bigger.  The intent is to make this as feature complete as possible for exploring with workloads and the identification of pain points.

Included in the push are a few workloads to start.  Three are basic and one is more advanced.  One is a simple addition test, one is conversions between types, and another is loading and storing to arrays based on an index variable. The other is a Mandelbrot fractal generator that I adapted to this newer spec from the older one we had previously.  The Mandelbrot generator attempts to use most of the features of the Vector API (left out shuffling right now, but there is a place to do it) in the ways that cause us the most pain on the code gen side.  Particularly, we are using masking which we haven't done much of before.  We are also using vector accumulators in loops, which has probably been the biggest single sticking point where code generation is concerned.  Mandelbrot also projects boolean values by reductions of masks derived from comparisons of vectors.  It's a pretty hairy example and also one that, if you can do it well, will probably result in pretty good code generation for a lot of other examples.  Some early work on our end has shown that there exists a path to intrinsification of this type of programming model, so we are very interested in exploring this spec further.  This Vector API can also act as the back end of the Expression Language posted a couple weeks ago as that approach is based upon MethodHandles.

Am very happy to get this spec out the door for other people to play with and see what workloads they can think of to drive it with.  Would love to get your feedback!  In the meantime I will be exploring other more advanced workloads and posting them when they're ready.

--Ian


[1] http://cr.openjdk.java.net/~jrose/arrays/vector/Vector.java
[2] http://cr.openjdk.java.net/~jrose/panama/using-interfaces.html