PHP support

[xiongxin]

It would be great if PHP was supported

Thanks

[brettwooldridge]

@xiongxin "Why PHP is not supported?" is rather a rude question. This is a volunteer effort, there is no entitlement to support of any particular language.

"It would be great if PHP was supported" or "I would like to vote for PHP support" would be a request that developers are more likely to respond positively to.

[thomaswue]

It is a legitimate question and thanks for asking it.

We would be happy to collaborate with one of the existing PHP implementors for adding PHP support (e.g., Zend or Facebook). Or maybe adding Hack support, which is a PHP dialect.

Implementing a language on GraalVM is a lot easier than from scratch (because compiler, GC, and other infrastructure pieces are provided for free). For languages with complex semantics (and a large library implemented in native code) like PHP it is still a considerable effort. We can support such an effort, but are ourselves currently focused on JavaScript, R, Ruby, and Python.

We can potentially fund a student thesis project or internship to investigate the topic if there is a talented and motivated candidate for exploring this task.

[pabl0rg]

Would it be possible to levrage anything from quercus (a php interpreter and stamdard library written in java)?

https://github.com/am-immanuel/quercus [edited link]

[lucaswerkmeister]

I assume that should be this Quercus: https://github.com/CleverCloud/Quercus

[pabl0rg]

Sorry, I fixed the link. The CleverCloud repo has been abandoned for a long time. This one has more recent updates: https://github.com/am-immanuel/quercus

[inoop]

There appears to be an Antlr gammar here: https://github.com/antlr/grammars-v4/tree/master/php

There's also JPHP: https://github.com/jphp-group/jphp

[mcarbonneaux]

My addition to this exchange...

in what i understand about graalvm, they 3 way to do :

• implemente with Truffle framework an php ast opcode interpreter....
• to use jvm bytecode...
• or llvm bytecode that are already supported...

AST interpreter approch...

To generate the php ast there already differente solution:

• https://github.com/nikic/PHP-Parser

A PHP parser written in pure PHP that generate AST.
they support PHP 5.6 to 7.2 syntax

note: this solution make possible bootstraping of php parser in graalvm...

This solution are not 100% original parsing solution...

• https://github.com/derickr/vld

The Vulcan Logic Dumper is and php extension that hooks into the Zend Engine and dumps all the opcodes (execution units) of a script. They use Zend Engine parser result.

• https://github.com/nikic/php-ast

This is a php extension that exposes the abstract syntax tree generated by PHP 7 (like vld). They use Zend Engine parser result.

• phpdbg, since PHP 5.6

phpdbg -p* test.php

• Opcache, since PHP 7.1

php -d opcache.opt_debug_level=0x10000 test.php

• PHP Tokenizer extension (http://php.net/manual/fr/function.token-get-all.php)

php function token_get_all from tokenizer extension permit to get ast from php source.

the advantage of this solutions they use original php parser, and à 100% compatible with original PHP.

but with ast generated we need to code a ast interpreter for php opcode....

Quercus dont generate php obcode, but generate java code directly from php parsing... is not a good starting point to implement php ast interepreter... but add many php extension implemented in java that can be usefull to add this extension to the final result...

jvm Bytecode approch:

JPHP parse php code and generate JVM bytecode... not implemente all standard php library but can be a good start point to start beceause they generate bytecode... that are directly usable in graalvm... but not to make a php ast interpreter...

LLVM bytecode approch:

• https://pecl.php.net/package/llvm

this php extension generate llvm assembly from php source with original parser.

possible C extension in grallvm language

in truffleruby i've seen that implement extension in c also, in that is possible to convert php extension to graalvm, to complement php ast intepreter...

Zend Engine Opcode list to implemente :

• https://github.com/php/php-src/blob/master/Zend/zend_vm_opcodes.h

good internal explanation of php zend engine:

• http://nikic.github.io/2017/04/14/PHP-7-Virtual-machine.html
• http://web.ist.utl.pt/nuno.lopes/pres/PHP_JIT_LLVM_conf08.pdf
• http://blog.golemon.com/2008/01/understanding-opcodes.html

the php specification:

• https://github.com/php/php-langspec

final comment...

there a hard work to do all of that !

[wjmboss]

Support for PHP has a promising future, php has a large number of users and open source projects, and the php language itself is flawed without thread and coroutine, if graalvm fully supports php and leads php in a new direction of development, Graalvm will be an advocate of multilingual development in the near future, so support PHP language very important.

[timglabisch]

any news on this? php has a great ecosystem and is widely adopted.
... and a lot of php developers want a different/better runtime.

[tarsa]

Grammar probably isn't a big problem. A big problem is finding a suitable (e.g. license compatible) and reliably maintained standard library implementation that could be actively reused in GraalVM (i.e. third party would be responsible for maintaining that standard library). Note that TruffleRuby effort is going for many years but it still is unable to run Ruby on Rails fully, the primary Ruby web framework. If a similar situation happens in PHP case then the effort would be effectively wasted - PHP implementation that can't run web frameworks is essentially useless (I guess).

[xiaoyanbot]

LLVM bytecode approch:

• https://pecl.php.net/package/llvm

This extension have no release ...

The code have 8 years old https://github.com/jabez-php/llvm

[kcloze]

PHP has many C extension, I think it's a very hard work to do.

[aurimasniekis]

I found a php antlr parser for 7.4 syntax looks like it works pretty well

https://github.com/antlr/grammars-v4/tree/master/php

@kcloze I don't think it has to do anything with C extensions if I understand correctly graalvm is basically a custom implementation of the language not just wrapping compiler/interpreter

[antanas-arvasevicius]

Without C extensions language will be useless, no database connection, no socket, no curl, no file system access and many more.

…

On 2020-01-16, Thu at 12:01, Aurimas Niekis ***@***.***> wrote: I found a php antlr parser for 7.4 syntax looks like it works pretty well https://github.com/antlr/grammars-v4/tree/master/php @kcloze <https://github.com/kcloze> I don't think it has to do anything with C extensions if I understand correctly graalvm is basically a custom implementation of the language not just wrapping compiler/interpreter — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#361?email_source=notifications&email_token=ABABZHESGLHL7XXXNU5FWHLQ6BECVA5CNFSM4E3ZHUYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJD2MLQ#issuecomment-575120942>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABABZHB6BOHGSGIQWOB35A3Q6BECVANCNFSM4E3ZHUYA> .

[aurimasniekis]

Even with just basic PHP support on graal you will have access to all other languages, libs, and extensions like java,ruby,js,r,python,c,c++ and etc. I think some of those implementations would be even ten times better than php ones.

[timglabisch]

... and it would be possible to write php's stdlib in php. currently it's an hen egg problem.

[aurimasniekis]

I think a good start would be to look into JPHP source and try to make something, I saw SimpleLang example project in Graal repo so maybe I will try to experiment when I will have time

[frank-dspeed]

@aurimasniekis your right with that you will only need php basic support no modules like its done with the nodejs implamentation graaljs-node

secund extension level will then be to recode wrappers for common php modules that are written in c like the modules written in c for nodejs

the wrapper will expose java objects with the right types inside php.

this is a example nodejs module https://unpkg.com/browse/@vertx/amqp-bridge@3.8.5/module.mjs

[frank-dspeed]

@aurimasniekis if you start the basic implementation I am willing to handle the automation and generation of the module stack I will also onboard the vertx team https://vertx.io/ that will then supply its ecosystem to you PHP implementation.

[abertschi]

Hi everyone,

I am an undergraduate student at ETH Zurich and I am interested in systems engineering, compilers and optimisations.
Evaluating performance on a PHP implementation on GraalVM seems like a good fit for a undergraduate thesis. I would love to work on such a implementation.

Initially we are planning to implement a subset of PHPs language features to measure the implementations’s peak performance on benchmarks from the Computer Language Benchmark Game (https://benchmarksgame-team.pages.debian.net/benchmarksgame/).

Implementing all language features seems to be a matter of time and commitment afterwards. Integrating PHP with other ecosystems such as vertx.io sounds like exciting following up work.

[frank-dspeed]

@abertschi start a repo call it graalphp we will later form a official graal project out of it I am at present bundling some people to jump also into that task

[abertschi]

@abertschi start a repo call it graalphp we will later form a official graal project out of it I am at present bundling some people to jump also into that task

Sounds good. The repository is going to be hosted here: https://github.com/abertschi/graalphp
I found a professor and a supervisor at ETH Zurich and can commit myself at least 30-40% of my time over the next 6 months for my thesis.

[anthonyvdotbe]

@abertschi I believe it would be useful to coordinate your effort with the core GraalVM team, for example @thomaswue, who said above:

We can potentially fund a student thesis project or internship to investigate the topic if there is a talented and motivated candidate for exploring this task.

[frank-dspeed]

@anthonyvdotbe I try to do the project management overhead all people are informed already.

[abertschi]

@abertschi I believe it would be useful to coordinate your effort with the core GraalVM team, for example @thomaswue, who said above:

We can potentially fund a student thesis project or internship to investigate the topic if there is a talented and motivated candidate for exploring this task.

@anthonyvdotbe Thanks for pointing that out. I personally would very much be interested in some form of collab/ mentoring but I have to investigate how
a thesis can be aligned with an industry partner and discuss further
details with my supervisor.

[frank-dspeed]

There is a Working Implementation! https://github.com/direktspeed/trufflephp

the new name should be trufflephp the source is at present even with the one from the Japanise Contributor author

Some slides showing it: https://github.com/direktspeed/trufflephp/raw/master/graalvm_jjug20190227.pdf

[Gasol]

the new name should be trufflephp the source is at present even with the one from the chineese contributor author

this are the slides showing it https://github.com/direktspeed/trufflephp/raw/master/graalvm_jjug20190227.pdf

Obviously, @kishida is Japanese.

[frank-dspeed]

@Gasol yes but he did rudimentary basic implementation there is an ETH Zurich Thesis project ongoing over the next 6 month that will give a more complete implementation and JPHP will also after the thesis join the overall effort: direktspeed/trufflephp#2

[abertschi]

Hi everyone, Over the past 6 months I worked on a preliminary peak
performance evaluation of a Truffle-hosted implementation for the PHP
programming language. The language implementation is currently
ca. 4000 LoC and shows promising results in the Computer Language
Benchmark Game benchmarks. We reach speedups of up to 859% compared to
PHP's reference implementation and show competitive to significantly
faster results compared to alternative implementations such as
HHVM (Hack) and JPHP.

The results and code are curated here:
https://github.com/abertschi/graalphp

More engineering efforts must be put into a feature complete
implementation. If you believe these results are promising I would
love to discuss opportunities to potentially continue the project.

[abertschi]

I uploaded the presentation I gave at ETH which summarizes the results of our experimental Truffle-hosted language implementation for PHP.

https://twitter.com/andrinbertschi/status/1308495323774550021

[Girgias]

Hi everyone, Over the past 6 months I worked on a preliminary peak
performance evaluation of a Truffle-hosted implementation for the PHP
programming language. The language implementation is currently
ca. 4000 LoC and shows promising results in the Computer Language
Benchmark Game benchmarks. We reach speedups of up to 859% compared to
PHP's reference implementation and show competitive to significantly
faster results compared to alternative implementations such as
HHVM (Hack) and JPHP.

The results and code are curated here:
https://github.com/abertschi/graalphp

More engineering efforts must be put into a feature complete
implementation. If you believe these results are promising I would
love to discuss opportunities to potentially continue the project.

Just to clarify is the reference implementation of PHP you are comparing against PHP 7.4 without OpCache support? As IIRC this is the current set-up for the Benchmark Game, due to OpCache needing a preliminary run.

It would also be interesting how this compares to PHP 8.0 and PHP 8.0 with it's newly implemented JIT.

[frank-dspeed]

@Girgias that all got covered watch the video linked on twitter from the comment above your comment

[Girgias]

@Girgias that all got covered watch the video linked on twitter from the comment above your comment

Just watched it, so PHP 8 Alpha does refer to the JIT version, however doesn't say which settings are used. This is relevant as in the first Beta release (Tagged 4th of August 2020: https://github.com/php/php-src/releases/tag/php-8.0.0beta) Changed some of default options of the JIT (see: php/php-src@0e1e991), most notably it changed from JITing all functions on first script load (mode xx0x) to a tracing JIT (mode xx3x) while also changing its optimization level from " optimized JIT based on static type inference and inner procedure analyses' (mode xxx5) to " optimized JIT based on static type inference and call tree" (mode xxx4). For reference of the modes please refer to the initial PHP RFC introducing this change (https://wiki.php.net/rfc/jit#phpini_defaults).

Moreover, some other keep parameters are not know, was PHP 7.4 run with OpCache enabled or disabled. Same for PHP 8.0. How much of OpCache's memory cache was allocated to the JIT (i.e. was opcache.jit_buffer_size= set to something other than 0). A good overview as how to test for the JIT is described in this article by one of the contributors of php-src: https://beberlei.de/2020/07/05/what_to_look_out_for_when_testing_php_jit.html

I'm not here to denigrate this project as I truly believe competition on the VM level is what brings the language forward as can be seen when Facebook released the HipHop VM (HHVM) which made a big push for performance improvements in PHP 7.0 (2x in nearly all use cases compared to PHP 5.6).
However, with the information provided in the talk I have no idea what settings where used.

It is still impressive that @abertschi and his team got a 8.5x performance increase and a ~2.5x performance (napkin maths for that one) increase compared to PHP Zend Engine JIT with their settings. But I just would like to know which settings they ran precisely. :-)

[abertschi]

Thanks a lot for asking! We used the default distribution of PHP 7 available on Ubuntu ubuntu:20.04.

The setup is reproducible in the docker file here:
https://github.com/abertschi/graalphp/tree/master/docker

Please also consider reading the technical report:
https://abertschi.ch/default_public/ethz/graalphp/download.php

The benchmarking infrastructure and timing results are stored in a database and are available here:
https://github.com/abertschi/graalphp/blob/master/benchmarks/scripts-report/bench.py

The presentation was only meant as an introduction.

The exact versions we used were:

php --version
PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies

php8 --version
PHP 8.0.0alpha3 (cli) (built: Aug  6 2020 12:31:02) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.0-dev, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.0alpha3, Copyright (c), by Zend Technologies

With JIT flags:

ini="/graalphp-build/php8/build/php/php.ini"
echo "zend_extension=opcache.so" >> $ini
echo "opcache.enable=1" >> $ini
echo "opcache.enable_cli=1" >> $ini
echo "opcache.jit_buffer_size=512M" >> $ini
echo "opcache.jit=1235" >> $ini

JPHP

jppm 0.6.7 which bundles jphp 1.0.3, Open-JDK 14

HHVM:

4.68.0 (rel)

Benchmarks were executed consecutively within a process and across multiple processes. See also report for more description.

See as an example fannkuchredux here:
https://github.com/abertschi/graalphp/blob/master/benchmarks/scripts-report/bench/fannkuchredux/fannkuchredux.php-1.php

And more information about the hardware setup:
Intel®Xeon®E-2176M CPU clocked at 2.7GHz - 4.4GHz and 16GB DDR4RAM. The device has Hyper-Threading disabled, Turbo Boost disabled, and CPU frequency driver intel pstate is used with governor performance manually set at a fixed clock rate of 2.7 GHz.

[Girgias]

Thanks a lot for asking! We used the default distribution of PHP 7 available on Ubuntu ubuntu:20.04.

The setup is reproducible in the docker file here:
https://github.com/abertschi/graalphp/tree/master/docker

Sadly my Docker skills are non existent 😓

Please also consider reading the technical report:
https://abertschi.ch/default_public/ethz/graalphp/download.php

I'll try to read this when I have some time :-)

The benchmarking infrastructure and timing results are stored in a database and are available here:
https://github.com/abertschi/graalphp/blob/master/benchmarks/scripts-report/bench.py

The presentation was only meant as an introduction.

The exact versions we used were:

php --version
PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies

php8 --version
PHP 8.0.0alpha3 (cli) (built: Aug  6 2020 12:31:02) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.0-dev, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.0alpha3, Copyright (c), by Zend Technologies

With JIT flags:

ini="/graalphp-build/php8/build/php/php.ini"
echo "zend_extension=opcache.so" >> $ini
echo "opcache.enable=1" >> $ini
echo "opcache.enable_cli=1" >> $ini
echo "opcache.jit_buffer_size=512M" >> $ini
echo "opcache.jit=1235" >> $ini

JPHP

jppm 0.6.7 which bundles jphp 1.0.3, Open-JDK 14

HHVM:

4.68.0 (rel)

Benchmarks were executed consecutively within a process and across multiple processes. See also report for more description.

See as an example fannkuchredux here:
https://github.com/abertschi/graalphp/blob/master/benchmarks/scripts-report/bench/fannkuchredux/fannkuchredux.php-1.php

And more information about the hardware setup:
Intel®Xeon®E-2176M CPU clocked at 2.7GHz - 4.4GHz and 16GB DDR4RAM. The device has Hyper-Threading disabled, Turbo Boost disabled, and CPU frequency driver intel pstate is used with governor performance manually set at a fixed clock rate of 2.7 GHz.

Thanks for the info 👍 the only thing I would probably change is to not use the CLI SAPI (Server API) but PHP-CGI as it seems to generate better results (I know I had some issues getting JIT/OpCache to work on the CLI) as stated in the article I linked above:

Do not run your examples in the CLI. Use “php-cgi” with the -T flag for reptitions. This allows Opcache and JIT to optimize on the first request, and then you can see in the following repetitions how the optimized performance is. Just for experimenting it makes sense to have “php-cgi -T 2” for running one warmup and one hot request against the same script.

Clarification: JIT works with the CLI, but I find its harder to make the exact effects visible and comparable and requires more configuration.

As an aside we probably should get back to maintaining the php-spec repo, especially as they have been some changes in how number-to-string comparisons work. But that's more a "us" job. :-)

[pabl0rg]

Aside from performance, key/huge benefit of phpGraal would be running in a managed memory environment.

[dotdevio]

Can we see an opcache.ini ? its important to enable it in cli mode.

[abertschi]

Can we see an opcache.ini ? its important to enable it in cli mode.

I am happy to give more information about the experimental setup. In order to reduce to noise in this issue I encourage you to file an issue in our github project or ping me on twitter. As I said the benchmark setup can be reproduced with the docker/podman file provided. All settings undertaken for PHP8 are here https://github.com/abertschi/graalphp/blob/2d536e40b77b7f8601ad72dfe878c09cfbc1d4e0/docker/install-php8.sh. I do not know where the "opcache.ini" file is stored. We did not manually create such a file. Opcache was enabled with "opcache.enable" and "opcache.enable_cli" in "php.ini". See docker file for more information.

[aurimasniekis]

PHP Support is now completed?

[alina-yur]

hi @aurimasniekis. Sorry for miscommunication, this is not planned at the moment.

[Spaceghost]

It hasn't been planned the whole time, what changed in the last part of '23 to close this and end visibility?

[thomaswue]

There was a great prototype created by @abertschi at https://github.com/abertschi/graalphp. We are happy to support anybody picking up that work or create a new Truffle language project around it. There are many third party language projects and also experiments out there. We list them at https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/Languages/.

[zaunere]

Hello - nothing at those links about PHP - will there be any further development on it?

Would be great to have a solid PHP engine, FFI and easy bindings to other languages since PHP is often forgotten. With fleshed out FFI, interoperability, async/etc it'd be an excellent orchestration language for pipelines. It already has great connectivity, and some great projects out there, and a common optimized engine would be very valuable.

Thank you,

Hans

[sgammon]

@zaunere He didn't say no, he just said that they are accepting contributions. https://github.com/abertschi/graalphp is definitely about PHP.

[zaunere]

Thanks Sam, it would be great to see this come back to life, and bringing in some modernization would be huge. PHP has always been about integration and agility and I think people would flock to a straightforward language that neatly implements modern techniques, while maintaining the intuitive syntax that made it famous. From web to AI pipeline, there's a void to fill that doesn't involve endless callbacks and packages. I'll see about bringing Graal PHP to 8.4 and hope to see this get out in the wild more! Thanks, Hans

…

On Sun, Aug 11, 2024 at 3:23 AM Sam Gammon ***@***.***> wrote: @zaunere <https://github.com/zaunere> He didn't say no, he just said that they are accepting contributions. https://github.com/abertschi/graalphp is definitely about PHP. — Reply to this email directly, view it on GitHub <#361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZVIJMCOJXBN233G2IOIWDZQZZD3AVCNFSM6AAAAABMJG2C62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBSGI3DQNJTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>