Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83561 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29376 invoked from network); 23 Feb 2015 10:13:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Feb 2015 10:13:52 -0000 Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.172 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 209.85.223.172 mail-ie0-f172.google.com Received: from [209.85.223.172] ([209.85.223.172:35607] helo=mail-ie0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/DB-01128-F5DFAE45 for ; Mon, 23 Feb 2015 05:13:51 -0500 Received: by iecrl12 with SMTP id rl12so22132878iec.2 for ; Mon, 23 Feb 2015 02:13:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=+axyaMXs+NB/6ZwXivRWJGVrMdcA3bzB6BJmCjuI/eE=; b=lupLtO4cjjmIGJaPvN3JZTC1f4VGOFZcvJR7CsrQiXnzuicISvWAThcgD6U2mYWD+h LbpzRm4CkO/266VR1QyWMLpewe7CCG1QZk8uh4+VIvl4GzX59jxBycdWm1m/vRAXX1Oo 8pZkyx3rLL/4ZM4h/uAIKKA6tn1/scDJYqreuyBnEIzJE5wT2T3GWMltd6N/c166Blcq Rl0pCs0uvmk4ELT2/FHh6hwr8xFnvxaW68QEnhkOqR+9tUrDc1auhPFPgRtauSx/KQ5g 9Ydx3S6Kx+iHWNvRELM5jUUNBMUNChBPit3Tchr0SiwvoHj3E0hyg2rvm8zRsCFhmyz3 PQtw== X-Gm-Message-State: ALoCoQlxX6JZhr2PY5vcNcwVVS5bPhocbfM/DKlyg1VIcaydo0cd+b9LwvjI2xyesgKV53Z4wu8x4gRdRVpWhjSvTfK5UgJhk4juhAp87/u62g2ETxqtBT7Y8ZNsjhaoTQguiFqCKwj3jARZzs4S2v0BCKr2qUNAwA== X-Received: by 10.107.15.96 with SMTP id x93mr12816741ioi.75.1424686428890; Mon, 23 Feb 2015 02:13:48 -0800 (PST) References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com> <54EA5EDA.8010605@gmail.com> <54EA6A99.5010609@gmail.com> <54EA7F15.9030606@gmail.com> <54EA891B.6030405@gmail.com> <09b9ee836c04b1750614a91bd39a5bed@mail.gmail.com> <54EA97A2.4010701@gmail.com> <661590f4daa710176268b43c1b950583@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDXD7ehmaYKzbAddTs7O1sB4MzmgIw+OLdAe4e2iYCibfnDQEmdWqtAiDZcfAB4cR2SQJXxpD6Ais01rQBOuFyBwIXH55kA0f2RCABOSCivwHTAtd6m8gRPBA= Date: Mon, 23 Feb 2015 12:13:48 +0200 Message-ID: To: =?UTF-8?Q?Pavel_Kou=C5=99il?= , Joe Watkins Cc: PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC) From: zeev@zend.com (Zeev Suraski) > -----Original Message----- > From: Pavel Kou=C5=99il [mailto:pajousek@gmail.com] > Sent: Monday, February 23, 2015 11:49 AM > To: Joe Watkins > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins > wrote: > > Zeev, > > > >> If you can infer the type with confidence, you can do away with > >> coercion > > code altogether. > > > > Maybe I'm ignorant of something, but isn't the only way you can begin > > to infer the type with real confidence is by having strict typed > > parameters ? > > > > This sounds like the kind of strict mode we're talking about, where no > > coercion is necessary because inference is so reliable given a good > > starting place (function entry with strictly typed parameters). > > > >> If you can't, then you're not obligated to generate optimized paths > >> for > > every possible input - you can just defer to the relevant coerce() > > function. > > > > If the parameters aren't strict but are typed then you need to travel > > coercion code paths somewhere, optimized inline, calling an API > > function, it makes no real difference. > > > > I guess we are hedging our bets that having to travel those paths will > > suck away so much performance, that it will make all of the effort > > required to make any of this a reality seem, somehow ... wasted. > > > >> JIT might end up being about making PHP viable for more CPU-bound use > > cases ... > > > > This is probably quite realistic. > > > > In case anyone is reading and thinks I'm using any of this to justify > > dual mode, I'm not doing that. The original RFC justified it well > > enough, I just happen to disagree with some of the assertions made in > > this thread and or RFC. > > > > Hello, > > if I understand the issue correctly, not even strongly typed parameters > won't > help you infer types of variables with real confidence? > > Imagine this piece of code: > function foo(int $x) { $x =3D fnThatReturnsRandomScalarType(); return $x;= } Absolutely correct. On the flip side, you can very often infer type without any type hints at all. In reality we'd have to rely on that quite heavily, since code is not only about - or even mostly about - function arguments. There are local variables, function arguments can be reassigned and change type (as you illustrated), etc. For example, from bench.php: function simplecall() { for ($i =3D 0; $i < 1000000; $i++) strlen("hallo"); } You can infer with full confidence that $i is an int without having any typ= e hint information for it. This is actually a remarkably common case. Zeev