Hi,
order to have other features work). This is a risky path for the open source MediaWiki though, as sooner or later I expect some announcement that MW will only work on HHVM, which would be a pity.
An interesting thought that may not be appreciated or shared by all third-party users or developers.
[0] shows that at least a Hack only functionality was considered and the question emerges about future development considering statements like:
" ... 1.55 times faster than PHP 7 on a MediaWiki workload ... none of these frameworks take advantage of the asynchronous I/O architecture available in HHVM (i.e., async) ..." [1]
"... advantage of the async capabilities offered by Hack and HHVM, we were able to examine the potential for performance gains through async execution. ..." [1]
" ... able to validate the importance of both JIT compilation and asynchronous execution for optimizing PHP performance ..." [1]
[0] https://phabricator.wikimedia.org/T99755
[1] http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performance
Cheers
On 6/13/15, Strainu strainu10@gmail.com wrote:
2015-06-12 18:47 GMT+03:00 Quim Gil qgil@wikimedia.org:
On Fri, Jun 12, 2015 at 12:59 PM, Gerard Meijssen <gerard.meijssen@gmail.com
wrote:
Hoi, And good news it is :) Thanks Ori :) were people of the WMF involved in this ?
It's not that Ori learned about these news by reading Twitter. ;) Tim Starling got dozens of patches merged in HHVM as well. Both are listed at https://github.com/facebook/hhvm/graphs/contributors, and you can learn about the rest of the team that has been working on this at https://www.mediawiki.org/wiki/HHVM
See also https://blog.wikimedia.org/2014/12/29/how-we-made-editing-wikipedia-twice-as...
A better question IMO is: have the FB engineers contributed any patches
to MW?
I'm not sure why is that a better question, considering that HHVM is running in Wikimedia servers and the numbers show the very tangible value it is providing to Wikimedia users.
Well, there are a number of reasons that made me consider their contributions more important:
- Downstream contributions are much less common than upstream ones
- Intuitively, the number of developers FB has on HHVM is
significantly larger that the number of WMF enigineers working on the subject. More eyes on our code is a good thing. 3. MW optimizations for HHVM will bring more to the WMF deployment that generic HHVM optimizations (see the part from the blog where they mention that some HHVM optimizations had to be reverted or reduced in order to have other features work). This is a risky path for the open source MediaWiki though, as sooner or later I expect some announcement that MW will only work on HHVM, which would be a pity.
Strainu
In any case, as Krenair has shown there are some patches indeed and, well, a Facebook engineer came to work to the WMF offices with Ori and friends during a month or so last Summer, so you see their willingness to help us.
For what I have seen, so far this has been an exemplar free software collaboration with different orgs, timezones, and latitudes involved. Beyond the code, I bet we have learned something about how Facebook's free software developers work and vice versa.
I wish Wikimedia is capable of attracting and engaging in similar free software partnerships, at this level and with these results!
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l