[MUD-Dev] Re: lurker emerges

["James Wilson" <jwilson#rochester,rr.com>]

-----Original Message-----
From: T. Alexander Popiel <popiel#snugharbor,com>
To: mud-dev#kanga,nu <mud-dev#kanga,nu>
Cc: popiel#snugharbor,com <popiel#snugharbor,com>
Date: Sunday, August 09, 1998 6:32 PM
Subject: [MUD-Dev] Re: lurker emerges 


>In message:  <13773.64266.876212.231468#arioch,tky.hut.fi>
>             Petri Virkkula <pvirkkul#iki,fi> writes:
>>>>>>> "Chris" == Chris Gray <cg#ami-cg,GraySage.Edmonton.AB.CA> writes:
>>
>>Chris> In general, I think its clear that threading will only actually
>>Chris> increase your speed if your system has multiple CPUs.
>>
>> That's only true if your program is CPU bound. If the program
>> is I/O bound then count of physical disks is more relevaant
>> factor. In a mixed case I would use (this is only a guess)
>> x+2*y as formula for optimal thread count (x is count of CPUs
>> and y is count of physical disks), count of physical disks are
>> multiplied with 2 to keep disks busy all the time.
>
>*blink blink*
>
>You seem to assume that it is impossible for a single thread to keep
>even one I/O device continuously busy.  Whatever happened to double-
>buffering and non-blocking I/O?  Has that art actually been lost in
>the annals of time?


I for one have only a vague idea of what this technique consists of.
Could you maybe give some details, or a url describing it? Why would
one need non-blocking i/o if select() tells you which sockets are
ready for reads and writes? That is, assuming you bound the size of
your output chunks appropriately, if the socket's ready for i/o shouldn't
blocking be moot?

>>Chris> Threading has overhead over non-threading, and there isn't
>>Chris> anything you can do about that.
>>
>> Don't forget that non-threading has overhead too: if there is
>> multiple file descriptors then select'ing and going through
>> fd_sets can burns CPU time too.
>
>While this is true, this overhead is something that a creative
>programmer can manage and reduce, while the overhead of multiple
>threads is untouchably bound in the OS kernel.
>
>I prefer problems that I have at least some hope of fixing.


I am curious as to how one could speed up this process - can you
avoid doing a search through the set of all active sockets to find
those that are ready for i/o? Could you split up the fd_sets somehow
to bound the number that would have to be checked? It seems like
when one gets to thousands of simultaneous connections this 
could become a bottleneck.

>- Alex
>
>-- 
>MUD-Dev: Advancing an unrealised future.
>