Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82905
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.220.50 as permitted sender)
Message-ID: <54E2838D.5000907@lerdorf.com>
Date: Mon, 16 Feb 2015 15:55:57 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Bob Weinand <bobwei9@hotmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <BLU436-SMTP151E12D0D6F709DCC26B14DE22E0@phx.gbl> <54E27D8D.5020901@lerdorf.com> <BLU436-SMTP20447FF9B28ABAAB9089513E22E0@phx.gbl>
In-Reply-To: <BLU436-SMTP20447FF9B28ABAAB9089513E22E0@phx.gbl>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="FfN0oEO4vKdGvrABdcAGQ36olhqxIEWMm"
Subject: Re: [PHP-DEV] Switch jumptable optimization
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--FfN0oEO4vKdGvrABdcAGQ36olhqxIEWMm
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 02/16/2015 03:47 PM, Bob Weinand wrote:
>> Am 17.02.2015 um 00:30 schrieb Rasmus Lerdorf <rasmus@lerdorf.com
>> <mailto:rasmus@lerdorf.com>>:
>>
>> On 02/16/2015 03:04 PM, Bob Weinand wrote:
>>> I'd like to show you my recent work on a jumptable optimization for
>>> switches.
>>>
>>> https://github.com/php/php-src/pull/1048
>>> <https://github.com/php/php-src/pull/1048>
>>>
>>> It is a fully transparent optimization of switches, by putting a new
>>> ZEND_SWITCH opcode at the top of the switch in case we can build a
>>> jumptable, which is the case if the cases are only scalars (no
>>> doubles) or evaluate to them at compile-time.
>>>
>>> Switches tend to be big sometimes with a lot of static (literals or
>>> constants usually) cases, which was a comparison for each case, and
>>> now just a simple hashtable lookup is needed, which greatly improves
>>> performance. In case where the result of the switch can be determined=

>>> at compile-time, it even replaces the comparisons with a simple
>>> ZEND_JMP opcode.
>>>
>>> In synthetic benchmarks the results are mind blowing, but in
>>> practice, benefits mostly are stateful userland parsers (often called=

>>> with sometimes big switches), where it makes it a few percent faster.=

>>> (For more concrete numbers see
>>> https://github.com/php/php-src/pull/1048#issuecomment-73032647)
>>>
>>> As the optimization is only done if there are 3 or more cases, the
>>> lookup is always faster than the single comparisons. So there's no
>>> negative performance impact.
>>>
>>> It already works, except with opcache where the CFG optimization pass=

>>> still lacks support. Dmitry or Laruence volunteered to add support
>>> for opcache.
>>>
>>> I'd like to know if there are any technical objections to the PR. If
>>> not, they will add opcache support and merge it in.
>>
>> It looks ok to me if Xinchen or Dmitry gets the opcache support workin=
g
>> for it and the feature is stabilized in time. I gave it a try and it i=
s
>> segfaulting for me (no opcache):
>>
>> =3D=3D5612=3D=3D Command: sapi/cli/php -n jump.php
>> =3D=3D5612=3D=3D
>> =3D=3D5612=3D=3D Invalid read of size 4
>> =3D=3D5612=3D=3D    at 0xA64637: _zend_is_inconsistent (zend_hash.c:44=
)
>> =3D=3D5612=3D=3D    by 0xA65749: _zend_hash_add_or_update_i (zend_hash=
=2Ec:427)
>> =3D=3D5612=3D=3D    by 0xA65AF9: _zend_hash_add (zend_hash.c:489)
>> =3D=3D5612=3D=3D    by 0xA37E28: zend_hash_add_ptr (zend_hash.h:458)
>> =3D=3D5612=3D=3D    by 0xA39B0A: zend_hash_add_constant (zend_constant=
s.c:486)
>> =3D=3D5612=3D=3D    by 0xA39D01: zend_register_constant (zend_constant=
s.c:523)
>> =3D=3D5612=3D=3D    by 0xA389E9: zend_register_long_constant
>> (zend_constants.c:194)
>> =3D=3D5612=3D=3D    by 0xA3855C: zend_register_standard_constants
>> (zend_constants.c:116)
>> =3D=3D5612=3D=3D    by 0xA52D6E: zend_startup (zend.c:671)
>> =3D=3D5612=3D=3D    by 0x9C7FAA: php_module_startup (main.c:2099)
>> =3D=3D5612=3D=3D    by 0xAFA460: php_cli_startup (php_cli.c:421)
>> =3D=3D5612=3D=3D    by 0xAFC4D6: main (php_cli.c:1335)
>> =3D=3D5612=3D=3D  Address 0x8 is not stack'd, malloc'd or (recently) f=
ree'd
>>
>> And jump.php is:
>>
>> <?php
>> $a =3D 1;
>> switch($a) {
>> case 0: echo 0; break;
>> case 1: echo 1; break;
>> case 2: echo 1; break;
>> case 3: echo 1; break;
>> case 4: echo 1; break;
>> case 5: echo 1; break;
>> case 6: echo 1; break;
>> case 7: echo 1; break;
>> case 8: echo 1; break;
>> case 9: echo 1; break;
>> }
>>
>> -Rasmus
>=20
> Hey,
>=20
> this doesn't really look related to my patch. Did you do something wron=
g
> when cloning my branch? Or forget a make clean or similar?
>=20
> Locally it works for me and echoes 1 as expected.

Ah, looks like you are right. A full distclean cleared it up. I had just
done a distclean, but I had built once before applying your patch.
Crappy Makefile deps..

-Rasmus



--FfN0oEO4vKdGvrABdcAGQ36olhqxIEWMm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlTig40ACgkQlxayKTuqOuAnvQCfetBapujPAW/SK/vUUuzfmCCR
0+4An0Vf0D7nr8mg4p0xOfK3xurgb146
=/vMJ
-----END PGP SIGNATURE-----

--FfN0oEO4vKdGvrABdcAGQ36olhqxIEWMm--