[MUD-Dev] Sockets

[Cynbe ru Taren]

Caliban Tiresias Darklock <caliban at darklock.com> joked:

| If multi-processing O/Ss were not efficient, then we would not run them.
| 
| Therefore, we run an O/S because it is efficient.
| 
| Therefore, if an O/S is being run, it must be efficient.
| 
| The world's most-run operating system is Microsoft Windows.
| 
| Therefore, Microsoft Windows is the world's most efficient operating system.
| 
| Go Bill!

Most efficient at extracting money from the rest of the world, clearly!

I think perhaps a bit more thought and attention need to be devoted to
-what- an OS or software paradigm is efficient at.

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.

E.g., check out "A Review of Experiences with Reliable Multicast"
at http://cs-tr.cs.cornell.edu/ and decide what the implications
are for mud-dev:  Is reliable multicast appropriate?  Practical?
Desirable?  Does it make it too easy for a single malicious
participant to bring everything to a halt?  How much consistency
between the views presented to different participants is required?
Desirable?  Practical?  Possible?

Just my two bits. :)

  Cynbe


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