LLILC – LLVM-Based Compiler for .NET CoreCLR
github.com
github.com
And also check out LLVMSharp -- http://www.llvmsharp.org which gives LLVM access to .NET
Disclaimer: I'm involved in both projects.
> LLILC is an LLVM based MSIL Compiler - we pronounce it 'lilac' - with a goal of producing a set of cross-platform .NET code generation tools. Today LLILC is being developed against dotnet/CoreCLR for use as a JIT, but an ahead of time (AOT) compiler is planned for the future.
The mailing list post is a bit clearer to my mind, and I'm now rewording the above in "layman's language" as follows, but I may still be wrong (please correct me):
"Today, LLILC is a modified version of CoreCLR (= .NET Core, which is the part of .NET which was open sourced by Microsoft in November 2014) where the code generation backend is replaced with LLVM (but still working as a JIT). We're also planning to implement an ahead of time compiler for MSIL (= CIL, which is what the .NET bytecode is a form of), also using LLVM, but then perhaps forgoing the use of (most of?) CoreCLR. The aim is also to make it possible to use the wide array of tools available in the LLVM ecosystem, such as code analyzers."
LLVMSharp provides C# bindings to LLVM's C interface. It does not allow LLVM projects to use dotnet code.
Maybe when this has AOT it can also be useable in the same way Unity IL2CPP and Xamarin Mono are used.
[1] http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...
Edit: I gave up trying to build a Linux-x86_64 to Android-ARM cross-compiled Mono a year ago. The configure script didn't even think of handling bitness differences between host and target... The commerical Xamarian toolchain for AoT iOS compilation seems more mature than what is released in Mono.
Diffing upstream with http://github.com/Microsoft/llvm will let you track what Microsoft is currently doing in its repo.
What are the chances of Enterprise switching to .Net instead of Java?
I think it's pretty disingenuous to say those things are hard to measure or even estimate. Java and C# are close enough that you actually CAN measure them in a pretty useful way.
Java has been behind the curve for YEARS as compared to .Net with perhaps the exception of the cross platform aspects and the more permissive licensing.
The closest thing I can think of is PyPy, which like Graal+Truffle lets you write a dynamic language in a high-level way, but still get specialized JIT compilation "for free". (In PyPy you write an interpreter, in Graal+Truffle it's more declarative.)
Both PyPy and Graal+Truffle achieve state of the art performance. I'm not aware of any dynamic language on .NET coming even close to that.
Both IronPython and IronRuby have used this for years.
The "Day 1" comment was specifically pointed at the read-between the lines for Graal, which is basically to create a real IL for Java instead of using the InvokeDynamic semantic that is currently envogue for Scala, Clojure, etc. .NET has had the multi-language one VM paradigm since day one.
The fundamental issue is that dynamic languages need JITs that are very aware of their internals. It's not enough to just emit some code interspersed with PICs and to add fast dynamic dispatch. You also need to speculatively compile and deoptimize in a way that is specific to each dynamic language. Without that, IronPython and other dynamic languages on .NET are often not a little slower but 10x slower than the same languages on the JVM or PyPy.
Graal together with SubstractVM offer AOT compilation and is also being used by AMD for the GPGPU support targeted for Java 9, latest Java 10.
Truffle is more of a AST manipulation framework for nodes that can be fed into Graal for compilation.
Then there are those meta-circular JVMs like JikesRVM which are done in Java.
Sumatra is planned for integration latest by Java 10.
There were a few Java ONE 2014 and JVM Language Summit Presentations.
JRuby: The Hard Parts, Reduction on GPUs, GPU/JVM Cooperation
http://www.oracle.com/technetwork/java/javase/community/jlss...
Ruby on Top of Graal
https://old.parleys.com/share_channel.html#play/543f88bee4b0...
Sumatra OpenJDK Project Update: Parallelize Yourself with the Stream API
https://old.parleys.com/share_channel.html#play/543fa782e4b0...
Now, that it is going to be open-source and MS is pushing it harder than it has before, it might have a good chance being used for "new projects" but I've seen MS do this before only to fall off the wagon and stop focusing on these type of stuff.
In addition, the "enterprise" market move much slower than anybody and they care about backward compatibility. It would be several years before .NET would be considered for new projects. It is in that timeframe that Microsoft needs to seriously focus on this and explain why .NET should be used instead of Java.
Plenty of enterprise shops are Microsoft full-stack shops (Windows Server/.NET/SQL Server/IIS). I get the impression -- though I haven't seen systematic data -- that .NET has been making gains against JVM as an Enterprise platform.
Both Java and .Net are viable, relevant and widespread technologies. It all depends on which segment of the market you happen to be catering to.
That doesn't make either language/runtime bad or better than the other. Their strengths aren't static, either. They are merely different tools suited for different tasks. Both have some extremely large names using them.
The world of enterprise systems isn't only Mac, GNU/Linux and Windows.
Additionally the pace of .NET doesn't matter, because the enterprise is dog slow to upgrade.
We are still doing .NET 4.0, Windows Forms and targeting XP. Some of the project code was written for .NET 3.5.
On the Java side, most corporations are now slowly moving from Java 6 to Java 7 and they hardly care about any alternative JVM languages.
In some cases they will never upgrade. I'm talking about places still running WebLogic 8 and JVM 1.4.2. Huge business critical production systems. They'll probably still run on that exact stack for the next 5 years at the very minimum. Everything new gets written in whatever the new stack is, that old stack just stays there, forever.
The strange world of mega corp enterprise IT.
If you live in JVM land and value modern development you are probably already on Groovy, Gradle and Grails - where Grails imo. is ahead of the MVC4/5/6 stack...
* scripting to manipulate Java classes, for testing and 50-line scripts in Gradle, though Gradle's been opening up its API so any JVM language can use it. When Java 8 becomes more widespread, a future version of Gradle might standardize on Java lambdas and ignore use of Groovy closures in its DSL
* the MOP used by Grails, though Grails is following its namesake Rails into obscurity
Although Groovy 2 bundled a statically-typed compiler to compete with Java, virtually no-one uses it. There's far better choices for developers who want to replace Java on the JVM, such as Scala. Groovy really should've stuck to its dynamic roots and niche by adding scripting support for Scala-compiled classes instead of going into head on competition with it and Java.
https://github.com/dotnet/llilc/blob/master/Documentation/ll...
Some blog posts I have read on the MSDN Developer Tools Blogs suggested Microsoft was already working on their own AOT compiler, this statement seems to suggest LLILC has not been developed for this purpose yet. So it's an independent project?
> Today LLILC is being developed against dotnet/CoreCLR for use as a JIT, but an ahead of time (AOT) compiler is planned for the future
Which doesn't make much sense to me, unless Microsoft is planning on ditching their existing AOT work for LLVM. (Fine by me, LLVM is quite nice.)
One of LLILC's major objective is give the community an MSIL frontend for LLVM.
This allows a JIT or an AOT compiler to take any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target.
Of course not. But why spread your effort across two projects that duplicate functionality when you could focus on one?
Q: How does LLILC relate to the .NET Native work? A: .NET Native provides a broad tool-chain, targeting Windows. The LLILC AOT could be used as the compiler component of .NET Native to target other platforms.
Since LLVM can run on Windows, you could also use it as your AOT compiler for multiple platforms (including Windows) once LLILC gets there.
Anything regarding coreclr seems to be handled with a goal of being through and through cross-platform.
Because of this tools like cmake, LLVM etc are used instead of Microsoft in-house tools. Because of this, formerly closed-source tools like MSBuild are now being made open-source.
It's a departure from how Microsoft traditionally have done things in the past, but it's perfectly aligned with where the .NET Foundation is currently going.
https://github.com/dotnet/llilc/blob/master/Documentation/ll...
Andy Ayers from the LLILC team will be presenting this exact topic at the EuroLLVM developer meeting: http://llvm.org/devmtg/2015-04
I imagine the LLVM folks will put the meeting videos up on their website like they have in the past, and it would be an interesting video to watch if you're looking for GC specific details in LLILC.
https://github.com/llvm-mirror/llvm/tree/svn-tags/RELEASE_27...