[Coldstuff] Re: Bytecoded language speed

[klaus schilling]

michael@mudge.com writes:
 > On Wed, 17 July 2002, "Frank Crowell" wrote
 > 
 > > I am not clear on what it would take to handle a heavily populated, animated
 > > world.  I saw the death of Gods Net (if I remember the name correctly) on
 > > LambdaMOO die because it was too much for the server.  Even LPMuds started
 > > to show signs of poor performance when they had mobs that did too much.
 > > Dikus probably did a little better because there was no interpeted coded.
 > > 
 > > At some point maybe this becames a server issue and not a database issue.
 > 
 > Much of the problem here is that bytecode MUDs are very easy to code on, and
 > they're very fast before people start logging on.  Everyone gets so wrapped up
 > with writing cool code quickly, nobody pays attention to speed.  However, I do
 > think that bytecode MUDs can run efficiently if speed is kept in mind from the
 > start.
 > 
 > ColdC incorporates data types and programming structures that would be a major
 > bi*ch to implement in languages such as C, making C programmers much less
 > likely to use these optimized methods.  With things like dictionaries being so
 > easy to implement in ColdC, a speed-conscious programmer can easily make code
 > that is actually faster because it is easier to "do it right".

What about perl and python? They have dictionary-like stuff, too. 
(if perl's hashtables qualify as dictionaries).
But there;s no way to decompile there bytecode, this would make it
necessary to save code in ascii format and 'eval' or 'exec' every time
it's needed, making it almost worse than using purely interpreted
languages like guile.
The disadvantage of C is that it requires to shut down and restart the server
for every little changement in code. Diku builders may only fill in 
templates with new strings and integers, but not add or modify any
function at runtime, making dikus downright boring.


Klaus Schilling