Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break statement #261

Open
tissue3 opened this issue Oct 7, 2019 · 3 comments
Open

Break statement #261

tissue3 opened this issue Oct 7, 2019 · 3 comments
Labels
Discussion Needed Language features that need more discussion before implementation

Comments

@tissue3
Copy link
Contributor

tissue3 commented Oct 7, 2019

I feel we will need "break" statement in dahlia at some point. HLS does not support dynamic loop unrolling, but if...break can get rid of this constraint. Dahlia may have similar constraints.

@rachitnigam
Copy link
Member

Can you explain what problem they solve? From what I've heard, using break is generally not recommended (especially labelled break) because the complicate the control Finite-state machine (FSM). A soft rule I've heard from HLS users is that minimizing weird control statements like break is crucial for getting good performance.

@tissue3
Copy link
Contributor Author

tissue3 commented Oct 7, 2019

Any sorting algorithm needs break or dynamic loop. And you are right, control statements have to be kept as few as possible, but when one has to implement "weird control flow", break is a compromise to dynamic loop because in the latter case it cannot get unrolled at all.
Below is an example of knn where minimal distance needs to be chosen.
https://github.com/ptpan/ece5775/blob/04e2e004619e5edb96bd4dc58a713b6b173bc9ea/lab2/digitrec.cpp#L79
Though break unrolled is not that much different from nop if my understanding is correct.

@sampsyo
Copy link
Contributor

sampsyo commented Oct 8, 2019

That KNN loop is a good example!

To summarize the argument against break, from a Dahlia predictability perspective: adding a single line (break) inside an unrolled loop introduces extra hardware for every unrolled loop iteration. The loop PEs need to add exit-check logic to see if the parallel execution they're currently running is going to get "squashed" by the break signal computed by a different PE. That's a pretty large, global change just to support a seemingly-simple control flow construct that's easy for a normal CPU to implement.

Put differently, break is sort of an "anti-parallelism" thing because it introduces implicit serial dependencies between every iteration of the loop. Each iteration needs to know whether the previous iteration "canceled" the loop before it does anything that might have visible side effects.

But of course, sometimes that serialization is precisely what you want, as in the KNN example. I wonder if some sort of combine magic might be a more predictable way to express that—that is, a combine block would be allowed to break because its executions are already serialized! If we can think of a nice way to express things like a min-check reduction in a combiner, that would be awesome…

@rachitnigam rachitnigam added the Discussion Needed Language features that need more discussion before implementation label Feb 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Needed Language features that need more discussion before implementation
Projects
None yet
Development

No branches or pull requests

3 participants