Split processors into monitor and user #237
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Every single use of chip.processors was inefficient.
Typically the caller want just the ids and/ or just the user cores.
This pr adds extra methods to provide these more efficiently.
To add efficiency in the common case where just user processors (or their ids) are wanted the monitor and user processors are split into two dicts.
This comes at a slight cost for some methods using all processors but not enough to make is desirable to have duplicates dicts.
The only use cases that wanted all processors actually only wanted their ids so the new all_processor_ids method is faster anyway
Chip now also consistently uses machine_version().n_non_user_cores to determine the number of monitor processor and Chips just point to the global dict.
(A pointer to the global dict was required to allow some tests to hack in a different number of monitor cores)
tested by
http://apollo.cs.man.ac.uk:8080/blue/organizations/jenkins/Integration%20Tests/detail/chip_test/2/pipeline
(note that actually tested with Chip.processors completely remove which is why the different branch names)
Fixes #182