Can any one here provide me a good tutorial on compiling PHP using HipHop? i saw this link . But i cannot understand the linux commands. I developed the application in windows. I was not able to run those commands in linux
$HPHP_HOME/src/hphp/hphp test.php
This command gave me error bash command not found.
in the source i got, i do not have anything named hphp inside the folder hphp, is that a method inside main.cpp???
Can any one here provide me a good tutorial on compiling PHP using HipHop? [...] i cannot understand the linux commands.
HipHop and the companion/successor HHVM, are for advanced users that are trying to resolve specific performance edge cases. Normal PHP developers will not ever benefit from any of the things that HipHop provides. In fact, in many cases, you can get just as much of a performance benefit through simple performance profiling and targeted optimizations combined with a bytecode cache, like APC.
If you do not understand the commands needed to get it running, you do not fall into the class of user that should attempt to use it. Break out your profiling tools instead, as they will be far, far more valuable to you.
It's been clarified that the actual intent is to use HipHop as a PHP code protection mechanism. That's an even worse idea!
HipHop is designed to run as an application server. That is, it contains a web server.
HipHop binaries are huge, often greater than 500 MB. They are not appropriate for redistribution.
HipHop memory use is significantly larger than the binary.
HipHop is designed and intended to run on machines dedicated to the task.
It's not intended for that purpose... and everything can be decompiled. That includes the commercial products that are designed for the task, ionCube and Zend Guard. All it takes is a bit of time or money, and your source is mine. Your best defense against intellectual property theft is a good license and a good lawyer, not a technological solution that makes it harder to run your code.
Related
I've been reading about Facebook's Hack which lead me to reading about HipHop Virtual Machine. I wanted a better understanding of this and could not find a clear definition. Wikipedia defines it as: HipHop for PHP (shortened as HipHop) describes a series of PHP execution engines and improvements created by Facebook. I don't understand what PHP engines are...
So I guess then my question is: What exactly are "PHP execution engines?" and how exactly do the benefit PHP applications?
Thanks!
You can run your PHP code with the standard (Zend) engine that you download from php.net, that works great. If you download WAMP, MAMP, or any of the other pre-packaged PHP & MySQL for your Operating system packages, this is what you're getting.
Alternately you can run (most of[1]) your PHP code with HipHop, that works great.
Which one you're using should be effectively invisible to your end users. Your developers, and operations teams will need to know.
You may choose to use HipHop if you're running a site that gets a lot of traffic. HipHop while not supporting all of the features of PHP, does run a bunch faster. It also has some new features not available in the main PHP distribution mostly to do with type hinting. These can provide some pretty attractive tools to read through your code checking for bugs.
Reasons you may want to use HipHop:
Performance is a big deal for you
The static analysis tools available with HipHop have serious worth to your team
The new features in HipHop but not in Zend PHP are attractive to your team.
Reasons you may want to use Zend PHP
You need an extension not available for HipHop (there's lots of extensions out there, think: gd, curl, imagemagik, etc. Many are available for HipHop now, many aren't).
Your code, or framework is making use of unsupported features.
You have a lot of expertise in hosting your current Webserver & PHP stack, and don't want to start from scratch.
This post goes into some HHVM vs HACK differences, and gives a nice run down: http://www.marco.org/2014/03/21/hack
[1] Not all code that you can run with the regular PHP engine currently works on HipHop. They're working on most of the issues, some they've just decided not to fix (I think variable variables may be an example of this e.g. $$var)
We want to write a Linux service in php and compile it with HIPHOP. Since we started the project with php and we could do all the programming in-house instead of hiring a c++ programmer etc. we would love to stick to php. Speed in execution is not (so) relevant for us since the daemon is just doing some monitoring but we would like to close up the code to obfuscate it. The daemon will do some network communication and logging to a db. Is this a viable route to go? In another post someone described that hiphop needs special attention in programming since not all php features are implemented. Is this still the case? I would love to here your overall opinion on our idea.
HIPHOP is quite a beast to handle. It is very limited, so it depends specifically on your application and where it will be deployed. Remember, at present it only runs on 64 bit architectures .. so if you wanted to deploy on a 32-bit machine, you are immediately stuck in the mud.
You may have to build many different binaries for different linux distro's depending on the nature of your application. Since HipHop only works well on Fedora and CentOS, you are severely limiting your scope. Once you move off of the PHP interpreter, you lose a very large amount of interchangeability between operating systems (Think about it: Windows, Virtually all Linux, All Major BSD Distributions, ... )
Also keep in mind, I'm not sure to what extent you want to "obfuscate" your code. If you want to make network calls, etc and keep those hidden as well, a packet sniffer can see exactly how you are communicating with the outside world extremely easily.
Likewise, a debugger and a reasonably seasoned programmer will be able to reverse engineer your binary to a larger degree than you may be aware.
You may want to look into alternatives such as Zend Encoder or IonCube Encoder would be the preferred method to go about things, but these are non-free options. There are other encoders out there as well that you may want to look into.
I'm not exactly sure what you're doing other than "monitoring", so I can't say for sure. But a secondary option would be simply to severely limit the amount of code that is being run on the client machines (assuming they are reporting to a server machine) and let the server machines, which are assumed in your total control, handle more processing if any way possible.
I invite you to simply explore the idea yourself by testing, since once again, it's extremely dependent on the nature of your application and where you intend to deploy it. (And for many people, something like "where to deploy" can change rapidly). HipHop was created with a very narrow scope: Run PHP code as fast as possible. It isn't designed to be highly flexible or highly interchangeable between OS's and CPU Architectures. Please consider this before you write a large application reliant on it, and please make sure you fully understand every implication of using HipHop. Test, test, test.
Would it make sense to switch to HipHop instead of XCache?
Is HipHop ready for primetime or should we wait several months before implementing it?
Edit: we are interesting in testing the configuration on a server running vBulletin.
Let me clear up a misconception you might have about Hiphop and Xcache. XCache works by adding Opcode caching to ZEND's PHP implementation (like APC and friends), while Facebook's HipHop allows for PHP code to be transformed into C++ code and then compiled using g++. It's not possible to run XCache with HipHop as HipHop doesn't depend on Zend interpreter (and doesn't even use php opcodes as it's compiled to bytecode after transformed to C++).
Now to answer your question, HipHop is being used live to host a large amount of Facebook's traffic. Facebook wouldn't release this project if it wasn't near stable, but since it is very new I would still exercise caution. HipHop is not just a patch to the old Zend Interpreter, it is a completely different way to run the PHP code and will probably have a few bugs in it.
One thing that Facebook did to ensure that Hiphop was working before they switched to it was they were able to setup very rigorous unit tests of each possible request on their site. That way if the output from Hiphop was different from the normal Zend PHP, they would go back and debug some more until everything "worked for them". Just because it "works" on Facebook code base doesn't prove that it'll work for yours. If you do decide to switch to HipHop, make sure to test it well.
EDIT:
HHVM (new VM version of HPHP) can now eval and create_function. They should be the same for all/most meaningful reasons.
There are a few things that aren't compatible with HipHop. They removed the eval and create_function functions. They also only support PHP 5.2.x for now, but they are plan to add support for 5.3 "soon".
I like the idea of HipHop, so don't get me wrong here, but there is something to remember: HipHop is not for everyone. From Sebastian Bergmann:
it is not a solution for a problem faced by 99.9% of the PHP deployments out there
Unless you have Facebook proportion traffic and your bottleneck is CPU or memory usage, you're not likely to see much of a benefit (as compared to xcache, apc, etc). Database and file system access are still going to be your killers.
I'm fairly confident that vbulletin 3.x will not work with HipHop. VB 3's plugin system consists of nearly 2000 eval statements sprinkled throughout the code, and eval is not supported by hiphop.
That's probably only the tip of the iceberg, when it comes to getting vbulletin to compile.
The news in the PHP world today is Facebook's HipHop, which:
HipHop for PHP isn't technically a compiler itself. Rather it is a source code transformer. HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it. HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features — such as eval() — in exchange for improved performance. HipHop includes a code transformer, a reimplementation of PHP's runtime system, and a rewrite of many common PHP Extensions to take advantage of these performance optimizations.
My question is, what type of web applications is this actually useful for?
Seems like typical database-bound web apps may not be greatly served by this, but rarer CPU-bound apps would.
Web applications that do a lot of processing and/or use a lot of memory. Apparently this HipHop will reduce CPU usage by around 50% and also reduce memory usage (I didn't see how much the memory usage would be reduced by mentioned anywhere). This means that you should be able to serve the same number of requests with fewer servers.
An added benefit may be that there will be some basic type checking to ensure that the code is consistent before it is compiled. This should help to locate the type of bugs that PHP currently tends to ignore as a result of its weak type system.
The downside appears to be that it might not support some of PHP's more dynamic features such as eval (though arguably that's a positive too).
Well it "transforms" PHP into C++ to help performance of a largely scalable website.
So, HipHop is for when you have a website that you started at Harvard that you quickly grow into a billion dollar company and that people are making a movie about starring Justin Timberlake. When you have such a website and want to save CPU cycles, but don't want to rewrite your codebase, you use HipHop.
If you are just starting out, unless you are trapped on a desert island with only PHP programmers that refuse to learn a more scalable language, you don't use HipHop.
Running machine code over interpreted code is faster. This is useful in one sense, but also reduces the amount of machines you require, as each processor has less work to do.
This is good for a company like Facebook, in that they can cut the amount of machines they need.
In terms of why it's useful for them, they probably run a lot of sorting and indexing, on the large amounts of data they have.
This article:
http://terrychay.com/article/hiphop-for-faster-php.shtml
answers this question perfectly with its series of "if" statements.
You can think of it as some sort of compiler that takes in a bunch of .php files, and generate a bunch of c++ files for which you can then compile using g++ (Not sure if other compilers are supported). The resulting exe is your web application with a web server included. That means you could run the exe and you are good to go. The web server is based on libevent and supposedly pretty efficient.
Hip Hop is essentially pointless to everyone except Facebook and other gigantic PHP-based sites. I'm sure many people will jump on the bandwagon due to "it's fast" but how many PHP based apps use whole server farms?
Just because you are working on a social network site, doesn't mean you should consider using HH.
If I write a hello world app using a PHP web framework such as CodeIgniter and then I compile it and run it using HipHop. Will it run faster than if I write the same hello world app in django or rails?
HIPHOP converts php code into C++ code, which needs to be compiled to run. Since pre-compiled code runs faster and uses less memory then scriping languages like python/php it will probably run faster in the example you have given.
However, HIPHOP does not convert all code. A lot of code in php is dynamic and can not be changed to c++, this means you will have to write your code with this in mind. If codeigniter can even be compiled using HIPHOP is another question.
Terry Chay wrote a big article about HIPHOP, covering when to use it, it's limitations and future. I would recomment reading this, as it will most likely answer most of your questions and give you some insight into how it works :)
http://terrychay.com/article/hiphop-for-faster-php.shtml
At that point the run time is inconsequential. HipHop was designed for scaling... meaning billions of requests. There's absolutely no need to use something like HipHop for even a medium size website.
But more to the point of your question... I don't think there have been comparison charts available for us to see, but I doubt the run time would be faster at that level.
i don't know about django or rails, so this is a bit off-topic.
with plain php, the request goes to apache, then to mod_php. mod_php loads the helloworld.php script from disk, parses & tokenizes it, compiles it to bytecode, then interprets the bytecode, passes the output back to apache, apache serves it to the user.
with php and an optimizer the first run is about the same as with plain php, but the compiled source code is stored in ram. then, for the second request: goes to apache, apache to mod_php, apc loads bytecode from ram, interprets it, passes it back to apache, back to the user.
with hiphop there is no apache, but hiphop itself and there's no interpreter, so request goes directly to hiphop and back to the user. so yes, it's faster, because of several reasons:
faster startup because there's no bytecode compilation needed - the program is already in machine-readable code. so no per-request compilation and no source file reading.
no interpreter. machine code is not necessarily faster - that depends on the quality of source translation (hiphop) and the quality of the static compiler (g++). hiphop translated code is not fast compared to hand-written c code, because there's a bit of overhead because of type handling and such.
with node.js, there's also no apache. the script is started and directly compiled to machine code (because the V8 compiler does that), so it's kind of AOT (ahead of time) compiling (or is it still called JIT? i don't really know). every request is then directly handled by the already compiled machine code; so node.js is actually very comparable to hiphop. i assume hiphop to be multithreaded or something like this, while node does evented IO.
facebook claims a 50% speed gain, which is not really that much; if you compare the results of the language shootout, you'll see for the execution speed of assorted algorithms, php is 5 to 250 times slower.
so why only 50%? because ...
web apps depend on much more than just execution speed, e.g. IO
php's type system prevents hiphop to make the best use of c++'s static types
in practice, a lot of php is already C, because most of the functionality is either built in or comes from extensions. extensions are programmed in C and statically compiled.
i'm not sure if there was a huge performance gain for hello world, because hello world, even with a good framework, is still so small execution speed could be negligible in comparison to all the other overhead (network latency and stuff).
imo: if you want speed and ease of use, go for node.js :)
Running a simple application is always faster in any language. When it's become as complex as facebook, then you will face numerous of problems. PHP slowness will be show it's face. In same times, converting existing code to another language is not an options, since all logic and code is not so easy to translated to other language's syntax. That's why facebook developer decide to keep the old code, and make PHP faster. That's the reason they create their own PHP compiler, called HipHop.
Read this story from the perspective one of Facebook developer, so you know the history of HipHop.
That is not really an apple to apples comparison. In the most level playing field you might have something like:
Django running behind apache
Django rendering an HTML template to say hello world (no caching)
AND
HPHP running behind apache
HPHP rendring an HTML template to say hello world (again, no caching)
There is no database, almost no file I/O, and no caching. If you hit the page 10,000 times with a load generator at varying concurrency levels you will probably find that HPHP will outperform Django or rails - that is to say it can serve render more pages per second and keep up with your traffic a bit better.
The question is, will you ever have this many concurrent users? If you will, will they likely be hitting a database or a cached page?
HPHP sounds cool, but IMHO there is no reason to jump ship just yet (unless you are getting lots of traffic, in which case it might make sense to check it out).
Will it run faster than if I write the
same hello world app in django or
rails?
It probably will, but don't fret. If we're talking prospective speed improvements from yet unreleased projects, Pythonistas have pypy-jit and unladen-swallow to look forward to ;)