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

Justin Rogers justin at mlstoday.com
Wed Jan 17 21:29:19 CET 2001


[Szii]

> .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:

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.

> IMHO, .NET is just a way for MS to tie together all of the
> bastardized technologies that they've come up with over the years.
> And you said yourself that "it could be size months or 2 years
> before this is available."  MS is not really well known for keeping
> schedules, or having "super-robust technologies."

Yeah.  I have to fudge the numbers and hypothesize to keep my NDA.
Not a big deal.  For those who have worked with the Beta 1
technologies already out, they will have realized that the platform is
already quite far along (and that was in November).

> 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.

Justin Rogers

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



More information about the mud-dev-archive mailing list