Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82932
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.192.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLsuo9ZaLiWsSciXN6ZBLT0d=7za9hO+utriREYkWT7MPA@mail.gmail.com>
References: <BLU436-SMTP151E12D0D6F709DCC26B14DE22E0@phx.gbl>
	<CA+9eiLsuo9ZaLiWsSciXN6ZBLT0d=7za9hO+utriREYkWT7MPA@mail.gmail.com>
Date: Tue, 17 Feb 2015 07:46:44 +0000
Message-ID: <CAL=_i_=Y-xKuzuxw2jk1E3TNfDOogTEKxdP6hdSiNDwjnrsFwA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6787107df761050f43e77c
Subject: Re: [PHP-DEV] Switch jumptable optimization
From: pthreads@pthreads.org (Joe Watkins)

--047d7b6787107df761050f43e77c
Content-Type: text/plain; charset=UTF-8

Very clever ... thanks bob :)

Cheers
Joe

On Tue, Feb 17, 2015 at 6:46 AM, Dmitry Stogov <dmitry@zend.com> wrote:

> On Tue, Feb 17, 2015 at 2:04 AM, Bob Weinand <bobwei9@hotmail.com> 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.
> >
> > Thanks,
> > Bob
>
>
> The patch looks interesting.
> We will implement support for opcache and then analyze its impact on
> performance.
> I see it as a self-containing feature that won't affect anyone  (except
> opcache and may be debuggers).
> I'm not going to work on it in nearest days or weeks, because of more
> critical tasks.
>
> Thanks. Dmitry.
>

--047d7b6787107df761050f43e77c--