[MUD-Dev] TECH: .Net (was: programming languages (was: Re: TE CH: STL / Heaps, etc.))

[Adam Martin]

----- Original Message -----
From: "Justin Rogers" <justin at mlstoday.com>
> [Jo]

>> My understanding is that .NET code is compiled to native code
>> before execution - it never runs in an interpreted/JITted VM at
>> all. Hence you get native code speed without the overhead of
>> running a JIT.

[sorry - replying to two authors at once on the same topic:]

The assumption that executing code in a VM-with-JIT is slower than
"native code" is naive. One situation where I've seen some practical
demonstrations of this is memory management (what it's accessing,
when, how, emergent patterns, etc) - when the reality of how an
application is behaving is visible in situ, all at once, to a VM,
there are numerous tricks it can perform automatically that are
beyond the original programmer (who would presumably have to predict
and map out all the possible execution paths and scenarios just to
gather the same quality of information).

There's an interestng web page somewhere on the net "java vs. C" (my
bookmarked URL for it has become 404, but I suspect you could find a
copy reasonably quickly with google). Interesting graphs comparing
JDK 1.2 / 1.1 / GCC / MS-C / IBM-JDK on a variety of tasks, and
showing how they scale, which ones end up taking better advantage of
caches etc. It wasn't amazingly rigourous, but enough to provide
food-for-thought if you hadn't realized how good a VM can be.

> Do we do some neat JIT scenarios?  Yes we do.  We do JIT on
> demand, but we cache the results so it is only ever JITed once.
> We can selectively JIT down to the method level I believe, I don't
> think we can selectively JIT and cache a piece of a method.

As far as I was aware, caching-JIT compilers have been the norm for
some time now? Certainly I've encountered numerous references to the
Symantec Java one as working this way (the Symantec one is the one
Sun has been giving out with the JDK for donkey's years.)

I agree it seems there's a lot of mileage in doing clever things
with VM's; e.g. look at the commerical Java VM's (sorry to
consistently cite Java examples, but its the only VM-platform I've
had cause to dig deep into at all) - IBM's JDK's, Compaq's VM's for
running on their Himalaya Non-Stop servers, + numerous others from
big vendors.

Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev