>> 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. ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
