[Home] [Groups] - Message: [Prev in Group] [Next in Group]
10080: RE: [MUD-Dev] Sockets
[Full Header] [Plain Text]
From: Petri Virkkula <pvirkkul@iki.fi>
Newsgroups: nu.kanga.list.mud-dev
Date: Sat, 8 May 1999 10:57:43 +0300 (EEST)
References: [1]
Organization: Kanga.Nu
>>>>> "Chris" == Chris Gray <cg@ami-cg.GraySage.Edmonton.AB.CA> writes:
Chris> [Jon A. Lambert:]
>> I think the performance boost
>> from threading has been understated or misunderstood on single-processor
>> machines probably due to early thread implementations.
Chris> Is this deliberate flamebait, or just accidental?
Chris> Please explain to me how adding the overhead of thread switches, locks
Chris> and extra memory usage can increase performance. Or, perhaps you meant
How are you measuring your performance figures? As average
per command response time or average commands per a second?
Which one of the two choices below has better performance:
Singlethreaded:
Average per command response time: 10ms
Average commands per a second: 100 commands/s
Multithreaded:
Average per command response time: 11ms
Average commands per a second: 120 commands/s
Above numbers are just examples, but I wouldn't be too
suprised if they were near the truth in a real system.
I prefer the commands per a second performance measurement,
because that number tells more directly how many players can
be supported by a system.
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.
Petri
_______________________________________________
MUD-Dev maillist - MUD-Dev@kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev