Yay! I'm so excited to use the `async` methods in production with MySQL. The biggest bottleneck for our PHP apps can now have a workaround in some cases, that's brilliant.
> Integration of LLVM as a further optimization step to make the hottest code run even faster on HHVM.
These multistage JITs are absolutely fascinating, I believe Safari is doing something similar with Javascript. Intuitively I would've assumed the overhead of firing up yet another JIT and VM to run it on would make it not worth it, but I guess the instructions currently generated are so far off optimal that it is worth doing.
EDIT: Anyone know of any papers regarding multi-stage JITs that I can check out?
The async support you linked, while useful, isn't really the same thing. It requires explicit, manual coordination between different parts of the code that want to fetch data. You're responsible yourself for batching fetches, polling, and running other code until the results are returned.
With Hack's async support, the runtime manages all of this for you. You call "await $query", and then your function is suspended until the data is available. Other code automatically runs until it too hits an await statement -- which might block it on MySQL, memcache, curl, or anything else, with no extra manual coordination needed. The runtime manages it all for you.
http://hhvm.com/blog/7091/async-cooperative-multitasking-for... has some examples for what this looks like with curl -- in the final example, notice how you can just "await" on a bunch of different things and let the runtime worry about coordinating all of them.
The async stuff in HHVM is far more powerful than the meagre-at-best support for asynchronous operations in the original PHP runtime. In usage, HHVM's will be much more powerful.
LLVM isn't really a VM, it's just a compiler toolkit. And really, the overhead of converting your data structure to LLVM IR is almost certainly trivial compared with the cost of the optimizations it is performing.
LLVM IR is definitionally coding to a virtual machine. It doesn't bear a ton of similarity to the underlying architecture in most cases. gcc's GIMPLE is the same idea. (That it's compiled down to machine code doesn't make what you're working with not-a-virtual-machine.)
Heh, I originally wrote something more pedantic then edited it down. It's definitely a virtual machine insofar as its an abstract computational machine, but it's not in the probably more common definition of "an interpreter, possibly with a JITing compiler on the side, for an abstract computational machine" (though LLVM does have an interpreter, it's not really ever intended to be used for anything).
Multi-stage JITs are indeed fascinating and give some nice wins, but as a "user" (that is, a developer) I find them frustrating at times because they make it more difficult to reason about the performance and behaviour of my code.
Not only a priori, but in terms of testing actual code and designing benchmarks as well - you have to make sure the right sections of code are hot, hitting the right levels, etc. It's extra mental load and work. (and if you're a JS developer, you may have to do this across multiple platforms). And oh, regressions and updates.
I'm not entirely convinced it's all worth it, but so far I'm begrudgingly accepting it.
Sure, but with most AOT compliers you only get one machine-code version of your code, which is easier to benchmark than worrying about the multiple levels of a JIT.
I'm rather disappointed that full, non-experimental xdebug support isn't on this list. I can't think of a more pertinent feature. I like HHVM's development as well as Hack, but without proper remote debugging, it remains rather inaccessible. I would personally love to contribute to getting some of the major frameworks that are not quite 100% compatible up to par but have been deterred in being able to fix bugs in a timely matter because of the lack of debugger support.
It's not on the list since it was released a few versions ago! Try it in the latest stable version, and please file issues on GitHub if you run into problems. There are already a couple of known issues filed there that are being looked into, but at least the PHPStorm developers have told us that it works well enough they are able to work on XDebug+HHVM support in their IDE.
I have recently tried out to run our huge, about 10 years old application using HHVM. Interestingly enough, aside of few 5.6 features it didn't support yet, the process was surprisingly painless.
However, HHVM was generally between 2 and 5 times slower than vanilla PHP at rendering pages. In micro benchmarks it was way ahead, but running the whole application was a very different matter.
I decided to wait until the thing matures a bit more before trying again and then hopefully with more time to investigate the causes of this huge difference in performance.
That's really interesting, as I brought one of our services at my old job over onto HHVM and gained 4 times more performance, I'm really curious what workload you were throwing at it, and I know that the HHVM people would love to take a look at it; performance regressions from PHP to HHVM have been basically nil for me over the past 12 months.
also, if this is an open source workload, any chance you could submit it to https://github.com/hhvm/oss-performance ? We generally optimize based on those benchmarks, and Facebook itself.
Sorry for yet another rant against php, but does anyone else here feels a bit sad that those obviously brilliant people work so hard to improve this language instead of basically any other main one ?
Edit : seems like i wasn't clear. I don't mean sad for the people working on the project ( i'm sure they love what they're doing), i mean sad because as a non-php dev ( but basically everything else dev), i know many "better" languages that would benefit from having those kind of people on board.
Shared nothing. Simple deployment. "Web" focused. Those are PHP's strengths, and why it continues to do well, despite it's huge amount of quirks.
Modern PHP, with Composer, the PSR standards, and the Framework Interoperability Group's efforts is a very different beast to PHP4 or <=PHP5.3. Sure, one can make an argument that a "better" language would be a nicer target for this sort of amazing talent, but that ignores reality: So many things run on PHP, that it's a good idea to fix PHP's issues. HHVM and Hack are doing sp (in parallel with the communities efforts), and I thank them for it,
Besides inconsistent/bad library argument order/naming, and a couple parser related issues that are slowly being fixed (like the "immediately use an array returned from a function" issue fixed in 5.4) I don't see any "huge amount" of quirks.
I do see a lot of bikeshedding, from people who could have found similar BS in most languages in major use.
Yup. The argument order of similar functions being inconsistent is the only thing I run into on a day to day basis. I never remember the order or even names of most functions anyways and with proper tools it's irrelevant. Honestly, I think people like to bust on PHP mainly because it's in vogue and "acceptable" by a lot of ignorant folks. I assume in some circles it gets one brownie points. It's almost as if they're pretending that bad code doesn't exist in the language of their choice, that somehow the choice of language can protect one from others' stupidity and bad code. In the meantime, PHP developers are actually getting things done and the good ones are writing extremely clean code. Like most of the PHP community, I'm extremely glad for the effort going into HHVM which I see as the future of PHP.
Most languages aren't templating languages at first place. PHP was saved because it decided to look like Java,which neither Ruby or Python do,which allows writing these huge codebases like Doctrine or Symfony.
I personnally started coding with Actionscript 3, I wish PHP looked exactly like that,while keeping the scripting and the execution model.
> PHP was saved because it decided to look like Java,which neither Ruby or Python do,which allows writing these huge codebases like Doctrine or Symfony.
What does looking like Java have to do with being able to write huge codebases? Both Python and Ruby have libraries just as big as (or bigger than) Doctrine and Symfony.
> What does looking like Java have to do with being able to write huge codebases? Both Python and Ruby have libraries just as big as (or bigger than) Doctrine and Symfony.
Django and Rails, to name just two open source projects, and I've seen proprietary Python apps with hundreds of thousands of lines of code. You still haven't said how PHP allows you to write bigger codebases than Python or Ruby, and what that has to do with looking like Java.
These issues are the least of it's 'quirks'. The most important thing that is wrong with it is the badly or 'un-designed' core of the language. This result of this is that when you are implementing modern programming constructs, you won't be able to implement it in a consistent way (Most of the time the implementers does not care, but even if you do you ill see quickly running out of options.). So the modern features PHP get are often half-baked so that if you try to put it to real use, it ll come to a grinding halt.
Another aspect of this 'un-designed' core is that there will be a big fight over introduction of any 'core-like' feature. And often implementers wont be able to go with one philosophy and is forced to make everyone happy, ending up with very weird behaviors in the implementation.
Another thing is Exceptions. Because the exceptions was not available from the start, only a part of the language uses them. So you cannot rely on exceptions being thrown in a consistent way.
Another important thing is the most people who have been working on the language are hobbists and students with no sort of professional experience, and they end up implementing the features in the most awkward fashion (Eg: Methods on the datetime object mutating it).
P1 - "PHP sucks, it's a terrible language with no proper design and no serious person would ever want to use it"
P2 - "But tons of large projects are built on it and people ship with it everyday"
P1 - "So? It's still terrible"
P2 - "What do you think is so terrible?"
P1 - "Oh lots and lots of things, I wouldn't even know where to begin"
P2 - "How about this: let's throw boatloads of cash on it for a while and see where we get."
P1 - "Oh gee, I dunno if..."
P2 - "Boatloads of cash it is.
[edit] After seeing how my comment could be seen as ridiculing HHVM: I'm a PHP dev and I'm loving every second of what they're doing. I think they're right on the money.
I actually appreciate the work that Facebook is doing in this space... it's definitely beneficial to those running PHP codebases that have been around a long time. While I don't like PHP the language, I can understand the utility of it.
That said, I'm appreciating the move to containerization and micro-services more... replacing some pieces with better options becomes far easier when those pieces are smaller. I can prototype in something like node, and move those troublesome bits to something like go or c++ if needed.
This comment is sad. First people complain about problems with PHP. Then when problems are being solved people complain about people fixing them. It honestly looks like PHP is simply in a lose / lose situation with many people. That's the real disappointment in my eyes.
PHP is a lose / lose only to people that are not using it / won't bother learning it. It's the same with Perl. It's not hot nor trendy and that's why many people get so frustrated when they hear about people still using it because there's something "newer and better". Haters gonna hate.
It's simply not viable from a time-investment point of view to throw away tools you know extremely well, are well entrenched, well supported and stable every few years because something new comes along.
I think much of the hatred towards PHP fundamentally comes down to the fact that it broke down a lot of barriers to entry in the web development world which allowed for anyone with a basic text editor to patch together CRUD apps. This led to an army of "w3cschools.com developers" referring to themselves as software engineers, which offended many in enterprise Java land.
Based on what? They rewrote the language into another that is largely backwards compatible, fixes PHP's quirks and is insanely fast.
Given the choice of migrating / transpiling an entire codebase or making the underlying interpreter / compiler and language fantastic and speedy, the latter is a big, big win.
What would rewriting the whole thing in, say, Ruby or Python have done beyond limiting the amount of "PHP sucks!" critique they so often get?
Seriously, take a look at Hack. It's very well done.
This is not to diss any particular language but an architectural problem - frontend and backend are very tightly coupled which makes it difficult to develop anything outside this stack. By splitting a humongous (and always growing) homogenous application into smaller services you get smaller failure domains and better interoperability with acquisitions and potential new groundbreaking projects that do not easily fit into the current development model. Again, I have no opinion about HHVM and Hack which are completely orthogonal to the problem at hand.
The coupling has nothing to do with the language and everything to do with the fact that FB grew organically into this giant monolithic mess of spaghetti. Can you do SOA in PHP? Of course. Does FB do it? Nope. Will this bite them in the long run? I believe so.
PHP has merits relative to other web development tools, like the way the environment for every request starts "clean" and global state has to be explicitly managed. Adding typechecking to PHP with Hack and making it run fast is very useful and not sad at all.
> Integration of LLVM as a further optimization step to make the hottest code run even faster on HHVM.
These multistage JITs are absolutely fascinating, I believe Safari is doing something similar with Javascript. Intuitively I would've assumed the overhead of firing up yet another JIT and VM to run it on would make it not worth it, but I guess the instructions currently generated are so far off optimal that it is worth doing.
EDIT: Anyone know of any papers regarding multi-stage JITs that I can check out?