Too many tasks? overhead questions.

Too many tasks? overhead questions.

[system]

Hello,
Largely as a learning exercize I am writing*  a mud** with Ada using the
Gnat compiler.  One of the possibilities is to make it highly threaded 
with each character getting their own thread. (Yes, there are design 
reasons for doing this)

However, assuming that I ever complete this project the mud may actually
run for extended periods of time on a non-dedicated machine.

The result of this is that I would have between a few hundred and potentially
a few thousand tasks running around.  The tasks would exist for significant
periods of time (hours) and interact with the world and each other.
(My minimal digging in this area suggests that I would be using ?protected
functions? to deal with synchonization issues)

My question is what kind of overhead would this entail.  There are
three probable operating environments: Digital Unix on an Alpha probably
with 128 mb but possibly 64, OS/2 on a pentium 133 with 32mb, VMS on
an Alpha with at least 128mb.

Muds are not generally cpu intensive (but then they don't generally
have a few hundred threads) so I am mostly concerned about memory
and ??? I don't know what else.

If I ran it on the OS/2 machine it may well only have a hundred or
even fewer tasks.

Out of curiousity I am wondering how tasks are going to be handled
by the VMS compiler.  Presumably not by using full-fledged processes.
Dec-Threads, perhaps?

I am not looking for hard and fast numbers (rather obviously) just
some general ideas of what to expect if I go this route.

Robert

*Well, I have written some code, but truthfully I am mostly still in the 
design mode.
**For those who have a real life a mud is a computer game in which
multiple people interact with each other and the world described by the
game.

specify the e-mail address below, my reply-to: has anti-spam added to it
Morphis@physics.niu.edu
Real Men change diapers

Re: Too many tasks? overhead questions.

[Nick Roberts]

system@niuhep.physics.niu.edu wrote in article
<5jlkdu$rub@corn.cso.niu.edu>...
> Hello,
> Largely as a learning exercize I am writing*  a mud** with Ada using the
> Gnat compiler.  One of the possibilities is to make it highly threaded 
> with each character getting their own thread. (Yes, there are design 
> reasons for doing this)
[etc.]


Yes, provided the machine you are running on will allow it, you should use
a task to represent each character (player and NPC), as well as each object
in the game (e.g. a magic door which opens under certain conditions, etc.).
No, don't use protected types for communication, use entries. However, be
careful about getting into race conditions (pragma Priority may help
(sometimes!)), lock-up conditions (e.g. tasks calling each other at the
same time), and so on. Define a task type for players, a task type for each
category of NPC and game object. Declare the task type specifications in
advance of the bodies. Declare a god task which has power over all the
other tasks. Ensure that this god (you!) has the ability to save the entire
game state to a file (it should interrogate the other tasks by calling
entries to them to get data from them), and reload from the file. Include a
room-defining feature: this is very popular with the punters, and is a
great way to expand the dungeon (watch out: it grows fast!)

To see if the number of tasks you require will run on a particular machine,
write a test program which spawns lots of tasks. It needn't be very
complicated.

Hope this helps. Good luck!

PS: Post us when you get your MUD going, some of us play MUDs!

Nick.

Re: Too many tasks? overhead questions.

[Robert I. Eachus]

In article <01bc5256$1c9c4640$28f982c1@xhv46.dial.pipex.com> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

  > Yes, provided the machine you are running on will allow it, you should use
  > a task to represent each character (player and NPC), as well as each object
  > in the game (e.g. a magic door which opens under certain conditions, etc.).

  Sure have a task for each player, but objects should be protected
objects--they don't need their own thread of control.  NPCs are an
interesting issue, those pinned in a certain place should probably be
treated as objects, those that wander the dungeon should have their
own task or tasks.  (Of course, if you have one task for all NPCs,
make sure that NPCs don't try to interact...)

  Good luck.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Too many tasks? overhead questions.

[system]

eachus@spectre.mitre.org (Robert I. Eachus) writes:
>"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

>> Yes, provided the machine you are running on will allow it, you should use
>> a task to represent each character (player and NPC), as well as each object
>> in the game (e.g. a magic door which opens under certain conditions, etc.).

>  Sure have a task for each player, but objects should be protected
>objects--they don't need their own thread of control.  NPCs are an

I want to thank Robert and Nick for the suggestions, they are definately
going into the mill as I work on how I want to do this, but they don't
answer the primary question, which is 

how much overhead can I expect a few hundred tasks to involve?

And what kind of overhead?

hmmm, Most (90%?) of the tasks would involve NPCs most of whom
(well, at least 50%) would be quiescent most of the time.  So those
(say 40-60& of the character tasks) would be just taking up memory
but no cpu or I/O most of the time (I would make a WAG that for non-
central NPCs average interaction would occur no more than for 5 minutes
per hour.).

The alternative to threading is to have the central process poll each
and every character every tic (which is planned to be one second long).

<sigh>

Thanks again for the ideas, if anybody has some input to the overhead
question I would appreciate input.

Robert

specify the e-mail address below, my reply-to: has anti-spam added to it
Morphis@physics.niu.edu
Real Men change diapers

Re: Too many tasks? overhead questions.

[system]

system@niuhep.physics.niu.edu writes:
>eachus@spectre.mitre.org (Robert I. Eachus) writes:
>>"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

>I want to thank Robert and Nick for the suggestions, they are definately
>going into the mill as I work on how I want to do this, but they don't
>answer the primary question, which is how much and what kind of overhead 
>can I expect a few hundred tasks to involve?

urp, Nick wrote in his original reply:
-------------------------------------------------------------------------
To see if the number of tasks you require will run on a particular machine,
write a test program which spawns lots of tasks. It needn't be very
complicated.
-------------------------------------------------------------------------
which I missed completely, my apologies.

I have a few excuses for not having done that, I don't have
a functional ada compiler and it will be a while before I do and I am
competant enough to write such a program.  And while I am learning
to code in Ada I am also developing some ideas on the mud that
may be impacted by whether I run it multithreaded or not.

My other original excuse was that I didn't want to invest a bunch of
time learning tasking if I wasn't going to use it, but my interest
has been piqued so... (besides, if I get serious about Ada I'll
want to learn it anyhow.)

I guess I will just have to install GNAT and get to work :)  Thanks
again for the help.

Robert
specify the e-mail address below, my reply-to: has anti-spam added to it
Morphis@physics.niu.edu
Real Men change diapers

Re: Too many tasks? overhead questions.

[Robert Dewar]

Robert Eachus said

<<  Sure have a task for each player, but objects should be protected
objects--they don't need their own thread of control.  NPCs are an
interesting issue, those pinned in a certain place should probably be
treated as objects, those that wander the dungeon should have their
own task or tasks.  (Of course, if you have one task for all NPCs,
make sure that NPCs don't try to interact...)>>


Robert Dewar notes

Be very careful about recommending the use of protected types. They are
by no means a general abstraction mechanism (the abstraction is severely
limited by the restriction on potentially blocking operations0.

We have found a lot of users getting themselves into trouble, e.g. by
doing a delay directly or indirectly in a protected operation, which is
of course erroneous.

It is clear that a lot of users (not surprisingly) do not understand
this restriction.

Unless efficiency is an overriding concern, it is better to use tasks
for synchronization, since there you have no such concerns.

Re: Too many tasks? overhead questions.

[Robert I. Eachus]

In article <5k317h$o54@corn.cso.niu.edu> system@niuhep.physics.niu.edu writes:

  > how much overhead can I expect a few hundred tasks to involve?

  > And what kind of overhead?

   The first answer to your question is, "How much overhead do you
want to allow?"   See 13.3(59..67): T'Storage_Size is
allowed to use more memory than you require, but on most
implementations, if you request a small task size you will get
approximately that size.

   Also see C.7.2 Task_Attributes.  This allows you to allocate per
task attributes neatly and cleanly when you have dozens of different
task types.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Too many tasks? overhead questions.

[Robert I. Eachus]

In article <dewar.862310793@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > Be very careful about recommending the use of protected types. They are
  > by no means a general abstraction mechanism (the abstraction is severely
  > limited by the restriction on potentially blocking operations).

  Ah, the wonders of the English language which allows one word to
mean so many different things. ;-)  The objects in a dungeon may or
may not be objects in the programming (or OO) sense.  They are things
which can be picked up by players and NPCs (non-player characters) and
moved from place to place, but in the programming sense do not have an
associated thread of control.  Usually you just want to move them from
room to room or to the player's backpack or hand, and to display them
when the room or player is displayed.

   The only thing I could see causing the type of problem that Robert
Dewar is worried about would be a potion of sleep or some such.  But
the implementor is going to have to handle sleep right in any case.
If a player casts a sleep spell, only the target creature should be
out of commission until the spell wears off.  Of course this allows
some creativity on the part of the dungeon builder--going to sleep
from such a spell could allow you some "last wishes" before you start
to snore...



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...