Hello,
I've being reading about HHVM and the numbers are looking great but I was
just wondering if we will we ever see something like HHVM being added to
the PHP core?
Best regards
__
Raymond
Hello,
I've being reading about HHVM and the numbers are looking great but I was
just wondering if we will we ever see something like HHVM being added to
the PHP core?
No, not likely. Maybe an LLVM-based JIT one day, but the HHVM approach
is not something any of us are looking at.
-Rasmus
I've being reading about HHVM and the numbers are looking great but I was
just wondering if we will we ever see something like HHVM being added to
the PHP core?No, not likely. Maybe an LLVM-based JIT one day, but the HHVM approach
is not something any of us are looking at.
To echo Rasmus' reply: No.
HHVM is a reimplementation of the PHP language from the ground up, so
logically speaking "adding it to the PHP core" doesn't actually make
sense. They're different birds from the get-go.
PHP could adopt a similar strategy of translating bytecode to native
machine code (again echoing Rasmus' reply), but that would be a large
undertaking by itself, and adapting zval unions to static type
analysis is a whole other layer of complexity beyond that.
The important thing to keep in mind is what each implementation is
good at, and what it's not. As the maintainer of the OSS version of
HipHop (HHVM), I'll be the first to admit that the official PHP engine
and runtime have a broader range of platform/architecture support, and
stronger community, and a larger library of extensions and
functionality behind it. Also, because of it's lifecycle design, PHP
outperforms HHVM on single-run command-line scripts.
On the other hand, HHVM does outperform Apache+PHP for web requests
quite well. Facebook would need at least 5x as many web-servers (and
we use a lot as it is) if we were using normal PHP. That's not to say
PHP isn't fast, but interpreted bytecode using loose typing will never
keep pace with native machine code and strict typing.
Standard Disclaimer: Yes, front-end CPU time isn't the end-all be-all
of optimization. You should always start with your data access layer
and the efficiency of the scripts you write.
-Sara
P.S. - I do disagree with Rasmus' statement about none of us looking
at fitting a JIT into PHP. ;)
P.S. - I do disagree with Rasmus' statement about none of us looking
at fitting a JIT into PHP. ;)
I think you misread my reply. I specifically said that a JIT is a
possibility, just not the HH approach.
-Rasmus
P.S. - I do disagree with Rasmus' statement about none of us looking
at fitting a JIT into PHP. ;)I think you misread my reply. I specifically said that a JIT is a
possibility, just not the HH approach.
No no, I caught that. I was just being pedantic in that I am
looking at fitting a few JIT approaches into PHP (via extensions),
including one based on HipHop's approach. :p But if we're still being
pedantic, then I should admit to not working too hard on that front.
-Sara
Many thanks for the feedback.
I would love see some JIT features added to the core as this would help to
improve the overall performance.
Sara,
I like your extension idea as this would not require any changes to the
core.
Here's another idea:
- Modify PHP core to cache opcodes on first request
- Create external program (or library) that can be scheduled to compile
cached opcodes to native code when necessary. This can be scheduled as a
cron job - PHP will then run either the cached opcodes or the compiles codes when
the page is request a second time.
In this solution you get bets of both worlds. PHP can execute opcode cache
or native code if it's available. There would be no need for the core to
further compile or optimize the opcodes as the external program will
perform these operations. The end result is that the application
performance will improve with usage and time.
What do you think?
__
Raymond
On Mon, Nov 26, 2012 at 9:09 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:P.S. - I do disagree with Rasmus' statement about none of us looking
at fitting a JIT into PHP. ;)I think you misread my reply. I specifically said that a JIT is a
possibility, just not the HH approach.No no, I caught that. I was just being pedantic in that I am
looking at fitting a few JIT approaches into PHP (via extensions),
including one based on HipHop's approach. :p But if we're still being
pedantic, then I should admit to not working too hard on that front.-Sara
If you're so inclined to pursue it, you don't (technically) need to
modify PHP core at all.
- Make an extension which hooks zend_compile_file (just as APC and
many others do). - First request of a file passes through to the real compiler and
both returns main() opcodes and sends a copy of main() (and any new
classes/functions) to JITter. - Subsequent requests get ZEND_INTERNAL_(FUNCTION|CLASS) stubs
created for calling JIT code - RSHUTDOWN method explicitly cleans up ZEND_USER_(FUNCTION|CLASSe)s
and JIT-stub ZEND_INTERNAL_(FUNCTION|CLASSe)s since the default sweep
will get confused by the staggered function/class types.
Only hard part in there is the JIT itself, but that was never going to
be simple. :)
Many thanks for the feedback.
I would love see some JIT features added to the core as this would help to
improve the overall performance.Sara,
I like your extension idea as this would not require any changes to the
core.Here's another idea:
- Modify PHP core to cache opcodes on first request
- Create external program (or library) that can be scheduled to compile
cached opcodes to native code when necessary. This can be scheduled as a
cron job- PHP will then run either the cached opcodes or the compiles codes when
the page is request a second time.In this solution you get bets of both worlds. PHP can execute opcode cache
or native code if it's available. There would be no need for the core to
further compile or optimize the opcodes as the external program will perform
these operations. The end result is that the application performance will
improve with usage and time.What do you think?
__
RaymondOn Mon, Nov 26, 2012 at 9:09 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:P.S. - I do disagree with Rasmus' statement about none of us looking
at fitting a JIT into PHP. ;)I think you misread my reply. I specifically said that a JIT is a
possibility, just not the HH approach.No no, I caught that. I was just being pedantic in that I am
looking at fitting a few JIT approaches into PHP (via extensions),
including one based on HipHop's approach. :p But if we're still being
pedantic, then I should admit to not working too hard on that front.-Sara