FAQ
Since nobody -- not even the "perpetrators" themselves -- has brought
this to this list yet I'll simply post these two links:

- http://edwardbear.org/optimizations

- http://www.edwardbear.org/fasterharderstronger.diff

I am posting this since there are already a couple of people asking
whether or not these optimizations will make into the official PHP
versions and this list seems to be the place of choice for discussing
this, no? :-)

Search Discussions

  • Jani Taskinen at Aug 25, 2003 at 11:47 pm
    That diff seems to revert some fixes made in the branch..

    --Jani

    On Mon, 25 Aug 2003, Sebastian Bergmann wrote:

    Since nobody -- not even the "perpetrators" themselves -- has brought
    this to this list yet I'll simply post these two links:

    - http://edwardbear.org/optimizations

    - http://www.edwardbear.org/fasterharderstronger.diff

    I am posting this since there are already a couple of people asking
    whether or not these optimizations will make into the official PHP
    versions and this list seems to be the place of choice for discussing
    this, no? :-)
  • Rasmus Lerdorf at Aug 26, 2003 at 1:28 am
    It would also have to be a new 4.4 branch as it breaks binary
    compatibility for extensions.

    -Rasmus
    On Tue, 26 Aug 2003, Jani Taskinen wrote:


    That diff seems to revert some fixes made in the branch..

    --Jani

    On Mon, 25 Aug 2003, Sebastian Bergmann wrote:

    Since nobody -- not even the "perpetrators" themselves -- has brought
    this to this list yet I'll simply post these two links:

    - http://edwardbear.org/optimizations

    - http://www.edwardbear.org/fasterharderstronger.diff

    I am posting this since there are already a couple of people asking
    whether or not these optimizations will make into the official PHP
    versions and this list seems to be the place of choice for discussing
    this, no? :-)
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sascha Schumann at Aug 26, 2003 at 1:32 am

    On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:

    It would also have to be a new 4.4 branch as it breaks binary
    compatibility for extensions.
    It is far from being usable in mainstream as it relies on various
    GCC features in many places. Of course, using portable C is
    a requirement for being accepted into the repository. I
    suppose the patch authors are aware of that which is why they
    have not come forward yet.

    - Sascha
  • Rasmus Lerdorf at Aug 26, 2003 at 1:41 am

    On Tue, 26 Aug 2003, Sascha Schumann wrote:
    On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:

    It would also have to be a new 4.4 branch as it breaks binary
    compatibility for extensions.
    It is far from being usable in mainstream as it relies on various
    GCC features in many places. Of course, using portable C is
    a requirement for being accepted into the repository. I
    suppose the patch authors are aware of that which is why they
    have not come forward yet.
    As long as there are appropriate checks and fallbacks, I see no problem
    using compiler-specific hacks. Especially in cases where it would benefit
    a large percentage of users.

    -Rasmus
  • Sascha Schumann at Aug 26, 2003 at 1:51 am

    As long as there are appropriate checks and fallbacks, I see no problem
    using compiler-specific hacks. Especially in cases where it would benefit
    a large percentage of users.
    Run-time execution time is not everything, otherwise the
    whole world would still be using Assembler for all
    programming.

    Hacks often adversely affect maintainability of any given
    system. For example, the computed goto hack relies on
    separate definitions of all opcodes. Failing to keep this
    list up to date can result in subtle, hard to diagnose
    failures which is undesirable for a stable system (PHP 4).

    - Sascha
  • George Schlossnagle at Aug 26, 2003 at 2:01 am

    On Monday, August 25, 2003, at 09:51 PM, Sascha Schumann wrote:

    As long as there are appropriate checks and fallbacks, I see no
    problem
    using compiler-specific hacks. Especially in cases where it would
    benefit
    a large percentage of users.
    Run-time execution time is not everything, otherwise the
    whole world would still be using Assembler for all
    programming.
    This is of course a faulty comparison, in that users don't have to
    change their programming style or language to benefit from this patch.
    Hacks often adversely affect maintainability of any given
    system. For example, the computed goto hack relies on
    separate definitions of all opcodes. Failing to keep this
    list up to date can result in subtle, hard to diagnose
    failures which is undesirable for a stable system (PHP 4).
    With a robust enough test suite the dangers of this are minimal.

    George
  • Sascha Schumann at Aug 26, 2003 at 2:16 am

    As long as there are appropriate checks and fallbacks, I see no
    problem
    using compiler-specific hacks. Especially in cases where it would
    benefit
    a large percentage of users.
    Run-time execution time is not everything, otherwise the
    whole world would still be using Assembler for all
    programming.
    This is of course a faulty comparison, in that users don't have to
    change their programming style or language to benefit from this patch.
    Rasmus advocated using compiler-specific hacks for improving
    the run-time behaviour. This reduces portability. If you
    continue that trail of thought (trading portability for
    efficiency), you end up with nothing less but Assembler.

    Anyway, George, don't turn this into an off-topic thread.
    The patch is not ready for primetime yet and no amount of
    arguing will change that.
    With a robust enough test suite the dangers of this are minimal.
    Are you volunteering?

    - Sascha
  • George Schlossnagle at Aug 26, 2003 at 2:18 am

    On Monday, August 25, 2003, at 10:15 PM, Sascha Schumann wrote:
    Anyway, George, don't turn this into an off-topic thread.
    The patch is not ready for primetime yet and no amount of
    arguing will change that.
    How is pointing out the bogusness of your arguments going off-topic?

    George
  • Sascha Schumann at Aug 26, 2003 at 2:34 am
    On Mon, 25 Aug 2003, George Schlossnagle wrote:
    On Monday, August 25, 2003, at 10:15 PM, Sascha Schumann wrote:
    Anyway, George, don't turn this into an off-topic thread.
    The patch is not ready for primetime yet and no amount of
    arguing will change that.
    How is pointing out the bogusness of your arguments going off-topic?
    George, it is one of your most annoying habits that you try
    to drag people into meta-discussions.

    End of this particular sub-thread,
    - Sascha
  • Rasmus Lerdorf at Aug 26, 2003 at 2:05 am

    On Tue, 26 Aug 2003, Sascha Schumann wrote:

    As long as there are appropriate checks and fallbacks, I see no problem
    using compiler-specific hacks. Especially in cases where it would benefit
    a large percentage of users.
    Run-time execution time is not everything, otherwise the
    whole world would still be using Assembler for all
    programming.

    Hacks often adversely affect maintainability of any given
    system. For example, the computed goto hack relies on
    separate definitions of all opcodes. Failing to keep this
    list up to date can result in subtle, hard to diagnose
    failures which is undesirable for a stable system (PHP 4).
    As if the list of opcodes is likely to change in PHP 4. That sounds like
    a bogus argument to me.

    -Rasmus
  • Sascha Schumann at Aug 26, 2003 at 2:27 am

    Hacks often adversely affect maintainability of any given
    system. For example, the computed goto hack relies on
    separate definitions of all opcodes. Failing to keep this
    list up to date can result in subtle, hard to diagnose
    failures which is undesirable for a stable system (PHP 4).
    As if the list of opcodes is likely to change in PHP 4. That sounds like
    a bogus argument to me.
    Rasmus, that was one example (zend_gc.c), not the argument
    (negative effect on maintainability). You really should know
    the difference.

    Regardless, to move the discussion forward, the patch
    contains a number of interesting concepts. Maybe
    Sterling/Thies could split them up and make them available
    for review, if they consider them to be stable enough for
    inclusion.

    - Sascha
  • Rasmus Lerdorf at Aug 26, 2003 at 2:56 am

    On Tue, 26 Aug 2003, Sascha Schumann wrote:

    Hacks often adversely affect maintainability of any given
    system. For example, the computed goto hack relies on
    separate definitions of all opcodes. Failing to keep this
    list up to date can result in subtle, hard to diagnose
    failures which is undesirable for a stable system (PHP 4).
    As if the list of opcodes is likely to change in PHP 4. That sounds like
    a bogus argument to me.
    Rasmus, that was one example (zend_gc.c), not the argument
    (negative effect on maintainability). You really should know
    the difference.
    And I do, but you were the one who picked the example. I agree that hacks
    increase maintenance work, but you picked a particularly bad example of
    that suggesting that we would have on ongoing nightmare of keeping the
    opcode table in synch when in fact the opcode table is likely to never
    change in PHP4. In a stable codebase, where features are not being added
    anymore, performance-oriented hacks are quite appropriate.

    -Rasmus
  • Sascha Schumann at Aug 26, 2003 at 3:22 am

    In a stable codebase, where features are not being added
    anymore, performance-oriented hacks are quite appropriate.
    are we a bit obsessed with the hacks? :-)

    the patch contains some optimizations which don't rely on gcc
    features and some fixes. it is prudent to consider these
    changes first.

    what remains is the execution architecture optimization. ze2
    uses function pointers where the patch relies on computed
    gotos. the latter was obviously faster to implement, but it
    is still unportable. i'd prefer to see it changed to a
    ze2-style function pointer array which works with all
    compilers. there should not be any difference
    performance-wise, especially if -fomit-frame-pointer is used.

    - Sascha
  • Andi Gutmans at Aug 26, 2003 at 5:04 am

    At 06:41 PM 8/25/2003 -0700, Rasmus Lerdorf wrote:
    On Tue, 26 Aug 2003, Sascha Schumann wrote:
    On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:

    It would also have to be a new 4.4 branch as it breaks binary
    compatibility for extensions.
    It is far from being usable in mainstream as it relies on various
    GCC features in many places. Of course, using portable C is
    a requirement for being accepted into the repository. I
    suppose the patch authors are aware of that which is why they
    have not come forward yet.
    As long as there are appropriate checks and fallbacks, I see no problem
    using compiler-specific hacks. Especially in cases where it would benefit
    a large percentage of users.
    I agree with Sascha. I actually did this patch on my own a few months ago
    and didn't feel that the performance improvement was good enough to make
    the code quite a bit less maintainable. It also makes execute() uglier
    because you need an entry point into execute to retrieve the addresses. In
    any case, it doesn't fit into the PHP 5 architecture of using a function
    call per-opcode.
    Some of their other patches are nice and I will look into them.

    Andi
  • Derick Rethans at Aug 26, 2003 at 6:12 am

    On Tue, 26 Aug 2003, Sascha Schumann wrote:
    On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:

    It would also have to be a new 4.4 branch as it breaks binary
    compatibility for extensions.
    It is far from being usable in mainstream as it relies on various
    GCC features in many places. Of course, using portable C is
    a requirement for being accepted into the repository. I
    suppose the patch authors are aware of that which is why they
    have not come forward yet.
    From their optimizations file:

    On architectures where computed gotos aren't supported, a simple define
    allows you to switch back to the switch based execution architecture.

    regards,
    Derick

    --
    "Interpreting what the GPL actually means is a job best left to those
    that read the future by examining animal entrails."
    -------------------------------------------------------------------------
    Derick Rethans http://derickrethans.nl/
    International PHP Magazine http://php-mag.net/
    -------------------------------------------------------------------------
  • Sterling Hughes at Aug 26, 2003 at 7:48 am

    On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:
    It would also have to be a new 4.4 branch as it breaks binary
    compatibility for extensions.
    It is far from being usable in mainstream as it relies on various
    GCC features in many places. Of course, using portable C is
    a requirement for being accepted into the repository. I
    suppose the patch authors are aware of that which is why they
    have not come forward yet.
    Sascha,

    Take a look at the code, the C is fully portable. Computed gotos
    are completely #ifdef'd out, meaning that if you don't compile with
    gcc we could built it with a switch() loop.

    -Sterling

    (Not getting into the discussion about inclusion, just pointing it out :)
    - Sascha

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Zeev Suraski at Aug 26, 2003 at 9:23 am

    At 10:48 26/08/2003, Sterling Hughes wrote:
    On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:

    It would also have to be a new 4.4 branch as it breaks binary
    compatibility for extensions.
    It is far from being usable in mainstream as it relies on various
    GCC features in many places. Of course, using portable C is
    a requirement for being accepted into the repository. I
    suppose the patch authors are aware of that which is why they
    have not come forward yet.
    Sascha,

    Take a look at the code, the C is fully portable. Computed gotos
    are completely #ifdef'd out, meaning that if you don't compile with
    gcc we could built it with a switch() loop.
    Guys,

    We're not going to have major changes in the 4.x branch. We'll look into
    each of the changes and decide whether to incorporate it into ZE2. Some of
    them are good (like the cached zval allocation and saved calls to
    copy_ctor/dtor) and some of them are not so good (like the lookup caching
    for variables), and some don't apply to ZE2 (like the computed gotos).

    Sebastian - I think the fact that Sterling and Thies didn't raise it here
    was intentional (could be wrong, though).

    Zeev
  • Sebastian Bergmann at Aug 26, 2003 at 11:32 am

    Zeev Suraski wrote:
    We'll look into each of the changes and decide whether to incorporate
    it into ZE2.
    That was the whole purpose of my posting -- not raising popcorn sales,
    like someone on IRC suggested ;-)
  • Cristiano Duarte at Aug 31, 2003 at 11:29 pm
    Does these hacks apply to ZE2 too ?

    "Sebastian Bergmann" <sebastian@php.net> escreveu na mensagem
    news:php.internals-4165@news.php.net...
    Since nobody -- not even the "perpetrators" themselves -- has brought
    this to this list yet I'll simply post these two links:

    - http://edwardbear.org/optimizations

    - http://www.edwardbear.org/fasterharderstronger.diff

    I am posting this since there are already a couple of people asking
    whether or not these optimizations will make into the official PHP
    versions and this list seems to be the place of choice for discussing
    this, no? :-)

    --
    Sebastian Bergmann
    http://sebastian-bergmann.de/ http://phpOpenTracker.de/

    Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
  • Sterling Hughes at Aug 31, 2003 at 11:32 pm
    yes. PHP4 was only chosen because PHP5 (Zend Engine 2) was a moving
    target, and after a day, our patch would be broken, or we'd constantly
    have to remerge. Nearly every optimization applys to Zend Engine 2,
    with the exception of the optimizations that are already in Zend Engine
    2 that is :)

    -Sterling

    Am Mo, 2003-09-01 um 01.29 schrieb Cristiano Duarte:
    Does these hacks apply to ZE2 too ?

    "Sebastian Bergmann" <sebastian@php.net> escreveu na mensagem
    news:php.internals-4165@news.php.net...
    Since nobody -- not even the "perpetrators" themselves -- has brought
    this to this list yet I'll simply post these two links:

    - http://edwardbear.org/optimizations

    - http://www.edwardbear.org/fasterharderstronger.diff

    I am posting this since there are already a couple of people asking
    whether or not these optimizations will make into the official PHP
    versions and this list seems to be the place of choice for discussing
    this, no? :-)

    --
    Sebastian Bergmann
    http://sebastian-bergmann.de/ http://phpOpenTracker.de/

    Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
    --
    We all agree on the necessity of compromise. We just can't agree on when
    it's necessary to compromise.
    - Larry Wall
  • Cristiano Duarte at Aug 31, 2003 at 11:43 pm
    How long have you been testing these hacks? Are there any side-effects ?
    Are you planning a ZE2 patch? I can test it...

    Cristiano

    "Sterling Hughes" <sterling@bumblebury.com> escreveu na mensagem
    news:1062328344.31562.57.camel@hasele...
    yes. PHP4 was only chosen because PHP5 (Zend Engine 2) was a moving
    target, and after a day, our patch would be broken, or we'd constantly
    have to remerge. Nearly every optimization applys to Zend Engine 2,
    with the exception of the optimizations that are already in Zend Engine
    2 that is :)

    -Sterling

    Am Mo, 2003-09-01 um 01.29 schrieb Cristiano Duarte:
    Does these hacks apply to ZE2 too ?

    "Sebastian Bergmann" <sebastian@php.net> escreveu na mensagem
    news:php.internals-4165@news.php.net...
    Since nobody -- not even the "perpetrators" themselves -- has
    brought
    this to this list yet I'll simply post these two links:

    - http://edwardbear.org/optimizations

    - http://www.edwardbear.org/fasterharderstronger.diff

    I am posting this since there are already a couple of people asking
    whether or not these optimizations will make into the official PHP
    versions and this list seems to be the place of choice for
    discussing
    this, no? :-)

    --
    Sebastian Bergmann
    http://sebastian-bergmann.de/
    http://phpOpenTracker.de/
    Das Buch zu PHP 5:
    http://professionelle-softwareentwicklung-mit-php5.de/
    --
    We all agree on the necessity of compromise. We just can't agree on when
    it's necessary to compromise.
    - Larry Wall
  • Sterling Hughes at Aug 31, 2003 at 11:45 pm
    we're not planning anything. sebastian brought this to the list, not
    us.

    -sterling

    Am Mo, 2003-09-01 um 01.43 schrieb Cristiano Duarte:
    How long have you been testing these hacks? Are there any side-effects ?
    Are you planning a ZE2 patch? I can test it...

    Cristiano

    "Sterling Hughes" <sterling@bumblebury.com> escreveu na mensagem
    news:1062328344.31562.57.camel@hasele...
    yes. PHP4 was only chosen because PHP5 (Zend Engine 2) was a moving
    target, and after a day, our patch would be broken, or we'd constantly
    have to remerge. Nearly every optimization applys to Zend Engine 2,
    with the exception of the optimizations that are already in Zend Engine
    2 that is :)

    -Sterling

    Am Mo, 2003-09-01 um 01.29 schrieb Cristiano Duarte:
    Does these hacks apply to ZE2 too ?

    "Sebastian Bergmann" <sebastian@php.net> escreveu na mensagem
    news:php.internals-4165@news.php.net...
    Since nobody -- not even the "perpetrators" themselves -- has
    brought
    this to this list yet I'll simply post these two links:

    - http://edwardbear.org/optimizations

    - http://www.edwardbear.org/fasterharderstronger.diff

    I am posting this since there are already a couple of people asking
    whether or not these optimizations will make into the official PHP
    versions and this list seems to be the place of choice for
    discussing
    this, no? :-)

    --
    Sebastian Bergmann
    http://sebastian-bergmann.de/
    http://phpOpenTracker.de/
    Das Buch zu PHP 5:
    http://professionelle-softwareentwicklung-mit-php5.de/
    --
    We all agree on the necessity of compromise. We just can't agree on when
    it's necessary to compromise.
    - Larry Wall
    --
    "Microsoft isn't evil, they just make really crappy operating systems."
    - Linus Torvalds

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedAug 25, '03 at 1:44p
activeAug 31, '03 at 11:45p
posts23
users10
websitephp.net

People

Translate

site design / logo © 2022 Grokbase