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

Parallel Expressions #33

Open
j-hui opened this issue Oct 22, 2021 · 2 comments
Open

Parallel Expressions #33

j-hui opened this issue Oct 22, 2021 · 2 comments

Comments

@j-hui
Copy link
Contributor

j-hui commented Oct 22, 2021

"yield abstraction" might not be the best name for this, but that's what I've called it for now in our IR pipeline (and it does nothing right now). Perhaps "par lift" or "par abstraction" is a better term.

But @Rewbert actually brought up this issue as it was something he thought of while working on ssm-edsl.

Say we have something like this:

par do wait x
       after 1, y <- ()
    do after 1, x <- ()
       wait y

This expression alone already has some fairly interesting temporal behavior, and is something we do allow in our language. But codegen doesn't know how to deal with this, because it only knows how to deal with parallel function calls.

That can be achieved by lifting these into immediately applied lambdas:

par (\() -> wait x
            after 1, y <- ()) ()
    (\() -> wait y
            after 1, x <- ()) ()

This should be done before lambda lifting (#32) to ensure that these newly introduced lambdas are lifted to the top-level so that they are compatible with Codegen's compilation scheme.

@j-hui
Copy link
Contributor Author

j-hui commented Oct 22, 2021

Oh and I should note that for parallel expression with no temporal behavior, they should just be desugared down into sequential code for efficiency (avoids unnecessary context switches). So for instance:

par x <- 1
    y <- 2

shoudl just desugar down into

let _ = x <- 1
y <- 2

@sedwards-lab sedwards-lab changed the title Yield abstraction Inline Parallel Expressions Oct 22, 2021
@sedwards-lab
Copy link
Contributor

sedwards-lab commented Oct 22, 2021

It should be "parallel expressions"

Broadly, it's just desugaring par expr (|| expr)* into parallel function calls. We did something like this in the SHIM language; it's mechanical here because the expressions are totally ordered.

@sedwards-lab sedwards-lab changed the title Inline Parallel Expressions Parallel Expressions Oct 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants