Heh. I remember when you were supposed to make Linux swap partitions of
128M or less, because more would not be used.



I suspect most mud admins have no real clue whther they're swapping or not,
unless they're hosting out of their own basement. With hosting solutions these
days being black boxes to the end user, I think I'd be hard pressed to know myself.

-Crat
http://lpmuds.net

Yes, I agree, which is partly why I think the issue isn't really something that newbie coders should be thinking about. Not yet, at least.


With access to 'top' or something, you can find out easily enough.

With access to 'top' or something, you can find out easily enough.

Well, maybe. That was true up until the introduction of VM systems. Now, you can see if you're using the "swap" that's in YOUR little universe, but you can't tell if your entire universe is being bounced in and out of the swap that's in the parent universe the VM's are all running in!

The possiblity that you might try to tune your swap parameters in your Linux VM, only to realize that it's a moot point because your VM itself is at the mercy of the Windows 2003 server's virtual memory system, makes Piplup sad.

On my system at least, top displays resident memory as actual physical memory usage – if this number is less than what you know your program is using actively, you know stuff is being swapped out.

My point was, there's no way (from software) to tell if what you're seeing is real physical memory, or what the VM you're running in is telling you is real physical memory. I could give you a VM where all your "memory" is mapped to a floppy disk drive, and aside from it being really slow, you have no way to know that.

Obviously, that's only relevant to folks who are using hosting services, since if it's YOUR system, you ought to know how it's setup and working. :)

Sorry, I thought you were talking about virtual memory systems (which is why I was a little confused about your answer…), not virtual machine systems. Yes, I completely agree that if you're in a virtual machine, all bets are off.

Quix's rant pretty much covered all the bases on performance concerns, as far as I'm concerned, it just depends on what you want to stick to.

As for C#, it sounds like you are dreading or generally have an aversion to OO design. Personally I'm of the opinion that OO is superior for applications like a MUD server where you're dealing with plenty of objects be they actual objects\items or players, mobs, etc.

Basically I'm adding nothing productive to this thread except to say that Elanthis, Quix, and the others have pretty much covered what needs to be said. If your concern is whether C# is viable, I can tell you - as a C# developer - that the answer is unequivocally yes. I'd even go so far as to say that, if you're starting from scratch, it's much easier to get things done in C#. Of course, if you're not, there are plenty of starting points and code snippets available in C\C++\Ruby\Python\Java.

There are now at least a half dozen codebases in C# but, interestingly enough, most of them are pretty different from each other and they vary from the brute-force simplistic to the over-designed. Either way, I would highly encourage you to start in C#, eventually there will be enough samples of code out there where this is not ever a question again.

Considering how vastly different the development environment is in C# (typically Visual Studio) vs. C (typically vim/emacs/etc and make/gcc/etc)…. perhaps it's time for a C# SocketMUD?

Working on it. I could probably release it as is but I'm looking to fully marry IronPython to the codebase in order to offer the built-in scripting interface should you choose to use it.

Edit: I should clarify that currently I'm using IronPython 2 which is having some issues with Mono. MonoDevelop is a great tool for Linux users who want a Visual Studio like interface, though they could also still use VIM and just use the command line compiler ala GCC too.

It would probably be pretty cool to see both versions, as the changes you need to make to embed and enable python would be a good tutorial on how to do that kind of thing in general, should someone else want to embed lua/ruby/whatever.

Here's a dumb question… C# is a .NET language (meaning the C# code is compiled into the .NET runtime bytecode). So, in theory you can already write code in other .NET languages and (provided you've used types that exist on both sides) just hook the modules in. I also assume most .NET languages give you a way to dynamically load modules without having to resort to making .dll's? If so, could you write arbitrary .NET code and have your game driver invoke the appropriate compiler (if installed) to generate a module, and then load it?

Yeah, I still think a scripting language is more useful… but that would allow you to modify or extend the API hooks of the scripting language itself on the fly.

Yeah, I'll go sit over there and be quiet. :)

The answer is yes to most of your questions. You can build a module in VB or any other .NET language and then import it in C# and use the classes contained therein. There are also classes for compiling code on the fly.

The 'problem' with using that as your scripting interface though is that you're hog-tied to the rigidity of the .NET compiled languages. This is not an issue with a 'real' developer at the helm but it can be an issue if you want your designers to be able to do smaller, more compact scripts via an API you expose through - say - Python, without having to burden them with learning how to properly write a C#\VB class file.

There is another issue with loading a lot of small modules in .NET related to memory consumption, as well. Essentially what you're doing is taking the code file and making a DLL then linking it at runtime. However, if it's a script that gets changed a lot then every time you re-load it you use more memory and it isn't released until the application shuts down. There is a workaround that involves running your code in a separate app-domain, or bubble, and then releasing that bubble when you're done with it but this comes with some performance issues.

In short, the compile-on-the-fly is useful for one-time discovery while a scripting library, like IronPython, is probably best for the other stuff since it is far more optimized than I could ever hope to make the former. One use for the compile-on-the-fly method that I'm using is skills. When the game starts it will compile skills from files in a folder, if you need to make a change you can re-compile the file after the changes are done. This should also help with sharing stuff because you don't really have to change the code and re-compile, you just drop it in a folder and go. Most of the major components can be replaced, or hotfixed, in this way if you're careful about how you structure the references. So if I use an instance of a class for processing my combat functions rather than a static class I can re-compile and hotfix that instance at any time if I need some changes made.

Anyway it's pretty neat. All in all the Dirt library (just add water, get it?) is a fairly small amount of code but I'm really trying to get those wrappers around the codeDom for generation and ironpython in so that others don't have to deal with that plumbing.

Doesn't need a VM for things to get confusing. Your application's address space (its virtual memory mappings) are not necessary backed by physical RAM. You can mmap() a file and get address space assigned for that file even though no actual pages of RAM have been allocated yet.

You can have virtual memory mappings onto other hardware devices like video memory, accelerated NIC buffers, sound card buffers, and so on.

You can run on a an AMD64 system with virtual memory randomization where even a small app gets several hundred megs of virtual address space allocated so that addresses can be spread out, randomized, and hard to guess/abuse during a buffer overrun or code injection. You could have virtual memory mapped by a special driver that generates data on the fly, like a block-version of /dev/random.

Figuring out real current real memory usage and potential memory usage (pages that haven't been allocated for you yet but will be because virtual address space has been allocated for it) is hard. Look around on a Linux desktop mailing list some time and you'll see at least once a week somebody going "OMGZ Xorg is using 700MB of RAM on my machine!!! I'm just running Firefox and I have a 512MB graphics card, why is Xorg leaking memory u guzy sux0rz!!!!"

i was serious! do u know why? my vista doesn't do that

-Crat

This is true, but when talking about MUDs fortunately these complexities do not tend to be relevant so I didn't even get into mmap. (I don't imagine many MUD devs out there are mmapping onto hardware devices, or even the disk…)

Vista doesn't use any of your video card's dedicated memory? No wonder everyone thinks XP is faster. ;)



Preposterous! All MUDs should be mapping /dev/mem! It makes the code more manly, right Scandum? :p

Hey Vassi, do you have any experience with DLR languages for .NET? I think IronPython is running off the DLR now, right? (Haven't kept up on that stuff.)

Yes, and yes. IronRuby is in the pipeline but it's not coming along nearly as quickly as IronPython is.

So… is it good? Easy to implement sandboxed scripting languages?

Hosting options for almost any type of language you want to run are not severely limited nowadays :) VPS' like http://www.linode.com/ let you configure your own instance of a server however you like so you are free to install mono. I would imagine other "mud host" oriented hosts would be willing to offer mono as long as you're willing to pay.

Hehehe, they don't need to!



So, not only might your application's memory vs. swap not be right, but the "memory" it's using may not even exist, AT ALL!

I can't really speak to how easy it is compared to something like C or C++ but yes, it was pretty easy on the first release. The DLR version (IPy 2.0) was a bit more complicated to embed but it's still pretty easy to do. As for sandboxing, that's a bit of a pain because you have to dig into more than the basics of how the .NET security model works - which one could say is only a good thing anyway - but I mention it because the 'default' way to do it is inherently very unsafe. Since you can call up all of the .NET libraries it's easy to write a python script that will exit the application or completely hijack it. If you do it right, with a permission set, you can avoid all of that.

In the end, though, I managed to write my entire wrapper library in about 250 lines of code. The features I managed to fit into that include running a script (either from the sandboxed instance for public scripts or from a private instance for full-power) and a shortcut for retreiving an object class from a python script with reflection. The nice thing about that one is that it can be an arbitrary object you're asking for, because of generics. Usage looks like:

Scripting.MapDirectory("Host", "HostScripts", true); 
//parameters: Alias, Path, true (means the path is relative to the exe directory)

Scripting.AddReference(typeof(PyObject).Assembly, PyRuntime.Private); 
//Adding the object definition to the private engine so that I can inherit it in a Python class

PyObject py = Scripting.GetObject<PyObject>(cmd[2], "Host", target); 
//Creating the object. cmd[2] represents the filename (i.e. script.py), the alias path to look in
//and target represents the engine I want.

To run a script, not just pull an object out:

var obj = new EditObject();
var scope = Scripting.GetScope(target); 
//Again target represents the desired instance, public or private.

scope.SetVariable("Obj", new EOWrapper(obj)); 
//Adding the object to make it available as Obj to the python script.
//The EOWrapper represents the 'API' I want it to have.

Scripting.RunScript(cmd[2], "Host", scope);

Objects are passed by reference, so the changes made in the script do not go out of scope. Also, RunScript actually compiles the code and caches it so that subsequent calls to the same script don't incur the overhead of interpreting unless the file has been changed since it was last compiled. That check is done simply by checking the last modified date against the cached version. Once compiled it runs as fast as one would expect normal code to run, so speed penalties are not a concern.

Edited to fix hscroll.