Issue877

Title performance improvements for relaxation heuristics
Priority meta Status chatting
Superseder Nosy List cedric, jendrik, malte, silvan
Assigned To Keywords
Optional summary
Conceptual ideas:

1. Compute heuristics for general operators instead of unary operators.
   For operators with conditional effects, we would create a separate
   version of the operator for each effect condition, as in our planning
   lecture slides.
   => This should make the heuristics more informative on tasks with
      conditional effects.


Performance ideas (G, H, I, K and N stem from issue814):

G. Use struct-of-vector representation instead of vector-of-struct
   representation, keeping related data together.
   => Might be worth trying out.

H. Separate rarely accessed data, frequently read data, and frequently
   read+written data.
   => Might be worth trying out.

I. Compute h^FF as a side effect of marking preferred operators rather than
   actually computing the relaxed plan explicitly.
   => With this change we could avoid looping over all operators to see
      whether they are part of the relaxed plan. However, this change is
      probably only useful if we use general operators instead of unary
      operators and can set an instance variable to mark an operator as
      part of the relaxed plan (see 1.).

K. Compile the goal into an operator.
   => Would allow some simplifications while making the setup more
      complicated. Could be worth trying out, but not top priority.

N. Precompute the set of no-precondition actions.
   => Probably won't change too much, but would also be quite
      easy to do. Not high priority.

O. Make data needed for setup_exploration_queue() trivially copyable.
   => This should make the compiler use a memcpy and thus speed
      up the initialization of the queue.

Created on 2018-12-10.20:30:10 by jendrik, last changed by silvan.

Summary
Conceptual ideas:

1. Compute heuristics for general operators instead of unary operators.
   For operators with conditional effects, we would create a separate
   version of the operator for each effect condition, as in our planning
   lecture slides.
   => This should make the heuristics more informative on tasks with
      conditional effects.


Performance ideas (G, H, I, K and N stem from issue814):

G. Use struct-of-vector representation instead of vector-of-struct
   representation, keeping related data together.
   => Might be worth trying out.

H. Separate rarely accessed data, frequently read data, and frequently
   read+written data.
   => Might be worth trying out.

I. Compute h^FF as a side effect of marking preferred operators rather than
   actually computing the relaxed plan explicitly.
   => With this change we could avoid looping over all operators to see
      whether they are part of the relaxed plan. However, this change is
      probably only useful if we use general operators instead of unary
      operators and can set an instance variable to mark an operator as
      part of the relaxed plan (see 1.).

K. Compile the goal into an operator.
   => Would allow some simplifications while making the setup more
      complicated. Could be worth trying out, but not top priority.

N. Precompute the set of no-precondition actions.
   => Probably won't change too much, but would also be quite
      easy to do. Not high priority.

O. Make data needed for setup_exploration_queue() trivially copyable.
   => This should make the compiler use a memcpy and thus speed
      up the initialization of the queue.
Messages
msg8229 (view) Author: malte Date: 2018-12-11.10:55:28
The main point about #1 is that this would allow to actually compute relaxed
plans for problems with conditional effects, which we currently don't do. I've
elaborated the idea a bit in the summary.
msg8220 (view) Author: jendrik Date: 2018-12-10.20:30:10
This issue collects several ideas we had while working on issue814 (making the
relaxation heuristics more efficient, especially in 64-bit builds).
History
Date User Action Args
2018-12-11 11:12:30silvansetnosy: + silvan
2018-12-11 10:59:05cedricsetnosy: + cedric
2018-12-11 10:55:28maltesetstatus: unread -> chatting
title: ideas for relaxation heuristics -> performance improvements for relaxation heuristics
messages: + msg8229
summary: Conceptual ideas: 1. Compute heuristics for general operators instead of unary operators. => This should make the heuristics more informative on tasks with conditional effects. Performance ideas (G, H, I, K and N stem from issue814): G. Use struct-of-vector representation instead of vector-of-struct representation, keeping related data together. => Might be worth trying out. H. Separate rarely accessed data, frequently read data, and frequently read+written data. => Might be worth trying out. I. Compute h^FF as a side effect of marking preferred operators rather than actually computing the relaxed plan explicitly. => With this change we could avoid looping over all operators to see whether they are part of the relaxed plan. However, this change is probably only useful if we use general operators instead of unary operators and can set an instance variable to mark an operator as part of the relaxed plan (see 1.). K. Compile the goal into an operator. => Would allow some simplifications while making the setup more complicated. Could be worth trying out, but not top priority. N. Precompute the set of no-precondition actions. => Probably won't change too much, but would also be quite easy to do. Not high priority. O. Make data needed for setup_exploration_queue() trivially copyable. => This should make the compiler use a memcpy and thus speed up the initialization of the queue. -> Conceptual ideas: 1. Compute heuristics for general operators instead of unary operators. For operators with conditional effects, we would create a separate version of the operator for each effect condition, as in our planning lecture slides. => This should make the heuristics more informative on tasks with conditional effects. Performance ideas (G, H, I, K and N stem from issue814): G. Use struct-of-vector representation instead of vector-of-struct representation, keeping related data together. => Might be worth trying out. H. Separate rarely accessed data, frequently read data, and frequently read+written data. => Might be worth trying out. I. Compute h^FF as a side effect of marking preferred operators rather than actually computing the relaxed plan explicitly. => With this change we could avoid looping over all operators to see whether they are part of the relaxed plan. However, this change is probably only useful if we use general operators instead of unary operators and can set an instance variable to mark an operator as part of the relaxed plan (see 1.). K. Compile the goal into an operator. => Would allow some simplifications while making the setup more complicated. Could be worth trying out, but not top priority. N. Precompute the set of no-precondition actions. => Probably won't change too much, but would also be quite easy to do. Not high priority. O. Make data needed for setup_exploration_queue() trivially copyable. => This should make the compiler use a memcpy and thus speed up the initialization of the queue.
2018-12-10 20:30:10jendrikcreate