FAQ
Hi,

Attached is a patch to optimize variable fetches (basically it caches the
fetches so that variables aren't re-fetched every time, most noticeable in
loops with the loop control counter but also it's a general improvement).
It's similar to the patch Sterling and Thies did a year ago in their
optimization patch.
As compiling the zend_execute.c file is starting to take a long time
(minutes) due to inlining with the goto VM architecture, I suggest to apply
Zend.m4 to make the default the function handler paradigm. The performance
difference is not big and it'll make it easier to work on PHP. For
production environments one can use a configure switch to turn this on.
I'd
be happy to hear of benchmarks.

In general, there might be problems with extensions which access the active
symbol table directly. It's something I still need to look into so please
report any problems.

Please try and take some time to test it.

Andi

Search Discussions

  • Andi Gutmans at Oct 1, 2004 at 4:40 pm
    http://snaps.php.net/~andi/Zend.m4.diff.gz
    http://snaps.php.net/~andi/cv.diff.gz
    At 09:31 AM 10/1/2004 -0700, Andi Gutmans wrote:
    Hi,

    Attached is a patch to optimize variable fetches (basically it caches the
    fetches so that variables aren't re-fetched every time, most noticeable in
    loops with the loop control counter but also it's a general improvement).
    It's similar to the patch Sterling and Thies did a year ago in their
    optimization patch.
    As compiling the zend_execute.c file is starting to take a long time
    (minutes) due to inlining with the goto VM architecture, I suggest to
    apply Zend.m4 to make the default the function handler paradigm. The
    performance difference is not big and it'll make it easier to work on PHP.
    For production environments one can use a configure switch to turn this on.
    I'd be happy to hear of benchmarks.

    In general, there might be problems with extensions which access the
    active symbol table directly. It's something I still need to look into so
    please report any problems.

    Please try and take some time to test it.

    Andi


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Thies C . Arntzen at Oct 2, 2004 at 10:44 am
    before: 34.430
    after: 20.126

    do i need to say more?

    (if it really works, which i haven't tested yet)

    great andi!
    re,
    tc

    PS: i really think that the vm should be generated by a script! looking
    at what makes most of the patch i really think that we're making
    hacking the engine more complex than needed.

    On 2004-10-01 18:31:37 +0200, Andi Gutmans <andi@zend.com> said:
    Hi,

    Attached is a patch to optimize variable fetches (basically it caches
    the fetches so that variables aren't re-fetched every time, most
    noticeable in loops with the loop control counter but also it's a
    general improvement).
    It's similar to the patch Sterling and Thies did a year ago in their
    optimization patch.
    As compiling the zend_execute.c file is starting to take a long time
    (minutes) due to inlining with the goto VM architecture, I suggest to
    apply Zend.m4 to make the default the function handler paradigm. The
    performance difference is not big and it'll make it easier to work on
    PHP. For production environments one can use a configure switch to turn
    this on.
    I'd be happy to hear of benchmarks.

    In general, there might be problems with extensions which access the
    active symbol table directly. It's something I still need to look into
    so please report any problems.

    Please try and take some time to test it.

    Andi
  • Andi Gutmans at Oct 4, 2004 at 8:08 pm

    At 12:44 PM 10/2/2004 +0200, Thies C. Arntzen wrote:
    before: 34.430
    after: 20.126

    do i need to say more?

    (if it really works, which i haven't tested yet)
    Made another fix (we had to take care of global variables being messed with
    by extensions).
    PS: i really think that the vm should be generated by a script! looking at
    what makes most of the patch i really think that we're making hacking the
    engine more complex than needed.
    I am not sure. There are advantages and disadvantages to both.

    pre-processor vs. script
    Advantage: Only maintain source and not script (which might be icky), no
    pre-build scripts (which might be a PITA on platforms like Windows), no
    script portability issues
    Disadvantages: More magic in the source code itself, might be slightly
    harder to debug.

    Frankly, I am not sure what's better. I think it might be a good idea to
    see what can be done with a script and then compare. Will look into it.

    Andi
  • Andrei Zmievski at Oct 6, 2004 at 8:40 pm

    On Sat, 02 Oct 2004, Thies C. Arntzen wrote:
    PS: i really think that the vm should be generated by a script! looking
    at what makes most of the patch i really think that we're making
    hacking the engine more complex than needed.
    I agree..

    - Andrei
  • Wez Furlong at Oct 6, 2004 at 10:10 pm
    I'm a big fan of making the computer do the work on our behalf (that's
    what it's there for, right?).

    It shouldn't be a huge problem to write a php script to generate the
    different executors from a source file. If you're worried about
    bootstrapping, we can keep the generated files in CVS and/or bundle
    them pre-generated in the distro.

    --Wez.


    On Wed, 6 Oct 2004 13:36:38 -0700, Andrei Zmievski
    wrote:
    On Sat, 02 Oct 2004, Thies C. Arntzen wrote:
    PS: i really think that the vm should be generated by a script! looking
    at what makes most of the patch i really think that we're making
    hacking the engine more complex than needed.
    I agree..

    - Andrei
  • Sterling Hughes at Oct 6, 2004 at 10:14 pm

    Wez Furlong wrote:
    I'm a big fan of making the computer do the work on our behalf (that's
    what it's there for, right?).

    It shouldn't be a huge problem to write a php script to generate the
    different executors from a source file. If you're worried about
    bootstrapping, we can keep the generated files in CVS and/or bundle
    them pre-generated in the distro.
    Yeah, actually Dmitry wrote a script that converted the old executor
    into the new executor, so the script was already there. I think its
    that Andi doesn't like the concept (I do like the concept btw), not the
    work involved. Personally, I'd prefer to see the executor generated, so
    long as the source format is well thought-out. Cause it will allow us
    to do things like, for example, generating an x86 JIT.

    -Sterling
  • Andi Gutmans at Oct 6, 2004 at 10:28 pm

    At 03:15 PM 10/6/2004 -0700, Sterling Hughes wrote:
    Yeah, actually Dmitry wrote a script that converted the old executor into
    the new executor, so the script was already there. I think its that Andi
    doesn't like the concept (I do like the concept btw), not the work
    involved. Personally, I'd prefer to see the executor generated, so long
    as the source format is well thought-out. Cause it will allow us to do
    things like, for example, generating an x86 JIT.
    I actually liked the concept too :) (my initial prototype was a script). I
    agree that the macro's aren't that easy to handle.
    We're working on doing this with a script now, which means that it'll be
    easier to see what's going on (the script will be slightly harder to
    maintain but it's probably worth it).
    We might need to keep the generated files in CVS but that shouldn't be a
    problem.

    Andi

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 1, '04 at 4:31p
activeOct 6, '04 at 10:28p
posts8
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase