[MUD-Dev] ANNC: .NET Frameworks based Mud Codebase

[szii at sziisoft.com]

At 09:29 PM 1/17/01 -0800, Justin Rogers wrote:

>> .NET is just a framework - a "way of doing things" that's more
>> abstract that it is concrete.  Things like VB, JScript, etc just
>> aren't high-performance creatures.  Even the new C# (does anyone
>> else see a huge resemblance to Java here?) will probably be better
>> than Java, but won't reach pure-compiled code speed.  Not everyone's
>> a coder - some are game designers and this point won't matter to
>> them as much as a quick and stable platform for some world-building.
>> =)

> C# is faster than Java.  Your kind of missing the true .NET platform
> because your being forayed by marketing which states that this is a
> JIT technology.  Your also assuming that C# will only run in this
> state.  These are both marignally correct/incorrect assumptions.
> The following may shed some additional light:

I've not worked with C# all that much; I quit my NT Systems job in
lieu of a Linux position just about the time C# beta 1 came out.  I've
no doubt that C# will be faster (and easier) than Java.  It's
bascially the next incarnation of the idea.  However, C# still
compiles to MSIL (basically bytecode/p-code) and is then JIT'd.  The
nice thing about .NET is that anything (VB/C++/C#, etc) can compile to
MSIL and use the CLR underneath it.  So why use CLR at all?  To patch
together and clean up JScript, VB, C++, C#, etc.  Good idea?
Definately.  Good implementations?  Well, that's why my faith in MS
deteriorates.  Even while their glorious Win2k servers have a good
deal written in C#, I've still seen a good number of BSOD and system
hangs just using their admin tools on a perfectly clean installation
(on a very-boring Dell 410)

> C# is as feature rich as C or C++ and doesn't rely on the .NET
> Framework to be fully compiled.  I've written a compiler with a
> straight Assembler output that (should I optimize the code
> generation) resembles the same code that a C/C++ compiler might
> output.  Anyways before running the code is compiled.  The compiled
> code is then stored so next time the code is run it doesn't need to
> be compiled.  The JIT engine also has something called Native JIT
> which means that the IL is compiled the first time it hits the
> machine and is then only saved in native code identical to a C/C++
> executable.  You can also take advantage of Managed C++ which has
> speed equivalent to that of normal C/C++.  The only perf hits are
> when trying to cross the managed/unmanaged border.  This is known as
> transitioning and the same perf hit is obtained by going in either
> direction.

Why would you need JIT then?  Why not compile to MSIL, and then to
Native?  The only reason for the JIT would be some cross platform
stuff, and while they SAY that they're going to port the CLR engine to
other platforms, I just don't really see it happening.  If Native
JIT's as fast as raw cool....cool!  That'd rock, and would still give
you the nice .NET features later on.  The whole .NET thing is a good
idea, as is C# (although I'd have loved to see them work with Sun on
it and come out with -1- killer spec.  At a Tech Conference here in
San Jose MS demo'd their .NET tools...and locked up the app.
Ctrl-Alt-Del=>End Process.  "Oh, this is still in Beta."  Good demo in
front a hundred people or so at your own conference.  (The specific
app was their cluster management tool which is still fairly new to
them, so I can't knock them too much.)

>> Sorry for the negativity - I've wasted thousands of hours tracing
>> through MS crap and dealing with their system code.  They may
>> surprise me, but I just wanted to throw out a heads-up warning to
>> keep your eyes open if you go this route.

> Hehe.  I'm on the team so I'm certainly going this route.  I know
> what the code is capable/not capable of.  I program portions that
> are critical to the inner workings of a MUD.  And so far I haven't
> seen any bottlenecks in the system that might destroy it before it
> gets started beyond the data access time and level of data
> abstraction.  Of course that isnt' an area that I can influence, but
> my associates assure me that several objects are available with
> little or none of the overhead that I'm worried will damage my
> system.

Hey, as I said, just keep your head up. =) The whole suite of
COM/ATL/STL problems cost us, as I said, thousands of hours and dozens
of hotfixes from MS.  When your white paper's done toss it my way!

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