# New VM architecture - Thread: https://externals.io/message/12935 - Original archive: https://news-web.php.net/php.internals/12935 - Started by Andi Gutmans on 2004-09-22T18:09:47+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #12935 — Andi Gutmans — 2004-09-22T18:09:47+00:00 URL: https://externals.io/message/12935#12935 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 --- ## #12937 — Derick Rethans — 2004-09-22T18:17:47+00:00 URL: https://externals.io/message/12935#12937 · In reply to: #12935 > 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 --- ## #12939 — Marcus Boerger — 2004-09-22T20:49:26+00:00 URL: https://externals.io/message/12935#12939 · In reply to: #12937 Hello Andi, Wednesday, September 22, 2004, 8:17:47 PM, Derick Rethans wrote: > > > […] > 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 --- ## #12945 — Thies C.Arntzen — 2004-09-23T08:31:49+00:00 URL: https://externals.io/message/12935#12945 · In reply to: #12935 On 2004-09-22 20:09:47 +0200, Andi Gutmans 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 --- ## #12950 — Andi Gutmans — 2004-09-23T16:06:18+00:00 URL: https://externals.io/message/12935#12950 · In reply to: #12935 At 10:31 AM 9/23/2004 +0200, Thies C. Arntzen wrote: >On 2004-09-22 20:09:47 +0200, Andi Gutmans said: > > > […] > >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 --- ## #12965 — Elfyn McBratney — 2004-09-24T17:17:37+00:00 URL: https://externals.io/message/12935#12965 · In reply to: #12935 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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