Fun fact, the Mono Linker project started 10 years ago during the second edition of the Google Summer of Code!
It was originally used to reshape the entire Mono class library into a subset to expose the Silverlight class library API surface for Moonlight.
It was then used to link iOS and Android applications in MonoTouch and Mono for Android, and Xamarin continued to use and improve it.
The Mono Linker has an open architecture making it reasonably easy to customize how it processes code , and detect patterns specific to each platform to link them away. Xamarin added linker steps to do more than tree-shaking, and remove dead code inside methods. For instance:
if (TargetPlatform.Architecture == Architecture.X64) {
// ..
}
The entire if body can be removed if the linker knows that TargetPlatform.Architecture will not be X64.
And now, it's the base for the .NET Core linker. Quite a journey!
Hi jbevain :-) Nice to see you here! Having a tiny switch to a new blog engine, but next part should come up soon enough. Have a nice day, and once more. You rock!
The «immediate» experience is pretty awesome. You just open the web page and you're playing.
It takes longer to download, probably the size of the engine and the assets, but I've been very much impressed with the Unity3D WebGL export of this FPS:
It's pretty cool to see .NET catching up with Mono on that front ;)
Fun fact, MonoTouch applications are built with a very similar pipeline, except that LLVM does the compilation in the end.
The steps 4 and 5 in the blog post map quite exactly to the Mono.Linker and the Mono.Tuner. Both tools are using a XML file format for whitelisting pieces of code that need to be included, that's useful if you're calling code with reflection at runtime which is not statically discoverable at build time.
Yeah, the MDIL thing sounds like it could have been an LLVM IR derivative. Too bad they always have to NIH things (though I guess in this case there might be legitimate reasons to do something different than the level of LLVM IR).
Too bad they always have to NIH things (though I guess in this case there might be legitimate reasons to do something different than the level of LLVM IR).
I'm going to guess that in this case, their reason to not go with LLVM was the most compelling one possible: When Microsoft was designing the .NET toolchain, LLVM didn't exist yet.
Given the timing of when it came out, I wouldn't even be surprised if LLVM wasn't at least partially envisioned as an open-source answer to .NET. In which case there's a hint of NIH behind LLVM, with Mono being the non-NIH open source option.
MDIL is designed to solve a different problem than LLVM IR. LLVM IR is an exchange format between a compiler frontend and backend. MDIL is designed to solve certain fragility problems in binaries.
.NET Native uses MDIL to create a looser coupling between NUTC and the runtime. This means NUTC doesn't have to understand the precise binary layout of the runtime. The binder takes care of fixing that up!
Competition isn't per-se bad, and if we're assuming they aren't using LLVM, what gains are there to using the IR? More front-ends, I suppose. But I wouldn't be surprised if they had more machine dependent behaviour than LLVM IR (which, let's be honest, includes a fair bit), especially for things like overflow detection. There also are pretty bad limitations to LLVM IR's ability to deal with GC roots, which for MDIL will be especially important.
MS is one of the very few organizations to whom I'll give an NIH pass, if for no other reason than merely to have someone exploring alternate implementations.
LLVM IR is machine-independent, so the NIH accusation is not really fair.
MDIL is described to be the platform's native machine code + some extension tokens (to avoid direct encoding of pointers, for example).
A similar LLVM IR derivative would no longer be by a long shot something resembling LLVM IR, so the property of being "derivative" would not buy you anything.
LLVM IR is machine-independent? What? There's plenty that isn't machine-independent, from the obvious (e.g., x86_fp80), to the less obvious (to create IR in the first place one has to have knowledge of the target ABI), what integer types are supported (i64 isn't supported everywhere!), etc.
While true in a narrow sense, it does so by targeting the lowest common practical denominator—in practice, a chip that looks a lot like a 386 or 32-bit ARM with no SIMD pipeline. That puts it as little more than a better GNU Lightning.
Hopefully it's not like the CIL (CLR intermediate language), which is competitive with Java in verbosity. E.g.
.class public Foo
{
.method public static int32 Add(int32, int32) cil managed
{
.maxstack 2
ldarg.0 // load the first argument;
ldarg.1 // load the second argument;
add // add them;
ret // return the result;
}
}
If you ever look at a disassembled CLR executable, expect to see a heap of lines like:
LLVM IR is much less verbose than CIL, isn't class-based, and on the whole is much simpler. The CIL's complexity makes it less flexible than something like LLVM IR or JVM bytecode; this is one of the reasons alternative languages have flourish on the JVM, whereas the CLR only has C# and F#, and F# had to rely on the developers' influence at Microsoft to get the runtime to support some of its features.
> achieved equal popularity to that of Clojure, Scala or Groovy on the JVM
Clojure and Scala seem to be tied for 2nd place popularity behind Java, but Groovy's lagging far behind. Were you looking at the bintray-maven download stats at https://bintray.com/groovy/maven/groovy/view/statistics for Groovy when you put it in with Scala and Clojure? Even tho those stats show 660,000 downloads of Groovy over the past month, click on country and you'll see 625,000 of them came from a server in China, only 12,000 from the US, and 2000 from Germany, the 3 biggest countries. Obviously the China stats are fabricated. Groovy's true popularity is far behind Scala and Clojure.
I was just listing what I assumed were the top 3 most popular non-Java languages on the JVM. But perhaps it's already been overtaken by Kotlin or Ceylon.
I've been using this since the beta. The entire code of my startup is on GitHub so it really helps to be able to monitor and triage incoming changes quickly.
The app itself is still missing some things for my particular workflow: I'd like to have visibility on incoming code that's not part of pull requests. Like simple pushes to branches.
I'd also have the possibility to unsubscribe from repos directly from the app.
> It is my company, my private property. I should be able to do as I please with it as long as don't mess with other's freedom, this is a constitutional right in the declaration of human rights, private property is sacred.
No you should not, and no, that's really not what the declaration of human rights is about.
When you create a french company your create a “personne morale”, a legal entity, an entity on its own, that is viewed more like a living entity and not like an inanimate object. You do have rights on this entity, but you do also have obligations, not the least of which is to follow the law.
So no, just because you want to you can't employ underage kids for instance.
And just because you want, you can't just fire people at will without reasons.
One could argue that laws could be improved, but that's really not the point you're making.
It was originally used to reshape the entire Mono class library into a subset to expose the Silverlight class library API surface for Moonlight.
It was then used to link iOS and Android applications in MonoTouch and Mono for Android, and Xamarin continued to use and improve it.
The Mono Linker has an open architecture making it reasonably easy to customize how it processes code , and detect patterns specific to each platform to link them away. Xamarin added linker steps to do more than tree-shaking, and remove dead code inside methods. For instance:
The entire if body can be removed if the linker knows that TargetPlatform.Architecture will not be X64.And now, it's the base for the .NET Core linker. Quite a journey!