You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In pydantic-core we have been building with PGO for x86_64 Windows and Ubuntu for some time, and we're now also looking at GitHub's new M1 runners to run PGO optimization for arm macOS. pydantic/pydantic-core#1063
This is in a sort of grey area where we can make it work with maturin by passing in the PGO RUSTFLAGS directly and then running normal maturin build steps. We could call it an orthogonal problem which maturin doesn't need to solve.
There are two reasons why I think it would be nice for maturin to have firsthand support for PGO builds:
We can then make it easy for all Rust extension authors to PGO optimize their builds
We can only pass one --interpreter to build with PGO, which makes our build matrix very large (M platforms, N Python versions). It would be nice to be able to pass --interpreter 3.7 3.8 ... with all versions to make use of better build caching and reduce the number of jobs.
To have support for PGO, I think maturin would need to:
build the PGO-instrumented wheel for a given interpreter
install that wheel into a temporary virtual environment and run some step to generate PGO samples (we'd need configuration for this)
build the PGO-optimized wheel using the samples
... and repeat the above for each interpreter in turn.
I think all the configuration that would be needed is the set of packages to install into the temporary virtual environment and then a script to run to generate the PGO sample. The script could even be responsible for installing the dependencies, reducing to a single configuration entry, but then it probably needs to be a shell script and it gets a little harder to be cross-platform.
There is maybe an argument to leave all of this functionality to maturin-action. A nice thing about putting this directly in maturin is that the PGO build could then also be done locally, e.g. to benchmark it.
cc @konstin I took a quick look at the ruff workflow and it looks like you don't make use of PGO builds, is that something you tried and found it wasn't worth it, or just not ever looked into? In pydantic-core we won about 20-30% speedup from PGO, so potentially there is a nice ruff performance win to celebrate sitting on the table 😄
The text was updated successfully, but these errors were encountered:
cc @konstin I took a quick look at the ruff workflow and it looks like you don't make use of PGO builds, is that something you tried and found it wasn't worth it, or just not ever looked into? In pydantic-core we won about 20-30% speedup from PGO, so potentially there is a nice ruff performance win to celebrate sitting on the table 😄
I haven't actually looked at it, 20-30% is massive!
In
pydantic-core
we have been building with PGO for x86_64 Windows and Ubuntu for some time, and we're now also looking at GitHub's new M1 runners to run PGO optimization for arm macOS. pydantic/pydantic-core#1063This is in a sort of grey area where we can make it work with
maturin
by passing in the PGORUSTFLAGS
directly and then running normalmaturin
build steps. We could call it an orthogonal problem whichmaturin
doesn't need to solve.There are two reasons why I think it would be nice for
maturin
to have firsthand support for PGO builds:--interpreter
to build with PGO, which makes our build matrix very large (M platforms, N Python versions). It would be nice to be able to pass--interpreter 3.7 3.8 ...
with all versions to make use of better build caching and reduce the number of jobs.To have support for PGO, I think
maturin
would need to:... and repeat the above for each interpreter in turn.
I think all the configuration that would be needed is the set of packages to install into the temporary virtual environment and then a script to run to generate the PGO sample. The script could even be responsible for installing the dependencies, reducing to a single configuration entry, but then it probably needs to be a shell script and it gets a little harder to be cross-platform.
There is maybe an argument to leave all of this functionality to
maturin-action
. A nice thing about putting this directly inmaturin
is that the PGO build could then also be done locally, e.g. to benchmark it.cc @konstin I took a quick look at the
ruff
workflow and it looks like you don't make use of PGO builds, is that something you tried and found it wasn't worth it, or just not ever looked into? Inpydantic-core
we won about 20-30% speedup from PGO, so potentially there is a niceruff
performance win to celebrate sitting on the table 😄The text was updated successfully, but these errors were encountered: