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.. :) -Shay -- +---------------------------------------------------------------+ | 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