Re: Google summer of code SIMD primitives

Matthew Fluet <matthew.fluet <at> gmail.com> writes:

> 
> 
>     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
-> unitwhich 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.

  The GSoC proposal is due by tomorrow and before I submit it I was
wondering if I could email you my proposal to look over and insure that it
is reasonable and fits the requirements.
   Tucker



------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel