<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: processors --> <!--X-From-R13: X Q Znjerapr <pynjNxnatn.ah> --> <!--X-Date: Sun, 31 Jan 1999 22:22:28 -0800 --> <!--X-Message-Id: E107Ckc-0007kR-00#koala,kanga.nu --> <!--X-Content-Type: text/plain --> <!--X-Reference: Pine.BSF.4.05.9901301831390.16840-100000#shell9,ba.best.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: processors</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw#kanga,nu"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00339.html">Previous</a> | <a href="msg00341.html">Next</a> ] Thread: [ <a href="msg00336.html">Previous</a> | <a href="msg00341.html">Next</a> ] Index: [ <A HREF="author.html#00340">Author</A> | <A HREF="#00340">Date</A> | <A HREF="thread.html#00340">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: processors</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Re: processors </LI> <LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#kanga,nu">claw#kanga,nu</A>></LI> <LI><em>Date</em>: Sun, 31 Jan 1999 22:22:25 -0800</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On Sat, 30 Jan 1999 19:00:11 -0800 (PST) diablo <diablo#best,com> wrote: > J C Lawrence wrote: > <many undoubtedly erudite questions snipped> > I snipped those questions above because I wouldn't know how to > answer them. While Linux (from my semi-brief checking) seems to be rather weak in this area, most commercial Unixes have extensive system statistics reporting tools. Sometimes they are grouped under some sort of menuing or shell program, equally often they are standalone tools; ioperf, sar, dio, tprof, etc. > I am guessing the problem is processor-related becuase I was able to > solve most of the problem by reducing the number of calls per second > our main mobile ai routine gets. I do presume that you are only involing your AI routines when there is direct cause to, and not every XXX time units? You can usually fix a lot here by going for a blocking model where the majority of the time the "event" is blocked (cf process schedulers and the concept of "blocked" or waiting" processes). > This fixed the problem we were having, which was that our tasks > (timed events) were taking WAY too long to go off. I presume you are handling your own event scheduling, and that you are not using cooperative multi-tasking under your scheduler (ie an event, prior to compleation, cannot "yield" the processor to other events awaiting execution (potentially after their own "yields")? ColdX, and some motions in the MOO word (I never tracked if they actually happened) benefit significantly from this latter approach. > A 3 second task would take 20 seconds, but this only happened with a > heavy player load. Our tasks are held in a table indexed to some > number (some sort of ticker in linux? I don't know the proper names > for anything). That table is polled every time the game searches for > player input (it cycles through all our player lines constantly), > and if a task is found to be either overdue or ready to go off, it > goes off. Ouch. Cheaper: 1) Keep the table, but sort it by due time and pProcess the table only up to the first record that has a due date in the future. You need to take care in your table and sort code to make it minimally expensive (choice of sorting algorithm), and in your storage format to ensure minimal traversal and ordering expense (no buffer copies, only pointer copies if possible). 2) Forget about polling your players. Use blocking IO and only hit them if there's something there waiting. > The problem comes when those tasks start taking too long. This of > course causes a cascading effect as more and more tasks build up. Aye. > Generally, the way the author of our language/engine explained it to > us is that the engine and language are not Object Oriented in order > to be faster... Eeek. OO is not inherently slow. It *can* be slow, but then so can standard top-down structured code. Good OO designs can be quite performant. > ...and in order to allow for more proactivity (as opposed to > reactivity). This doesn't relate to the first pat of your sentence. Its either a red herring or a misunderstanding. OO has nothing particularly to do with pro-active or retro-active design considerations, or how well such perform. > We will try reduce the drain that things like mobile ai put on the > processor, but it's a pretty heavy task, complete with string > manipulation and interpreting a mini-programming language we have > inside the game. Other possibilities: 1) Move, where possible, string processing to reference counted strings. Buffer copies get expensive, quickly. 2) Watch your malloc/sbrk rate (profiler). Minimse it. 3) Look into moving your language to a mini VM and then byte-coding it. Your server can then execute the bytecode rather than re-interpreting the scripting language every time again (ie save parse and interpret expenses). 4) Look into the table sorting and blocking models mentioned above and see about minimise the number of useless calls. > Could someone like yourself, or someone similarly erudite about such > matters speed things up by recoding? Probably, but there's a lot of > code, and probably a _lot_ that needs doing. We'll certainly try to > do it, but we will also be buying the fastest processor we can > afford. I know it goes against the programmers ethic to dismiss a > problem by saying "buy more memory" or "buy a new processor" but > I've committed worse sins I suppose (though my new coder starts > foaming at the mouth everytime I suggest it. I'm a little frightened > that upgrading instead of optimizing will kill him.) There's a balance in there. Given a competent programmer (for suitable values of "competent"), and a reasonable choice of algorithm and implementation (nothing wonderful required, just "good enough") of that algorithm, then yes, faster hardware is almost always the cheaper and more rewarding answer. Programmer time is expensive. Hardware is cheap. The counter side of course is that lazy, or pseudo-competent programmers come to rely on this, get sloppy with algorithm and implementation choices, and then try and answer everything with faster hardware. Its a fuzzy line. As I make my living writing code, and in particular from cleaning up other's code, I tend to be a little biased here, despite my best efforts not to be. My general rules of thumb: 1) Ask the programmer what the performance constraints on the system are, why they are what they are, and why that is justified. He should know. He might not know with any great accuracy, or even have checked into it much, but he should at least have some sort of idea as to what the limiting factors are going to be etc. 2) Check into those answers if your a programmer, or have your programmer check into them. Usually no more than a few hours or perhaps a day is needed. You'll either (hopefully) find that your programmer's ideas were correct, or you'll fidn the reasl answer. 3) Get with the programmers in question and the people who know the basic design and reasons for the design for the system (in your case this is probably just the programmer, in corporation=-land, you can end up with a dozen people). Find out if the performance constraints as found are "reasonable" or are something reasonably easily corrected/changed. 4) Take their answer, and if it is reasonable, find out what the next performance constraint is going to be. 5) Now evaluate whether it is worth doing what was found in #3. >> Unfortunately this whole area is a bit of an art. Very very tiny >> changes made to systems can have massive performance returns (or >> penalties). > In that case, consider me the Thomas Kincaide of programming. <kof> I mentioned above changing the stripe size on a RAID array. The server in question was a standard news server (inn). We found, thru simple happy accident, that raising the stripe size from less than 1Meg to 1Meg or more, suddenly more than doubled system thru-put for news feeds. We knew that disk IO was a bottleneck, but had never imagined that the response/latency characteristics of the RAID array were driving the limitation. As we raised the strip size up past 1Meg (working on the basis of making the basic stripe size larger than the majority of single articles, and thus "encouraging" any single article to only reside on one stripe on one disk in the array), performance continued to grow (diminishing returns of course). Tiny change. Huge reaction. If the story is correct (passed on by a mate at SGI), in an earlier version of IRIX they killed some "unecessary" buffer copies in the TCP/IP stack (as I understand it, just a single extra copy per packet). Stack performance gained by over 35%. Tiny change. Huge reaction. > Do profilers have to be written for specific languages? Typically they come with compilers. > My code is written in a language written and maintained by a friend > of mine. Not marketed. And the compiler base? -- J C Lawrence Internet: claw#kanga,nu ----------(*) Internet: coder#kanga,nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00344" HREF="msg00344.html">[MUD-Dev] Re: processors</A></strong> <ul compact><li><em>From:</em> Adam Wiggins <adam#angel,com></li></ul> <li><strong><A NAME="00341" HREF="msg00341.html">[MUD-Dev] Re: processors</A></strong> <ul compact><li><em>From:</em> Marc Hernandez <marc#ias,jb.com></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00331" HREF="msg00331.html">[MUD-Dev] Re: processors</A></STRONG> <UL><LI><EM>From:</EM> <diablo#best,com></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00339.html">[MUD-Dev] Re: processors</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00341.html">[MUD-Dev] Re: processors</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00336.html">[MUD-Dev] Re: processors</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00341.html">[MUD-Dev] Re: processors</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00340"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00340"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>[MUD-Dev] Re: processors</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <LI><strong><A NAME="00323" HREF="msg00323.html">[MUD-Dev] Re: processors</A></strong>, Mik Clarke <a href="mailto:mikclrk#ibm,net">mikclrk#ibm,net</a>, Sat 30 Jan 1999, 12:26 GMT </LI> </ul> <LI><strong><A NAME="00329" HREF="msg00329.html">[MUD-Dev] Re: processors</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Sun 31 Jan 1999, 02:18 GMT <UL> <LI><strong><A NAME="00331" HREF="msg00331.html">[MUD-Dev] Re: processors</A></strong>, diablo <a href="mailto:diablo#best,com">diablo#best,com</a>, Sun 31 Jan 1999, 03:00 GMT <UL> <LI><strong><A NAME="00336" HREF="msg00336.html">[MUD-Dev] Re: processors</A></strong>, Mik Clarke <a href="mailto:mikclrk#ibm,net">mikclrk#ibm,net</a>, Sun 31 Jan 1999, 18:50 GMT </LI> <LI><strong><A NAME="00340" HREF="msg00340.html">[MUD-Dev] Re: processors</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Mon 01 Feb 1999, 06:22 GMT <UL> <LI><strong><A NAME="00341" HREF="msg00341.html">[MUD-Dev] Re: processors</A></strong>, Marc Hernandez <a href="mailto:marc#ias,jb.com">marc#ias,jb.com</a>, Mon 01 Feb 1999, 07:08 GMT </LI> <LI><strong><A NAME="00344" HREF="msg00344.html">[MUD-Dev] Re: processors</A></strong>, Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Mon 01 Feb 1999, 18:53 GMT </LI> </UL> </LI> <LI><strong><A NAME="00342" HREF="msg00342.html">[MUD-Dev] Re: processors</A></strong>, Petri Virkkula <a href="mailto:pvirkkul#iki,fi">pvirkkul#iki,fi</a>, Mon 01 Feb 1999, 07:36 GMT </LI> </UL> </LI> <LI><strong><A NAME="00338" HREF="msg00338.html">[MUD-Dev] Re: processors</A></strong>, Greg Underwood <a href="mailto:gunderwood#donet,com">gunderwood#donet,com</a>, Mon 01 Feb 1999, 02:15 GMT </LI> </UL> </LI> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>