Conversation
|
OS:ubuntu-22.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
… to their own class
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
…tion of the same consecutive command
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
|
OS:ubuntu-20.04 |
This is still work in progress. Currently the loop context is passed to the scheduler, but the scheduler still only executes each loop body once.
We currently need to figure out how to reexecute the same node in a loop more than once. I think the way to implement this is to unroll loops in the partial order while executing (see attached picture), and never executing/stepping/speculating/commiting/frontiering the loop node. The loop nodes should act as barriers that cannot be committed and we will decide to unroll them at some points. We can be conservative and just unroll the loop when the frontier is empty (which means that the next non-committed node is a loop node) or unroll it optimistically allowing speculation too.
TODO before merging: