add parallel dataflow blog #540
Conversation
sampsyo
left a comment
sampsyo
left a comment
There was a problem hiding this comment.
Really nice work, y'all! This is a fantastic set of outcomes, and it seems like you've set things up for even more cool results in this area. Would any of you be interested in continuing to work in this vein and possibly to come up with something publishable?
| ## Mixed | ||
| During testing and early evaluations, we found that some benchmarks are too small to benefit from parallelization. This is likely because the amount of time required to execute the worklist algorithm is less than the amount of time it takes to spawn and collect threads. We attempted to find a heuristic, based on the size of a function in basic blocks, that we can use for switching between our sequential and parallel versions of the algorithm. | ||
|
|
||
| This version of the algorithm takes an integer threshold as an additional input; if the size of the function is below that threshold it uses the sequential algorithm and otherwise it uses the parallel algorithm. |
There was a problem hiding this comment.
Is the “size” here the number of basic blocks?
There was a problem hiding this comment.
Yep! Just made it clearer
|
|
||
| For generating random Bril programs, we used [Bear](https://stephenverderame.github.io/blog/bear/), an existing fuzzer for Bril. | ||
|
|
||
| ## Parallelizing a Single CFG |
There was a problem hiding this comment.
Can you say a little more about your experimental setup? The most relevant details are the core/thread count.
There was a problem hiding this comment.
Added a short experimental setup section here
| Runtime includes the amount of time it takes to build a CFG and run the worklist algorithm on it. It does not include the time to parse a Bril program. | ||
|
|
||
|  | ||
| In general, it seems our parallel algorithm provides at least some speedup over the sequential one. It also seems that our heuristics for all of our hybrid algorithms were quite bad, since at best they are on par with the fully parallel implementation. In the case of the reaching definitions analysis all of the hybrid algorithms are actually slower than the sequential one, so our heuristics were probably wrong more often than they were right. It is also possible that different heuristics are required for different types of analyses, which we did not explore. |
There was a problem hiding this comment.
Here is where it seems especially important to know how many threads we have to "spend" to yet this speedup.
There was a problem hiding this comment.
Added a short paragraph discussing speedup vs thread count here
|
Looks great!! I'll hit the green button now, but do let me know if any of y'all would be interested in chatting about taking this project to its natural conclusion… |
2 participants
Closes #502