Re: Google summer of code SIMD primitives

>
>     I am sorry for the delayed response, I was not subscribed to the
> mailing
> list until recently so I did not see your reply. My current idea for the
> project, based on the given idea, would be to write an architecture
> independent sml library supporting a core set of simd primitives and create
> an example implementation for an x86 back end using sse instructions. I
> think this would be feasible in the given time frame, and would be
> extensible to other architectures. What do you think of this idea? Also
> what
> sort of format should my proposal be in, is there any specific layout I
> should use? One final question would be how specific should my proposal be,
> should I have an idea of the specific set of instructions I intend to
> implement or could this be a part of the project itself.
>

I do think that the project would naturally divide into a core set of
primitive SIMD operations and then an SML library that makes use of those
primitives more convenient.  Of course, then one also needs to balance how
easily or difficult the primitives are to add to MLton.  For example, I
suspect that the simplest kinds of SIMD primitives to add to MLton would be
ones that perform SIMD operations on arrays, since SML arrays are both
aggregate types and mutable types.  That is, one could imagine a primitive
like:
  val simd_add4 : real array * int * real array * int * real array * int ->
unit
which would be used like:
  simd_add4( inp1, idx1, inp2, idx2, outp3, idx3)
where one sends in two input arrays and indices from which to fetch the
sequence of 4 reals and the output array and index at which to store the
added sequence of 4 reals.

Somewhat harder might be to add new primitive types corresponding to a
sequence of 4 reals.  The reason that this might be somewhat harder is that
a sequence of (exactly) 4 reals would most naturally be represented in SML
as a 4-tuple of reals, but a tuple is treated as an aggregate, memory type
in the compiler, not as an atomic, direct type (like int or real) in the
compiler.  Not to say that such a primitive type couldn't be added (and,
indeed, that seems to be the approach taken in SIMD libraries for C), just
that it might not be as easy.

I definitely think that investigating and designing a core set of portable
SIMD primitives should be part of the project itself.  I'd certainly be
interested in seeing a good design document that summarizes and critiques
the various sets of SIMD intrinsics in other compilers (gcc and Clang are
obvious candidates) and libraries.

As for a proposal format, the outline and example proposals from the GSoC
Student Guide (http://en.flossmanuals.net/GSoCStudentGuide/) provide good
skeletons.  I think that some kind of timeline and estimate of hours/week
spent on the project help us to make sure that a student hasn't proposed
much more than is possible in the timeframe.  Somewhat for the
student-side, it is great if there is an short, easy deliverable that
establishes early success in the project.

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel