MCJIT or ORC JIT for new project?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

MCJIT or ORC JIT for new project?

Kevin Atkinson

Hi,

For a new language I am developing (in the very early stages, nothing public
posted yet) I would like to able to use a JIT for several purposes:

1) Create a functional REPL as is done is done with in the Kaleidoscope
tutorial.

2) Be able to interpret my language in addition to compiling.

3) While compiling, be able to execute arbitrary code at compile time.  The
simple case will be to get a value, similar to C++ constexpr but without any
restrictions.  The complicated case will be to support a full macro system
similar to syntax-rules in Racket or defmacro in Lisp.

For (1) I would require being able to execute a function at a time. I would
also like to be able to discard temporary functions used just to get a
value.

For (2) and (3) lazy compilation is required, catching the results would also
be great.

For right now I plan to use a direct AST based interpreter, but I would also
like have JIT available when it is needed.

It looks like the new ORC JIT will be better suited for my needs.  Would it be
better to use the devel version of LLVM and the new JIT?  Or is the new ORC
JIT too much of a moving target and would it be better to stick with MCJIT?

If it is best to stick with MCJIT can someone point me to a working
Kaleidoscope that will work with MCJIT and the latest released version of
LLVM.  There are several versions floating around and I am confused on what
version to use.  The examples in Kaleidoscope/MCJIT/lazy don't compile with
3.6.1 and I was hoping there was a version that would compile.

Let me know if anything is unclear.

Thanks in Advance,
Kevin


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: MCJIT or ORC JIT for new project?

Russell Hadley
We  (the LLILC project) have moved to ORC.  It's been stable for us and much more flexible than MCJIT.  (In terms of size of input, we've scaled up to being able to jit/run both the Roslyn C# compiler and 3k tests in the dotnet CoreCLR repo.)   We don't have the same requirements as to compilation but ORC seems like it'd be a better fit.

-R

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Kevin Atkinson
Sent: Wednesday, July 1, 2015 10:51 PM
To: [hidden email]
Subject: [LLVMdev] MCJIT or ORC JIT for new project?


Hi,

For a new language I am developing (in the very early stages, nothing public posted yet) I would like to able to use a JIT for several purposes:

1) Create a functional REPL as is done is done with in the Kaleidoscope tutorial.

2) Be able to interpret my language in addition to compiling.

3) While compiling, be able to execute arbitrary code at compile time.  The simple case will be to get a value, similar to C++ constexpr but without any restrictions.  The complicated case will be to support a full macro system similar to syntax-rules in Racket or defmacro in Lisp.

For (1) I would require being able to execute a function at a time. I would also like to be able to discard temporary functions used just to get a value.

For (2) and (3) lazy compilation is required, catching the results would also be great.

For right now I plan to use a direct AST based interpreter, but I would also like have JIT available when it is needed.

It looks like the new ORC JIT will be better suited for my needs.  Would it be better to use the devel version of LLVM and the new JIT?  Or is the new ORC JIT too much of a moving target and would it be better to stick with MCJIT?

If it is best to stick with MCJIT can someone point me to a working Kaleidoscope that will work with MCJIT and the latest released version of LLVM.  There are several versions floating around and I am confused on what version to use.  The examples in Kaleidoscope/MCJIT/lazy don't compile with
3.6.1 and I was hoping there was a version that would compile.

Let me know if anything is unclear.

Thanks in Advance,
Kevin


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: MCJIT or ORC JIT for new project?

Lang Hames
In reply to this post by Kevin Atkinson
Hi Kevin,

My recommendation for people starting new projects is to use ORC rather than MCJIT where possible, as ORC has a strict superset of MCJIT's functionality. There are no guarantees on ORC API stability however, so if that's truly critical then MCJIT's C API would be a better fit for you.

If you're living on ToT (which we also generally recommend), then the minimal day-to-day churn on Orc should be manageable. If you're planning to live on stable releases you'll have the usual (and difficult-to-predict) inter-release headaches.

Either way, let me know how your choice works out for you: I'm keen to keep improving LLVM's JIT support.

Cheers,
Lang.


On Wed, Jul 1, 2015 at 10:50 PM, Kevin Atkinson <[hidden email]> wrote:

Hi,

For a new language I am developing (in the very early stages, nothing public posted yet) I would like to able to use a JIT for several purposes:

1) Create a functional REPL as is done is done with in the Kaleidoscope tutorial.

2) Be able to interpret my language in addition to compiling.

3) While compiling, be able to execute arbitrary code at compile time.  The simple case will be to get a value, similar to C++ constexpr but without any restrictions.  The complicated case will be to support a full macro system similar to syntax-rules in Racket or defmacro in Lisp.

For (1) I would require being able to execute a function at a time. I would also like to be able to discard temporary functions used just to get a value.

For (2) and (3) lazy compilation is required, catching the results would also be great.

For right now I plan to use a direct AST based interpreter, but I would also like have JIT available when it is needed.

It looks like the new ORC JIT will be better suited for my needs.  Would it be better to use the devel version of LLVM and the new JIT?  Or is the new ORC JIT too much of a moving target and would it be better to stick with MCJIT?

If it is best to stick with MCJIT can someone point me to a working Kaleidoscope that will work with MCJIT and the latest released version of LLVM.  There are several versions floating around and I am confused on what version to use.  The examples in Kaleidoscope/MCJIT/lazy don't compile with 3.6.1 and I was hoping there was a version that would compile.

Let me know if anything is unclear.

Thanks in Advance,
Kevin


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: MCJIT or ORC JIT for new project?

Kevin Atkinson

Thanks for the advice.

I think I will switch to the ToT[1] and try out the ORC JIT,  I think I will
switch to to a release version once 3.7 is out (assuming it included the ORC
JIT.)

I let you know how it goes.

Kevin


[1] which by the way I had to google as I never herd that term before :)


On Fri, 3 Jul 2015, Lang Hames wrote:

> Hi Kevin,
>
> My recommendation for people starting new projects is to use ORC rather
> than MCJIT where possible, as ORC has a strict superset of MCJIT's
> functionality. There are no guarantees on ORC API stability however, so if
> that's truly critical then MCJIT's C API would be a better fit for you.
>
> If you're living on ToT (which we also generally recommend), then the
> minimal day-to-day churn on Orc should be manageable. If you're planning to
> live on stable releases you'll have the usual (and difficult-to-predict)
> inter-release headaches.
>
> Either way, let me know how your choice works out for you: I'm keen to keep
> improving LLVM's JIT support.
>
> Cheers,
> Lang.
>
>
> On Wed, Jul 1, 2015 at 10:50 PM, Kevin Atkinson <[hidden email]> wrote:
>
>>
>> Hi,
>>
>> For a new language I am developing (in the very early stages, nothing
>> public posted yet) I would like to able to use a JIT for several purposes:
>>
>> 1) Create a functional REPL as is done is done with in the Kaleidoscope
>> tutorial.
>>
>> 2) Be able to interpret my language in addition to compiling.
>>
>> 3) While compiling, be able to execute arbitrary code at compile time.
>> The simple case will be to get a value, similar to C++ constexpr but
>> without any restrictions.  The complicated case will be to support a full
>> macro system similar to syntax-rules in Racket or defmacro in Lisp.
>>
>> For (1) I would require being able to execute a function at a time. I
>> would also like to be able to discard temporary functions used just to get
>> a value.
>>
>> For (2) and (3) lazy compilation is required, catching the results would
>> also be great.
>>
>> For right now I plan to use a direct AST based interpreter, but I would
>> also like have JIT available when it is needed.
>>
>> It looks like the new ORC JIT will be better suited for my needs.  Would
>> it be better to use the devel version of LLVM and the new JIT?  Or is the
>> new ORC JIT too much of a moving target and would it be better to stick
>> with MCJIT?
>>
>> If it is best to stick with MCJIT can someone point me to a working
>> Kaleidoscope that will work with MCJIT and the latest released version of
>> LLVM.  There are several versions floating around and I am confused on what
>> version to use.  The examples in Kaleidoscope/MCJIT/lazy don't compile with
>> 3.6.1 and I was hoping there was a version that would compile.
>>
>> Let me know if anything is unclear.
>>
>> Thanks in Advance,
>> Kevin
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev