8 ms·
Graalphp: An Efficient PHP Implementation Built on GraalVM
- mrigger 6y agoFrom the report at https://abertschi.ch/default_public/ethz/graalphp/download.php 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."
- dvh 6y agoNot implemented features: classes, namespaces, exceptions
- tluyben2 6y agoSo 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.
- fogihujy 6y agoThat'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.
- tluyben2 6y agoAlso 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.
- continuations 6y agoPHP is implemented in C, right? What makes a PHP version implemented in a JVM 9x faster than PHP implemented in C?
- phplovesong 6y agoMostly 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)
- maxk42 6y agoI'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/ https://www.techempower.com/benchmarks/
- ldeangelis 6y agoI 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
- emteycz 6y agoHuh? Nearly every PHP job is Laravel or Symfony nowadays, at least in Europe.
- 6y ago
- slifin 6y agoDoes 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?
- chrisseaton 6y agoEither they work or they should be relatively easy to add.
- pas 6y agoVisualVM 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/Limitations.md 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.
- ldeangelis 6y agoHere's a benchmark of CRuby vs JRuby vs TruffleRuby: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-benchmark-2020-cruby-vs-jruby-vs-truffleruby/ https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b...
- patates 6y agoWhat'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.
- kasperni 6y agoLike 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.
- suyash 6y agoEnterprise version is also free if you deploy it on Oracle Cloud, more info : https://www.graalvm.org/faq/ https://www.graalvm.org/faq/
- znpy 6y agoNice try salesman, nice try. Remember kis: Oracle has no customers, only hostages.
- koenigdavidmj 6y agoSo 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?
- 6y ago
- Cu3PO42 6y agoIt'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/ https://www.peachpie.io/ [1] https://www.peachpie.io/benchmarks https://www.peachpie.io/benchmarks
- kijin 6y agoThose 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.
- patates 6y agoI 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.
- elktea 6y agoas 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.
- jolux 6y agoI wonder why Facebook built HipHop and HHVM and PHP 8 is getting a JIT then.
- tyingq 6y agoThe 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.
- Ambix 6y agoModern 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 https://github.com/gotzmann/comet
- NationalPark 6y agoIt'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.
- tinus_hn 6y agoIt is possible to get the best of both worlds if you support both, easy development and performant deployment.
- ldeangelis 6y agoThe performance seems pretty impressive! I'd like to see comet being added to techempower's benchmark, to see how it competes against other frameworks.
- sradman 6y agoTruffle is an integration layer for interpreted languages in GraalVM. The canonical Truffle language included in the Graal distribution is GraalJS, a replacement for the now deprecated Nashorn JavaScript engine for the JVM. Similarly, TruffleRuby is an alternative to JRuby and GraalPython is an alternative to Jython. Neither of these Truffle implementations has gained traction and they will not until they fully implement the main frameworks for each ecosystem (Ruby on Rails and Django/NumPy respectively). 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.
- kipply 6y agoDescribing 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
- etbusch 6y ago> 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.
- fetbaffe 6y agoI 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.
- fetbaffe 6y ago
- andyayers 6y agoFWIW [peachpie](https://www.peachpie.io/2020/09/peachpie-1-0-preview1.html 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.html https://www.peachpie.io/2018/06/performance-progress-report....).
- ltratt 6y agoPHP 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 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!