On 04. 12. 24 20:32, William Cohen wrote:
On 11/21/24 17:32, Miro Hrončok wrote:
On 21. 11. 24 23:11, William Cohen wrote:
Sediment has been designed to work with the RPM build process.
Currently, one needs to use modified RPM macros. These can be created
quickly by writing the output of the sediment make_sediment_rpmmacros
command into ~/.rpmmacros. One will also need to define set the pgo
macro to 1 for the rpmbuild process. The rpm spec file has minimal
modifications. It has the callgraph files stored as a source file and
a defines the global call_graph to the source file that holds the call
graph.
Hey Will,
let's say I wan to try this for Python. Where do I start? The README on https://github.com/wcohen/sediment is not very helpful.
This is what I did based on your email:
$ sudo dnf --enable-repo=updates-testing install sediment
...
Installing sediment-0:0.9.3-1.fc41.noarch
I run make_sediment_rpmmacros, it gives me some macros. Now I am supposed to put those to ~/.rpmmacros. Exccept I never build Python loclly, I use Koji or mock. I can probably amend this to use %global and insert it to python3.14.spec. But what else I need to do? Do you have a step by step kind of document I can follow?
Hi Miro,
The tooling doesn't yet fit your work flow of building packages in
koji and mock. I am looking into ways of addressing that issue.
I an earlier email I mentioned the important thing was have good
profiling data. Do you have suggestions on some benchmarks that would
properly exercise the python interpreter? I have used pyperformance
(https://github.com/python/pyperformance) to get some call graph data
for python and added that to a python3.13 srpm available at
https://koji.fedoraproject.org/koji/taskinfo?taskID=126526066. Note
Koji is NOT building code layout optimization. One would still need
to build locally python3.13-3.13.0-1.fc41.src.rpm with sediment-0.9.4
(https://koji.fedoraproject.org/koji/buildinfo?buildID=2596791)
installed and ~/.rpmmacros following steps:
make_sediment_rpmmacros > ~/.rpmmacros
rpm -Uvh python3.13-3.13.0-1.fc41.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -ba --define "pgo 1" python3.13.spec
The notable difference in the python3.13.spec file is the addition of:
# Call graph information
SOURCE12: perf_pybenchmark.gv
%global call_graph %{SOURCE12}
The perf_pybenchmark.gv was generated with steps:
python3 -m pip install pyperformance
perf record -e branches:u -j any_call -o perf_pybenchmark.data pyperformance run -f -o fc41_x86_python_baseline.json
perf report -i perf_pybenchmark.data --no-demangle --sort=comm,dso_from,symbol_from,dso_to,symbol_to > perf_pybenchmark.out
perf2gv < perf_pybenchmark.out > perf_pybenchmark.gv
Added the file to the python srpm:
cp perf_pybenchmark.gv ~/rpmbuild/SOURCES/.
# edit ~/rpmbuild/SPECS/python3.13.spec to add call graph info
The improvements were mixed between the code layout optimized python
and the baseline version of the pyperformance benchmarks. This can be
seen in the attached python_pgo.out generated by:
python3 -m pyperf compare_to fc41_x86_python_baseline.json fc41_x86_python_pgo.json --table > python_pgo.out
It looks like a number of the benchmarks are microbenchmarks that are
unlikely the benefit much for the code layout optimizations.
Are there other python performance tests that you would suggest that
have have larger footprint and would better gauge the possible
performance improvement from the code layout optimization?
Are there better python code examples to collect profiling data on?
Hey Will,
thanks for looking into this.
For your question: Upstream is using this for PGO:
$ python3.14 -m test --pgo
Or:
$ python3.14 -m test --pgo-extended
In spec, this can be used:
LD_LIBRARY_PATH=./build/optimized ./build/optimized/python -m test ...
---
What is the blocker to run this in Koji/mock?
You do `make_sediment_rpmmacros > ~/.rpmmacros`.
What's the issue with %defining such macros at spec level?
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue