The CARP project

[Stuart Brorson]

Hi Guys,

I just happened to see an article in EE Times about this European
Industry/Academia project:

http://www.carpproject.eu/

It seems to have some goals which are similar to things the Julia
group is working on, in particular optimized compilers for numerics.
It may be of interest to the team. Perhaps folks are already aware of
this project?

Stuart

[Jeff Bezanson]

It seems like the goal of this is to be a higher-level replacement for
OpenCL and CUDA, which is certainly welcome. I imagine it is the same
kind of thing one usually sees in niche HPC languages, i.e. defining a
limited domain of programs and data and aiming for peak flops within
that domain. (The process often culminates in adding an object system,
at which point everybody starts to wonder what went wrong.)

Julia "gets it wrong" by NOT doing this. Instead we start with the
workflow of matlab/python/R, and try to provide it within a richer
compiler infrastructure that we hope will eventually allow building up
pretty much anything instead of needing to "call out". Another way to
see it is to look at the huge effort that goes into building something
like NumPy, Star-P, pMatlab, or Accelereyes' Jacket. The goal of julia
is to make building functionally-similar platforms to those much
easier by moving work from people to a compiler. And the work that we
move is not just the typical fortran-compiler-style optimizations, but
rather dealing with the prevailing dynamic dispatch environment, so
one does not have to keep inventing ad-hoc type descriptors and
dispatch mechanisms to select operations, and code is written in julia
rather than in C against a "Julia API".

That was a bit gratuitous, but I just felt like writing it :)

[Stefan Karpinski]

I enjoyed it, but I'm in the choir here.

[Stefan Karpinski]

The project looks interesting, but it doesn't look like there's any code there yet, just a mission statement.

[fork]

Stefan Karpinski <stefan.karpinski@...> writes:

>
> The project looks interesting, but it doesn't look like there's any code there
yet, just a mission statement.

When I saw the words "European Union" and all those signatories, I thought "This
will never happen". Then I thought "I hope it never happens, because if it does
work it will be bloated crap like Java and XML".

But that's just my cynical side talking.

[david tweed]

On Tuesday, May 29, 2012 9:56:04 PM UTC+1, Jeff Bezanson wrote:

It seems like the goal of this is to be a higher-level replacement for
OpenCL and CUDA, which is certainly welcome. I imagine it is the same
kind of thing one usually sees in niche HPC languages, i.e. defining a
limited domain of programs and data and aiming for peak flops within
that domain. (The process often culminates in adding an object system,
at which point everybody starts to wonder what went wrong.)

Julia "gets it wrong" by NOT doing this. Instead we start with the
workflow of matlab/python/R, and try to provide it within a richer
compiler infrastructure that we hope will eventually allow building up
pretty much anything instead of needing to "call out".

I have to admit to being a slightly on a different philosophy on that one. One of the things that I've never understood is the way that a focused language gets expanded into a widely general language, which tends to result in a language which is both poorly compiled for the "focus" but also not particularly effective as a general purpose system. (One of the attractive thing about a focused language is that it can make restrictions which would be intolerable in a general purpose language,) It'd be nice if there were a framework for using the different languages with different paradigms where they are most appropriate, eg, Pure, Haskell, Prolog, Erlang, etc, in a way with convenient interactions.

That's not to say that I think Julia's design goes to far, but I suspect that making Julia a good language for writing a word processor or a theorem prover would make it a worse language for numerical computing.
 

[Jeff Bezanson]

I should clarify that when I said "pretty much anything" I meant
within the realm where things like CARP might be applicable :) Being a
good language for writing a word processor is not a priority.

But, I think some languages (like matlab) are excessively non-general.
I think julia is an example of how you can have a better
general-purpose language without giving up ease-of-use for, say,
linear algebra. If matlab were able to do something like generate
near-optimal GPU code from programs, then its special-purpose nature
would be better justified.

[Stuart Brorson]

Hi All --

I guess the thing which jumped out at me from the (possibly vaporous)
description of the CARP project was that they had it in mind to create
compilers which emitted highly optimized GPU code. Since that's a big
area of interest (hype?) in numerics nowadays, they have identified a
useful niche for their project.

Since a main design goal of Julia is emission of highly optimized code
for the specialized domain of numerics, there seemed to be an overlap
in the two projects' goals. Therefore, they might be either a
competitor or a collaborator, and which they become can depend upon
striking the right alliances.

Stuart

[david tweed]

Note that Julia already has Krystof Kamienecki who's interested in running Julia on the GPU and (time permitting) I'm experimenting with emitting SIMD vectorised/temporary removed code for the CPU. So there's certainly some good overlap, and hence cross fertilization, possibilities there. The biggest question I have is a general one stemming from OpenCL: it takes a decision that, primarily from end-user familiarity, it's going to be "C with all the GPU-fundamentally-problematic elements taken out". That's fine, but inferring what optimizations are valid in C is tricky, because of the way most of it's constructs are the most general they can be (eg, the for loop), so I'd be interested to see how much an OpenCL compiler can actually non-trivially optimise code. The presence of Monoidics suggests that they're deploying heavy technology on the inference front, but it's still unclear to me if there's not more "bang for the buck" from making a language more amenable to analysis.

[Krzysztof Kamieniecki]

I am currently walking a fine line between wanting to get the GPU integrated and not wanting to rebuild LLVM in Julia (and also not replicate what NVidia is doing with PTX generation in LLVM). I've been busy with other things, but I have been thinking about this, and I think I have finally figured out a simple/quick way to get basic PTX code generated, that can be replaced when the LLVM/PTX backend comes up to speed. Even when the GPU code is generated there is still the issue of deciding how, when, how much data is moved to the GPU and back, and when to execute the kernels. I want that interface to match with @parallel and DArray, although I may change how it behaves with the GPU, I hope that eventually the behavior will converge when everyone has code to experiment with.  

My big hope is that with Julia, I can give it a general algorithm I want implemented, have it try different ways of breaking up the problem, profiling it on the GPU to find the best solution, and then spit out an .so that I can link to it :) 

[Stefan Karpinski]

On Wed, May 30, 2012 at 4:21 PM, Krzysztof Kamieniecki <kr...@kamieniecki.com> wrote:

My big hope is that with Julia, I can give it a general algorithm I want implemented, have it try different ways of breaking up the problem, profiling it on the GPU to find the best solution, and then spit out an .so that I can link to it :) 

Given enough metaprogramming, this should be possible.

[Andrei de Araújo Formiga]

2012/5/30 Krzysztof Kamieniecki <kr...@kamieniecki.com>:

> I am currently walking a fine line between wanting to get the GPU integrated
> and not wanting to rebuild LLVM in Julia (and also not replicate what NVidia
> is doing with PTX generation in LLVM). I've been busy with other things, but
> I have been thinking about this, and I think I have finally figured out a
> simple/quick way to get basic PTX code generated, that can be replaced when
> the LLVM/PTX backend comes up to speed. Even when the GPU code
> is generated there is still the issue of deciding how, when, how much data
> is moved to the GPU and back, and when to execute the kernels. I want that
> interface to match with @parallel and DArray, although I may change how it
> behaves with the GPU, I hope that eventually the behavior will converge when
> everyone has code to experiment with.

Based on my experience with GPUs, this will be hard to do if the goal
is good performance, but you noted some of the issues in your message.
I think a first step is to provide ways for Julia users to send stuff
to the GPU if they need it, even if it means changing/restructuring
the functions that will be executed on the GPU. That is, create a more
low-level layer for people who want to use it, and then build the
higher level layers on top of it.

Regarding OpenCL, as far as I know it is precisely done to make the
programmer have control over the GPU, I don't know how OpenCL "takes
out" the problematic elements of GPU programming. Programming OpenCL
is similar to programming CUDA at the Driver API level, which is
considerably lower-level than CUDA C. The only difference is that
OpenCL has vector programming support, and the Intel OpenCL SDK has an
automatic vectoriser, but I don't think it does everything magically
(haven't used it though).

---
[]s, Andrei Formiga

[Jeff Bezanson]

This sounds right.
I think people often make too big a deal about language semantics in
these cases; GPU support can/will/has been available in matlab,
python, etc. People seem content to write begin_GPU ... end and get
whatever semantics are necessary within that block, for example.

I am hoping that enough type infrastructure and metaprogramming will
be enough, and that from there a compiler for a gpu sublanguage can be
written.