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(a)gmail.com> wrote:
> 2015-06-12 18:47 GMT+03:00 Quim Gil <qgil(a)wikimedia.org>rg>:
>> On Fri, Jun 12, 2015 at 12:59 PM, Gerard Meijssen
>> <gerard.meijssen(a)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-a…
>>
>>
>>> 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
>> Wikitech-l(a)lists.wikimedia.org
>>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l