Are multithreaded planners allowed?

[Martin Mueller]

I have a question regarding the competition machine. Will it be able
to run code that uses multiple cores in parallel? If yes, how many
cores will be available to each participant?

[Malte Helmert]

Hi Martin,

thanks for the question, because that's an important topic that we
haven't talked about yet. I'll try to answer it in some detail.

Planners will be evaluated as if they were run on a machine with a
single core, with a 30 minute timeout (CPU time plus time for I/O; the
latter should be negligible unless your planner does external search.)
That is, if you use three parallel threads, you'll be able to spend 10
minutes in each. Actually, we'd prefer people to only use a single
thread because that will facilitate managing our experiments. If you
want to use multiple threads, please indicate this in the registration
form so that we're aware of it.

There's a couple of reasons why we don't want to go multi-core yet
despite the current hardware trend:

1. Implementation effort: If someone uses several cores, everyone will
need to use several cores to stay competitive. This year's competition
will be a significant engineering challenge compared to previous years
due to the blind evaluation mode. Planners will need to be much more
robust than they used to. Having action costs in the "basic"
sequential planning track is also an added challenge. We don't want to
add another significant engineering challenge on top of that.

2. State of the art: I'm not aware of any papers about planning on
parallel architectures, so we don't want to forge ahead of the state
of the art here too far. I'm sure there is some good work in that
direction out there, but we feel it's not mainstream enough (yet!) to
be part of the competition. Certainly the competition is also to a
certain extent about pushing the state of the art, not just evaluating
it, but I feel there are other significant challenges this year that
will be tough enough for people to tackle. I admit this is a bit of a
chicken-and-egg problem, and the decision should be revisited for the
next competition, when multi-core CPUs will likely be even more
widespread. I recommend discussing this well ahead of time, e.g. in
the competition workshop, if there will be one in 2009.

3. Limited CPU resources: Because runtime doesn't matter this year but
quality does, we expect many people to implement any-time planners
that will spend the whole 30 minutes on each task. This means that we
may be spread quite thinly with respect to CPU resources. If we give
(e.g.) four cores to everyone, this again effectively reduces our
available resources by a factor of 4.

There are some other reasons related to the kinds of machine
architectures we will use to run the experiments, but final decisions
on that haven't been made yet because they depend on the number of
participating planners.

Best regards,

Malte