Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » New VM architecture »

New VM architecture

php.internals

Andi Gutmans

21 years ago
Guys, There's no feedback about the new VM architecture and it's hard to maintain the patches as changes are being made to the source base constantly. I will recommit the patches on Monday unless someone has reasonable objections. I reverted the patch so that people had time to review but it doesn't seem to have happened eventhough I've sent out two reminders. In general, this patch improves performance by about 20% and supports goto opcode threading. I don't see a very good reason not to commit it. Andi

Derick Rethans

21 years ago
On Wed, 22 Sep 2004, Andi Gutmans wrote:
> Guys, > > There's no feedback about the new VM architecture and it's hard to maintain > the patches as changes are being made to the source base constantly. > I will recommit the patches on Monday unless someone has reasonable > objections. I reverted the patch so that people had time to review but it > doesn't seem to have happened eventhough I've sent out two reminders. > In general, this patch improves performance by about 20% and supports goto > opcode threading. I don't see a very good reason not to commit it.
As long as there is still a way to overload opcodes in some way, I see no problem. I would have liked to test it, but simply couldn't find the time yet. Derick

Marcus Börger

21 years ago
Hello Andi, Wednesday, September 22, 2004, 8:17:47 PM, Derick Rethans wrote:
> On Wed, 22 Sep 2004, Andi Gutmans wrote:
>> Guys, >> >> There's no feedback about the new VM architecture and it's hard to maintain >> the patches as changes are being made to the source base constantly. >> I will recommit the patches on Monday unless someone has reasonable >> objections. I reverted the patch so that people had time to review but it >> doesn't seem to have happened eventhough I've sent out two reminders. >> In general, this patch improves performance by about 20% and supports goto >> opcode threading. I don't see a very good reason not to commit it.
> As long as there is still a way to overload opcodes in some way, I see > no problem. I would have liked to test it, but simply couldn't find the > time yet.
Obviously everyone who cares liked the patch besides the need to be able to overload....'and the chaos kept it's silence'...silence as agreement :-) best regards marcus
-- Best regards, Marcus mailto:helly@php.net

Thies C. Arntzen

21 years ago
On 2004-09-22 20:09:47 +0200, Andi Gutmans <andi@zend.com> said:
> Guys, > > There's no feedback about the new VM architecture and it's hard to > maintain the patches as changes are being made to the source base > constantly. > I will recommit the patches on Monday unless someone has reasonable > objections. I reverted the patch so that people had time to review but > it doesn't seem to have happened eventhough I've sent out two reminders. > In general, this patch improves performance by about 20% and supports > goto opcode threading. I don't see a very good reason not to commit it.
andi, i really think it's time to write some engine-level benchmarks (loops etc) so we can actually see the improvement. even though i really think that the VM-loop should be generated and not done thru cpp-magic i think committing it is a "step forward" .remember, sterling and i had a patch for this (& more) more than a year ago... what's next? thies

Dmitry Stogov

21 years ago
The problem, that not all C compilers support direct threaded code (GOTO), so we cannot generate one code that will run with all compilers. And we will get a lot of troubles with support different executors. Now with this patch we use one executor's definition and can select different threading model in compile time. Also, the patch makes opcode specialization so definition for one opcode may be converted (in compile-time) into 16 different handlers. Thanks. Dmitry.

Andi Gutmans

21 years ago
At 10:31 AM 9/23/2004 +0200, Thies C. Arntzen wrote:
>On 2004-09-22 20:09:47 +0200, Andi Gutmans <andi@zend.com> said: > >>Guys, >>There's no feedback about the new VM architecture and it's hard to >>maintain the patches as changes are being made to the source base constantly. >>I will recommit the patches on Monday unless someone has reasonable >>objections. I reverted the patch so that people had time to review but it >>doesn't seem to have happened eventhough I've sent out two reminders. >>In general, this patch improves performance by about 20% and supports >>goto opcode threading. I don't see a very good reason not to commit it. > >andi, > >i really think it's time to write some engine-level benchmarks (loops etc) >so we can actually see the improvement.
We have something quite synthetic (loops and function calls) so I wouldn't give it too much weight but I'll commit it to the Zend CVS.
>even though i really think that the VM-loop should be generated and not >done thru cpp-magic i think committing it is a "step forward" .remember, >sterling and i had a patch for this (& more) more than a year ago...
Yeah, I actually also did this patch in the past (the threading patch) but threw it away because I didn't want to hard code it, especially as many compilers don't work with it. Now we thought of an automated way of doing it where we can also easily change the execution architecture. That is the reason it has waited for so long, because we never had the right implementation. What's next? Well I'd like to get the realpath() into PHP. We've played around with taking the function handler execution architecture and serializing it into machine code but it doesn't really improve performance over the threaded goto. The main problem also is that when you check the non-synthetic benchmarks but real life apps like php-nuke or other apps, then the bottlenecks are usually elsewhere. Andi

Elfyn McBratney

21 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 22 Sep 2004 19:09, Andi Gutmans wrote:
> Guys, > > There's no feedback about the new VM architecture and it's hard to maintain > the patches as changes are being made to the source base constantly. > I will recommit the patches on Monday unless someone has reasonable > objections. I reverted the patch so that people had time to review but it > doesn't seem to have happened eventhough I've sent out two reminders. > In general, this patch improves performance by about 20% and supports goto > opcode threading. I don't see a very good reason not to commit it.
Code looks swell, similar methodology we're gonna use for a new db losqe ;-) I'm gonna try and get this into Gentoo as a useflag, so hopefully this and the realpath (other caches? ;-) stuff can get some more widespread testing/free qa 0-) Is this ok by you guys? Elfyn - -- Elfyn McBratney beu on irc.freenode.net/savannah.[non]gnu.org PGP Key ID: 0x456548B4 PGP Key Fingerprint: 29D5 91BB 8748 7CC9 650F 31FE 6888 0C2A 4565 48B4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBVFaxaIgMKkVlSLQRAjR0AKCHjJtO299dNBTZ/361iOhjcL0TJgCffO51 qfphN62UPEhzS/6CJEePzP0= =HyDy -----END PGP SIGNATURE-----