Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104459
MIME-Version: 1.0
References: <DM6PR02MB59326E10841277F34E4EFF75BF910@DM6PR02MB5932.namprd02.prod.outlook.com>
 <CAF+90c_LzxUTcsbdKGiJFjp=z84jLMFzq_JReXjsNygsBDVoYw@mail.gmail.com>
 <866a9262-4f49-fa20-e9d2-dcf2f4b0d320@zend.com> <6fda2b56-b99d-d383-af4d-24280767096e@zend.com>
 <CAF+90c84swz8g0siZXOp9XBAbjM0idsOUv2C8HHrxpVZWq4WVA@mail.gmail.com>
 <CAF+90c9WMQRZv0CE-hZ1BEORZbPuUMVRS8s5d4XyZeEjkqAmTg@mail.gmail.com>
 <CA+hqhpfg1WZpqEMse-_KDg6aSq6ODpzkbG92o3xLwGKizci6Xw@mail.gmail.com>
 <97e258b8-6a88-f9fa-0489-7f34455e9dfb@zend.com> <CA+hqhpc=O-TQBU18zJiND9Fg8LnR+xDn7otW9p9xhR8ei145fA@mail.gmail.com>
 <CADqioP1brsToR0fr5Yts20FMzC9rzTDzcGwSx6drA3aUfYgn6A@mail.gmail.com> <cd257ac1-4458-f831-824a-4e9309722407@zend.com>
In-Reply-To: <cd257ac1-4458-f831-824a-4e9309722407@zend.com>
Date: Mon, 18 Feb 2019 17:04:08 +0100
Message-ID: <CADqTB_j6P1q5AUvPc_UTMpZm40cFNf2skgG8oEHEwGekG4qXyg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Eugene Leonovich <gen.work@gmail.com>, Bruce Weirdan <weirdan@gmail.com>, 
	Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c6c78805822d467a"
Subject: Re: [PHP-DEV] [RFC] JIT
From: rasmus@mindplay.dk (Rasmus Schultz)

--000000000000c6c78805822d467a
Content-Type: text/plain; charset="UTF-8"

> 1.3-1.5 times speed-up

Dare I ask.

But is this even worth while?

This does not bring PHP to the level of performance where you could
reasonably implement, say, interpolated image resampling or a JPEG
decoder/encoder, correct?

This is still orders of magnitude slower than C, am I wrong?

Please don't think that I'm trying to shit on anybody's hard work, and
forgive me for asking, but how much maintenance overhead does the JIT add
to the language going forward?

Will this significantly slow down the development of every new language
feature?

If not, then by all means, please continue :-)

But if this is adding substantial maintenance overhead or significantly
increasing the barrier for contributions, I'd say, think very carefully
about this.

Developers are not picking a dynamic scripting language for the excellent
performance, unless we're talking near-C level performance (e.g. Lua-JIT
and, to my knowledge, not much else) and I don't get the impression this is
anywhere in that neighborhood?

Again, really not trying to bring down this very impressive piece of work -
but, as with any new language feature, we need to weigh complexity against
benefits, and I'm not convinced this kind of speed-up really opens PHP to
any new use-cases?

Being faster is always nice, but unless it's actually "fast", by which I
mean "fast enough to enable doing something new", it's only nice - it's not
necessarily a must.

For example, if this doesn't rival the performance of, say, WASM,
integration of a WASM engine might be a more worth while pursuit in the
long term.

Just wondering.

Please try not to see this post as aggressive or negative - I just hope
we're entering into such a major language change with eyes open? :-)

Thanks.


On Thu, Feb 14, 2019 at 7:45 AM Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> On 2/14/19 3:02 AM, Eugene Leonovich wrote:
> > On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan <weirdan@gmail.com
> > <mailto:weirdan@gmail.com>> wrote:
> >
> >     On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov <dmitry@zend.com
> >     <mailto:dmitry@zend.com>> wrote:
> >      > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
> >      > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s
> >     (95.1%)
> >      > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000
> >      > > -dopcache.jit=1201): 29.95s (92.7%)
> >      >
> >      > It may be interesting to try -dopcache.jit=1235. It should JIT
> >     only hot
> >      > functions and requires some warm-up.
> >
> >     For this use case 1201 was the fastest of all the options I tried
> >     (including 1235).
> >
> >     --
> >     PHP Internals - PHP Runtime Development Mailing List
> >     To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> > Here are my results of benchmarking rybakit/msgpack.php:
> >
> > bench.php, w/o jit:
> >      Total     9.8220     4.3121
> >
> > bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
> >      Total     8.7255     3.3350
> >
> > bench2.php, w/o jit:
> >      pure msgpack: 2.2818 sec
> >      pure msgpack packed: 2.1717 sec
> >
> > bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
> >      pure msgpack: 1.5221 sec
> >      pure msgpack packed: 1.4739 sec
> >
> > Details:
> https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f
>
> 1.3-1.5 times speed-up.
> Thanks for benchmarking.
>
> Dmitry.
>

--000000000000c6c78805822d467a--