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
BOLT was a Facebook research project that has since been merged into LLVM.
It is a post-link optimizer that optimizes the binary based on a profile, as the binary layout can have a certain influence on performance.
We could possibly try this out in the context of PHP - there are now more and more open source projects that use BOLT.
For example, rustc, the Rust compiler has implemented this in its CI pipeline (3-5% performance improvement).
There was also a blog article for Postgres. Even more performance was achieved there.
I could well imagine that BOLT would do PHP a lot of good.
However, BOLT is only supported for Linux binaries - whether Windows & *BSD support is coming is questionable.
What do you think? Should we try it out in the context of PHP?
For example, rustc, the Rust compiler has implemented this in its CI pipeline (3-5% performance improvement). There was also a blog article for Postgres. Even more performance was achieved there.
To note also binaries size increase noticeably (I do not know how much for rustc however I ve tried few times and for one the binaries were 5 times bigger while having also similar performance increase (< 5 %)).
@devnexen But is storage / binary size a big problem today?
The PHP interpreter is not really an application that runs very often on IoT devices where the storage is actually that relevant.
Personally, I would consider performance to be more important than binary size.
If there are significant differences in the binary size, we could consider whether it might make sense to publish a kind of “php-slim”.
But I think it might be worth trying BOLT and benchmark the performance differences.
Maybe not, but note that binary size can also hurt instruction cache. So, it's not a given that performance actually improves. It heavily depends on what code paths are hit. We already signal this to compilers using the __builtin_expect intrinsic. For many branches, this will depend on your individual PHP application. This poses the question: On what application(s) would we profile PHP? There is no good answer to this. So, if you'd like to make use of PGO (profile-guided optimization), you'll most likely need to profile and build PHP for your individual use-case.
So, I don't believe there's anything we should do here.
Also note that PHP for everything but Windows is compiled and distributed by distributions. So, this is not something we can decide anyway.
No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.
Activity
devnexen commentedon Oct 6, 2024
To note also binaries size increase noticeably (I do not know how much for rustc however I ve tried few times and for one the binaries were 5 times bigger while having also similar performance increase (< 5 %)).
NattyNarwhal commentedon Oct 6, 2024
We're not shipping binaries except for Windows, so I don't know what this would entail other than testing it in CI.
devnexen commentedon Oct 6, 2024
Sure... was just highlighting benefits vs costs.
deeprobin commentedon Oct 6, 2024
@devnexen But is storage / binary size a big problem today?
The PHP interpreter is not really an application that runs very often on IoT devices where the storage is actually that relevant.
Personally, I would consider performance to be more important than binary size.
If there are significant differences in the binary size, we could consider whether it might make sense to publish a kind of “php-slim”.
But I think it might be worth trying BOLT and benchmark the performance differences.
devnexen commentedon Oct 6, 2024
Oh I do not disagree
iluuu1994 commentedon Oct 7, 2024
Maybe not, but note that binary size can also hurt instruction cache. So, it's not a given that performance actually improves. It heavily depends on what code paths are hit. We already signal this to compilers using the
__builtin_expectintrinsic. For many branches, this will depend on your individual PHP application. This poses the question: On what application(s) would we profile PHP? There is no good answer to this. So, if you'd like to make use of PGO (profile-guided optimization), you'll most likely need to profile and build PHP for your individual use-case.So, I don't believe there's anything we should do here.
Also note that PHP for everything but Windows is compiled and distributed by distributions. So, this is not something we can decide anyway.
github-actions commentedon Oct 22, 2024
No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.