Handle memouts more appropriately #27

Closed
opened 2017-11-27 20:54:01 +01:00 by patrick · 1 comment
Owner

In order to treat benchmark runs with memouts more justly, we should configure the corresponding configurations to respect the memory limits. In this way, there won’t be memouts, and the results might be more representative.

In order to treat benchmark runs with memouts more justly, we should configure the corresponding configurations to respect the memory limits. In this way, there won’t be memouts, and the results might be more representative.
patrick added this to the Extended Paper for TPLP Journal milestone 2017-11-27 20:54:01 +01:00
patrick added the
bug
benchmarks
task
labels 2017-11-27 20:54:01 +01:00
Author
Owner

I modified the configuration as follows:

  • The planners get a soft memory limit of 8192 MB. They should stick to this limit and not allocate more than that.
  • There is a tolerance margin of 1024 MB, meaning that the hard memory limit is 9216 MB. After that, the benchmark job is shut down, and the result is counted as a memout.

In this way, all the existing results are still valid.

I removed all results of affected instances (with memouts) and restarted the benchmark runner to redo them.

I modified the configuration as follows: - The planners get a soft memory limit of 8192 MB. They should stick to this limit and not allocate more than that. - There is a tolerance margin of 1024 MB, meaning that the hard memory limit is 9216 MB. After that, the benchmark job is shut down, and the result is counted as a memout. In this way, all the existing results are still valid. I removed all results of affected instances (with memouts) and restarted the benchmark runner to redo them.
This repo is archived. You cannot comment on issues.
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

0001-01-01

Dependencies

No dependencies set.

Reference: patrick/plasp#27
No description provided.