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

runtime: investigate a hybrid memory clearing strategy based on prove results #57000

Open
jake-ciolek opened this issue Nov 30, 2022 · 6 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone

Comments

@jake-ciolek
Copy link
Contributor

In some cases, it might be better/faster to have a hybrid memory clear where from prove we know that a clear will be at least X bytes long.

We could use a static clear and then handle the unknown-sized remainder (either via a call to memclrNoHeapPointers or some inlined clear for the remainder). This could improve performance or allow more optimizations to fire due to the static clear part enabling things like DSE.

@seankhliao seankhliao changed the title Investigate a hybrid memory clearing strategy based on prove results runtime: investigate a hybrid memory clearing strategy based on prove results Nov 30, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Nov 30, 2022
@seankhliao seankhliao added Performance NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 30, 2022
@randall77
Copy link
Contributor

In what situations would we know that the size is >X but not constant?

@jake-ciolek
Copy link
Contributor Author

I dumped it from prove and didn't get to confirm whether this ends up being compiled to a call to memclrNoHeapPointers or not, but:

data = append(data, 0)

It seems that if prove was able to have a min limit on the len then we could use it to setup the static clear.

@randall77
Copy link
Contributor

I don't follow how that snippet of code is relevant to this issue.

@jake-ciolek
Copy link
Contributor Author

A simple example could be something like:

func myfunc(clear bool, size int, arr [32]int8) []int8 {
    slice := arr[:]

    for i := 0 ; i < size ; i++ {
        slice = append(slice, int8(i))
    }

    if clear && size & 1 == 0 {
      // We know that this len has to be at least 32 so we could
      // create a static 32 byte clear and handle the rest dynamically
      for x := range slice {
          slice[x] = 0
      }
    }

    return slice
}

@randall77
Copy link
Contributor

This seems like an exceedingly rare situation. I'd want to see a situation where this actually triggers before we spend time on it.

Since we have to call into the runtime anyway, it also seems like a really small win.

@jake-ciolek
Copy link
Contributor Author

On a related note, maybe we could use PGO to find clears where one clear size dominates. If they are almost always x we could inline the most common clear and then have check if size == x (otherwise call memclrnoheappointers).

@mknyszek mknyszek added this to the Backlog milestone Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
Development

No branches or pull requests

5 participants