April 1999
- In-Game Languages Eli Stevens {KiZurich}
- In-Game Languages Per Vognsen
- In-Game Languages Chris Gray
- In-Game Languages Caliban Tiresias Darklock
- In-Game Languages Eli Stevens {KiZurich}
- In-Game Languages Matthew D. Fuller
- In-Game Languages Mik Clarke
- In-Game Languages Michael Hohensee
- In-Game Languages Ben Greear
- In-Game Languages Michael Hohensee
- In-Game Languages Mik Clarke
- In-Game Languages Hans-Henrik Staerfeldt
- In-Game Languages David Bennett
- In-Game Languages Richard Woolcock
- In-Game Languages Hans-Henrik Staerfeldt
- In-Game Languages Caliban Tiresias Darklock
- In-Game Languages Hans-Henrik Staerfeldt
- In-Game Languages Andrew Ritchie
- In-Game Languages Matthew D. Fuller
- In-Game Languages adam@treyarch.com
- forward: consistency Ola Fosheim Grøstad
- Confined Gameworld Ling
- Confined Gameworld Caliban Tiresias Darklock
- Confined Gameworld Richard Woolcock
- Confined Gameworld Eli Stevens {KiZurich}
- Confined Gameworld The Wildman
- Confined Gameworld Koster, Raph
- User centered? Ola Fosheim Grøstad
- User centered? Caliban Tiresias Darklock
- User centered? Marc Bowden
- User centered? Adam Wiggins
- User centered? Richard Woolcock
- User centered? Benjamin D. Wiechel
- User centered? Koster, Raph
- target audience Matthew Mihaly
- target audience Caliban Tiresias Darklock
- target audience Marc Bowden
- Fw: Self-organizing worlds (was: Elder Games) Kylotan
- Fw: Self-organizing worlds (was: Elder Games) Matthew Mihaly
- ScryMUD 1.8.11 released. Ben Greear
- Mud driver architecture info B. Scott Boding
- Blending graphics with text u1391470
- Blending graphics with text Laurel Fan
- Blending graphics with text Kylotan
- Blending graphics with text Chris Gray
- Blending graphics with text J C Lawrence
- Blending graphics with text Caliban Tiresias Darklock
- Blending graphics with text Chris Gray
- Blending graphics with text Ola Fosheim Grøstad
- Blending graphics with text Hans-Henrik Staerfeldt
- Blending graphics with text Mik Clarke
- Blending graphics with text u1391470
- Blending graphics with text claw@kanga.nu
- Blending graphics with text Alex Stewart
- Blending graphics with text J C Lawrence
- Virtual machine design Shane King
- Virtual machine design Alex Stewart
- Virtual machine design Jo Dillon
- Virtual machine design Ben Greear
- Virtual machine design Niklas Elmqvist
- Virtual machine design Shane King
- Virtual machine design Ben Greear
- Virtual machine design claw@kanga.nu
- Virtual machine design Alex Stewart
- Virtual machine design Felix A. Croes
- Virtual machine design Eli Stevens {KiZurich}
- Virtual machine design Mik Clarke
- Virtual machine design Schubert, Damion
- Virtual machine design Ben Greear
- Virtual machine design Ben Greear
- Virtual machine design Felix A. Croes
- Virtual machine design Matthew Mihaly
- Virtual machine design Hans-Henrik Staerfeldt
- Virtual machine design claw@kanga.nu
- Virtual machine design Mik Clarke
- Virtual machine design Oliver Jowett
- Virtual machine design Chris Gray
- Virtual machine design claw@kanga.nu
- Virtual machine design Chris Gray
- Virtual machine design Ola Fosheim Grøstad
- Virtual machine design claw@kanga.nu
- Virtual machine design Petri Virkkula
- Virtual machine design Ben Greear
- Virtual machine design Chris Gray
- Virtual machine design Ola Fosheim Grøstad
- Virtual machine design Nathan F Yospe
- Virtual machine design Ola Fosheim Grøstad
- Virtual machine design Petri Virkkula
- Virtual machine design Jon A. Lambert
- Virtual machine design Koster, Raph
- Virtual machine design Jon A. Lambert
- Virtual machine design Chris Gray
- Rebooting (was: Virtual machine design) Eli Stevens {KiZurich}
- Game design highpoints (was Virtual machine design) claw@kanga.nu
- Sockets Quzah [softhome]
- Sockets Alex Stewart
- Sockets Quzah [softhome]
- Sockets Jo Dillon
- Sockets Jon A. Lambert
- Sockets Jon A. Lambert
- Sockets Chris Gray
- Sockets Petri Virkkula
- Sockets Chris Gray
[Petri Virkkula:]
> I prefer the commands per a second performance measurement,
> because that number tells more directly how many players can
> be supported by a system.
I would tend to agree. My belief is that your example numbers are weighted
the wrong way, however. I could see it possible for a lightly loaded
multi-threaded system to respond to a single request faster than a
single-threaded system, but that the single-threaded system, having less
overhead, could respond to more requests per second.
> Chris> to say "multi-processor machines"? One could perhaps imagine how a good
> Chris> threaded implementation of something could perform better a poor
> Chris> non-threaded implementation, but I don't think that's what you mean.
>
> Actually there aren't many "single-procesor" machines in the
> market today (neither so many SMP machines however). Many
> (most?) disks for example have their own processors, thus a
> PC could be said to be a "multi-processor" machine. However
> the term "multi-processor" usually refers to SMP.
I was of course referring to the usual definition of "multi-processor"
as a single computer having multiple normal processors used for doing
whatever user work is thrown at them. Typically SMP (Symmetric Multi-
Processors).
I should perhaps expand on what I'm getting at here. Everyone should agree
that the use of threads on a given system introduces more overhead to
that system because of the need for thread switching, if nothing else.
However, the design of some operating system interfaces may be such that
maximum performance can only be obtained by using multiple threads.
Earlier discussions of the cost of large select or poll calls is an
example of some overheads that may be reduced by having multiple outstanding
calls.
The WIN32 interface in particular is one which essentially forces the
programmer to use multiple threads. Consider the "asynchronous I/O"
features available. You can use their completion routines stuff, but they
aren't really asynchronous because they are only triggered when some
I/O related system call completes (e.g. a poll). You can use their
interface which sends a message on call completion, but for that you
have to have an active window, which is something a MUD server (or http
server or ftp server, etc.) is not likely to want. I'm guessing that
this silliness (sending messages to a window, rather than to an
arbitrary message port) is a historical thing. Lastly, you can use the
"overlapped I/O" features, where an event handle becomes signalled when
the operation completes. Here, you must have something (i.e. a thread)
that is waiting for a bunch of such handles to be ready. The call used
for that, WaitForMultipleObjects, has a fixed, hard limit of 64 handles
that it can wait on. If you want more than that, you have to either
start polling (ugh!) or have multiple threads, each waiting for groups
of handles. So, I agree, that if you are programming under the WIN32
API, you will get better performance by using threads than if you
didn't, but *that is a result of the nature of the API, rather than any
inherent advantage of threads*.
Threads are a tool which can be used to restructure your program into a
style that can be easier to read. They do so at the expense of a little
extra overhead. This is just like using C++ classes with virtual functions
to similarly restructure your program, at a small expense.
--
Don't design inefficiency in - it'll happen in the implementation.
Chris Gray cg@ami-cg.GraySage.Edmonton.AB.CA
http://www.GraySage.Edmonton.AB.CA/cg/
- Sockets Chris Gray
- Sockets Caliban Tiresias Darklock
- ScryMUD 1.8.13 snapshot released. Ben Greear
- Interview I did that may interest you Koster, Raph
- Censorship Greg Munt
- Censorship Ben Greear
- Censorship Matthew Mihaly
- Censorship Shawn Halpenny
- Censorship Darren Henderson
- Censorship Quzah [softhome]
- Censorship Hans-Henrik Staerfeldt
- Python B. Scott Boding
- Python Gaffney, Jeremy
- AW: Censorship Hofbauer Heinz
- AW: Censorship Matthew Mihaly
- AW: Censorship Damion Schubert
- Censorship, Virtual v Artificial Worlds, Python Greg Munt
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Ben Greear
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Ben Greear
- Censorship, Virtual v Artificial Worlds, Python Dan
- Censorship, Virtual v Artificial Worlds, Python Matthew Mihaly
- Censorship, Virtual v Artificial Worlds, Python Marian Griffith
- Censorship, Virtual v Artificial Worlds, Python Benjamin D. Wiechel
- Censorship & Its Impact On World Immersion Greg Munt
- Censorship & Its Impact On World Immersion Matthew Mihaly