Hi Derick, On Fri, Sep 15, 2023 at 5:35 PM Derick Rethans <der...@php.net> wrote:
> I think this is great work. It looks like the new JIT-IR approach is > more suitable. I have however concerns with a few things here. > > This is a lot of new code, that very few other people understand in > great detail. > > I think it is unwise if we have another large part of the engine that > does not have enough people understanding enough of it, to be able to > debug issues, and contribute to its continued development. > The IR Framework project is going to be developed separately from PHP. Ideally this project will involve compiler experts from different areas. I'm doing my best in this direction. > As such, I don't think this should just be merged, without a > comprehensive document explaining what it is, how it works, what pitfalls > there are, etc. In the mid of October I'll speak about IR at a Java related conference. Then I'll make available a presentation that explains many internals of the IR Framework. > The natural process that we have for PHP would be to > create an RFC. > I'm not sure. The PR just adds a different way to generate native code. Instead of existing ``zend_jit_x86.dasc`` and ``zend_jit_arm64.dasc`` where we had to write assembler code manually, now we have a single ``zend_jit_ir.c`` where we have to construct the IR graph. Disassembler, Linux perf interface and other low-level JIT details were also moved to JIT framework. So, actually the PHP part becomes even simple. > An RFC should also include a user-facing API on how to configure, and > enable, the JIT and its optimisations, as our current implementation > it is not the most convenient for users. > Nothing has changed. The new JIT is a completely self-containing replacement. Only few new ``opcache.jit_debug`` options that may show the IR. I understand that working on an RFC for such a complex issue is going to > take time, but that also gives to opportunity to pair with somebody, > who, while writing it, will also learn how it works. That would also > ready improve the debugging/contributing issues. > IR documentation could be a good addition and it's going to be created soon or later. I don't think it's a blocker, because the IR APIs are quite simple and intuitive. Just two public C headers https://github.com/dstogov/ir/blob/master/ir.h and https://github.com/dstogov/ir/blob/master/ir_builder.h Separately, I am not sure why your PR couldn't just replace the JIT that > we already have? It would IMO not make sense to have two different ones > at the same time. > This is a question. I decided to keep the old JIT to have an ability to quickly switch back in case of big problems. On the other hand we will be able to revert to PHP-8.3. > Furthermore, I am curious as if you have already done some benchmarks. I > am curious to learn how well it makes non-benchmark code run faster. > This doesn't improve the speed of the real apps yet. bench.php is 5-10% faster. Thanks. Dmitry.
