Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104124
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=X5oLVRFxkKfNPW2NlQmX0rT9vUayP3qUU1bTiYmaScl4plGLa4BII5X6cZVMjL
	malyWYRA7B8I2YsiBNWbkPzAFL5MZCm5UdKmOLEstmd9d4eopy8VWMv4JyoduK/O
	qXlDrXFhZkw7l+uQCZb9hcHyV4rgSCnN4truUQjRgu20I=;
MIME-Version: 1.0
References: <DM6PR02MB59326E10841277F34E4EFF75BF910@DM6PR02MB5932.namprd02.prod.outlook.com> <5c5814e2.1c69fb81.ba123.0510SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5c5814e2.1c69fb81.ba123.0510SMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 4 Feb 2019 16:45:09 +0200
Message-ID: <CAJHtznxDLN6R4GjMALA6LbPVKeRAZQZ_33G7+fSgrfQeFsTR3g@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c1c7190581128a40"
Subject: Re: [PHP-DEV] [RFC] JIT
From: zeev@php.net (Zeev Suraski)

--000000000000c1c7190581128a40
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 4, 2019 at 12:33 PM Andrea Faulds <ajf@ajf.me> wrote:

> A concern I have with the current RFC is a lack of a good case for why
> it should be necessary;


While this is a subjective opinion, it's definitely a valid one.  Unlike
phpng (PHP 7) which was a slam dunk - JIT isn't - and whether or not the
added value is worth the added complexity is very much up for debate.

One our hopes in opening this up for comments, is that people would
actually try the code themselves and experiment with it - well beyond what
we can do ourselves.  If & when we get feedback from folks on apps and use
cases they tried this on with interesting results, we'll add them to the
RFC.  I'd love to hear from folks trying it on things like React.  Then,
there's also the possibility of writing builtin functions in PHP - although
that would obviously require a much wider platform support than we
presently have to be viable.


> and not much else. Maybe PHP being able to be used for this kind of
> software would be cool, but it wouldn't justify the added complexity
> (and for that matter security headaches) of adding a JIT to PHP given C,
> C++, FORTRAN and so on already exist and are better-suited to it.
>

This too is a subjective (& obviously completely valid) opinion.  Of
course, if the only point of JIT would be 'coolness' then it's probably not
worth the trouble (although JIT is a huge selling point even if it doesn't
bring huge gains, as we've seen in the past).  But I don't think it'll end
just there.  For me, I would prefer using PHP over any of these if I can
help it and if the performance is reasonable enough - and I doubt I'm the
only person on the planet that feels that way.  Again, we don't think it's
a slam dunk (the RFC would have looked differently if we did), but it's not
inconceivable that if we position PHP as a language where you can get the
ease of development benefits of PHP, while getting near-native performance
- it will open the door to new audiences.

Zeev

--000000000000c1c7190581128a40--