[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Scripting in .NET
- From: MichaelL@...
- Date: Thu, 30 Jan 2003 17:22:56 -0500
Here's a blog from someone who's developing a scripting language in .NET:
He's compiling his language in .NET, he isn't interpreting it from a
.NET-based program. Here are some excerpts:
The simple and direct answer is that I have been waiting to release S#.NET
for a very long time and I wanted to initial release to withstand the
inevitable problems without being dismissed. I was unhappy with the
performance issues of Microsoft's .NET Jitter for use in hi-performance
dynamic dispatching scenarios ? the how and why of this are much deeper
discussion. I chose to incorporate my own scaled-back-jitter [borrowing it
from S#.AOS] for x86 code within .NET. I was also deeply perturbed by what
I considered flawed design constraints in DotNet that I had been putting
up with to get the job done, which eventually I decided to aggressively
circumvent ? a decision which has made me mentally much happier but was
the other contributing action that has resulted in this release delay.
I simply could not stand the performance, the extra hoops, the
combinatoric explosion of pre-computed classes and methods I had to
generate, or the x86 code the .NET IL jitter was generating for the
revised/compromise mechanism. I bit the bullet and started to take
seriously the idea of dropping in my own jitter and re-doing the
architecture. It was a very late date in the game to be going back into
R&D mode ? but the pain/anguish of the work and performance numbers was
Even better, my new .NET dispatchers were acceptably close to the
performance of my own AOS.IL jitters in S#.AOS. Translated, this means
that it is now faster than any interpreted Smalltalk, and within a couple
of cycles [of AOS performance] on a per dispatch decisions point basis.
The difference between S#.NET dynamic dispatch/call performance C#.NET
static dispatch performance is very reasonable [roughly within 6-15
cycles] per call. It could be directly cycle-for-cycle competitive if my
S#.AOS jitter mechanisms were incorporated into Microsoft's .NET jitters.