[MUD-Dev] Re[2]: [MUD-Dev] Sockets

[Travis Casey]

On Thursday, May 13, 1999, Cynbe ru Taren wrote:

> We're swimming in hardware capacity these days -- the costs of PCs are
> collapsing in large part because we finally do have more CPU oomph than
> we know how to effectively apply, by and large.

> IMHO, the low-level CPU efficiency differences between using multiple
> threads blocking on sockets vs a single thread and select() are
> entirely negligible at this point:  Nobody is -ever- going to select
> your design because you got that decision "right".

> What matters a hell of a lot more is which choice will lead to the
> most robust, understandable, maintainable, effective application.

> We all learned to program when CPU bandwidth was much more expensive
> than it is now:  We're habituated to credit it with far more importance
> than it now deserves.

> The efficiency issues we should be worrying about now are efficient
> use of programmer time, efficient use of end-user time, efficient
> distribution of bugfixes and the like -- not efficient use of CPUs
> which are anyhow 98% idle.  I've personally got about (I've lost
> count) 16 CPUs on the internet at the moment, any one of them probably
> capable of carrying all of kernel.org's traffic, and I'd bet none of
> them less than 98% idle as I type this.  (Using no less then three of
> those CPUs spread over two states to handle each character typed, but
> who cares?)

> Efficient use of today's CPUs means applying that 98% idle time to
> do something useful for the user, not upping it to 99% idle time.

It does depend a lot, though, on *what* you're doing.  Network traffic
doesn't tax modern CPUs much because it's IO-bound -- the network is,
in most cases, slower than the CPU.  However, that doesn't mean that
there aren't situations where optimization can be important.  I've
seen real-time compression and decompression of audio and/or video
take 50 to 90% of high-end CPUs, and I've seen high-traffic databases
take 50+% of the CPU on high-end minicomputers (specifically, a
system with 6 400 MHz Alpha CPUs).

However, I'll readily agree that nothing that a typcial text-based mud
does is very taxing in CPU terms.  When I was reading the mud
newsgroups, I used to be very amused at how, when people brought up
the idea of writing a mud from scratch in C++, there were people on
the Diku groups who would argue that C++ wasn't efficient enough to
run a mud.  Given that there are plenty of muds running on
*interpreters*, I had to wonder how much efficiency they thought was
needed...

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev