Created on 2018-12-10.20:30:10 by jendrik, last changed by malte.
|
See also issue890 for (perhaps) lower-hanging fruit.
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.
|
|
| 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).
|
|
| Date |
User |
Action |
Args |
| 2019-01-21 13:56:47 | malte | set | 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. -> See also issue890 for (perhaps) lower-hanging fruit.
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-11 11:12:30 | silvan | set | nosy:
+ silvan |
| 2018-12-11 10:59:05 | cedric | set | nosy:
+ cedric |
| 2018-12-11 10:55:28 | malte | set | status: 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:10 | jendrik | create | |
|