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 <[email protected]> wrote: > 2015-06-12 18:47 GMT+03:00 Quim Gil <[email protected]>: >> On Fri, Jun 12, 2015 at 12:59 PM, Gerard Meijssen >> <[email protected] >>> 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-fast/ >> >> >>> 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: > 1. Downstream contributions are much less common than upstream ones > 2. 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
