ways to improve speed?

[David Epstein]

Hi folks,

Florian and Malte, thank you for your detailed response concerning 32 bit versus 64 bit. I'll look into this topic more next week if necessary. 

I use the PDDL plugin for Visual Studio Code to write domain and problem files and to call FD from the editor. When FD is running, the editor process uses 100% of a single CPU. But, I see very little additional memory usage over the editor idling. Perhaps total memory usage goes from 7.3GB to 7.4GB when FD is running. I have 32GB installed and six processors.

What options do I have to speed up performance? For example, if I don't care whether the plan is optimal, would removing "metric" in the problem file speed up performance? Are the command line options that might help me find a plan fast--not necessarily a good plan?

Here is output from a problem with "metric" I let it run for more than five minutes and then stopped it.

python D:/projects/Programming/c/fastdownward2/fast-downward.py C:\Users\david\AppData\Local\Temp\domain-16600shkBd7XtdX1E.pddl C:\Users\david\AppData\Local\Temp\problem-16600TCqYjH0E3yV7.pddl   --search "astar(lmcut())" 

INFO     Running translator.

INFO     translator stdin: None

INFO     translator time limit: None

INFO     translator memory limit: None

INFO     translator command line string: 'C:\Users\david\Anaconda3\python.exe' 'D:\projects\Programming\c\fastdownward2\builds\release\bin\translate\translate.py' 'C:\Users\david\AppData\Local\Temp\domain-16600shkBd7XtdX1E.pddl' 'C:\Users\david\AppData\Local\Temp\problem-16600TCqYjH0E3yV7.pddl' --sas-file output.sas

Warning! SIGXCPU is not available on your platform. This means that the planner cannot be gracefully terminated when using a time limit, which, however, is probably supported on your platform anyway.

Parsing...

Parsing: [0.000s CPU, 0.020s wall-clock]

Normalizing task... [0.000s CPU, 0.000s wall-clock]

Instantiating...

Generating Datalog program... [0.000s CPU, 0.003s wall-clock]

Normalizing Datalog program...

Duplicate arguments: Adding equality conditions.

Normalizing Datalog program: [0.016s CPU, 0.006s wall-clock]

Preparing model... [0.000s CPU, 0.010s wall-clock]

Generated 127 rules.

Computing model... [5.266s CPU, 5.268s wall-clock]

77438 relevant atoms

721142 auxiliary atoms

798580 final queue length

861296 total queue pushes

Completing instantiation... [1.500s CPU, 1.513s wall-clock]

Instantiating: [6.953s CPU, 6.960s wall-clock]

Computing fact groups...

Finding invariants...

41 initial candidates

Finding invariants: [0.016s CPU, 0.014s wall-clock]

Checking invariant weight... [0.000s CPU, 0.000s wall-clock]

Instantiating groups... [0.016s CPU, 0.017s wall-clock]

Collecting mutex groups... [0.000s CPU, 0.011s wall-clock]

Choosing groups...

25085 uncovered facts

Choosing groups: [0.016s CPU, 0.013s wall-clock]

Building translation key... [0.078s CPU, 0.088s wall-clock]

Computing fact groups: [0.609s CPU, 0.605s wall-clock]

Building STRIPS to SAS dictionary... [0.031s CPU, 0.026s wall-clock]

Building dictionary for full mutex groups... [0.016s CPU, 0.022s wall-clock]

Building mutex information...

Building mutex information: [0.031s CPU, 0.020s wall-clock]

Translating task...

Processing axioms...

Simplifying axioms... [0.000s CPU, 0.001s wall-clock]

Processing axioms: [0.062s CPU, 0.075s wall-clock]

Translating task: [1.625s CPU, 1.627s wall-clock]

0 effect conditions simplified

0 implied preconditions added

Detecting unreachable propositions...

0 operators removed

0 axioms removed

731 propositions removed

Detecting unreachable propositions: [0.969s CPU, 0.978s wall-clock]

Reordering and filtering variables...

95 of 24775 variables necessary.

0 of 37 mutex groups necessary.

17040 of 43920 operators necessary.

0 of 0 axiom rules necessary.

Reordering and filtering variables: [0.438s CPU, 0.435s wall-clock]

Translator variables: 95

Translator derived variables: 0

Translator facts: 1546

Translator goal facts: 9

Translator mutex groups: 0

Translator total mutex groups size: 0

Translator operators: 17040

Translator axioms: 0

Translator task size: 90332

warning: could not determine peak memory

Writing output... [0.359s CPU, 0.358s wall-clock]

Done! [11.109s CPU, 11.121s wall-clock]

translate exit code: 0

INFO     Running search (release).

INFO     search stdin: output.sas

INFO     search time limit: None

INFO     search memory limit: None

INFO     search command line string: 'D:\projects\Programming\c\fastdownward2\builds\release\bin\downward.exe' --search 'astar(lmcut())' --internal-plan-file sas_plan < output.sas

reading input... [t=2.37e-05s]

done reading input! [t=0.125276s]

Initializing landmark cut heuristic...

Building successor generator...done! [t=0.149511s]

peak memory difference for successor generator creation: 3336 KB

time for successor generation creation: 0.0097717s

Variables: 95

FactPairs: 1546

Bytes per state: 24

Conducting best first search with reopening closed nodes, (real) bound = 2147483647

New best heuristic value for lmcut: 42

[g=0, 1 evaluated, 0 expanded, t=0.156378s, 13896 KB]

f = 42 [1 evaluated, 0 expanded, t=0.156387s, 13896 KB]

Initial heuristic value for lmcut: 42

pruning method: none

New best heuristic value for lmcut: 36

[g=5, 21 evaluated, 1 expanded, t=0.282409s, 13896 KB]

New best heuristic value for lmcut: 32

[g=10, 45 evaluated, 2 expanded, t=0.439897s, 13896 KB]

[Malte Helmert]

On 13.10.19 13:37, David Epstein wrote:
> Hi folks,
>
> Florian and Malte, thank you for your detailed response concerning 32
> bit versus 64 bit. I'll look into this topic more next week if necessary. 
>
> I use the PDDL plugin for Visual Studio Code to write domain and problem
> files and to call FD from the editor. When FD is running, the editor
> process uses 100% of a single CPU. But, I see very little additional
> memory usage over the editor idling. Perhaps total memory usage goes
> from 7.3GB to 7.4GB when FD is running. I have 32GB installed and six
> processors.
>
> What options do I have to speed up performance? For example, if I don't
> care whether the plan is optimal, would removing "metric" in the problem
> file speed up performance? Are the command line options that might help
> me find a plan fast--not necessarily a good plan?
>
> Here is output from a problem with "metric" I let it run for more than
> five minutes and then stopped it.

The configuration you're using in this example ("--search
astar(lmcut())") guarantees an optimal solution. These optimal-plan
configurations tend to take a lot more time to find a solution than good
configurations that don't care about solution quality.

The lmcut() heuristic is among the ones that fill up memory the slowest
because it spends a lot of time in analyzing every state. It's one of
the exceptions to what I wrote about memory usually filling up quickly.

If you don't care about the quality of the solution at all, a good first
configuration to try first is the "lama-first" alias. Invoke this with

./fast-downward.py --alias lama-first domain.pddl problem.pddl

Note that when using an alias, the alias must be given *before* the PDDL
files, which is different from manually specified search configurations,
which come *after* the PDDL files.

If you care *somewhat* about solution quality, there are also
configurations that fall in between the two extremes, but perhaps let's
try first if this one works for you.

Regarding the "metric" specification: all other things being equal, the
easiest scenario for the planner is when all actions have a cost of 1.
There are two ways to achieve this:

A) Don't use any of the cost-related features. Don't define
(total-cost), don't specify costs for actions, don't define a metric.

B) Define the minimize total-cost metric, but explicitly have every
action increase the cost by 1.

There is no difference in performance between these two.

There are also planner configurations that completely ignore the action
costs during search. The "--alias lama-first" mentioned above is one of
them.

Cheers,
Malte

[David Epstein]

Wow! Big difference! FD solved the problem in 0.7 seconds! It is a reasonable solution but I have no idea how it compares to a better solution. Could I try some of the in between configurations you mentioned? I can see different specifications here:  http://www.fast-downward.org/PlannerUsage but I have no idea how they behave. I'm especially interested in configurations that permit setting a time limit (on Windows) and default to the lama-first solution if a better one isn't found.

-david

[Malte Helmert]

Hi David,

you can run "--alias lama" instead of "--alias lama-first" to run an
any-time configuration that begins with the same algorithm as
"lama-first" but keeps going after finding a solution to find better
ones. The first plan produced will be the same as with lama-first. The
later stages of the algorithm increasingly emphasize quality over speed.

I don't know the Visual Studio Code PDDL plugin well enough to know how
it deals with such anytime configurations. If you run such a
configuration on the command line, the planner will produce a new
numbered plan file (sas_plan.1, sas_plan.2 etc.) every time it finds a
plan that is better than all previous ones.

On most problems, an anytime configuration will keep going until
aborted, so setting time and perhaps memory limits is important.
Unfortunately, we don't currently support time or memory limits on
Windows. Perhaps the plugin has its own way of limiting them?


We would be happy to add support directly to Fast Downward if someone
with more Windows expertise can point us towards a good way of doing
this. We currently use Python's resource.setrlimit, which uses the POSIX
"setrlimit" system calls, which are not available on Windows. I have
searched around a bit and discovered that starting with Python 3.3, time
limits on Windows are possible with the subprocess module.

Memory limits look more tricky, though. From my brief research, it seems
that the Windows "Job Objects" API may be the right tool for the job,
but we would need to access it from the Python part of the Fast Downward
code, and that doesn't seem trivial. The pywin32 package seems to
contain a module called "win32job" that could be used, but adding a
dependency on pywin32 could make the build a lot more tricky, as the
Python code is currently pure Python and doesn't have any non-stdlib
dependencies, which dramatically simplifies the build process.

(In case someone wonders, as we were discussing 32 vs. 64 bits in this
context: win32 really means "32-bit Windows or later versions", as
opposed to 16-bit. So win32 applies to 64-bit Windows.)


Are there other Windows users here that would appreciate such an
addition? We cannot promise to deliver it in the near future, but the
likelihood certainly depends on the demand.

Cheers,
Malte

[David Epstein]

Thanks Malte. I'll try the "--alias lama" setting soon. In the short term, since I'm calling the planner from my own Python code using subprocess.run with subprocess.pipe to get output, I may investigate ways to kill the process from Python after a minute and then take the best plan it had time to write.

[David Epstein]

Hi folks,

Could anyone give me a few examples of configurations that fall between "--search astar(lmcut())" and  "--alias lama-first" that will work on Windows? In particular, I'd like something where I can tell the planner to try for X seconds or X iterations.

-david

[davi...@umich.edu]

Regarding my previous message, if all else fails, I could try "--alias lama" and then programmatically kill the process like we discussed previously. My concern is that it might be in the middle of writing to the plan file sometimes when it's killed.

[Malte Helmert]

On 28.10.20 18:52, davi...@umich.edu wrote:
>
> Regarding my previous message, if all else fails, I could try "--alias
> lama" and then programmatically kill the process like we discussed
> previously. My concern is that it might be in the middle of writing to
> the plan file sometimes when it's killed.

Hi David,

this is the solution I would suggest.

Aborts in the middle of writing a solution can happen with Fast
Downward's built-in timeout mechanisms (on platforms other than Windows)
as well. This is the primary reason why existing plans are never
overwritten but rather every new plan is written to a new numbered plan
file.

The suggested way to deal with the possibility of such aborted runs is
to check if the last plan file that was produced is complete and delete
it otherwise. It is complete iff the last line in the file begins with
";" and ends with a newline. On Windows, I assume that means a CR+LF
character combination, but I don't have access to a Windows machine to
check it. (Should be easily testable for people on Windows, though.)

Best,
Malte

[David Epstein]

Ok. I'll try that. Thank you!