Graalphp: An Efficient PHP Implementation Built on GraalVM(github.com)
github.com
Graalphp: An Efficient PHP Implementation Built on GraalVM
https://github.com/abertschi/graalphp
57 comments
Efforts like this with GraalVM and the upcoming JIT in PHP 8
should lead to, I believe, that many of the existing C extensions of PHP to be converted to pure PHP implementations.
When you have a JIT based language you want as much to be executed in that language, jumping back and forth between PHP and C is a drawback from a JIT perspective.
However there exist many PHP C extensions that are just thin wrappers around large C libraries like cURL, it is not really feasible to implement that in pure PHP.
But with the introduction of a foreign function interface with PHP 7.4 that has made it possible to call C libraries with ease, as long the C library doesn't do too much macro magic, and to my understanding upcoming Java release ships with a much improved native bridge with better support for native types, these two thing could lead to, guessing here, that you only need to implement the bridge for each implementation but share the rest of the PHP wrapper code for that C library.
However the foreign function interface introduced in PHP 7.4 is signigfanctly slower that the old style C extension of Zend PHP, but to my understanding is that future evolution of the JIT could theoretically reduce that performance impact.
When you have a JIT based language you want as much to be executed in that language, jumping back and forth between PHP and C is a drawback from a JIT perspective.
However there exist many PHP C extensions that are just thin wrappers around large C libraries like cURL, it is not really feasible to implement that in pure PHP.
But with the introduction of a foreign function interface with PHP 7.4 that has made it possible to call C libraries with ease, as long the C library doesn't do too much macro magic, and to my understanding upcoming Java release ships with a much improved native bridge with better support for native types, these two thing could lead to, guessing here, that you only need to implement the bridge for each implementation but share the rest of the PHP wrapper code for that C library.
However the foreign function interface introduced in PHP 7.4 is signigfanctly slower that the old style C extension of Zend PHP, but to my understanding is that future evolution of the JIT could theoretically reduce that performance impact.
> When you have a JIT based language you want as much to be executed in that language, jumping back and forth between PHP and C is a drawback from a JIT perspective.
The Truffle solution to this is to run the C extension in the same JIT, so that's it's not a barrier to optimisation anymore.
The Truffle solution to this is to run the C extension in the same JIT, so that's it's not a barrier to optimisation anymore.
> It will need to support the C interface components like PDO database drivers and the Laravel web framework.
Laravel does not have any C PHP modules in its codebase. While it makes use of drivers provided by them, it does not have any components that are written in C.
Laravel does not have any C PHP modules in its codebase. While it makes use of drivers provided by them, it does not have any components that are written in C.
I read the original poster's post as Graalphp needs to support both PDO, the C extension, AND Laravel, specifically every language construct that Laravel uses.
Describing truffle implementations as alternatives to Java implementations is not quite correct. They are always alternatives for the reference implementations (CRuby, Cpython). They're also not really about integration with Java Bytecode
Also Truffle will let you run C extensions unlike regular jvm implementations due to the polyglot nature of Graal and Sulong
Also Truffle will let you run C extensions unlike regular jvm implementations due to the polyglot nature of Graal and Sulong
From the report at https://abertschi.ch/default_public/ethz/graalphp/download.p...: "Experimental results indicate that our runtime reaches competitive results with performance gains of up to 859% compared to PHP 7. These preliminary results suggest that a Truffle-hosted PHP implementation might be significantly faster than existing language implementations."
Not implemented features: classes, namespaces, exceptions
So it will work for really old(-style) php then. I still see new software coming out (and being sold) written in that style: no frameworks, classes or exceptions. Not relevant for this implementation, but many (popular) commercial wp plugins are still written like that; installed one for a client a few days ago and it was a dense mix of code and html without classes, exceptions or namespaces. And that is a popular, new, commercial one.
That's pretty common within the WordPress community, yeah, and it doesn't have to be ugly if the coders knew what they were doing. A lot of it is a mess, though.
Also commercial standalone scripts as I see; I think many are 15+ years old originally and are just updated with better fronts and some new features but all the logic is just the same hacking.
PHP is implemented in C, right?
What makes a PHP version implemented in a JVM 9x faster than PHP implemented in C?
What makes a PHP version implemented in a JVM 9x faster than PHP implemented in C?
The JVM version implements a JIT compiler; the C version implements an interpreter. So it's the same thing that makes PyPy faster than CPython, Java 1.3 faster than 1.2 and the first release of Chrome's V8 faster than earlier JavaScript implementations.
PHP 8 also introduces a JIT compiler, which is presumably less mature but more complete: https://wiki.php.net/rfc/jit
PHP 8 also introduces a JIT compiler, which is presumably less mature but more complete: https://wiki.php.net/rfc/jit
also, the implementation we're talking about is not a complete implementation of the PHP language.
It's easy being faster when you're doing less.
It's easy being faster when you're doing less.
The JVMs are amazingly fast.
A majority of the dynamic compilation research goes into JVMs. (The remainder being apportioned mostly to the javascript vms and the clr, with mike pall waving his luajit hat in the distance.)
An overwhelming majority of GC research also goes into JVMs, thanks to Jikes RVM.
A majority of the dynamic compilation research goes into JVMs. (The remainder being apportioned mostly to the javascript vms and the clr, with mike pall waving his luajit hat in the distance.)
An overwhelming majority of GC research also goes into JVMs, thanks to Jikes RVM.
Apart from the interpreter part, the GraalVM project also has a focus on creating native images, basically compiling directly to the assembly of the architecture. That's what the native results are from.
Ever seen a java Spring project start in 0.015s, or a java rest service living in 16-32mb of ram? With graal these things are now possible.
Ever seen a java Spring project start in 0.015s, or a java rest service living in 16-32mb of ram? With graal these things are now possible.
They are using CPU intensive synthetic benchmarks to compare tight loops, fannkuch-redux, spectral-norm, and similar done in PHP code and aren't directly implemented in C.
The kind of things they are benchmarking aren't what people typically use PHP for.
The kind of things they are benchmarking aren't what people typically use PHP for.
The JVM compiles the PHP code to highly optimised machine code at runtime. The C implementation doesn't compile to machine code at all (or I think they only just started doing it and it's very limited.)
Mostly because PHP is implemented very poorly. Its used to be really slow (its a little bit better now with newer versions) and it always amazed me, because of its basically a thin wrapper on C.
I guess PHPs core types are very inefficient and the team behind PHP lacks time to really do a rewrite. A prime example is the PHP "array". Its not a list, its not an array, but more of a weird object thing. PHP is full of these weird things that are probably hard to optimize (in the PHP runtime)
I guess PHPs core types are very inefficient and the team behind PHP lacks time to really do a rewrite. A prime example is the PHP "array". Its not a list, its not an array, but more of a weird object thing. PHP is full of these weird things that are probably hard to optimize (in the PHP runtime)
I'll point out that in the latest Techempower Benchmarks[1] PHP makes up 20% of the fastest 25 frameworks. It also makes two appearances before the first Java framework.
PHP might not be suited to every application, but it's certainly not slow.
[1] https://www.techempower.com/benchmarks/
PHP might not be suited to every application, but it's certainly not slow.
[1] https://www.techempower.com/benchmarks/
Thats a total BS claim. I took a quick look at the top 25, and the ones that made the list (top 25) that are PHP based are:
- 11: php-ngx-pgsql
- 12: workerman-pgsql
- 22: workerman
- 23: php-ngx-mysql
- 25: Swoole
Here you see a trend, workerman and swoole are BOTH nodejs clones, they have a event loop and are non-blocking. This means you CANNOT use 95% of core PHP because its blocking by nature. These are all a non-starter for 99.9% of PHP based apps. Also swoole is a PHP C-extension, not a "installable" framework like say Symfony is, taht said these are NOT frameworks at all, not sure why they are on the list?
Heres the REAL rankings of the PHP frameworks that are used in the wild:
- 299: codeigniter
- 323: fatfree
- 369: cakephp
- 370: symfony
- 377: laravel
PHP occupies the lower bottom of the ranking, and will probably always be there becuase og how PHP is built. The core model of execution is always going to be slower than a "running" program. This is evident with the nodejs clones.
- 11: php-ngx-pgsql
- 12: workerman-pgsql
- 22: workerman
- 23: php-ngx-mysql
- 25: Swoole
Here you see a trend, workerman and swoole are BOTH nodejs clones, they have a event loop and are non-blocking. This means you CANNOT use 95% of core PHP because its blocking by nature. These are all a non-starter for 99.9% of PHP based apps. Also swoole is a PHP C-extension, not a "installable" framework like say Symfony is, taht said these are NOT frameworks at all, not sure why they are on the list?
Heres the REAL rankings of the PHP frameworks that are used in the wild:
- 299: codeigniter
- 323: fatfree
- 369: cakephp
- 370: symfony
- 377: laravel
PHP occupies the lower bottom of the ranking, and will probably always be there becuase og how PHP is built. The core model of execution is always going to be slower than a "running" program. This is evident with the nodejs clones.
I have to point out that what you say applies only on the "Fortunes" benchmark. On the others benchmarks, Java always comes before PHP. I'll also add that most people don't use the top performing frameworks (most people use Laravel and Symfony for PHP, which are near the bottom), but that applies to everything here.
[edit]: clarification
[edit]: clarification
Huh? Nearly every PHP job is Laravel or Symfony nowadays, at least in Europe.
I wasn't clear, sorry. What I meant to say is that most people use Laravel and Symfony, which are nowhere near the top performing PHP frameworks on the benchmark.
What's the licensing situation for GraalVM? Do they throw lawyers at you if you are making enough money like with other Oracle products[0]?
[0]: Please note that was the impression I got from reading anything Oracle related in HN, not personal experience. I don't otherwise know what I'm talking about.
Signed: .NET developer very interested in the new developments in the Java World but heard too many scare stories.
[0]: Please note that was the impression I got from reading anything Oracle related in HN, not personal experience. I don't otherwise know what I'm talking about.
Signed: .NET developer very interested in the new developments in the Java World but heard too many scare stories.
Like a lot of similar software. GraalVM has a free and open source community edition. And an enterprise version that comes with increased performance and security. The enterprise version is free for evaluation and development. And for production costs around 100-200 USD year/processor. This includes 24/7 support.
Community edition runs any program that runs on GraalVM Enterprise.
Community edition runs any program that runs on GraalVM Enterprise.
Enterprise version is also free if you deploy it on Oracle Cloud, more info : https://www.graalvm.org/faq/
Nice try salesman, nice try. Remember kis: Oracle has no customers, only hostages.
So I work at Oracle, but as an engineer. These are of course my own thoughts and I’m not representing OCI.
As far as I know, there’s no difference between any of the clouds as far as basic payment structure. If you don’t want to be locked in on a contract, you just give a credit card and pay the publicly posted rate. Exactly how are you a hostage in that position?
As far as I know, there’s no difference between any of the clouds as far as basic payment structure. If you don’t want to be locked in on a contract, you just give a credit card and pay the publicly posted rate. Exactly how are you a hostage in that position?
Portability between clouds assumes that you exclusively use the cloud provider as a sort of VPS host. Any service beyond that becomes a form of lock-in. YMMV, and this is of course true for all clouds.
Fool me once, shame on you. Fool me tw... can't get fooled again.
Just want to comment on java: Just stay away from Oracle Java and use OpenJDK, which is GPL2'd (with asterisk). If you want stability, stick to LTS versions... I have no idea why people would use Oracle Java for new projects.
"GraalVM Community editions are based on OpenJDK version 1.8.262 and on OpenJDK version 11.0.8."
https://www.graalvm.org/docs/getting-started-with-graalvm/
https://www.graalvm.org/docs/getting-started-with-graalvm/
> Just stay away from Oracle Java and use OpenJDK
Is there any difference anymore? I’m not sure there is.
> I have no idea why people would use Oracle Java for new projects
Expert support, for example.
Is there any difference anymore? I’m not sure there is.
> I have no idea why people would use Oracle Java for new projects
Expert support, for example.
> I have no idea why people would use Oracle Java for new projects.
Maybe because there are businesses out there that care about support?
Maybe because there are businesses out there that care about support?
[deleted]
Here's a benchmark of CRuby vs JRuby vs TruffleRuby: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b...
Unfortunately still doesn't run Rails ( yet ).
TruffleRuby [can run Rails](https://speakerdeck.com/eregon/running-rack-and-rails-faster...), if that is what you refer to.
PHP is an... interesting... language to implement. The de facto standard PHP interpreters have become very fast over time. It's been a long time since I measured HHVM, but it always used to have very good warm-up time. I always felt it was a bit of a pity that no-one took on HippyVM (PHP in RPython https://github.com/hippyvm/hippyvm): it implemented a very large chunk of the language, had decent performance, but still some low-hanging fruit to improve (I had some fun making fairly substantial performance improvements to some aspects of it). It would be interesting to compare HippyVM and Graalphp once they implement equivalent chunks of the language, especially if someone takes on maintainership of HippyVM!
It's always really cool to see alternate language implementations with new features or advantages !A similar project for PHP is Peachpie [0]. It runs PHP on the CLR and also claims rather massive performance improvements in some areas [1]. To my understanding it does support some more language features than this.
[0] https://www.peachpie.io/ [1] https://www.peachpie.io/benchmarks
[0] https://www.peachpie.io/ [1] https://www.peachpie.io/benchmarks
I believe if you "do it right", PHP7 is already crazy fast. The problem is, without a JIT compiler, those random keys in arrays ("will be object or won't be object?" trope) and crazy dynamic programming is killing all those benefits, and that is typical to those huge organically grown PHP code-bases one usually sees.
Gut feeling: Any attempts on JITting see huge benefits just because of this.
Gut feeling: Any attempts on JITting see huge benefits just because of this.
Those benchmarks are extremely misleading. They compare Peachpie against PHP 7.2 without opcache.
That's like comparing your CPU against a competing product with 2/3 of the cores disabled.
That's like comparing your CPU against a competing product with 2/3 of the cores disabled.
FWIW [peachpie](https://www.peachpie.io/2020/09/peachpie-1-0-preview1.html) is a fairly complete PHP stack running on top of .NET core, leveraging the .NET runtime and jit. It can do things like host WordPress.
It fares pretty well in [techempower](https://www.peachpie.io/2018/06/performance-progress-report....).
It fares pretty well in [techempower](https://www.peachpie.io/2018/06/performance-progress-report....).
as far as I understand, PHP web applications don't benefit from a JIT that much. Each request is like running the entire application from scratch, which is why the opcache can help so much.
Modern PHP frameworks initialize "entire application" only once at startup and process each request really fast.
See the benchmarking charts there: https://github.com/gotzmann/comet
See the benchmarking charts there: https://github.com/gotzmann/comet
It's interesting to see this comment here. In the usual quarterly arguing about PHP posts, the CGI-style "statelessness" is often brought up as a positive feature that differentiates PHP from more "modern" web app stacks.
It is possible to get the best of both worlds if you support both, easy development and performant deployment.
The performance seems pretty impressive! I'd like to see comet being added to techempower's benchmark, to see how it competes against other frameworks.
Sort of. It's not a new process invocation, but it is a new interpreter. Most high volume set ups cache user space startup state in Redis or Apcu. And, as you said, the built in opcache caches the commonly used code.
I wonder why Facebook built HipHop and HHVM and PHP 8 is getting a JIT then.
The PHP team is pretty transparent about the JIT not really helping much with the sort of things people use PHP for. It just opens up using PHP for more CPU intensive stuff that you would have called out to a C library for.
Does this mean we'll be able to use VisualVM or Chrome's inbuilt debugger with PHP? The same way other GraalVM languages can?
Also I assume the polyglot and native image features of GraalVM will work?
Also I assume the polyglot and native image features of GraalVM will work?
VisualVM and JVM reflection/introspection depend on HotSpot, and on GC safepoints, and so on.
GraalVM uses its own GC, and has some limitations: https://github.com/oracle/graal/blob/master/substratevm/Limi... (basically it needs to statically know what will be accessed via reflection, so it can add those to the native-image).
In theory, sure it can be made to work with VisualVM. But I'd be surprised if it works out of the box.
GraalVM uses its own GC, and has some limitations: https://github.com/oracle/graal/blob/master/substratevm/Limi... (basically it needs to statically know what will be accessed via reflection, so it can add those to the native-image).
In theory, sure it can be made to work with VisualVM. But I'd be surprised if it works out of the box.
Either they work or they should be relatively easy to add.
The same will hold true for a Truffle implementation of PHP. It will need to support the C interface components like PDO database drivers and the Laravel web framework.
The linked project was created as part of a graduate thesis and demonstrates the feasibility of GraalVM/Truffle as a performant polyglot platform. I'm not convinced that Ruby/Python/PHP integration with Java Bytecode is an important use case moving forward. It could have been when Rails/Django/Laravel were on top of the web framework game but the demand for this use case is diminishing.