Howdy,

> Most of the code in MediaWiki works just fine with it (since most of
> it is mundane) but things like dynamically including certain files,
> declaring classes, eval() and so on are all out.

There're two types of includes in MediaWiki, ones I fixed for AutoLoader and 
ones I didn't - HPHP has all classes loaded, so AutoLoader is redundant. 
Generally, every include that just defines classes/functions is fine with HPHP, 
it is just some of MediaWiki's startup logic (Setup/WebStart) that depends on 
files included in certain order, so we have to make sure HipHop understands 
those includes.
There was some different behavior with file including - in Zend you can say 
require("File.php"), and it will try current script's directory, but if you do 
require("../File.php") - it will 

We don't have any eval() at the moment, and actually there's a mode when eval() 
works, people are just scared too much of it. 
We had some double class definitions (depending on whether certain components 
are available), as well as double function definitions ( ProfilerStub vs 
Profiler )

One of major problems is simply still not complete function set, that we'd need:

* session - though we could sure work around it by setting up our own Session 
abstraction, team at facebook is already busy implementing full support
* xdiff, mhash - the only two calls to it are from DiffHistoryBlob - so getting 
the feature to work is mandatory for production, not needed for testing :) 
* tidy - have to call the binary now

function_exists() is somewhat crippled, as far as I understand, so I had to 
work around certain issues there.
There're some other crippled functions, which we hit through the testing... 

It is quite fun to hit all the various edge cases in PHP language (e.g. 
interfaces may have constants) which are broken in hiphop. 
Good thing is having developers carefully reading/looking at those. Some things 
are still broken, some can be worked around in MediaWiki. 

Some of crashes I hit are quite difficult to reproduce - it is easier to bypass 
that code for now, and come up with good reproduction cases later. 

> Even if it wasn't hotspots like the parser could still be compiled
> with hiphop and turned into a PECL extension.

hiphop provides major boost for actual mediawiki initialization too - while 
Zend has to reinitialize objects and data all the time, having all that in core 
process image is quite efficient. 

> One other nice thing about hiphop is that the compiler output is
> relatively readable compared to most compilers. Meaning that if you

That especially helps with debugging :) 

> need to optimize some particular function it's easy to take the
> generated .cpp output and replace the generated code with something
> more native to C++ that doesn't lose speed because it needs to
> manipulate everything as a php object.

Well, that is not entirely true - if it manipulated everything as PHP object 
(zval), it would be as slow and inefficient as PHP. The major cost benefit here 
is that it does strict type inference, and falls back to Variant only when it 
cannot come up with decent type. 
And yes, one can find offending code that causes the expensive paths. I don't 
see manual C++ code optimizations as way to go though - because they'd be 
overwritten by next code build.

Anyway, there're lots of interesting problems after we get mediawiki working on 
it - that is, how would we deploy it, how would we maintain it, etc.
Building on single box takes around 10 minutes, and the image has to be 
replaced by shutting down old one and starting new one, not just overwriting 
the files. 

Domas
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to