Re: [RFC] JIT
| From: | Larry Garfield | Date: | Fri, 01 Feb 2019 16:30:37 +0000 |
| Subject: | Re: [RFC] JIT | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-103990@lists.php.net to get a copy of this message | ||
On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote:
> On 2/1/19 3:29 AM, Larry Garfield wrote:
> > Question from a non-compiler-engineer: Could we end up in a situation
> > where
> > future language features (in 8.3 or something) are only performant on JIT-
> > enabled platforms? I know there were some RFCs rejected in the past on
> > the
> > grounds that they involved too many runtime checks (and thus a performance
> > hit); if it were possible for a JIT to optimize some of those away, it
> > might make the cost acceptable. However, if a JIT only works on some
> > systems that might widen the gap between have- and have-not platforms.
>
> I think, JIT only approach doesn't make a lot of sense for PHP, with one
> of the most fast VM. And this is a trend. Even V8, starting from JIT
> only, switched back to VM+JIT.
>
> Thanks. Dmitry.
I'm... not sure how that answers my question? I'm saying "if we had a VM+JIT,
and the JIT part made feature X acceptably fast but it wasn't acceptably fast
with just the VM, is that a problem?" Or is that a situation that cannot
happen? Or that we don't care if it happens?
--Larry Garfield
Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc
Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc