New VM architecture

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

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

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

-----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