DPH and CUDA status

[Scott Michel]

Are you also planning a LLVM backend for ghc, in a general sense, or just
for the accelerated work you're doing? It seems to me that ghc itself could
be well served with a LLVM backend, especially if one relies on the JIT
mode. That could help identify code paths in the core and runtime that are
infrequently used, further optimizing ghc's overall performance.

That's the gist behind Latter's work to accelerate the OpenGL stack on Mac
OS. The LLVM JIT determines which code paths are actually taken, generating
code for only those paths.


-scooter

PS: I do stand behind my assertion regarding the Cell. I'm the CellSPU
backend hacker for LLVM and I've pretty much stopped work on it because IBM
has more or less killed the chip.

On Thu, Feb 4, 2010 at 3:07 PM, Manuel M T Chakravarty <chak at cse.unsw.edu.au
> wrote:

> Felipe Lessa:
> >> I would suggest that any GSoC project in this space should be based
> >> on D.A.Accelerate (rather than DPH), simply because the code base is
> >> much smaller and more accessible.  There is not much point in
> >> writing a CUDA backend, as we already have a partially working one
> >> that we are going to release in due course.  However, I repeatedly
> >> had people asking for an OpenCL backend.  So, there appears to be
> >> some demand for that (and it's the right thing to do, given that
> >> CUDA is tied to a single company).  An OpenCL backend for
> >> D.A.Accelerate also appears to be in the scope of what a good coder
> >> can achieve in the timeframe of a GSoC project.  (To be precise, I
> >> think, a good coder can implement a working backend in that
> >> timeframe, but it will probably require more work to generate well
> >> optimised code.)
> >
> > Thanks, that's very interesting.  What about an LLVM backend, would it
> > be useful?  Perhaps it would be possible to use its vector operations
> > to use SIMD instructions of modern CPUs (I think GHC isn't there yet,
> > right?).  This is just a thought :).
>
> I'm currently implementing an LLVM backend.  I'm not planning on using SIMD
> instructions in the first version, but it is an interesting idea for when a
> basic LLVM works.
>
> Manuel
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100205/6e231707/attachment.html