Page MenuHomePhabricator

[Spike] Try out hack (<?hh) for mediawiki-config
Closed, DeclinedPublic

Description

A fun hackathon project-level test to see what would be required.

NB: This is not a first step in a proposal to switch us wholly over to Hack.

Related Objects

StatusAssignedTask
Declineddemon
ResolvedNone
ResolvedJoe
ResolvedJoe
ResolvedJoe
Resolvedtstarling
ResolvedJoe
Resolvedkaldari
Resolvedjcrespo
ResolvedVolans
Resolvedaaron
InvalidNone
DeclinedArielGlenn
ResolvedArielGlenn
Resolvedori
DeclinedNone
ResolvedMoritzMuehlenhoff
ResolvedJoe
ResolvedJoe
ResolvedJoe
ResolvedAndrew
ResolvedJoe
Duplicatefgiunchedi
Resolvedbrion
Resolvedbrion
Resolved bd808
ResolvedJoe
Resolvedfgiunchedi
ResolvedEBernhardson
ResolvedKrenair
ResolvedNone
Resolvedhashar
Resolvedtstarling
Resolvedtstarling

Event Timeline

greg created this task.Mar 4 2015, 11:45 PM
greg assigned this task to demon.
greg raised the priority of this task from to Lowest.
greg updated the task description. (Show Details)
greg added a project: Release-Engineering-Team.
greg added a subscriber: greg.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 4 2015, 11:45 PM
demon added a comment.Mar 19 2015, 5:03 PM

We'll have to turn it on first. I broke testwiki trying :p

Qgil added a subscriber: Qgil.May 27 2015, 10:23 PM

Did someone work on this project during Wikimedia-Hackathon-2015? If so, please update the task with the results. If not, please remove the label.

greg set Security to None.
demon removed demon as the assignee of this task.EditedJun 2 2015, 2:42 PM
demon added a subscriber: demon.

Don't want to lick this cookie too hard, haven't had time to play with it. We'll have to change some settings in HHVM (forgot which one) and scap & co will need updates to reflect the proper linter.

(Should we be linting with hhvm anyway? Hmm....)

We can't even consider this until the entire production MW server fleet is running on HHVM. This includes the misc servers such as tin and turbium. As Tim has pointed out before, it would be embarrassing if we couldn't run our own software. :)

Beyond that blocker, I guess I would be fine with the attempt but I'm not sure what concrete benefits we would hope to achieve beyond an "it didn't break" proof of concept. As far as I understand it, the primary benefits of Hack are the ability to provide stronger type hints for the JIT compiler and access to various async constructs developed uniquely for Facebook. Neither of these sounds like things that would be highly beneficial at the wiki farm config level but maybe I'm missing something.

Ricordisamoa added a subscriber: Ricordisamoa.

(Should we be linting with hhvm anyway? Hmm....)

Once tin is upgraded to trusty php will point to hhvm and we'd be linting with HHVM. But until 5.3 is dead we should be linting with the lowest requirement.

Also HHVM's linter is significantly slower than PHP5: https://github.com/JakubOnderka/PHP-Parallel-Lint/issues/47

Also HHVM's linter is significantly slower than PHP5: https://github.com/JakubOnderka/PHP-Parallel-Lint/issues/47

This is a general consequence of HHVM and its JIT. HHVM will always be slower than PHP5 for short lived tasks due to the startup time costs of setting up the JIT system and recording bytecode in the sqlite bytecode cache.

demon added a comment.Jun 3 2015, 3:04 AM

Also HHVM's linter is significantly slower than PHP5: https://github.com/JakubOnderka/PHP-Parallel-Lint/issues/47

This is a general consequence of HHVM and its JIT. HHVM will always be slower than PHP5 for short lived tasks due to the startup time costs of setting up the JIT system and recording bytecode in the sqlite bytecode cache.

Maybe a better first step is just adding HHVM linting to Jenkins? :)

Restricted Application added a subscriber: Matanya. · View Herald TranscriptJun 30 2015, 5:44 AM
Joe added a subscriber: Joe.Aug 7 2015, 10:28 AM

Do we really want to vendor-lock us into HHVM? For what gain?

Do we really, really have a compelling reason to use hack in mediawiki-config? A performance gain?

greg renamed this task from Try out hack (<?hh) for mediawiki-config to [Spike] Try out hack (<?hh) for mediawiki-config.Aug 7 2015, 3:18 PM
greg updated the task description. (Show Details)
In T91590#1517624, @Joe wrote:

Do we really want to vendor-lock us into HHVM? For what gain?
Do we really, really have a compelling reason to use hack in mediawiki-config? A performance gain?

I indirectly replied by editing the description to make it clear this isn't meant to be a backdoor to us using Hack. This is a fun hackathon idea (for Lyon) that didn't happen. Lowest priority for a reason :)

hashar added a subscriber: hashar.Aug 10 2015, 8:08 PM

Maybe we should just close this task until we open up the discussion to migrate to Hack? Meanwhile, that is yet another opened bug adding overhead :(

greg added a comment.Aug 10 2015, 8:47 PM

Maybe we should just close this task until we open up the discussion to migrate to Hack? Meanwhile, that is yet another opened bug adding overhead :(

I'm fine with that if there's no plans to do anything with it. @demon?

demon closed this task as Declined.Aug 10 2015, 10:20 PM
demon claimed this task.

I don't have a problem with open unassigned bugs, but I guess others do.

greg moved this task from INBOX to Done on the Release-Engineering-Team board.Sep 8 2015, 8:44 PM
hashar removed a subscriber: hashar.Mar 21 2018, 1:50 PM