On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:
Dmitry,
Hi Anthony,
If you are working on JIT, you should understand that declare() switch to
strict typing can't improve anything, because it works on caller side
and in
each function you now will have to generate code for both weak and strict
checks.Well, if you know the destination function at compile time, you don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).
Right, but in real life app you almost never know what function or method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function placed
into a single PHP file.
In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).
For cases when you know the called function and all passed and expected
types, it's possible to use more efficient calling convention passing real
arguments in CPU registers.
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.
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.
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.
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.
Thanks. Dmitry.
Anthony
Morning,
I'm not sure where this conversation started ...
where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).
Why do you need to generate conversion logic, why can't you call Zend API
functions ?
Alternatively, possibly preferably, wouldn't a guard to tell if the
function is being called in strict mode
be a good idea here ?
If the generated code is really complicated and that sucks away the
performance
then why not just avoid it, and only enter machine code when a function is
called in strict mode ?
I see the assembly generated by your JIT, but it doesn't really tell us
much, it tells us a little,
what would be really useful is seeing your research, with the understanding
that it is just research.
Please think about that again.
Cheers
Joe
On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:Dmitry,
Hi Anthony,
If you are working on JIT, you should understand that declare() switch
to
strict typing can't improve anything, because it works on caller side
and in
each function you now will have to generate code for both weak and
strict
checks.Well, if you know the destination function at compile time, you don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).Right, but in real life app you almost never know what function or method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function placed
into a single PHP file.In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).For cases when you know the called function and all passed and expected
types, it's possible to use more efficient calling convention passing real
arguments in CPU registers.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.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.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/5f71d23f387332e9d77cUnfortunately, 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.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.Thanks. Dmitry.
Anthony
Morning,
I'm not sure where this conversation started ...
it's a fork from "Salar Type Hints"...
where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).Why do you need to generate conversion logic, why can't you call Zend API
functions ?
Even VM just calls a conversion function.
Alternatively, possibly preferably, wouldn't a guard to tell if the
function is being called in strict mode
be a good idea here ?
If we know what function is called in strict mode, we must already know
where it's called from, so we should also know the types of passed
arguments, then we may eliminate checks at all (independently on
strictness). If we don't know the types we will need to check them anyway.
If the generated code is really complicated and that sucks away the
performance
then why not just avoid it, and only enter machine code when a function is
called in strict mode ?I see the assembly generated by your JIT, but it doesn't really tell us
much, it tells us a little,
what would be really useful is seeing your research, with the
understanding that it is just research.
Please think about that again.
Yeah, we will need to open it, even if it doesn't make gain for real life.
but lets make all the PHP7 related work first.
I would be glad, if later we'll combine our experience and work on JIT/AOT
together.
Thanks. Dmitry.
Cheers
JoeOn Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:Dmitry,
Hi Anthony,
If you are working on JIT, you should understand that declare()
switch to
strict typing can't improve anything, because it works on caller side
and in
each function you now will have to generate code for both weak and
strict
checks.Well, if you know the destination function at compile time, you don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).Right, but in real life app you almost never know what function or method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function
placed
into a single PHP file.In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).For cases when you know the called function and all passed and expected
types, it's possible to use more efficient calling convention passing real
arguments in CPU registers.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.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.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/5f71d23f387332e9d77cUnfortunately, 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.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.Thanks. Dmitry.
Anthony
I guess we can gave a try. PHP 7 is fine well enough. let's working
hard to make it published.
The talk about other things should be early . let's see PHP 7 released
and see how it will change our world.
Code it , ship it. Let's see the result.
Appreciate your time.
Netroby
2015-02-16 15:32 GMT+08:00 Dmitry Stogov dmitry@zend.com:
Morning,
I'm not sure where this conversation started ...
it's a fork from "Salar Type Hints"...
where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).Why do you need to generate conversion logic, why can't you call Zend API
functions ?Even VM just calls a conversion function.
Alternatively, possibly preferably, wouldn't a guard to tell if the
function is being called in strict mode
be a good idea here ?If we know what function is called in strict mode, we must already know
where it's called from, so we should also know the types of passed
arguments, then we may eliminate checks at all (independently on
strictness). If we don't know the types we will need to check them anyway.If the generated code is really complicated and that sucks away the
performance
then why not just avoid it, and only enter machine code when a function is
called in strict mode ?I see the assembly generated by your JIT, but it doesn't really tell us
much, it tells us a little,
what would be really useful is seeing your research, with the
understanding that it is just research.
Please think about that again.Yeah, we will need to open it, even if it doesn't make gain for real life.
but lets make all the PHP7 related work first.
I would be glad, if later we'll combine our experience and work on JIT/AOT
together.Thanks. Dmitry.
Cheers
JoeOn Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:Dmitry,
Hi Anthony,
If you are working on JIT, you should understand that declare()
switch to
strict typing can't improve anything, because it works on caller side
and in
each function you now will have to generate code for both weak and
strict
checks.Well, if you know the destination function at compile time, you don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).Right, but in real life app you almost never know what function or method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function
placed
into a single PHP file.In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).For cases when you know the called function and all passed and expected
types, it's possible to use more efficient calling convention passing real
arguments in CPU registers.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.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.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/5f71d23f387332e9d77cUnfortunately, 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.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.Thanks. Dmitry.
Anthony
It's Monday morning, maybe I'm misunderstanding ...
we must already know where it's called from, so we should also know the
types of passed arguments, then we may eliminate checks at all
We'll always know the types of arguments at the call site surely ? It's
knowing the types at the location being called that is important,
and needed in order to eliminate checks, isn't it ?
Cheers
Joe
I guess we can gave a try. PHP 7 is fine well enough. let's working
hard to make it published.The talk about other things should be early . let's see PHP 7 released
and see how it will change our world.Code it , ship it. Let's see the result.
Appreciate your time.
Netroby
2015-02-16 15:32 GMT+08:00 Dmitry Stogov dmitry@zend.com:
On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins pthreads@pthreads.org
wrote:Morning,
I'm not sure where this conversation started ...
it's a fork from "Salar Type Hints"...
where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).Why do you need to generate conversion logic, why can't you call Zend
API
functions ?Even VM just calls a conversion function.
Alternatively, possibly preferably, wouldn't a guard to tell if the
function is being called in strict mode
be a good idea here ?If we know what function is called in strict mode, we must already know
where it's called from, so we should also know the types of passed
arguments, then we may eliminate checks at all (independently on
strictness). If we don't know the types we will need to check them
anyway.If the generated code is really complicated and that sucks away the
performance
then why not just avoid it, and only enter machine code when a function
is
called in strict mode ?I see the assembly generated by your JIT, but it doesn't really tell us
much, it tells us a little,
what would be really useful is seeing your research, with the
understanding that it is just research.
Please think about that again.Yeah, we will need to open it, even if it doesn't make gain for real
life.
but lets make all the PHP7 related work first.
I would be glad, if later we'll combine our experience and work on
JIT/AOT
together.Thanks. Dmitry.
Cheers
JoeOn Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara <ircmaxell@gmail.com
wrote:
Dmitry,
On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov dmitry@zend.com
wrote:Hi Anthony,
If you are working on JIT, you should understand that declare()
switch to
strict typing can't improve anything, because it works on caller
side
and in
each function you now will have to generate code for both weak and
strict
checks.Well, if you know the destination function at compile time, you don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).Right, but in real life app you almost never know what function or
method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function
placed
into a single PHP file.In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).For cases when you know the called function and all passed and expected
types, it's possible to use more efficient calling convention passing
real
arguments in CPU registers.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.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.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/5f71d23f387332e9d77cUnfortunately, 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.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.Thanks. Dmitry.
Anthony
I would be glad, if later we'll combine our experience and work on
JIT/AOT together.
This is obviously something I look forward too :)
Cheers
Joe
It's Monday morning, maybe I'm misunderstanding ...
we must already know where it's called from, so we should also know the
types of passed arguments, then we may eliminate checks at allWe'll always know the types of arguments at the call site surely ? It's
knowing the types at the location being called that is important,
and needed in order to eliminate checks, isn't it ?Cheers
JoeI guess we can gave a try. PHP 7 is fine well enough. let's working
hard to make it published.The talk about other things should be early . let's see PHP 7 released
and see how it will change our world.Code it , ship it. Let's see the result.
Appreciate your time.
Netroby
2015-02-16 15:32 GMT+08:00 Dmitry Stogov dmitry@zend.com:
On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins pthreads@pthreads.org
wrote:Morning,
I'm not sure where this conversation started ...
it's a fork from "Salar Type Hints"...
where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).Why do you need to generate conversion logic, why can't you call Zend
API
functions ?Even VM just calls a conversion function.
Alternatively, possibly preferably, wouldn't a guard to tell if the
function is being called in strict mode
be a good idea here ?If we know what function is called in strict mode, we must already know
where it's called from, so we should also know the types of passed
arguments, then we may eliminate checks at all (independently on
strictness). If we don't know the types we will need to check them
anyway.If the generated code is really complicated and that sucks away the
performance
then why not just avoid it, and only enter machine code when a
function is
called in strict mode ?I see the assembly generated by your JIT, but it doesn't really tell us
much, it tells us a little,
what would be really useful is seeing your research, with the
understanding that it is just research.
Please think about that again.Yeah, we will need to open it, even if it doesn't make gain for real
life.
but lets make all the PHP7 related work first.
I would be glad, if later we'll combine our experience and work on
JIT/AOT
together.Thanks. Dmitry.
Cheers
JoeOn Mon, Feb 16, 2015 at 6:59 AM, Dmitry Stogov dmitry@zend.com
wrote:On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara <
ircmaxell@gmail.com>
wrote:Dmitry,
On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov dmitry@zend.com
wrote:Hi Anthony,
If you are working on JIT, you should understand that declare()
switch to
strict typing can't improve anything, because it works on caller
side
and in
each function you now will have to generate code for both weak and
strict
checks.Well, if you know the destination function at compile time, you
don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).Right, but in real life app you almost never know what function or
method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function
placed
into a single PHP file.In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion
logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the
generating
code).For cases when you know the called function and all passed and
expected
types, it's possible to use more efficient calling convention passing
real
arguments in CPU registers.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.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.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/5f71d23f387332e9d77cUnfortunately, 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.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.Thanks. Dmitry.
Anthony
It's Monday morning, maybe I'm misunderstanding ...
may be I'm too :)
we must already know where it's called from, so we should also know the
types of passed arguments, then we may eliminate checks at allWe'll always know the types of arguments at the call site surely ?
not always. For "foo(bar())" the type of argument passed to foo() may be
unknown at compile-time, similar to foo($a[0]) or foo($a->prop).
It's knowing the types at the location being called that is important,
and needed in order to eliminate checks, isn't it ?
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.
Thanks. Dmitry.
Cheers
JoeI guess we can gave a try. PHP 7 is fine well enough. let's working
hard to make it published.The talk about other things should be early . let's see PHP 7 released
and see how it will change our world.Code it , ship it. Let's see the result.
Appreciate your time.
Netroby
2015-02-16 15:32 GMT+08:00 Dmitry Stogov dmitry@zend.com:
On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins pthreads@pthreads.org
wrote:Morning,
I'm not sure where this conversation started ...
it's a fork from "Salar Type Hints"...
where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).Why do you need to generate conversion logic, why can't you call Zend
API
functions ?Even VM just calls a conversion function.
Alternatively, possibly preferably, wouldn't a guard to tell if the
function is being called in strict mode
be a good idea here ?If we know what function is called in strict mode, we must already know
where it's called from, so we should also know the types of passed
arguments, then we may eliminate checks at all (independently on
strictness). If we don't know the types we will need to check them
anyway.If the generated code is really complicated and that sucks away the
performance
then why not just avoid it, and only enter machine code when a
function is
called in strict mode ?I see the assembly generated by your JIT, but it doesn't really tell us
much, it tells us a little,
what would be really useful is seeing your research, with the
understanding that it is just research.
Please think about that again.Yeah, we will need to open it, even if it doesn't make gain for real
life.
but lets make all the PHP7 related work first.
I would be glad, if later we'll combine our experience and work on
JIT/AOT
together.Thanks. Dmitry.
Cheers
JoeOn Mon, Feb 16, 2015 at 6:59 AM, Dmitry Stogov dmitry@zend.com
wrote:On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara <
ircmaxell@gmail.com>
wrote:Dmitry,
On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov dmitry@zend.com
wrote:Hi Anthony,
If you are working on JIT, you should understand that declare()
switch to
strict typing can't improve anything, because it works on caller
side
and in
each function you now will have to generate code for both weak and
strict
checks.Well, if you know the destination function at compile time, you
don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).Right, but in real life app you almost never know what function or
method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function
placed
into a single PHP file.In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion
logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the
generating
code).For cases when you know the called function and all passed and
expected
types, it's possible to use more efficient calling convention passing
real
arguments in CPU registers.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.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.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/5f71d23f387332e9d77cUnfortunately, 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.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.Thanks. Dmitry.
Anthony
Dmitry and Joe,
On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:Well, if you know the destination function at compile time, you don't
need to generate generic code. you can generate a direct dispatch
(asm-level function call).Right, but in real life app you almost never know what function or method
you are really call. At function you also can't be sure that it always
called with proper arguments. This work well only for plain function placed
into a single PHP file.
I'm not talking about compiling an entire real-life application. I'm
talking about compiling hot-corners. For an application like WP, that
may not be possible. But with some light refactoring it may definitely
be possible with a large portion of applications.
The reason I'm talking about that instead of a generic compiler is
that the simpler the intermediary form (the more we can assume and
throw away) the more aggressive the optimizations can become. In the
long run, I can see a highly optimizing AOT compiler living along side
of a local/tracing JIT compiler. The JIT would handle more dynamic
code.
In this case, strict lets you push type
checks back to compile time, where in non-strict mode you still need
to generation runtime conversion logic. That runtime conversion logic
then requires the ability to hook into Zend's error handling
mechanism, vastly complicating the generated code (and the generating
code).For cases when you know the called function and all passed and expected
types, it's possible to use more efficient calling convention passing real
arguments in CPU registers.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.
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.
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/5f71d23f387332e9d77cUnfortunately, 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.
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.
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
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/5f71d23f387332e9d77cUnfortunately, 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
Dmitry,
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_pathL1:
addl Z_LVAL_P(%edx), %eax....
slow_path:
movl %edx, (%esp)
call convert_to_long
jmp L1This is code for strict type check:
cmpb Z_TYPE_P(%edx), IS_LONG je slow_pathL1:
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 backNo big difference...
The code I'm talking about generating is:
addl %edx %eax
No jumps, no type extraction, because it happened at compile time (and
strict lets us do that since we can determine types 100% at compile
time since dynamic types become errors).
So it's a significant difference (1 less conditional jump, 1 less
unconditional jump, 1 less comparison, a number less operations, etc).
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.
No, because I still need to promote back up to ZVAL before calling
another function (since the type conversion is allowed). Therefore I
cant error on type conversion, I need to generate the code to handle
it.
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/5f71d23f387332e9d77cUnfortunately, 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.
I think the high-level goals are the same, but yes, the low level
goals are very different. I see we compliment each other rather than
oppose. Which is why I am excited by it :-).
Thanks for the discussion :-)
Anthony
On Mon, Feb 16, 2015 at 5:21 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:
Dmitry,
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_pathL1:
addl Z_LVAL_P(%edx), %eax....
slow_path:
movl %edx, (%esp)
call convert_to_long
jmp L1This is code for strict type check:
cmpb Z_TYPE_P(%edx), IS_LONG je slow_pathL1:
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
backNo big difference...
The code I'm talking about generating is:
addl %edx %eax
No jumps, no type extraction, because it happened at compile time (and
strict lets us do that since we can determine types 100% at compile
time since dynamic types become errors).
So it's a significant difference (1 less conditional jump, 1 less
unconditional jump, 1 less comparison, a number less operations, etc).
If we know the type at compile-time we don't check it as well.
If you don't know it at compile-time you have to check it at run-time to
catch the error.
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.No, because I still need to promote back up to ZVAL before calling
another function (since the type conversion is allowed). Therefore I
cant error on type conversion, I need to generate the code to handle
it.
I see the difference now, but your approach won't work for all cases (like
call through zend_call_user_func).
It should be explained again by a bit different goals.
Thanks. Dmitry.
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/5f71d23f387332e9d77cUnfortunately, 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.I think the high-level goals are the same, but yes, the low level
goals are very different. I see we compliment each other rather than
oppose. Which is why I am excited by it :-).Thanks for the discussion :-)
Anthony