Single-threaded datacheck FP matching is already pretty efficient:
- Currently roughly 2/3 of datacheck entries are FPs.
datacheckerrors->entries is sorted asciibetically, and datacheckfps.csv is sorted pretty darn close to asciibetically.- Thus when an FP is matched, it's found & erased right off the beginning of the FP list, very little searching necessary.
- When there's no FP entry to match, we do search the whole list, but at least it's continually shrinking.
Still, it's about 5% of total execution time on lab2.
It doesn't lend itself well to multithreading:
- How to avoid data races when reading & erasing from the
datacheckfps list? - We could use a mutex, but the performance penalty would probably be a big one.
- Attempting to avoid this by splitting
datacheckerrors->entries and datacheckfps into n chunks to feed to n threads hurts our ability to "cross off" items right away.
A better approach?
Some datacheck errors are flagged during HighwayGraph construction, but after the structure is built out, we're all set.
Single-threaded datacheck FP matching is already pretty efficient:
datacheckerrors->entriesis sorted asciibetically, and datacheckfps.csv is sorted pretty darn close to asciibetically.Still, it's about 5% of total execution time on lab2.
It doesn't lend itself well to multithreading:
datacheckfpslist?datacheckerrors->entriesanddatacheckfpsinto n chunks to feed to n threads hurts our ability to "cross off" items right away.A better approach?
Some datacheck errors are flagged during HighwayGraph construction, but after the structure is built out, we're all set.
SubgraphThreadto start, and have our datacheck FP thread spawn one when it finishes up, just likeMasterTmgThreaddoes.-t 1is specified.