Perhaps I'm just naive, but can someone explain to me how translating PHP to C++ and then compiling it could be faster than just interpreting?
This is a discussion on HipHop for PHP within the Tech Board forums, part of the Community Boards category; http://wiki.github.com/facebook/hiphop-php/ Perhaps I'm just naive, but can someone explain to me how translating PHP to C++ and then compiling it ...
Because by interpreting prior to and at compile time instead of run time, you err... save on interpreting high level source code at run time.Originally Posted by Epy
I think there's some disconnect in my mind here...
1) Compiled languages: source code -> machine code prior to execution, at execution machine code is executed directly by CPU
2) Interpreted languages: source code read line-by-line -> line-by-line execution of different commands
3) JIT, i.e. Java: source code -> bytecode prior to execution, at execution bytecode -> dynamic translation to machine code by VM
Is HipHop taking the PHP and translating into C++ so that you can compile it and basically use it like a CGI file later? It's making it sound like the program translates PHP to C++ and compiles it right then and there, right when it's needed.
I don't have any experience with HipHop, but take a look at Running HipHop. The instructions get to the point where the reader is supposed to have a compiled binary (from the given PHP source) that is run.Originally Posted by Epy
Major implementations of Perl, python, (and I would have assumed php, but maybe not) et. al. first compile the source into bytecode, then execute it. When you run a script from the command line, both these stages happen one after another, which is why you can receive distinct compile errors. vs. actual runtime errors.
However, they don't have to. For example, using CGI, a server executes scripts the same way you would from the command line; this allows you to change the script without stopping the server (or having privileges to access it) but it is slower. The normative apache php module is the equivalent of this.
But if you "load" the script into the server at start-up (using some other method, eg, with apache, mod_perl, and I think mod_python does the same thing), it and the bytecode interpreter are compiled into the server. Hence, you will get compile time errors on the source scripts when the server starts, and changing those scripts while the server is running will not accomplish anything, since they are not used subsequently.
It looks to me like hiphop is a method for doing this with php, but independent of any server or interpreter, because it uses machine code. Sounds like a good idea, but...
So it would probably be better to have a mod_hiphop, even tho this ties you to apache or whatever.
Last edited by MK27; 12-13-2011 at 06:40 AM.
The fact remains: a single process synchronous server is not suitable for deployment online unless you have little or no traffic. Ie, whatever facebook is doing, they are not putting a hiphop app out front -- it is tiered in somewhere. For Joe Average, web developer, it would be more useful as a second generation mod_php, because you must have concurrent request handling, either via multi-threading, forking, or asynchronous queuing.
Of course, if Joe Average can write his own threaded/forking/asynch server in php and compile it with hiphop, then he's set.
* likewise, because perl and python both use intermediate bytecode, you could easily write a high performance threaded or async server from scratch that way. I've been working on an async server with a perl interface for a few months; altho a lot of the core is in C, it still all depends on the perl interpreter. It benchmarks about 80% the speed of a multi-threaded apache (on a dual core system) with a high level of concurrency -- as a single process without threads (ie, using only one core), and uses about 10% of the memory in a minimal configuration.
Last edited by MK27; 12-13-2011 at 01:11 PM.