heliosfa
commented
4 years ago I have been doing a little more playing with this in an attempt to break it/find flaws.
I wanted to validate your times from this:
A 128x128 heated plate, placed on 32, 16, 8, and 4 devices per thread. The former three complete in 104, 44, and 19 seconds respectively.
and compare to the current state of play. Unfortunately, from the documentation and a quick search of the source, I can't see how to constrain the number of devices per thread at runtime without recompiling. From the docs, I was guessing that it would be with the placement /constraint command, but the docs state that his is not defined? Care to enlighten me?
I'll comment on the docs in more detail, but they are lacking in examples and a command "quick reference".
The latter causes the Orchestrator to complain that there is not enough space to place the task (as it should). I've also tested 40x40 and 3x3 heat plates in various configurations.
Interesting, a 128x128 at 4 per thread should fit on the full system - it does with the "old" placement and the byron uif. A 6-board box has 6,144 threads - we would use 4097 of these for the 16,384 devices of a 128x128 plate.
All plates were tested using bucket filling.
How do I specify this as an algorithm? I am assuming that it defaults to it, but there is no list of supported algorithms.
Another thing, just to see what would happen, I threw my call files at it.
task /path = "/home/gmb/Orchestrator/application_staging/xml"
topology /load = "/local/orchestrator-common/single-box.uif"
topology /constrain="DevicesPerThread",4
task /load = "plate_128x128.xml"
link /link = "plate_128x128"
task /build = "plate_128x128"
task /deploy = "plate_128x128"
task /init = "plate_128x128"
task /run = "plate_128x128"I get this error:
POETS> 19:24:32.70: 136(I) Whatever you asked for, it's not working yet
from the topology /constrain="DevicesPerThread",4 line. While I don't expect this to work, it would be nicer if the error told me which command from the call file it did not like.
It also seems like the link /link = "plate_128x128" line works as it results in
POETS> 19:28:00.69: 209(I) Attempting to place task 'plate_128x128' using the 'link' method..., despite the docs not mentioning it?
mvousden
This changeset introduces the designed Placer structure and interface to the Orchestrator. It maintains feature parity with the existing Orchestrator, and introduces some experimental features, including a simulated-annealing placer, a random placer, and the ability to save and load placement information (experimental here means that it either doesn't work end-to-end, or is so nuanced as to be unusable by anyone apart from @mvousden).
There are obvious components of this changeset that are not finished. Our intention is to introduce a working set of components that plays nicely with the rest of the Orchestrator before adding further features (i.e., review/merge as early and often as possible).
This changeset has been tested (all on Ayres):
The unit tests (which all pass). Note the lack of placement unit tests - I plan to add these when the V4 parser is introduced to avoid writing the same tests multiple times.
The Mothership test examples in the orchestrator-examples repository.
A 128x128 heated plate, placed on 32, 16, 8, and 4 devices per thread. The former three complete in 104, 44, and 19 seconds respectively. The latter causes the Orchestrator to complain that there is not enough space to place the task (as it should). I've also tested 40x40 and 3x3 heat plates in various configurations. All plates were tested using bucket filling.
A more fine-grained overview of the changes:
Removes the old placement and constraints system completely, and replaces it with a new system. Threads no longer hold devices (and vice versa) - this relationship is encapsulated by the placement logic. Unlinking is no longer managed by devices, and is instead also managed by the placement logic.
Introduces "core pairs" (
P_core::pair) into the hardware model and deployers, to better support shared instruction memory behaviour.Moves some placement conveniences (like
P_engine::get_boxes_for_task) out of the hardware model and into the placement system.OrchBaseLink.cppis nowOrchBasePlace.cpp, andplaceoperator commands now exist in place oflinkoperator commands (supporting backwards compatibility for bucket filling).Integration of the new placement system into
OrchBaseTask.cpp, including in initialisation and deployment subcommands.Integration of the new placement system into
OrchBaseTopo.cpp. Loading a new hardware model irrecoverably clobbers placement information.P_builder. Good luck with that.Lots of (accidental) trailing whitespace removal (sorry).
Adds a series of flags for GDB and Valgrind executables in the launcher. Purely a convenience mechanism.
Disables contracted floating point operations when compiling the Softswitch. I thought this was done elsewhere...
Adds a 1-box test for Dialect 3 (also used in testing).
This PR complements the PR at https://github.com/POETSII/orchestrator-documentation/pull/4. When both of these PRs are approved, I will:
Merge them.
Close (now redundant) PR #118.
Edit 2020-09-07: Grammar