Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82796 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36949 invoked from network); 16 Feb 2015 09:10:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Feb 2015 09:10:24 -0000 Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.169 as permitted sender) X-PHP-List-Original-Sender: dmitry@zend.com X-Host-Fingerprint: 209.85.220.169 mail-vc0-f169.google.com Received: from [209.85.220.169] ([209.85.220.169:63121] helo=mail-vc0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 20/19-05176-FF3B1E45 for ; Mon, 16 Feb 2015 04:10:23 -0500 Received: by mail-vc0-f169.google.com with SMTP id kv19so10233095vcb.0 for ; Mon, 16 Feb 2015 01:10:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qHX6IybYXBwoGTzb3TIz8H+vOcpoMnPGxd/8CGLW/aw=; b=bZB0+y5yACJs4cB5FjiJVe4vSHMqyb/b//lRkZp6hjRsBq475Y7omIQMtAUAFIv6i3 E/vIFdORuS2QldMsFhwh0HPvbMUjJQQPJ5zIf7OL3H9Ckv9EsNxP+zaJ/WP4+7p+3yt6 PotLd2rJr9jA4pkSr62OBElz8eCvmqoYERfozPK2s4UUXAABue9zFgUv0Gu2xIFKtkVf vlsL3K2En3wH2HhJC3rR5k75Qd1YRnIRweQuWfCgtq70aTdk3vNd9XNQ1wWybXs0ZBHk NmjMDwHGDvLY98m6YyJ73UBYQoT8lliqBu8hZEV8A2IEob6rD64SM7Pfo8t0vowB6qAQ 8bcA== X-Gm-Message-State: ALoCoQm28DazS9P1uRRsqhULLdvX9JMaIb3YeNTj3rv8ZpgqF5kPBOBIh98D30LpKa9k8oZIvruhSK2tvskbtYzWP1v6tdg+ZOKR4VsI15ipx960MHW30FgjNNpQX+9aFxp+b9oZAI7JsiUCLxSCyLOUejlXAO3YuA== MIME-Version: 1.0 X-Received: by 10.52.26.110 with SMTP id k14mr12816781vdg.65.1424077820665; Mon, 16 Feb 2015 01:10:20 -0800 (PST) Received: by 10.52.74.73 with HTTP; Mon, 16 Feb 2015 01:10:20 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Feb 2015 13:10:20 +0400 Message-ID: To: Joe Watkins Cc: Netroby , Anthony Ferrara , Zeev Suraski , Andrea Faulds , Patrick ALLAERT , PHP Internals Content-Type: multipart/alternative; boundary=20cf307d0482a23950050f30f413 Subject: Re: [PHP-DEV] PHP JIT or AOT From: dmitry@zend.com (Dmitry Stogov) --20cf307d0482a23950050f30f413 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 16, 2015 at 11:00 AM, Joe Watkins wrote: > It's Monday morning, maybe I'm misunderstanding ... > may be I'm too :) > > > we must already know where it's called from, so we should also know the > types of passed arguments, then we may eliminate checks at all > > We'll always know the types of arguments at the call site surely ? > not always. For "foo(bar())" the type of argument passed to foo() may be unknown at compile-time, similar to foo($a[0]) or foo($a->prop). > It's knowing the types at the location being called that is important, > and needed in order to eliminate checks, isn't it ? > Right, but it's not always possible to know the types at compile time, and in this case hints may be helpful, however, strict and week hints give exactly the same information - they guarantee the type of argument inside the function. Thanks. Dmitry. > > Cheers > Joe > > On Mon, Feb 16, 2015 at 7:55 AM, Netroby wrote: > >> I guess we can gave a try. PHP 7 is fine well enough. let's working >> hard to make it published. >> >> The talk about other things should be early . let's see PHP 7 released >> and see how it will change our world. >> >> Code it , ship it. Let's see the result. >> >> Appreciate your time. >> ---------------------------- >> Netroby >> >> >> 2015-02-16 15:32 GMT+08:00 Dmitry Stogov : >> > On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins >> wrote: >> > >> >> Morning, >> >> >> >> I'm not sure where this conversation started ... >> >> >> > >> > it's a fork from "Salar Type Hints"... >> > >> > >> >> >> >> > where in non-strict mode you still need >> >> > to generation runtime conversion logic. That runtime conversion logic >> >> > then requires the ability to hook into Zend's error handling >> >> > mechanism, vastly complicating the generated code (and the generating >> >> > code). >> >> >> >> Why do you need to generate conversion logic, why can't you call Zend >> API >> >> functions ? >> >> >> > >> > Even VM just calls a conversion function. >> > >> > Alternatively, possibly preferably, wouldn't a guard to tell if the >> >> function is being called in strict mode >> >> be a good idea here ? >> >> >> > >> > If we know what function is called in strict mode, we must already know >> > where it's called from, so we should also know the types of passed >> > arguments, then we may eliminate checks at all (independently on >> > strictness). If we don't know the types we will need to check them >> anyway. >> > >> > >> >> If the generated code is really complicated and that sucks away the >> >> performance >> >> then why not just avoid it, and only enter machine code when a >> function is >> >> called in strict mode ? >> >> >> >> I see the assembly generated by your JIT, but it doesn't really tell us >> >> much, it tells us a little, >> >> what would be really useful is seeing your research, with the >> >> understanding that it is just research. >> >> Please think about that again. >> >> >> > >> > Yeah, we will need to open it, even if it doesn't make gain for real >> life. >> > but lets make all the PHP7 related work first. >> > I would be glad, if later we'll combine our experience and work on >> JIT/AOT >> > together. >> > >> > Thanks. Dmitry. >> > >> > >> >> >> >> Cheers >> >> Joe >> >> >> >> On Mon, Feb 16, 2015 at 6:59 AM, Dmitry Stogov >> wrote: >> >> >> >>> On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara < >> ircmaxell@gmail.com> >> >>> wrote: >> >>> >> >>> > Dmitry, >> >>> > >> >>> > On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov >> wrote: >> >>> > > Hi Anthony, >> >>> > > >> >>> > > If you are working on JIT, you should understand that declare() >> >>> switch to >> >>> > > strict typing can't improve anything, because it works on caller >> side >> >>> > and in >> >>> > > each function you now will have to generate code for both weak and >> >>> strict >> >>> > > checks. >> >>> > >> >>> > Well, if you know the destination function at compile time, you >> don't >> >>> > need to generate generic code. you can generate a direct dispatch >> >>> > (asm-level function call). >> >>> >> >>> >> >>> Right, but in real life app you almost never know what function or >> method >> >>> you are really call. At function you also can't be sure that it always >> >>> called with proper arguments. This work well only for plain function >> >>> placed >> >>> into a single PHP file. >> >>> >> >>> >> >>> > In this case, strict lets you push type >> >>> > checks back to compile time, where in non-strict mode you still need >> >>> > to generation runtime conversion logic. That runtime conversion >> logic >> >>> > then requires the ability to hook into Zend's error handling >> >>> > mechanism, vastly complicating the generated code (and the >> generating >> >>> > code). >> >>> > >> >>> >> >>> For cases when you know the called function and all passed and >> expected >> >>> types, it's possible to use more efficient calling convention passing >> real >> >>> arguments in CPU registers. >> >>> >> >>> The type checks in PHP7 is quite cheap (2-3 CPU instructions). Strict >> or >> >>> weak check doesn't make any difference for "fast path" (the same 2-3 >> >>> instructions). The slow patch for weak checks is going to be a bit >> more >> >>> expensive. >> >>> >> >>> >> >>> > >> >>> > In fact, the research I have been doing is precisely around that >> >>> > (where I know for a fact that all remaining function calls are going >> >>> > to be typed, and compile the entire block at one time with direct >> >>> > calls). So that way I never need to actually do even as much as a >> FCC >> >>> > to call a userland function. Which then lets me avoid generating >> >>> > typing code (since I know the types). Which is why I'm advocating >> for >> >>> > strict, since that way we can treat an entire graph of function >> calls >> >>> > as strict and compile them all in one go (no need to even JIT at >> >>> > runtime, just compile AOT). >> >>> > >> >>> > If your research has shown something different, care to share? >> >>> > >> >>> >> >>> Very similar :), but in cases when we know the called function the >> effect >> >>> from type hinting is negligible. It's almost always possible to >> generate >> >>> optimal code without any hints. >> >>> >> >>> See code for fibo_r() from bench.php generated by our old JIT for >> PHP-5.5 >> >>> (without type hinting): >> >>> https://gist.github.com/dstogov/5f71d23f387332e9d77c >> >>> >> >>> Unfortunately, we didn't make the same for PHP7 yet. >> >>> More important, in our experiments we saw improvements only on small >> >>> benchmarks (e.g. 25 times on mandelbrot), but nothing on real-life >> apps. >> >>> >> >>> So a some point, looking into ASM code that endlessly allocates and >> frees >> >>> zvals, we switched to engine re-factoring. >> >>> >> >>> >> >>> > >> >>> > > According to mandel() and integer to float conversion in the loop, >> >>> it's >> >>> > > possible to perform a backward data-propagation pass to catch this >> >>> case >> >>> > and >> >>> > > replace integer by float in first place. We did it in our old JIT >> >>> > prototypes >> >>> > > without any type hinting. Also, don't use "fild", use SSE2 and/or >> AVX. >> >>> > >> >>> > I did wind up doing a few passes to back-propagate the cast (among >> >>> > other optimizations). But it's still a point that the conversions >> >>> > aren't exactly cheap. But as I said before, that was a side-note and >> >>> > not really an argument for/against strict typing. So worth >> mentioning, >> >>> > but shouldn't affect anyone's decision. >> >>> > >> >>> > Re fild vs SSE/AVX: that was up to the backend code generator we >> were >> >>> > using (libjit). It may be an open req against that lib to generate >> the >> >>> > different instruction, or perhaps it just failed a heuristic. We >> were >> >>> > working a level higher than the generated ASM, so not really 100% >> sure >> >>> > why it made that decision. >> >>> > >> >>> >> >>> I saw a big speed difference between FPU and SSE2/AVX code on >> bench.php, >> >>> so >> >>> if you may tell libjit to use SSE2/AVX - do it. >> >>> >> >>> Thanks. Dmitry. >> >>> >> >>> >> >>> >> >>> >> >>> > >> >>> > Anthony >> >>> > >> >>> >> >> >> >> >> > > --20cf307d0482a23950050f30f413--