George <greerga@CIRCLEMUD.ORG> writes:
> >That is very much my point. Not so much peoples' machines, but
> >instead, the servers the muds are running on. I still highly doubt,
> >though that the headers will cause a problem. I'd say every .c file
> >in stock ends up including maybe 80% of the headers, by line. But
> >that could br wrong, just a hunch.
>
> Including a header many times doesn't increase memory and/or executable
> size. What isn't used it thrown out. I don't see your point here.
I as referring to the memory used during compiles. I am well aware
that they don't add to the compiled program's memory usage or disk size.
> >Optimization can't always be relied on. People use old compilers,
> >broken compilers, whatever. Depending on gcc to optimize code is
> >ridiculous -- it does a fairly decent job on local levels, but not on
> >algorithmic levels and above.
>
> If you're that worried, don't use optimization, I doubt your MUD will raise
> it's CPU used time much at all since CircleMUD sleeps most of the time.
I rarely do use optimizations. And you're right, it doesn't use much
CPU time. But if you use bad algorithms, then time will be wasted.
If your mud is running in a shared environment, you shouldn't polute
your neighbors' space by eating CPU cycles when you can avoid it.
> >No, but sooner or later, you will need to upgrade.
>
> My friend uses his XT laptop still. Great word processor.
Yes, but he isn't a server running Circle. That is my point.
> >Circlemud should keep up with the mean.
>
> Microsoft Windows keeps up (and pushes) the mean, CircleMUD shouldn't.
Yet circle is going to be multithreaded? In a world where
multithreaded libraries are incompatible and often poorly implemented?
That's a contradiction. Threads, particularly with the amount of
locking that will be needed, will significantly add to the CPU usage
of Circle.
> >I'm not saying we as coders should. The mean is what our machines
> >currently are, which I would wager in most cases is enough to have a 20 or
> >30k increase in compile-time memory ;)
>
> I'm sure everyone with not much memory disagrees.
>
> You have the choice of two philosophies:
> * Windows, run on today's (fast) hardware, forget 386's.
> * Linux, run on everything from a 386/16 with 2MB RAM to the newest PII/400
>
> If you wish to take advantage of your faster computer, go right ahead.
> We'll keep CircleMUD viable for the less fortunate.
How many people run muds from 386/16s? Not just debug runs -- I mean
supporting users, open to the public? Very few.
Like Linux, Circle should scale smoothly. Give it more hardware, it
should do more. If speed is a huge issue, turn debugging off and your
assert()'s will magically go away. Or turn optimizations on. Or
both.
But when the speed is available, use it to help avoid, or recover
from, disaster.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST