How much slower is...

a context switch between threads in a single program and a context switch between actual programs?

I'm just wondering if I could efficiently utilize multiple BMax programs to simulate multi-threading by passing some "pointers" from the parent program to the child program to use to send data back to the main program when it gets some. I suppose I could use UDP communication as well, although that seems like a lot of overhead for a direct communication.

Context switch between processes is at least an order of magnitude slower than a context switch between threads.

That's what I was afraid of. Thanks.

Although since BlitzMAX doesn't have support for threading, using multiple processes is really the only way to go, if you want to fake it. However you can communicate using stdio/stdout pipes rather than using UPD etc.

If you really have to do it, there really isn't any other option.

Well, to be honest I'm not sure I really need to do it. Right now I'm too wet-behind-the-ears to know what I'll need and not need for my current project.

What I am trying to do is foresee any potential problems and make sure that solutions will be available if said problem arises. In this case, there is a solution, but it's hack'ish and slow. I don't necessarily mind hacking it together, but the speed would be a problem, as the whole reason I'd resort to that measure would be to increase the speed/efficiency of my server.

I'm still wondering if choosing Blitzmax for my MUDserver isn't an attempt to fit a square in a circular hole. I'm just worried that if I switch languages now I'll never get this off the ground as my momentum will be killed. I'm just a hobbyist and while I have a lot of time, I don't have unlimited motivation (especially considering the ROI of this project is likely to be zero.)

Right now I'm looking at Franz' Allegro Common Lisp. I'm quite intrigued by Lisp as a language, and Allegro CL has a TON of features that would ultimately make this all a lot easier. I'm just wondering how long it'd take to get comfortable with the lisp language itself.

Well it's not really slow, as context switches in most pre-emptive operating systems are really, really fast.

However since processes cannot share data, the real problem would be inventing a mechanism to syncronize data between running processes.

Since (if memory serves) you're running all of this off a database, that may not be as large a problem as you might imagine, especially if the database is ACID compliant and reasonably fast.

BlitzMAX should easilly be able to run a MUD server, if implemented correctly.

Forever. Lisp is a horrible 4th generatiob language designed specificly for modelling the business needs of the financial sector.

It is for all other purposes useless, and has syntax that will make you wish you where using Perl.

Well, the syntax is a bit strange but it's so consistent that in the end it seems like it's easier than traditional languages (which have so many cases of unique syntax for a specific command/operator/etc).

I don't see why you'd say it's useless, though. Allegro CL (along w/ many other CL implementations) have native support for tons of things that'd be handy in a MUD server such as:
Networking
Multi-threading
Hash tables
The ability to adjust code on the fly, including redefing objects and their schema
The ability to use Lisp as both server code and script code
Automatic garbage collection
Higher order functions

It's nearly as fast as C++, according to the "Great Language Shootout." It's definitely faster than Lua - and considering that I was planning on implementing the majority of my MUD, even things such as player commands, as scripts (for ultimate flexibility and extensibility) - the speed difference could be extremely noticeable.

Add to that that Allegro CL has native support for MySQL databases, Oracle databases, ODBC support, and it's own AllegroCache OODB system (which looks to be the ideal DB approach for a MUD server) and it becomes even more appealing.

Toss in a comprehensive IDE, the ability to evaluate code w/o compiling (evaluating functions on the fly seems like it'd be a huge timesaver), an extremely detailed debugger, support for foreign functions and interfacing with other languages, SSL support, a built-in profiler, and more, and it seems like a no-brainer.

I think I'll spend the rest of the week reading up on Lisp and trying to port what I've already got and see how that goes.

I really love Blitzmax, but I think I'm just being stubborn by utilizing it for my MUD server. Yes, it *could* get the job done, but some of the features I'd like to include (a fully spatial/coordinate based world, for instance) are going to be fairly processor intensive. Actually, the real hold-up would probably be the lack of multi-threading support. I can't have the whole game lag if a database request takes longer than expected.

I'll still be using Blitz for the custom client though. :)

Because it's true.

Since the fundamental assumption in Lisp is that everything is a list, I don't see how hashtables would actually work (as they are decidedly non-listy). But anyway.

Also speed is only a consideration for people with slow computers. If you want to let players create scripts, Lisp is most definately a poor choice.

If you had to chose a language other than BlitzMAX, try Python or Eiffel. Lisp deserves to die the peaceful death it was denied 40 years ago.

The lisp of today is not the lisp of yore. For one, Lisp has many primitive data types. Most implementations allow you to compile to machine or byte code. It's just...well, I don't think it is the Lisp you are thinking of (although from what I've heard of the archaic lisp, I can understand your point of view)

If you have some spare time and are so inclined, check out this free book "Practical Common Lisp."

http://www.gigamonkeys.com/book/

The first chapter goes into all the reasons you might consider Lisp for a project.

Well, the speed concerns I am worried about are for my server.

I agree that Lisp as the scripting language might not be the best choice. Well, technically it might be (especially if the server was written in lisp) but on a pragmatic level, I'm sure that the language and it's syntax would scare off several builders. If that turned out to be true I could always write some bindings for Lua (what I am using w/ the current incarnation of the server).

Anyhow, I'm not trying to evangelize Lisp (I don't know enough about it to act as a Lisp crusader or anything), but I just get the impression that your idea of what Lisp is and what it is capable of is a decade or two out of date. I mean, if it was complete garbage, I doubt they'd have used it to implement the underlying searching for Orbitz or have used it for the Yahoo Store.