Hi everyone, my name is Alex, welcome everyone who woke up so early to visit this room,
there's a software performance, the room, I'm a the room organizer, I'm not an Bluetooth
work but let's find, we didn't have enough of them for us.
So, and for today, I wanted to talk about one interesting topic, interesting to me,
about software performance, but not about actual benchmarks, so I'm a state-of-the-art performance,
it's several domains, something like that.
I wanted to talk about how accessible this software performance is for regular people.
For like-for-ups, a few words about me, I'm a regular C++ engineer, right now I'm a Rust engineer,
I'm interested in different compiler stuff, especially LVM, I prefer LVM over GCC for several reasons.
I spent several years in C++ Commits Thunder Committee, I'm the offer of the awesome PGO project, if you hear about it,
and the room organizer, and I actually actually like rapids of swear.
So, what do we usually hear about software?
Usually, at first, different benchmarks, good benchmark report, and not so good benchmark reports,
please don't use the compound or benches, there's serious stuff, different engineering and blogs,
something like we rewrote something, usually in Rust, and it became blazingly fast,
hardcore, and low-level optimization stuff, possibly from FFMP guys, something, rewriting in assembly,
and achieving great performance for conversions, and academic papers like, for example, a SIMD GISON,
like a normal technist, pretty noble technics for like three years ago, that was invented.
But one point is frequently missed, how all of this software performance equipment are easily,
to be used in everyday life. For example, check with one.
These are two titles from Faronics, and actually for this performance improvements for the Linux kernel,
and they are pretty significant, but can you say right now, which performance improvement is ready to use right now,
and which one is really is not achievable even after one year or two, with current tooling?
That's all the idea of my talk. So, let's start from the compilers, the compilation models, and that's driven optimizations.
So, actually there are two major compilation models ahead of time, and just a time compilation model,
and there are a pretty much differences between them.
For example, ahead of time compilation model is not limited in time, so much as a Justin time,
regarding how much time can we spend in performing different optimizations.
For example, we can spend several hours in extreme cases, even days for optimizing one binary.
If we can achieve, for example, one additional percent of performance.
In Justin time model, it's impossible, because it's usually run on a target machine,
it has limited time frame to perform optimizations, et cetera, et cetera.
However, Justin time model has one advantage.
It can collect on a target machine running for cloth, type of a cloth,
which paths of the coat are executed, how frequently et cetera.
At this information can be used during the compilers' optimization.
For example, more precise in lining, in lining was one of the most important optimizations,
hot cold splitting for better utilisation, CPU, iKesh, et cetera.
Fortunately, in the ahead of time world, it's not available, right?
It's not available, because on a target machine, we don't have a virtual machine
which can collect these metrics, we just have our own binary.
So, for ahead of time, we arose implemented a technology which is called profile guided optimizations.
Opidure, the idea is to practice the same.
We need to collect profile on a target machine, pass it to the compiler, probably convert, and that's it.
It's a pegoor, that's important, so do we need to carry about it.
So, I'll collect some benchmarks, that's part of the awesome Pedro project, and as you see,
a performance improvement, appropriate huge.
Sometimes, even two X, for example, it's about MongoDB, that's not so good database.
I would say, something from this perspective, for different libraries, compilers,
local analyzers, databases, et cetera, improvements are really huge.
So, we need to care about it.
However, so, in theory, enabling Pedro is a simple process, like just recompile your project.
If you're a special compiler switches, run target work load, collect profiles, and that's it.
However, if you will try to do it, you will get this one.
You will get a lot, and a lot of additional problems, which almost don't exist in just in time world.
You will have at first double or triple compilation model.
In extreme cases, you will need to compile your head of time binary four times.
In some extreme, a Pedro scenario, it's pretty huge overhead on CI.
You need to think about profiles, cube between different workloads.
You need to think about merging profiles for the same binary, but from different workloads.
You need to think about profile storage, if you want to reproduce your binary, et cetera, et cetera.
There are a lot of additional problems. You need to solve them.
There are some systems that can help you with that.
For example, there is a dedicated way to do Pedro, which is called sampling Pedro.
It eliminates instrumentation overhead from the instrumentation Pedro.
So, instrumentation Pedro has overhead several times.
On the run time, sampling Pedro can have one percent, for example.
Unfortunately, for using sampling Pedro, you need a bunch of additional tooling, one more,
and you need to install it, update, et cetera.
For example, if you want to use parca, or this yandex-perforator,
with system-wide profile or open source by yandex, which supports profiling,
the wall-serer fleet of binaries, and using these profiles during the profile guide optimization phase.
It can be integrated on CI, et cetera, et cetera.
Let's see how, actually, yandex Google simply didn't open source their own system.
Google white profiler, and actually, many other big projects are doing inside it.
However, as you see, you need to maintain additional amount of infrastructure.
For example, path-greSQL, usually cluster, click-house, cluster, and something,
some extra storage.
It's not that friendly.
So, you need to do a lot, really, a lot of additional work.
Just too much, the ability to mimic optimization of a just-in-time world.
Usually, we think that just-in-time optimizes worse when they head-of-time.
However, for workload-specific optimizations, just-in-time is just simpler to use,
compared to Pedro, just-in-time really just works.
For example, in every browser of 8, the 8th JavaScript engine, that's it.
So, we can try to eliminate at least part of this complexity by proper documentation.
I thought so, however, there are a lot of traps in this way too.
For example, performance optimization can take several forms,
or can have forms of really good books.
Like system-performance or brand-run-grade hackers, the light-famous, and inter-architect-specific optimizations.
Or any other form, like an official performance book,
project-specific simulation guidelines, like Reddit, staff, YouTube, coding influencers,
and a lot of different videos.
Even this talk.
But there is one issue with all of that.
Unfortunately, people just don't read it, don't wash it, and don't listen it.
And we are going once again, so we try to document something, like all of this Pedro stuff,
fancy how to avoid our problems, and people still will not do it.
Just because we don't care, we don't want to read, we don't have time,
we have work life balance, etc.
And just in time, it's simply better from this perspective.
Right right to eliminate for several frameworks.
I tried to push a little bit more optimizations to the upstream,
like to the documentation of these libraries.
Rata 2 is the most popular terminal user interface library in Rust.
They have a dedicated optimization guideline.
They also have a similar framework in Rust, dedicated optimization guideline,
and towering.
Almost the same.
However, I wanted to check how effective is this solution just putting
a documentation and crossing the fingers.
So, I checked a lot of GitHub projects,
and just found that people offers all these projects.
They have written their applications.
They didn't enable all of these optimizations from documentation.
They were existing at the moment.
And when I created a PR, it's enabling all of these optimizations.
They happily accept it.
Almost all of them.
I have a pretty high conversion rate, for example, like 90%.
That's a photography part.
That's for Rata 2 documentation.
And even when you're contributed,
some changes to the documentation,
like I did, for example, for Rata 2.
It was my contribution.
There is one more problem.
It will work, probably, probably work.
Only one newly created applications.
And all applications in the ecosystem, which I already exist in,
highly likely, will not be updated.
Simply because developers of these applications
will not find an update in the documentation of their framework.
They don't care.
They just write a wrong way of application one time, and that's it.
So, and even if they read documentation carefully.
The documentation doesn't care.
In many cases, really important details.
For example, that's why OSIMPJOR project was created,
because I tried to apply PJOR for several databases.
Let's say PostgreSQL, Escalated, etc.
And unfortunately, I found so many issues in current
documentation in the PJOR ecosystem.
So, I already spent three years in discovering
all the issues and hidden gems at treps
on the way, and I'm still not finished.
In many cases, the documentation is outdated,
and even worse, the documentation is outdated in such a way
that you cannot understand it, it's outdated.
For example, where it was a manual in client,
how to use PJOR, like a simple PJOR manual.
And this manual consisted of two PJOR modes.
It's called Frontend PJOR, F-PJOR, and IR PJOR,
intermediate representation PJOR, intermediate representation PJOR,
like L-O-V-R, IR.
So, by default, client was recommending using Frontend PJOR.
That's like in the guide line, a visual guide line from the compiler,
and only in the edge end of the instruction,
where it was written a small note, like very alternative way
to use PJOR, with the IR PJOR.
However, I randomly found an issue
that, actually, Frontend PJOR is deprecated.
And no one even written a note anywhere
in the documentation or whatever.
It was an internal knowledge in Google,
because Google was implementing most PJOR staff in LVM.
And we simply didn't put a note, and that's it.
And the issue was created in 2020,
and I only three years after that discovered this change,
only three years, and I need to ask additionally
from PJOR developers from Google
at the LVM discourse forum, and we answered my question.
So, unfortunately, there are already open source projects,
a pretty huge open source projects that are already integrated PJOR.
And they are integrated in the wrong way.
They integrated Frontend PJOR, and they were using
for many, many years.
It wasn't that critical.
You didn't need something performance.
Yes, unfortunately, they did.
When the client documentation was changed,
hardly pushed them to change a lot of things
in their PJOR guideline.
After some time, you go by the developers.
Somehow found it, probably because I reported an issue,
to the upstream.
And they decided to implement PJOR for their database,
and they got additional 10% improvement.
So, for many years, I guess, at least two or three years,
you got by the view was missing additional 10%
of performance for their and their users,
just because the documentation was,
I wouldn't say, line, it was updated.
It was updated in a pretty dirty way.
And sometimes, the documentation is simply line.
I had the case with SQLite.
So, when I started investigating PJOR for different database,
of course, I started from particular SQL,
my SQL, and someday I came to SQLite,
SQLite is fast database, so I wanted to optimize it even more.
SQLite and the documentation had a dedicated note
that PJOR doesn't help to optimize SQLite.
It was a dedicated note.
I, of course, I tested it on my own hardware,
and I got 10% improvement.
Of course, I reported to the upstream, they didn't believe me.
I needed to perform a bunch of additional benchmarks
on different compilers.
So, at first, I started with Clank.
They asked, please use GCC.
Okay, I reproduced on GCC.
So, later, they asked, so your benchmark suit,
I used Clankbench for lab workloads.
So, please use our own data.
Our own benchmark, we have speed test, something.
So, okay, I implemented once again.
I reproduced results with PJOR improvement once again,
10% on the after that, they just deleted this note
from the documentation, and they never added a note
about the PJOR helps to improve SQLite performance.
And this topic on the forum is still unanswered.
So, if documentation doesn't work,
maybe tooling can help us.
Okay, let's try.
How tooling can interior help us.
Okay, of course, we can try to automate some best practices
from optimization guidelines, from framework, et cetera.
Of course, we can do some kind of convenient benchmark
in the course, how can we measure performance
without a good benchmark is impossible.
So, actually, I've seen several projects
that we are measuring performance
of improvement by NI.
Actually, I am not lying into that GUI stuff.
We can try to automate optimization routines,
for example, at least semi-automatic PJOR stuff.
And, of course, profilerists, if a good visualization,
for example, imagine the newbie perspective
on Intel VTUN versus Linux Perf, which one is more friendly.
From my perspective, I'm kind of in UB.
I was in UB in profiling, Intel VTUN is much, much more friendly.
So, let's start with an example, creating a new application
from a template.
We can try to integrate in some templates,
ready to use template, our old recommendations,
regarding the link time optimization,
called Gen Units, whatever you want,
like all our favorite compilers wishes.
And, there are, actually, already,
a lot of, like, template, generators,
and ready to use templates.
I use the same framework,
rather, to the towering and dieoxos.
And, I integrated,
Intel, rather, to templates, these recommendations.
They are already merged, and ready to use.
Unfortunately, towering and dieoxos,
I created an issue in UB,
and, again, they are not that interested.
They are still unanswered.
So, when, if a router to user, right now,
we'll try to use a cargo-generate tool,
it's kind of the same standard tool in the RASTEK system,
and we'll try to create a new application for the router tool.
It's, it's, how recommended,
by the documentation from templates.
These optimizations will be enabled from the day one.
Not sometimes when I will create one and other PR
on the GitHub, please enable them from the day one.
However, this way still has issues.
People don't use project generators.
For various reasons, because they were just like copy paste
from their previous project,
they don't know about generators,
and they simply wipe coding stuff,
that's like a template engine, let's say,
and this wipe coded templates,
I'm not poisoned enough,
it's optimization guidelines, let's say.
And already written applications will not be covered anyway,
because when you change S,
the same situation is the documentation.
When you change it template,
it doesn't apply to the already created applications,
because people don't use generators only on the start.
In our example, let's compare benchmarking
between Rust and C++ stuff,
how the ecosystems are different,
and which one is more accessible to the developer.
benchmarking, of course, is needed
to measure performance, as I said.
So, good example is how it's done in Rust.
Rust, very, very,
by default, that's a default ecosystem,
it's called Cargabange.
I think I don't think that you can find
any benchmark in the Rust ecosystem
that will not be running by Cargabange command,
that's a standard,
and I did it hundreds of times for many, many projects,
it's always done in the same way.
Let's compare it to C++.
We can start from the simple question,
which benchmark library should we use?
Most people will say Google benchmark, okay, let's find.
How to connect, how to add the Google benchmark to your project?
There are a lot of different ways.
There are,
language-specific package managers like Conan,
the Cpc, of course, system dependencies,
like your favorite package manager on the system,
maybe an XOS, maybe whatever.
And next question,
how to run with benchmark?
In Rust, it's a very standard command.
In C++,
there is no any standard command to run a benchmark.
You will need, in the case of Google benchmark,
you will need to build a binary,
and run with binary.
And if it's your project,
it's fine.
But if you are running benchmarks for your
third-party project, you will need to figure out how run
with benchmark, read, read, read me,
and usually you need to read,
Simaq files, make files, whatever.
And of course, it's like a Zoo,
a C++.
And now, a good tool,
a good example of such helpful tooling,
supported with Cargo Vizor tool.
That's a tool that tries to automatically
apply, require some helpful optimizations
into your project.
So, how is it helpful?
When you have this tool,
you don't need to learn the
world documentation for the RustC compiler.
You don't need to be an expert in different compiler optimizations.
What does it mean?
About the different modes and the differences.
You can just run this Vizor.
This Vizor tool will do pretty good defaults
for you for several profiles and with it.
Unfortunately, there is anything comparable
in C++ for all.
Another example, post link optimization.
Post link optimization,
that's yet another step over profile guide optimization.
This technique actually,
what it does,
is actually the most important optimization.
It's a reordering functions in your binary
to make your CPU instruction cache happy,
because it reduces eye-cash instruction misses.
And it improves performance a lot.
There are three, like two.
Okay, two is at the moment.
With the most popular LVM bolt,
it was developed by phasebook slash meta.
That's default way to do payload right now.
And Google propeller, that's similar to
but from Google, works a bit in a different way,
because all of them both tries to disassemble your binary.
Reassemble it like re-shuffle functions,
and assembly binary gain.
But Google propeller,
they are modifying the compiler itself,
and they are reordering functions during the link in stage.
So they don't need to disassemble the reduced binary.
There are pros and cons of each approach,
and both developers and Google developers
don't agree with each other.
But it's what we have.
Also, we had Intel TLO,
finally out optimizer,
but it was up and sourced.
It had several commits,
and it's for now it's archived.
And since we have a lot of layoffs in Intel,
it's probably resting piece.
So forever.
So you can just look into the code,
but please don't use it.
Should we care about PLO?
Yes, we should,
because it gives one really great leap
in performance once again,
in compared to Pidgeor.
Let's talk from Amir Ayupov.
It's one of the developers, all of the emboldt.
And the implement of this tool for using internally
at Meta,
and they just decided to open source it.
And you can see,
they like to show LDM both
performance improvement on clinic.
But I have more benchmarks,
for example, on different databases,
for example, on the index database.
And I still, even on database,
on the real workload,
I can get plus 5% of performance,
just by applying this tool.
Let's approach the performance improvement
we are talking about already
LTO plus Pidgeor optimized binaries.
But how easy is to use PLO in practice?
So let's start from the good example.
I was done in Rust.
Rust has a yet another,
like plug-in to cargo, cargo Pidgeor,
cargo Pidgeor allows you to,
do in a semi-automatic way,
Pidgeor optimization routines,
and additionally both optimization routines.
And it's implemented in so good way.
So actually, you can implement
in exactly this comment,
Pidgeor plus PLO optimization pipeline.
That's a really, really powerful optimization pipeline.
It's used, it's used by clank,
not in distributions,
by default, but if you wear a scripts.
This pipeline is used by default by RustC,
right now.
So if you're using Rust,
and you're using RustC compiler,
it's optimized by this.
And let's compare to the C++ world.
How can you try to mimic it?
For example, C++ world doesn't have such a tool.
You need to implement everything on your own.
You need to start from the Pidgeor stuff.
You need to figure out proper compiler switches.
Of course, GCC, GCC, and clank,
they have similar compilers,
which are so Pidgeor, but they are not the same.
So we need to support in extreme cases both.
You need to build it, you need to run it.
Manually, of course, you need to collect Pidgeor profiles.
Pidgeor profiles are collected differently.
In GCC and clank ecosystems.
You need to convert this profiles to a proper format.
Format switches recognizable by the compiler.
It's done by different tools for GCC and clank.
And they are not compatible with each other.
You need to recompile your application once again.
Manually, of course, by parsing this profiles.
With additional bunch of compilers switches.
You need to figure out how to run LVM-bolt.
LVM-bolt internally has 289 switches.
And 100, I guess 150 are...
So a regular available.
You can just minus minus help.
And a rest of them.
You need to write something like minus minus hidden help.
And they will be available.
And even you will look through all of them.
You will not understand what does they mean and what we do.
So, of probably you figure out how to run both.
So, you need to instrument your binary once again.
It's both.
Somehow, you need to run your binary once again.
You need to collect both profiles.
They are not the same as Pidgeor profiles.
And finally, you need to optimize your binary of both.
All of these things are done only manually.
Only by you, you need to run scripts compared to this one.
It's all already automated.
It's all already automated by clever engineers from the RASDF team.
I would say RASDF is much, much simpler and more accessible to a regular developer.
I done both, both stuff.
And if you remember the table about Pidgeor table,
most of these applications, except for your libraries,
they are written in RASD.
Not because I'm a RASDZ,
because I've had a dedicated track for RASDF here.
But simply because it's so much easier can be done in RASD,
but I just don't want to waste my time with C++.
During the optimization routines, that's it.
Not because I just simply like RASD, but I like RASD.
So, not about issues is extra tooling.
Of course, people just don't know about Pidgeor tools.
The same issue is the documentation.
So, where we need to learn the documentation,
like official books or whatever they need to read it, we don't have time.
Tools are not easy to install for various RASDF reasons.
For example, no Pidgeor package in a repository.
For example, that was the case.
One year ago, I go for LVM Bolt.
I was suggesting an idea into different distributions.
The simple idea.
Please optimize Clank with LVM Bolt,
because it's already shown in a lot of conferences.
It really works.
I got exactly the same answer, I remember.
We don't have a package for LVM Bolt.
We don't care when we need to create a package.
So, sometimes, at that time, LVM Bolt wasn't LVM Bolt.
It was external tool, so they needed to compile it separately.
Create a package, et cetera, et cetera.
It's a maintainer overhead.
Luckily, right now, LVM Bolt is a part of LVM.
It can be built as a part of LVM.
And many all distributions have ready to use RASDF LVM,
and enable just another siege.
Now, easy way to build tool on your own.
For example, it's a really big program for Google Autofidio
and Google to stuff, because they need to specific LVM version.
They're not upstream, and if you'll try to build it as a LVM version,
of course there will be a lot of compilation errors.
We'll need to fix them.
No one can want to waste time here.
So, if even tools cannot help us in a good way,
maybe we'll try to change defaults in our ecosystem.
Okay, let's try.
So, if you'll be able to change defaults,
we will, we will, there is no need to read the documentation.
Install extra tools and whatever.
All recommended optimizations will be done by default.
For example, you just enable a release profile,
and instead of just up to level 3, up to level 2,
to LVM will be enabled by default,
and we will get a more optimized binary.
It's great.
However, there is a high room rule law.
So, if you have a lot of users,
and whatever you will try to change,
it will break some workloads, some scenarios.
And here we have exactly the same case.
Once again, Rustic Assistant is a good example here,
because we are trying to change defaults in a good way.
We are trying to push a more rapid linker
to optimize developer rigs, some benchmarks here.
And of course, we have even more quick linkers on the market.
But of course, we are not ready yet.
But we are already discussions, Rust,
team waiting for stabilizing wild linker or mild linker.
And we will try to switch from LLD to them,
because it gives more speed for us.
Rust, see and Rust analyze,
or like, claim this stuff, I already optimized this pjl
LLD by default.
Using a more optimized allocators for clip stuff,
like a clientize, trying to change,
very very carefully default release profile.
For example, strip debugging,
so binaries will be smaller,
because Rust binary is operating famous,
because since we are huge, by default.
However, in the Rustic Assistant,
we are asked some interesting defaults,
if not questionable.
One of the way, how regular Rust tools are installed,
it's a cargo install.
Cargo install with just,
again, to style installation way,
to take out your repository on your machine,
and compile it on your machine.
That's it.
No pre-built binary package,
whatever just from sources.
And of course,
and the SIG, again, to style installation.
Of course, you can optimize for your hardware,
but no one actually does it with cargo install.
And cons, you have much, much more limitations
in enabling expensive optimizations.
And here, there is a problem with LTO optimization,
because LTO optimization,
in the most aggressive,
it's form, full LTO.
VTLTO is really expensive.
It doubles your compilation time,
at least doubles,
and it requires much more memory.
Okay, okay,
1.5x to x independence,
depends on different flex.
So, if you will try to enable LTO by default,
for the release profile,
all cargo installed applications
will be installing twice time as before.
And it's a problem.
There are solutions to mitigate them,
just using cargo bin install with pre-built packages.
But unfortunately,
this solution is not that popular in the RASTEC system,
and it's not considered as a default.
Whereas,
the reason for that,
for example, cargo bin install is not maintained
by the main RASTEC team,
so credibility issues, etc., etc., etc.,
but it's a limitation.
Another example about defaults,
very dedicated tool for preparing the binary
for distributing cargo dist,
or right now it's called simple dist.
So, it's a tool that tries to pick
a good optimization optimization,
cargo switches for optimization of your binary.
However,
this tool enables not the most aggressive form of LTO,
and I was wondering,
what is the reason?
Because the final TOR,
it compiles much faster,
but the trade-off here,
is that the final TOR cannot perform
the most aggressive optimization,
and if we are trying to prepare a binary for delivering
for target machine,
usually we are trying to perform aggressive stuff.
And that was the reason, actually,
because a lot of simply,
on the other point of view,
a lot of build binaries,
build binaries for shipable binaries,
for distributing,
will not be shipped,
so they are not worth of optimizing.
Unfortunately,
this detail is not written as a documentation.
It's written only in a random comment
in the GitHub tracker,
and that's it.
And regular users don't know about this detail.
They simply,
and blindly apply cargo dist profile,
and that's it.
So, I just decided to test once again.
Probably,
cargo dist users will be okay.
This changing,
fine LTE war,
to fat LTE war,
or full LTE war,
in their profiles.
And as you see,
I have,
once again,
pretty good conversion rate here.
So,
I guess,
607 projects are accepted,
my changes,
and five,
five,
or four of them just didn't answer.
No,
no rejections.
No,
no,
it's all.
So, probably,
these defaults are not very good for users.
And we just don't know what we are enabling.
Let's see,
we are just simply following.
So,
I tried to push an idea
into the rough community about pushing LTE war
in any form,
actually,
to the default release mode.
Even if we are knowing about cargo install,
we are not,
we know stuff about,
not doubting compilation time,
if he knows your mode,
but more course on the CI,
and whatever.
Luckily,
we can enable LTE war in a much easier way
in the rough ecosystem,
compared to C++.
Because usually in C++,
enabling LTE war,
we will uncover a lot of hidden and defined behaviors.
And whatever,
we will meet a lot of interesting sick folds
in runtime of the enabling LTE war,
and we will disable it after that.
In Rust,
we don't have such a problem.
You can enable LTE war with one cargo command,
and this optimization is really safe in Rust,
compared to C++.
How dangerous is LTE in C++?
There is a great repository from gentle,
to LTE war,
and you can just see how many issues
there is in this repository,
and believe me,
all of them,
almost all of them,
are about blowing up some C or C++ code
from enabling LTE war.
Yes,
yes,
they are C++ victims.
In Rust,
we don't have such a big such an issue.
In C++ it's a huge issue.
However,
I met a bunch of additional issues.
Some people using cargo release profile
during their development phase on their local machines.
Even if you have documentation in cargo,
that release profile is meant for using on production.
We don't care.
We just don't care.
We are using release profile during the development phase,
and when we will try to point them,
just please don't do it.
We don't care.
We say,
that's okay for me.
That's it.
So,
one week ago,
where I was a topic,
when I read some,
subreddit,
about some of the messengers it's me.
This person created almost
five hundred issues manually,
on GitHub by,
about enabling LTE war in Rust projects.
So, the Rust community was wondering,
what is going on here?
So, that was my attempt
to convince Rust ecosystems in Rust dev team
that they are defaults,
are not that optimal,
and the Rust community are ready
to enable LTE of a very least profile.
So, unfortunately we have really,
we had really great conversation,
but finally I was banned,
not on Rust subreddit.
I was banned on Reddit.
So, I don't have an account anymore in Reddit,
but actually we had really good conversation.
We were raised some points,
good points in this conversation.
Fortunately, I wasn't able to answer all of them,
because I was banned.
So, sorry.
If someone didn't get an answer for me,
it's not my wish.
And so, I created more than 500,
that's only for us,
trust me, only for us projects,
more than 500 stuff,
and more than 300 and 50,
plus is closed.
Closed, unfortunately there is no filter,
to differentiate between closed,
accepted and closed, not planned.
But this statistics is public, you can check.
I would say 95% of closed issues are accepted,
out here, to the default release profile.
So, let's message to the Rust team.
Please reconsider your decision once again.
Probably we need to spend some more time here,
in an instigating and enabling out here for default.
And by the way,
I proposed only full out here.
It's the most aggressive one.
So, the most time consuming and resource consuming.
So, I wanted to test,
to test the border of acceptance from the project offers,
and the asset pretty well,
the trade-off,
because benefits from LTI war are so great,
performance, of course.
But you cannot measure performance for all projects,
because you need to implement benchmark full projects,
but you can easily measure binary size improvement,
and full LTI war gives 20% of binary size improvement,
just by one simple comment in the cargo-tombo file.
So, there are some LLM staff,
so when you try to enable,
of I was hardly switched off.
Okay.
So,
I'm fortunate the LLM is not that heavy,
if a full LTI war,
but Microsoft engineers say go away,
and that's it.
And I have actually much more ideas
to try to implement them,
like semi-automatic way,
to propose more efficient tools like grip,
something,
open the tables of performance challenges,
for different projects,
et cetera, et cetera,
like one beer,
sea-but-from-pants,
or stuff,
it could actually useful for anyone.
And I would say,
I want to collaborate with our
first-damn deaf rooms in different directions,
to compilers,
optimizing from different domains.
I want to hear your opinion about
software performance stuff,
and we can collaborate here
and exchange opinions,
trying to optimize something in different ways.
And actually,
that's it,
with all the reasons
that I've starting
awesome Pedro project,
awesome multi-all,
spin-off of awesome Pedro,
and with why I actually created
software performance dev room,
just to try to push as much as possible,
more optimizations,
much to the software,
and make them more accessible
to the regular developers.
Thank you.
If you have any questions,
you're a microphone.
You can say,
and I'll repeat.
Nobody's.
It seems to me that one would work
to make...
Hello.
So it seems to me that one way to make
this optimization more accessible
for C++ or C code
would be to integrate the settings
or build system,
something like CMAX.
So how difficult would that be
to add an option in CMAX to make life possible?
I will.
Yes.
I proposed all of these ideas
to the CMAX.
Where are open issues of that?
Of course.
No one is implemented.
Because it's difficult?
No.
Well,
I would say it will be more difficult
than for us,
because multiple build systems,
multiple compilers,
multiple dependency managers.
If you want to optimize the world three,
for example,
if Pedro,
you need to pass flags, etc.
It will be more difficult compared to us,
but it's achievable.
It's achievable.
And I know some people
that at least try and
implement it for CMAX.
But we have CMAX,
we have Basel,
we have Meazen,
we have...
We have a lot of stuff in C++.
And unfortunately,
there is no any major build system in C++.
You can see like poles
from official C++ committee
and CMAX will be like
one-third of the ecosystems,
only one-third.
Okay, thank you.
How does this apply to
we've talked now only about
real compiled languages without
any garbage collection or anything?
This is applied to the...
I'm talking about Pedro.
Yeah, Pedro, LTO,
LTO actually,
so let's say,
if you have an LVM-based compiler,
all of the stuff is already available
or easily implementable, I would say.
If you're talking about custom compilers,
you need to check the implementation.
Yeah, I'm talking about, let's say,
go or check here.
Go already supports Pedro.
Yeah,
we're supporting on the sampling Pidgeon mode,
but they know what they did.
So...
JPM rules?
Sorry?
The JPM world has just in time compilers,
it's the main model,
but if you want to ahead of time model,
where is Gralvem?
Gralvem supports Pidgeon,
but unfortunately,
it's insanely undocumented.
And they stopped answering my questions
in the upstream, after some point.
Okay, thank you.