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. > 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). -dak -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | | Newbie List: http://groups.yahoo.com/group/circle-newbies/ | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT