Ian Carmichael: The History and Future of the CLR | Charles

aL_
Rx ftw

i agree with stevo_ on this one, but it seems that everyone is pretty much in agreement here but dont realize it Smiley
IL is good for a runtime that supports lots of languages, source to native is good for a language that only supports one runtime. Lars is correct in the context of V8 but perhaps not so much in the context of .net [of witch he presumably has far less experience] nothing wrong with that.

stevo does make a great point though, IL is faster to compile than source. and charles, while it is true that IL is source, you must agree that its optimized for jitters more than humans Smiley by the same token, assembly code is source too Smiley i mean, technically it is, but not really in practice for most people. human readable is a relative term i suppose Smiley

il is really bare bones as far as lexing and parsing goes, its bacically just higher order instructions right? c#, vb js and pretty much all "normal" languages are more optimized for humans so they wont compile as fast i think.

also, consider tooling, if one is to write a tool for .net one only really have to understand IL, not a bunch of native code for various platforms.. thats a huge advantage Smiley

Ravenex

Lars had pretty good experience in VMs, and he had worked on JVMs which are quite similar to CLR in general, I'm sure he's knows enough about bytecodes/IL. I wonder if Charles read my reply in the other thread (CLR4 debugging and profiling API). I was trying to say, when Charles started the topic on IL, Lars was probably still in the context of V8/JavaScript, so he said what he said, and it made perfect sense. Having bytecodes in V8 wouldn't have helped much in keeping the VM fast and simple. And that you'll have to "check twice" if you had bytecodes as a wire format for JavaScript. Charles was in the context of CLR or a more general VMs, the two guys really weren't arguing about the same thing...

Going from source to bytecodes is much easier than getting straight to native code. A lot of JavaScript VMs are imlemented as interpreters, because interpreters are easier to build. So they would interpret bytecodes, and that's the only execution mode they have. V8 also has only one execution mode, and that's compiling straight to native code.

But there are VMs, like TraceMonkey, that use adaptive compilation system, and use bytecode for startup and profiling/tracing, and hot spots get compiled/optimized into native code. That's having two execution modes (or more) in the same system, which leads to complications in design and implementation. Lars had worked on such adaptive compilation systems before, so he knows why it's not suitable for the goal of V8 -- build a fast and simple JavaScript VM in short amount of time.

littleguru
<3 Seattle

In my eyes IL isn't similar to C#. It's true that you can execute methods and that everything is organized in classes, namespaces, methods, etc. - but that's more a property of OOP. IL is organized as a stack machine (you clearly see that if you do something with it) and C# is not exposing that at all.

Charles
Welcome Change

In reply to Ravenex

#Jun 10th @ 5:00 AM

Actually, I read your post and you're asumption is incorrect. As stated, the argument was focused on the necessity of IL, generally (and this includes Java bytecodes). The debate continued for at least 40 minutes after the camera was turned off. It was me versus Erik and Lars. As you can imagine, I had my work cut out for me... Erik isn't a big fan of MSIL, specifically. Lars thinks intermediate steps add unnecessary abstraction, always. That's all I'm going say on this since I will not speak for other people. If you want to know the details of their thinking, then you will have to ask them yourselves.

Regardless, this is a useful debate.

There are pros and cons all around us, all of the time. Understanding what they are exactly is key to becoming knowledable and readily capable of critically thinking through various contexts in which some set of pros and cons may take on a more dynamic characteristic moving closer to or father from one another.

C

Ravenex

In reply to Charles

#Jun 10th @ 10:00 AM

Thanks for clarifying the misunderstanding, Charles Smiley

Well...Walter Bright of Digital Mars doesn't seem to like the idea of having a VM/IL, either. And he designed the D language to have GC without a VM. The interview on CLR4 security changes mentioned you can do unsafe things with native code anyway, so VMs doesn't really buy you that last bit of security; that's OS' job.

My take is that IL is just like what would have been an intermediate representation in between front-ends and back-ends of a conventional compiler; in other words, you're just splitting a compiler into two parts, with some of the machine independent parts packed into a "compiler from source to IL", and machine independent parts with machine dependent parts packed into the VM. Then of course you can interpret IL, but in systems like the CLR, the JIT compiler is what would have been a back end of a conventional compiler, with time-consumption taken into account -- time-costly optimizations can't be performed because it'd hurt startup perf.

So deploying a managed app sounds like...distributing the sources (MSIL), and making sure a compiler (CLR) for the platform is installed. And when the user runs the managed app, CLR compiles the app and runs it. So for M source languages with N target platforms, you'd only have to write M compiler that target MSIL, and N CLR implementations for each platform, that's M+N instead of M*N in a traditional compiler architecture without a standard intermediate representation. JITting has this advantage of being able to dynamically linking libraries, and generating calls into the libraries with less indirection, because the JITter has knowledge of all methods' entry points; NGEN can't do that, so it's throughput is a bit worse than JITted code. That's why they had the troublesome hardbinding in NGEN before CLR4.

And generally bytecodes are easier to verify than native code. That buys you verifiablity, for JVM and CLR, that's important. But bytecodes are actually "harder to verify" than source code, because source languages tend to have more restrictions than their corresponding bytecodes.

Ah, and speaking of compilers...NGEN uses the JIT compilers as CLR does, but used in ahead-of-time compilation mode. NGEN is slow because it compiles everything, while JITting just compiles what's been invoked, so the compilation time is amortized and affordable. If you add up the total time to JIT everything used in a managed program, it'll probably take the same amount of time as NGEN does...