> > The type checks in PHP7 is quite cheap (2-3 CPU instructions). Strict or
> > weak check doesn't make any difference for "fast path" (the same 2-3
> > instructions). The slow patch for weak checks is going to be a bit more
> > expensive.
>
> Well, not really. It's 2-3 CPU instructions once you have the
> instructions for dealing with ZVALs. The concept I'm talking is having
> the AOT compiler not know anything about a ZVAL (except perhaps at an
> FFI level). So yes, it's 2-3 CPU instructions to check type, but it's
> also a branch. It's also more memory and values to keep track of. It's
> far more code to generate.
>
This is code for week type check:
cmpb Z_TYPE_P(%edx), IS_LONG
je slow_path
L1:
addl Z_LVAL_P(%edx), %eax
....
slow_path:
movl %edx, (%esp)
call convert_to_long
jmp L1
This is code for strict type check:
cmpb Z_TYPE_P(%edx), IS_LONG
je slow_path
L1:
addl Z_LVAL_P(%edx), %eax
....
slow_path:
movl %edx, (%esp)
...
call zend_error
jmp L1 ; we still have to support E_RECOVERABLE, so we may return back
No big difference...
>
> >>
> >>
> >> In fact, the research I have been doing is precisely around that
> >> (where I know for a fact that all remaining function calls are going
> >> to be typed, and compile the entire block at one time with direct
> >> calls). So that way I never need to actually do even as much as a FCC
> >> to call a userland function. Which then lets me avoid generating
> >> typing code (since I know the types). Which is why I'm advocating for
> >> strict, since that way we can treat an entire graph of function calls
> >> as strict and compile them all in one go (no need to even JIT at
> >> runtime, just compile AOT).
> >>
> >> If your research has shown something different, care to share?
> >
> >
> > Very similar :), but in cases when we know the called function the effect
> > from type hinting is negligible. It's almost always possible to generate
> > optimal code without any hints.
>
> It's always possible to generate optimal PHP code. But I want to
> generate optimal ASM code. And for that, I need type guarantees.
>
Doesn't week type hint make the same guarantee as strong?
It just makes conversion on mismatch.
>
> > See code for fibo_r() from bench.php generated by our old JIT for PHP-5.5
> > (without type hinting):
> https://gist.github.com/dstogov/5f71d23f387332e9d77c
> >
> > Unfortunately, we didn't make the same for PHP7 yet.
> > More important, in our experiments we saw improvements only on small
> > benchmarks (e.g. 25 times on mandelbrot), but nothing on real-life apps.
> >
> > So a some point, looking into ASM code that endlessly allocates and frees
> > zvals, we switched to engine re-factoring.
>
> Which for generic code, is amazing. And I'm all for optimizing dynamic
> code. You're going to get an overall big gain doing that. I just see a
> bigger gain is possible given some preconditions, and would love to
> see them working together.
>
I'm looking forward as well :)
Just busy with other things now.
>
> >>
> >>
> >> > According to mandel() and integer to float conversion in the loop,
> it's
> >> > possible to perform a backward data-propagation pass to catch this
> case
> >> > and
> >> > replace integer by float in first place. We did it in our old JIT
> >> > prototypes
> >> > without any type hinting. Also, don't use "fild", use SSE2 and/or AVX.
> >>
> >> I did wind up doing a few passes to back-propagate the cast (among
> >> other optimizations). But it's still a point that the conversions
> >> aren't exactly cheap. But as I said before, that was a side-note and
> >> not really an argument for/against strict typing. So worth mentioning,
> >> but shouldn't affect anyone's decision.
> >>
> >> Re fild vs SSE/AVX: that was up to the backend code generator we were
> >> using (libjit). It may be an open req against that lib to generate the
> >> different instruction, or perhaps it just failed a heuristic. We were
> >> working a level higher than the generated ASM, so not really 100% sure
> >> why it made that decision.
> >
> >
> > I saw a big speed difference between FPU and SSE2/AVX code on bench.php,
> so
> > if you may tell libjit to use SSE2/AVX - do it.
>
> Yeah, I'm not sure it's worth it at this stage, but will definitely
> keep in mind.
>
> > Right, but it's not always possible to know the types at compile time,
> > and in this case hints may be helpful, however, strict and week hints
> give
> > exactly the same information - they guarantee the type of argument inside
> > the function.
>
> Well, yes. However it also means that inside the function dynamic
> types (variables that change type) are fine, and you need to implement
> the conversion logic. Therefore you need to implement ZVAL
> abstractions in the compiler. Something I really want to avoid, as it
> exponentially raises the complexity that you need to handle.
>
We had different goals and may misunderstand each other.
We tried to make 100% transparent JIT for PHP that would able to run any
code.
Thanks. Dmitry.
> > Why do you need to generate conversion logic, why can't you call
> > Zend API functions ?
>
> We definitely can. However there are 2 problems with that. First the
> compiler must know and use the ZVAL abstraction (including the
> possibility of type change). The second is that we need to support the
> error mechanisms and the generated code needs to be aware of the
> engine state (for example, to implement try/catch, etc). Definitely
> possible, but also greatly increases complexity... Strict typing makes
> those cases compile-time errors, and therefore we don't need to handle
> it at all in the generated code.
>
> Thanks
>
> Anthony
>
