maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Axel Schwenke <axel@xxxxxxxxxxxx> writes:

> Wow. 25% is a lot. Have you also tried compiling MySQL 5.6 with PGO?

No.

> Because if that gets the same improvement, we haven't won anything in the
> comparison.

On the contrary, if the same works for MySQL 5.6 (and it seems likely it
will), then we have won double - both users on MariaDB _and_ users on MySQL
5.6 will benefit from increased performance.

(I know what you mean, of course, but seriously - the goal is to improve
performance for as many users as possible, not to "win" in some marketing
stunt. For me, it is.)

> This is interesting. By definition, PGO should work best if the workload
> used for profiling matches the production workload. I hadn't expected that a
> partial match gives such good results too.
>
> This is something that needs more tests.

Agree that more tests would be good. Even if the workload is not identical,
there should be many common code paths, which would explain that there is
still some improvement. If PGO would increase only one particular workload and
slow down the rest, then it would be unattractive. My tests so far seem to
show that this is not the case, but more testing would be good.

> Yes, I'll certainly do that.

Cool. Let me know if you need any help - hopefully the procedure I wrote in
the earlier mail will work for you. Note that currently, the gen_profile_load
program needs the build directory to be a directory inside the source
directory, IIRC (eg. mariadb-10.0/build/).

> Speaking of regressions - if we plan to deliver
> binaries built with PGO, we must also test the influence of different
> architectures. I.e. how behaves a binary built on Intel when being run on AMD.

Hm, yes it would be good to test, but do you expect any issues here? I did not
use any cpu-specific options, and the profiling output should be independent
of the underlying cpu, I think?

 - Kristian.