HipHop was the PHP -> C++ compiler. HHVM is a JIT-compiled implementation of PHP.
The 15% increase is relative to HHVM at the beginning of the 3-week sprint they just completed. HHVM was already far faster than vanilla PHP when it was first publicly announced over a year ago.
That's a good question. PHP 5.5 with the newly-open sourced (and integrated) opcache gave it a good run for its money before this optimisation sprint [1]. Under real-world 'bloated framework' usage, HHVM was already pretty cool [2]. I'd like to see the results after this speedup.
The Wikipedia article (https://en.wikipedia.org/wiki/HipHop_for_PHP) says "up to 6x", however, about 2x speedup versus plain PHP was a more typical experience for me when I used it before.
Me! Yeah, it's not 100% compatible, so my app runs all it's tests on HHVM to make sure I haven't run into any edge cases, which hasn't been an issue. I get more mileage out of my smallish VPS from it, with no effort on my part other than knowing what frameworks don't work (very very few now) and testing before deploying to staging (as you should be anyway).
I'm pretty happy with it. Is it worth it? Well, if you've got a test suite, run it through HHVM to see if you'll have any issues. If the answer is no, then why turn down free performance :)
I run HHVM on a website. I started in June (back then you had to write your config file from scratch and some API functions were missing). I refactored my code to PDO (mysqli was missing back then). It worked fine from the beginning, and the uptime and overall performance is really great.
It was about social network from spain. He provided a link to an article that talked about the old HpHp (HipHop C++ translator). I pointed it out, and then the guy deleted the comment entry, as it seems.
HipHop took PHP code and basically turned it into a statically compiled C++ application. The resulting binary acted directly as a web server. It was pretty fast, but very limited.
HHVM is an actual JITing virtual machine for PHP. It's still huge (one of the project pages say that the binaries are nearly a hundred megs), but it's now a real-world reimplementation of PHP, capable of doing anything PHP can, including eventually being run by mere mortals with normal code.
With the recent discussion on the origins of PHP function names, and about what, if anything, can be done to fix PHP without ruining it...I'm curious about what happens at Facebook. Besides HipHop, do they maintain a strict PHP style among their developers? Even if HipHop can handle all of PHPs variations, I imagine there's time saved by writing optimally-designed (for the human) code, too?
Code style is enforced (but overridable) by the code review system - both automated tools that provide feedback ("lint") on the code (things like "Don't use funcx() - it sucks <link here> - rather use funcy()"), and human code review.
Internally at my company, we've found https://github.com/scrutinizer-ci/php-analyzer to be very effective (after we made some hacks to support 5.5) and we can put it in our sniff pipeline in CI (a tad too slow for a pre-commit hook).
Poor choice of function names are the easiest of problems to fix. Write an internal base framework that you use and strongly discourage the use of functions outside of it. Even if the new set of APIs are as simple as just forwarding the call to the standard PHP one with reversed arguments, using one example people complain about all the time. This isn't hard to do, doesn't require a lot of upfront work (add APIs as you go) on a new project, and won't give you too much (if any) of a performance hit. You don't need to burn the house down because you don't like how the furniture is arranged.
PHP has so many more problems than that, though. I don't think it's worth the effort. It'd be like replacing the rotting floorboards of a house that has mold spores in every corner and a caved-in roof.
It does. COBOL also runs a large number of major banking and government infrastructures. Should we be working on a revision to COBOL with prettier syntax?
I don't hate PHP, but I've written, looked at, and audited enough of it to come to dislike it.
I'm actually a tad worried about what will happen to all the people who coded primarily PHP for their whole life when that roof finally collapses. Seems like it might look a bit like what happened with Symbian / Nokia -- they also had a massive cognitive dissonance over the quality of the developer environment, and when the system finally broke, it broke quickly and in a nasty way.
Then again, it's not impossible to learn a new environment or career path... and I'm quite against the thought that any language could permanently ruin a coder.
Additionally, something being popular implying it's good is a blatant fallacy.
Calling each and every criticism of the language you like as "frothing hatred" (as I've seen PHP folks do quite a lot lately) reeks of cognitive dissonance. Perhaps you should get over it.
Also, the end users of a programming language are the programmers, not the users of the application. 99% of users could not care less what's under the hood just as long as it works.
As someone who can't stand PHP, Laravel is pretty much the only thing that's made me feel like the language has some worth. It feels very similar to the Python and Ruby frameworks I'm used to, and is actually pretty nice to read.
Now if only the rest of the PHP devs stuck in 2005 would switch to it...
What does Laravel do that other frameworks like FuelPHP and Yii don't do? I hear a lot about it but don't hear a lot about why it's so much better than others.
On the surface most of the popular PHP frameworks are not much different from each other. Basic MVC separation, some sort of dependency injection container (actually a service locator), Composer and standardized autoloading, etc. Once you dig into the coding aesthetics then the differences start to become clear. Yii isn't PSR compliant, both FuelPHP and Laravel make liberal use of Facades and/or __callStatic to preserve the style of static function calls that are prevalent in CodeIgniter. I guess what makes Laravel stand out is the sheer amount of documentation and examples that are available, both on the website and in the code itself. This makes it really easy to get started.
Me, I'm not really keen on the Component::function() syntax. Feels like a crutch to me. Especially when people go out of their way to avoid specifying namespaces by abusing class_alias. Plus you're not really saving that many keystrokes compared to, say, $this->app['component']->function(). (Yes, I like Silex).
$this->app['component']->function() gives me an instant headache. Which is why I always wind up giving up on Symfony/Silex after trying it out every now and then.
OTOH, I had a much easier time with Laravel, though it uses some of the same Symfony components under the hood.
Laravel has a half decent API and doesn't rely overmuch on (untestable) static functions. My evaluation of FuelPHP was admittedly brief, but let's take another look:
For those who may be unaware, the issue with static functions is that, if you are calling a static method, you will execute that method. You're not able to choose not to execute that method (unless you do something surpassingly stupid like checking whether you're in test mode), and you can't generally make that method return anything other than what it normally does. Isolating that static method is rather difficult, and if that static method happens to call another one, well, it had better not be an issue with your test, because you're not going to stop it happening.
I know the FuelPHP devs have gone on record saying that Fuel doesn't rely heavily on static methods, and that static methods aren't a problem, and that to the degree to which there is a problem, they are gonna fix it, but...
Here we compare CakePHP, Laravel, and FuelPHP (Thank you to Sebastian Bergmann for providing the statistics utility). For anyone actually evaluating these platforms, you may want to check out these benchmarks as well:
Without saying anything about how easy or fast it would be to develop for each of them, it seems that for trivial tasks Laravel > Fuel > Cake. From the code statistics, we have:
Fuel: 785 static methods (22.45%)
Cake: 530 static methods (7.96%)
Yii: 483 static methods (7.95%)
Laravel: 0 (0.00%)
Laravel seems pretty light as far as that goes, and generally when I'm faced with a large project I want the framework to be large as well. I feel like otherwise I'm going to end up finding or writing libraries for things that I feel like the framework should take care of. I would have a hard time recommending a PHP framework, imo they're all pretty much crap. Laravel is not better per se than other frameworks, but it does (far) less, and therefore does it less badly. Divine intervention alone will fix the PHP world at this point, but if you can avoid CodeIgniter, Yii, and FuelPHP, probably no other choices will be as bad.
I tried it two days ago after they made the fastcgi announcement. My day job sites are fairly big with what I consider a pretty large number of contrib modules. I managed to get it up and running, but the HHVM logs were full of notices and it finally bombed out after several requests (not enough to really warm up the VM) on something related to apachesolr, and another one related to GD, which is strange because we use imagemagick, but whatever. Sad Trombone.
The really cool part though, it truly was "drop in". Every bit of my existing nginx/fpm configs worked as is, so once it's a bit further along, it's just a matter of shutting down fpm and firing up HHVM.
There were also a couple of gotchas in the setup related to the fact that their apt installer installed HHVM configs that don't assume Fastcgi, so it took a little bit to figure out the correct edits to the init script and HHVM config so it'd listen on :9000 instead of :80, but all in all that it worked at all was really fun for a minute. Very excited about this project.
* you need a little bit of basic Linux knowledge
* install Linux or BSD (e.g. Ubuntu 12.04 LTS) (64-bit)
* install Nginx (or since last week HHVM also supports Apache with FastCGI)
* install HHVM
* install MySQL or MariaDB, etc.
* create a web directory where you place your php files
* edit the hhvm.hdf (config file)
* start hhvm
Btw. a lot of blog posts you find with Google search are still about the old HpHp (the former and now outdated PHP to C++ translator also called HipHop from FB)... so better skip third party blog posts older than January 2013 ;)
I wonder how hard it would be (for me) to take php and change all function names to be consistent. All PascalCase and spelled out (no awful abbreviations). Then download the documentation and change it there as well.
Given that many of PHP's method names are that way due to mirroring C (and others due to the hash table hackery), I think you'd just be much happier in a different language.
You're misrepresenting his position pretty badly. XMLHttpRequest is a comprehensible name. "MysqlndUhConnection" much less so.
Not being very familiar with PHP, I don't have any pet examples of inconsistent names to offer corrections for that might correspond with what he's actually talking about.
...like everyone who has learned C or its derivatives. It's just part of the vocabulary of the language. You could as well ask "what's a list comprehension" in Python, for example.
Yes, for some time (the dark ages I like to think) programmers had to sacrifice productivity to make things faster, or to make them fit in memory. The original C compiler had a 6 character limit on variable names, leading to abominations like `strstr()`.
Fortunately, by the Pentium era, which was when PHP was designed, those times were long gone.
"X made this design decision before us" is never a good justification for any design decision unless the decision is truly arbitrary (i.e., are arrays 0 or 1 indexed?) -- then it might be better to stick to what's more familiar. If it was a good design decision then, then there must have been some reason at the time that should be true now to give a good case for repeating a design decision.
Well, so long as they don't fix the parsing of octal int literals that is okay. Loosing both of my favourite offhand complaints would be rather disappointing. ;)
You can write wrapper functions in a PHP script and include it your index.php.
e.g.
function findFirst ($haystack, $needle, $before_needle=false, case_sensitive=false) {
if (case_sensitive) {
return stristr($haystack, $needle, $before_needle);
}
return strstr($haystack, $needle, $before_needle);
}
You can submit them as RFC to https://wiki.php.net/rfc and maybe your suggestion end up in a future version of PHP. As PHP code in HHVM is almost as fast as C++ code, your wrapper functions will be still useful for you in the meantime.
On paper the lack of consistency is a problem. In reality your editor will autocomplete the function name and tell you its arguments, so it's really not that big of a deal. I mostly hear non-PHP programmers complain about it.
It wouldn't be that hard if you did it in userland (i.e. pure PHP). But you also need to switch around inconsistent parameter orders (e.g. haystack vs needle) and disable the use of the old ones (which can't really be done w/ the pure PHP aliases). The docs are just docbook, but have had a ton of work, you'd be best to PHPDoc your new methods.
The problem is speed and compatibility. If you did it natively you'd have to do it twice, once for HHVM and once for the Zend engine. If you did it in pure PHP it would cause performance issues since the interpreter isn't smart enough to inline (maybe HHVM is, but even it will take a trace or two to realize the JIT need probably).
Python scales quite fine actually (Disqus and YouTube use it for a majority of core development). It's all about the tech behind the scenes (uWSGI, Tornado, Ngnix, memcache/redis, etc), not the language itself (just as it is with PHP). Try scaling PHP if only using Apache Prefork instead of mod worker + php-fpm or Ngnix + php-fpm and you'll see what I mean.
I have no problem with using either PHP or Python on a particular project, depending on what is involved. I wish PHP threads would show a bit more maturity/pragmatism on both sides of the aisle sometimes.
Does anyone have an easy method of testing HHVM on your website?
I was thinking of recording the production requests for x amount of time and replaying them on HHVM so you could see if responses are identical, there are no crashes, state of the database is same afterwards, etc.?
Seriously though, I decided that if I had a project that was difficult to test, that I knew had hairy code that used some funky features it was best to just stick to APC. All my new projects are being built on HHVM directly with test suites as I go.
Edit; that was a while back now, though. What frameworks and libraries are you using? Run their test suites through HHVM and if they all pass, you'll be fine. Facebook use it themselves now apparently.
Another idea once you're reasonably comfortable and have done a smoke test is to direct a small amount of your traffic/users (say 1%) to the HHVM version, while closely monitoring its error log.
I'm not sure about the particulars of this one, but a lockdown is generally a period where you are encouraged to prune away unnecessary and/or lower-priority requests for your time.
There generally aren't a lot of status meetings, team meetings, project meetings, and so forth at Facebook, but you might want to turn down a request to present at another team's meeting, or turn down those requests to interview - they can wait, or another person can be found.
People tend to make progress on lower-priority work items in between higher-priority work items - things like migrating onto a new library or version of a service, or maybe migrating from one set of machines to another if you aren't using one of the high-level service management systems. This is necessary to prevent these things from becoming interrupt items down the line, but during a lockdown period, it's okay to let these slide for a bit.
If the whole team does this, then suddenly you're spending a lot more time together. Instead of potentially working on different parts of the software like you usually do, you can all focus on a particular class of problem - in this case, performance and parity. That means everyone has that context loaded up, and you can have better discussions and quicker code reviews.
It seems at the moment there's no way to have a DB server available when running tests. Is that correct? Until that happens, I don't imagine WP tests will be able to run.
I haven't looked into integrating with the test harness, but the test suite was pretty easy to get running locally. Unfortunately it crashes halfway through, but up until that point, the majority of the tests passed.
They mention the compatibility of the projects unit tests with their own testing so perhaps WordPress has some things in their test setup that didn't fit. They mentioned CakePHP as another example that wasn't included.
Is the 15% performance increase relative to vanilla PHP or to a previous version of HHVM?