Re: [AD?] New Java version of CircleMUD

From: shay (
Date: 03/27/02

At 03:53 AM 3/27/2002 -0800, you wrote:
>On Sun, 24 Mar 2002, Shay wrote:
> > It depends on how you setup the threads and how much you keep static.
>Yes and no.  Let's be clear, here.  I'm not saying multithreading is,
>across the board, an inferior model.  The parallelism is quite important
>in many domains.  Massive parallelism, which is what a thread/connection
>truly is, has fewer application domains and, more importantly, is wholly
>inappropriate for a great many.  The problems are many and more than can
>be reasonably discussed on the Circle list.  We need to consider both the
>number of thread contexts and the cost of the context switch.  In the
>thread/connection model, the context switch overhead might be low, but the
>number of context switches can be problematic (thrashing and
>synchronization issues come to mind).
>For I/O bound applications -- which a Mud (along with damn near any other
>Internet service) is -- we want to exploit concurrency, not parallelism,
>and thus multiplexing and not multithreading.  This does NOT mean we
>cannot exploit parallelism for parts of our application.  Instead, it
>merely suggests that we need to look at different *models* of parallelism
>than the naive strategy Java formerly forced people into using.
> > I'll admit that not every turn requires computation, but when it comes
> > to things like battles, they can be.
>The issue is not whether a turn is computationally expensive, but whether
>a turn for *every* connection is computationally expensive.  Note that in
>setting aside a complete separate context for *each* user, we're saying
>that for each I/O cycle in which this thread becomes active it might be
>doing something which takes significant time.  If the cost of a context
>switch is not a small fraction of the computation time, we start to run
>into trouble.

>If we're worried that combat calculations will cause latency, then we can
>set aside a single thread for those calculations.  In this way, we
>eliminate the latency caused by the little bubbles of inactivity between
>polling for I/O, sleeping, and processing the combat events.  It's hard,
>however, for me to imagine a combat system that is so computationally
>expensive that it merits such treatment.  If you're getting noticeable lag
>due to combat, you might look for algorithmic improvements before
>attempting optimization of any sort (but especially MT, which introduces
>separate engineering concerns like synchronization).  If the lag is an
>unavoidable consequence of the system's complexity (why is it that
>complex?!), then we might consider moving it to a separate thread with
>other feasibly expensive operations, such as global event processing.

I agree.  The approach I have decided to go with is using a MUX for
players, and
threads for certain computations..  Like battles..  I prefer to use threads for
battles so that it wont effect the world time as much.  I'm not going to worry
about adding it in till after alpha however.

> > Funny, I think C is ugly..
>It is, of course, but in a different way than Java.  C is ugly because of
>syntactical warts and the preprocessor-fu needed to gain modularity (such
>ad-hockery is counterproductive -- I cannot count the number of times my
>zone has been broken by such meta-concerns as file organization), but for
>a procedural language it's fairly complete.  My biggest problem with Java
>is its feature set (although I'm not crazy about its overly verbose
>syntax, either; despite how it might seem, I'm not *that* fond of typing).
>To put it succinctly, Java feels too much like a neutered C++ for my
>tastes (but note that I'm admitting this is subjective; I darest not pass
>this opining off as a fair, objective comparison of the languages, nor do
>I want to see that topic raised).

Ahh.. come on..  I've used both for years..  I dont mind debating.. :)


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT