Hi everyone, my name is Alex, and today we are going to talk about Profile Guide
Deptimization of Pidgeor, but not about the optimization itself, about the challenges
of adopting the implementation of Pidgeor in practice.
Why is it like how many of you know what Pidgeor is?
Great, it's a great audience, so thank you, thank you.
If you were about me, so I spent some time with HECK and LVM, different parts,
especially static analyzer, so I was interesting in different kinds of optimizations.
My diploma project was about extending Pidgeor infrastructure for some specific cases,
and during the last years, during the work on the awesome Pidgeor project, where I am
trying to collect as much as possible information about Pidgeor.
Unfortunately, I collected as much as possible trips of Pidgeor in real life, and I want
to share this in my experience.
So, why do we care?
I should be care about Pidgeor, because it works, and it works for real applications,
it works for databases, compilers, browsers, log shipping solutions, and so on, and it
works especially efficiently efficient in practice.
And you know, we need to pay some price for that improvements, and this price is issues
if integration Pidgeor into different applications.
And let's start from the most, most refined one.
You know, reproducibility is an important topic nowadays, and actually, I was talking
with many, many, many containers from different ecosystems, and top one, blocker for adopting
Pidgeor was reproducibility.
We can talk, we can divide this problem into two parts, like two dedicated cases.
The first one is reproducible built in some kind of predefined Pidgeor profiles, safe,
and collect.
And the second one, the most complicated, reproducible Pidgeor profile generation.
So, the first one is pretty simple to be resolved.
You can just save some Pidgeor profile into your favorite version control system and reuse
this profile during each build.
So, if you're built was reproducible in this way, your build will stay reproducible.
However, you will generate a bunch of another interesting issues like updating Pidgeor profiles
between compiler, braids, and so on, because they are not compatible.
And many, many other issues.
But they are kind of resolvable.
The second case, unfortunately, is generally unresolved, because it requires deterministic
execution of the application.
And if you're talking about real application, big applications like data bases, browsers,
it's not a suitable in practice, unfortunately.
Oh, documentation.
I must admit, the documentation for Pidgeor in all their was improved significantly
during the last few months.
And I wanted to say thank you for everyone who was working on it, but still has some hidden
traps.
The first one, about hidden Pidgeor features.
For example, like some trickier ways to do a Pidgeor, like a CSS Pidgeor, or maybe some
relationships between Pidgeor and Pidgeor, because I was wondering that Pidgeor could
be improved when Pidgeor is used at the same time.
It's due to some internal implementation details.
These all features are not documented at all.
Clank has the best documentation about Pidgeor from all of them, based compilers.
And other LVM-based compilers, like Rossi, they like to just refer to the Clank documentation.
Unfortunately, it doesn't work in practice well, because don't let's call them down
stream compilers from the Pidgeor perspective, don't implement all Pidgeor features.
And you as a user should guess which parts of Clank documentation applicable to your compiler.
And I know which parts are applicable users in general don't.
And smaller issues like different warnings, like rings, start out of static counters and
they're like that.
And if you know, if you have some experience with Pidgeor, you don't care, but Pidgeor
and Ubis, let's call them like that.
They are scary about this one, because oh, Pidgeor broke my build, especially if they
have enabled by default warning questionnaire policy.
Many of these questions can be answered by, let's call them Pidgeor gurus.
And this is the most convenient way to resolve your current problems with Pidgeor, because
official documentation select of many, many interesting details.
And it's much easier just ask a question from bright people.
For example, from LVM, it's a single young, directly, I hope I pronounced properly.
Although it's a Johnson, they're both from Google, from the RFC compiler.
It's a Yaku Bironic, it's a person who optimized RFC, if Pidgeor and many, many other
people from different ecosystems like Pidgeor have a system, like a Keshe OS, they are crazy
about applying Pidgeor to different stuff.
And it would be nice to highlight such people in some way, so it will simplify a life
for future Pidgeor doctors.
Unfortunately, many people still are not aware about Pidgeor, about what is Pidgeor, how
efficient it is in practice and so on.
I found many times that different kinds of misinformation about Pidgeor.
For example, Eskillite, for many years, had the note in the official documentation that Pidgeor
doesn't help to optimise his QI performance.
I was triggered by it and I performed my own benchmarks and I got persecution movements.
I reported back to the upstream and after very, very long debate, with Eskillite deaths, they
removed this note from the documentation.
Unfortunately, they didn't add a note that Pidgeor helps.
So, it is what it is.
And let's also my favorite.
People try to apply Pidgeor to one application and do a dozen work-for-all cases.
And if it doesn't work for on case, they make a conclusion, Pidgeor doesn't work at all
and write, she's a comment on Reddit, so I think that's about, so please don't try
Pidgeor, it's all it didn't help to optimise my effect impact.
Eskillite's impact is a good piece of software from the performance perspective at least.
So, and sorry for the guys.
And unfortunately, almost all our software in the industry are not the same quality
from the performance perspective and it's a pity situation.
The lack of Pidgeor integration examples, you know, every engineer is a copy-pacing
engineer.
And it's fine because they have a different job to do like business job, optimising
whatever.
And unfortunately, current algorithm, the commitment has very, very few good examples
how to integrate Pidgeor in practice.
So we have built instructions for clank and cement caches and let's see it.
All these documentation doesn't ask questions like this.
And these questions are very important in practice, especially the last one is the most
trickest one, how can I report a performance degradation from Pidgeor to the upstream?
And there are many, many other questions like that and they are not answered by official
documentation, unfortunately.
And to make things worse, different use cases, different Pidgeor challenges.
For example, what Pidgeor kinds should I use in my case?
We have two major Pidgeor kinds of limitations and sampling.
And we can't give a simple answer here because we have different domains,
budget limitations and so on.
And different use cases require different kinds of Pidgeor.
And even if you give people some recommendations, they like to mess up these recommendations.
For example, only something Pidgeor should be used nowadays, nope, it shouldn't,
because it has their own limitation and for example, if you are talking about creating packages
for creating system tech, creating the results for creating system tech,
if sampling Pidgeor is not achievable, at least nowadays.
Instremutation Pidgeor can be used in production environment, nope, it's cannot be,
but please be careful. There are situations when instrumentation Pidgeor could be used.
For production environment, for example, when you want to squeeze as much as possible performance
from Pidgeor because instrumentation Pidgeor is still better than sampling Pidgeor from the
optimization of Pidgeor for the compiler.
And that's why we need much more examples from different ecosystems, different domains and so on.
So people will be able to find the closest to their use case example
and try to copy Pidgeor's multiple things from there. And that's fine.
Oh, tooling support.
Oh, so there are almost no dual system integrations for Pidgeor.
Basel hasn't some kind of integration and back to that dual system from phased methods, sorry.
Other dual systems like D4, dual system for C++, CMAC, doesn't have anything like that.
The same thing goes about depending on the semangereuse.
And it makes the life harder for regular Pidgeor users.
And we need to somehow resolve it.
Rust has a really great example of such a tool like a cargo Pidgeor.
I'm used this extension a lot in my practice and it simplifies the life
significantly when you want to apply Pidgeor at least at least in
in simple cases, at least in them. It has only images like no semangereuse support but
and so for different use cases, highly likely we will need different tools.
So about different use cases, semangereuse issues like more than a way to do Pidgeor.
As a default tooling for doing a semangereuse was is out of video that's a project from Google.
Unfortunately, it has own problems. Like a build, issues with the most recent
LVM versions, you need to fix them manually or apply it patches.
Different bugs and the things like huge memory consumption and instead of good
shell solution in upstream you get advice like that.
Sorry, I don't like to work on a heavily sloped Linux machine and I already have 48
gigabyte of RAM. So no, let's see not the solution.
Out of the video plans to migrate to the LVM repo so it will resolve at least all
built issues but unfortunately, GCC support highly likely will be dropped.
Where is the link to the mail thread about it and as far as I know GCC folks didn't
migrate it to their own repository. So it could be a problem for them.
We have another tool LVM Proof Gen and it so it can be used in some cases like replacements
for all the video. Unfortunately, not in all cases. For example, the most significant one is
non LBR support LBR. It's hardware feature from Intel CPUs. It helps to perform sampling
PIDRO in a more efficient way. This feature is available for Intel CPUs for many years but
unfortunately in AMD CPUs it's available only since then free with an asterisk and since then
4 without an asterisk. So this use case is still important for the industry.
So if you are talking about sampling PIDRO, frequently we want to apply
this optimization continuously because we have large fleet of services and someone
and we don't want to perform all optimizations manually for each release.
So Google does it internally. We have a special system like based on Google White Profiler.
It has a large architecture. It's like that. You need to understand that regular PIDRO user
can replicate it because Google implemented them internally and unfortunately this system is
closed-sourced but finally, today's ago, the AMD's open-sourced completely the same system.
It's a scope here for it. So you can use it. It's completely open-sourced. You can deploy it on your
on your servers and use it like Google does it internally. So highly recommend to give it a try.
By the way, the LBR compilers are supported at least yet. In a official way,
very discussions about other things like a Grafana Pyros code but nothing to try beside discussions yet.
And I don't see an activity. So, interesting question about profile guide optimization,
post-link optimization like LBR, both the propeller, people don't understand the difference
between both of these tools. They think it can give me one tool like to optimize my software
and I can understand the point of view. And since you have two different tools, you need to
tweak your build scripts twice and so on. And it creates more complexion in so on.
That's not a good thing. And you know, we need better documentation of PIDRO tools to
both have at least quite good read me. Google propeller, okay. So that's not the documentation, sorry.
And, you know, for my practice for PIDRO tools, in many, in almost four cases, it's much easier to just
ask a question directly in the LBR discord from the developers.
About the LPR integration into LBR itself, only Klan has some kind of integration.
What we can do more things like a Klan format, fland, Klan Gd, I have benchmarks for that,
already, no integration yet. And the same goes for PLO adoption to weekend optimise LBR tool
more we can, but we don't do it for now. Regarding PIDRO integration into other LBR based
compilers, Klan has the best support, RSC, RSC, all of the same as the Klan with some fancy PIDRO features
and other PIDRO LBR based compilers unfortunately support on the basic PIDRO
way instrumentation or maybe don't support that's all PIDRO. And it's a good big good
motivation for all LBR and non GSC based compilers to implement, to implement their good
optimising compilers based on all of them because the other LBR infrastructure will be
quite tricky to implement PIDRO in the right way. So why should we care about PIDRO?
The idea behind all some PIDRO project is quite simple. I'm trying to feel as much as possible
gaps in the current PIDRO infrastructure, in the current Klan ecosystem and not talking
not only about LBR. PIDRO efficiency demonstration rail applications,
highlighting more PIDRO features that are hidden different RFC and maybe commitments and so on.
Making a shift from just PIDRO and LBR documentation to how to use PIDRO
in practice for real stuff, not just like smaller example and also all possible
questions about PIDRO that could appear in the future. It is I want to introduce more data
driven optimizations into current world so without all the stuff like random and winding
and selling, it can do better based on a data. It's not a big prize to that and but
that I want to increase the default level, the default performance level for the world with
a system and improve the world. If even if you need to open some amount of issues, let's
stay from us today from my GitHub. And that's it for today. Thank you.
APP Plan
Avishkanta, are Tid Cruz's
Temporal. Temporal, Pidgeor. Well, Temporal Pidgeor, that's kind of Pidgeor, that was documented
a month ago, I guess, that's kind of Pidgeor that helps you to optimize startup time for
your application. That's it, Temporal. I don't have experience with this kind of Pidgeor.
I only, I only was reading RFC and discussions on LVM forum. I didn't try it. Sorry.
Can you maybe explain a bit how it's implemented in LVM? Is it a notification pass?
Yeah, that's one of several optimization passes here. How they implemented inside of
them, I cannot say you much because you know, different limitations, so on. Are you interested
in optimizing stuff or on the optimization phase or instrumentation phase? Optimization phase
basically what Pidgeor brings, why it's so helpful at practice. It helps to perform much
much better in LVM. And in LVM, if you know about something about LVM, inside it's a very important
optimization, not only because in LVM, it improves performance directly like LVM jumps, called
now in LVM, gives to a compiler a context to perform other optimizations. And that's why it's
so important. There are other things like, I guess, the virtualization, I'm not sure it's
implemented in LVM in goal, it's implemented in goal, compiler, but in LVM is the most important.
Okay, we're out of tune. Thank you.