HippyVM
hippyvm.com
hippyvm.com
As a PHP perf guy for serveral years, I have some weird questions to ask.
Is this an HTTP serving language VM or just a PHP as a language VM?
Because I spent years fixing the first part without ever really doing anything about the second part of that question.
If it can't listen on port 80, my interest drops a lot in the new VM - I'm not going to write scipy/numba.py problems in PHP, even if I could.
Am I missing something?
Much like WSGI in the Python world?
Sorry, couldn't help noticing, serveral years... :)
RTFA
I wrote about the PHPippo PHP preprocessor a few hours ago, though it went through HN unnoticed (so far): https://news.ycombinator.com/item?id=7861616
With languages like Python and Ruby, not to mention Java, a single interpreter process or thread can handle many requests and can re-use the database connection. In PHP, you're forced to do all the set-up all over again for every request. This is particularly wasteful with frameworks like Laravel, which do a non-trivial amount of work for setting up the application object, IoC controller.
Am I missing something here? I can't believe companies using PHP on a larger scale, like Facebook, discard and re-create the application environment and all DB connections (!) for every single request.
Further, I think PHP's request model is a good thing. It makes web programming easier and makes PHP resistant against memory leaks.
"Trim that fat"
The "fat" is something which is useful to a lot of people for development, it's just a performance hindrance (and far moreso than in other platforms).
That said, I've had some Java folks express some amazement at how fast PHP is, even when it's doing all the library loading and class instantiation on every page request. In multiple cases, they all expressed that they thought it would be far far slower, having grown used to "object creation is slow" in Java.
Facebook does recreate the state on every request, but they've got that down to a 10 ms bootstrap. In my own web services the bootstrapping before the business logic runs is below 20 ms. Most PHP frameworks load too much code up front though, which is why you'll see much worse request bootstrap performance in many cases.
The big benefit of request isolation is predictability. You know exactly what environment your code runs in because you construct it from scratch for every request.
And I thought this was the very "problem" that drove people away from CGIs back in the day.
The web service wrapper on the server has been cut down to the essence and does not use autoloading for the basic bootstrap. I've found that the PSR approach of a gazillion files each containing a small class and liberal use of autoloading is inherently slow, it is death by a thousand paper cuts due to the high degree of file access, memory consumption and running of all that constructor code. The code i write typically groups a web service in a handful of files, each containing a namespace with the bulk of the implementation in procedural logic (though i do use closures quite a bit). I typically use classes / objects only as types that encapsulate data, with the logic on the object limited to that logic which is necessary for working with that type (e.g. I don't put a save method on an object but instead write a saveObject function which accepts the object as a parameter and passes back an array of errors).
I suppose a lot of people nowadays find that sort of coding style blasphemous, but it is easy to write, test and maintain, and fast to execute. I'm not against the heavy OO approach common in most web dev nowadays, there are times when i do use it and need it. But CRUD web services are very linear: validate the input, create a transaction, run a bunch of db operations, commit or roll back, and return status / errors. If something is linear, i prefer to see it implemented in a cohesive linear procedural style, instead of getting chopped up into lots of objects that in practice end up obfuscating what's happening.
The way of initializing and validating data objects is quite similar to the approach we have in our production code. The missing part is the web service layer that maps the type definitions to a service description (i use reflection of phpdoc comments on a web service class to generate json and soap bindings, similar to the reflection approach in that github project).
I've been meaning to pick it back up and implement both the web service and db layers to make it an all-purpose web dev framework, but i've had other side projects intervene.
I suppose it's better off for the world if shitty languages are at least fast. Because I probably use something every day that depends on their performance :\.
(Made a small PR to it today)
Performance is meaningless if your VM can't run people's code.
Not sure how many of those they are actually passing though. https://github.com/hippyvm/hippyvm/tree/master/test_phpt/Zen...
Technical side-note: /Zend there appears to be just the tests for the Zend engine (i.e. from PHP's /Zend/tests), while the containing directory contains test folders copied from other parts of PHP (like the standard library)
Overview of PHP_5_5
Build Status: OK Last Build Time: 2 days
Compile Warnings: 611 Code Coverage: 0.3% Test Failures: 78 Expected Test Failures: 42 Valgrind Reports: 44
The "Expected Test Failures" is fascinating. http://gcov.php.net/viewer.php?version=PHP_5_5&func=expected...
We working hard to be as close to Zend as possible, though we are not there yet. You can try "translate" and run HippyVM against php-src suite.
"Basic" PHP compatibility was achieved which means that most of the syntax and stdlib from recent PHP is there. What we are doing right now is implementing modules (phar, fcgi, ...)
edit: I mean, is there a reason HHVM and HippyVM both use the word "Hip"?
They mention interop with Python code, but I was just wondering if this could go a bit further...
Though our current problem is which we are trying to fix is ,we have two repos: public and private. We are hopping to solve this soon, and move development to github. Sorry for the confusion.
Also: Look like it have a debugger! That is something I was looking how do. Plus, bytecode (look clean) too.
RPython could output to ARM?
Huh? Isn't that what HipHop is? Can someone elaborate on the matter? Is this a fork? Why aren't they just migrating their work back to HipHop, I mean all this leads to is fragmentation.
So it'll take some time I guess. Still nice to see people trying, Ruby is a great language but it needs as much love as possible.
Really sad state of affairs and the #1 reason why Ruby isn't faster and more feature-packed.
http://crystal-lang.org/ (not quite Ruby)
Combine all those working on those open source frameworks for years and all together create something fast...
I mean, sure, it's impressive that this VM is 7 times faster than stock PHP, but Java is over 100 times faster than stock PHP.
What is the gain here? Not having to go out of you little shell and learn a new language?
This is not about pleasing the bedroom programmer that can just "go out of his little shell and learn a new language". This is great news for any decent sized project or enterprise with infrastructure already running in PHP.
So as I said I've been doing PHP. And I have yet to see one of those unicorns in PHP-land. In fact, my first gut reaction was that you're being sarcastic up there.
If you already know PHP you should really check out frameworks like Symfony and Laravel (and Symfony Components, amazing reusable pieces to grow your own stuff). Also great tools like Composer for dependency management, PHPUnit, Behat, PHPSpec or Codeception for TDD/BDD. Same with ORMs like Doctrine or the Twig templating engine.
PHP has evolved greatly in the last years. There are tools for most of your needs and you can build stable and robust applications with them, and be excited about the future now that we are seeing efforts like HHVM or HippyVM, or even the internal changes being discussed for PHP 6.
You don't need a new "better" language to make new better products. PHP allows you to write perfectly nice, object oriented, clean code, no problem at all, that integrates easily with proven technologies. It also allows you to write a mess impossible to maintain. If somebody does the later when they can do the former with no extra effort, well, then maybe it's fair to question if that person is a good programmer at all.
The reason most of the PHP code is crap is not because PHP makes it impossible, but because a popular crap language with a low initial learning curve tends to attract a lot of crap programmers.
I'd actually say PHP has only gotten better over time, and every new release is better than the previous one. But you have a crap base (which PHP maintains religiously as not to break BC), and a crap community, and the software they write is crap. It's just what it is. The odd exception here and there.
You can overcome a horrible language, but that's not the problem (plus I'd argue PHP isn't the worst out there).
No, it's the crappy community around it. It's hard to overcome the horrible low quality PHP code libraries people write in PHP, because writing everything from scratch isn't practical in any language these days.
Composer is great and all (except for the lack of package signing, hey, who needs security, right?), but all Composer means you can install other people's PHP crap code more conveniently.
And while I wouldn't call the people behind Symfony "crap programmers", that framework is horribly overdesigned, slow, and comprised of an endless Inception of leaky abstractions.
It shows that a programmer can take all their experience and knowledge of design patterns, best practices and what not, and write a complete piece of turd.
Anyway I better run, because the modding of my posts here is showing I've angered the PHP fans.