Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82790 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21103 invoked from network); 16 Feb 2015 08:01:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Feb 2015 08:01:57 -0000 Authentication-Results: pb1.pair.com header.from=pthreads@pthreads.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=pthreads@pthreads.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.192.170 cause and error) X-PHP-List-Original-Sender: pthreads@pthreads.org X-Host-Fingerprint: 209.85.192.170 mail-pd0-f170.google.com Received: from [209.85.192.170] ([209.85.192.170:37121] helo=mail-pd0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1E/B6-05176-1F3A1E45 for ; Mon, 16 Feb 2015 03:01:56 -0500 Received: by pdbfl12 with SMTP id fl12so33599914pdb.4 for ; Mon, 16 Feb 2015 00:01:48 -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=QbErEvvqsBMu0BeNd2BuWsjfxti7n8FjyBQ2tWvp00E=; b=cUD/vq3F1STaZT+3qZK+12ua+9KFXt7N9CbH+uOHYSX7Aw3hqP+8eSQYIV1iUroSIk AFuOeBkNVokr+LUTXqIsGD3LUAC5h7G4Itx3rwEIQCowan5KfpHI8fClgBhs/iH5e+go iDDwJZGxxBtGWvg509B4JDfpogqDWRXuPdHbUhO2azoeoubrMYNjjaABmlVzMQYRER88 fLcfqVJ7jZaOMb2EdHRBN/BqF9HuylaRU6RcTI725rDNglgq3hSAUPovBNQl//TJpjDC +LaY70lAwt6apieiAZdNQ+KWhzLsgqgimLVHqUr/Ri0oe6ABRyjioSamAOoWiakLY2qZ xbpQ== X-Gm-Message-State: ALoCoQksCrT7TWh3wYudP9Ryn52lhAEZszofSKb5IwN+VXB9thTp0KX/hZXR1ez9jkh3p9qMLrx/ MIME-Version: 1.0 X-Received: by 10.70.124.163 with SMTP id mj3mr37187830pdb.110.1424073707928; Mon, 16 Feb 2015 00:01:47 -0800 (PST) Received: by 10.70.49.100 with HTTP; Mon, 16 Feb 2015 00:01:47 -0800 (PST) X-Originating-IP: [86.190.233.59] In-Reply-To: References: Date: Mon, 16 Feb 2015 08:01:47 +0000 Message-ID: To: Netroby Cc: Dmitry Stogov , Anthony Ferrara , Zeev Suraski , Andrea Faulds , Patrick ALLAERT , PHP Internals Content-Type: multipart/alternative; boundary=001a11c28f6c7ed6a4050f2fff52 Subject: Re: [PHP-DEV] PHP JIT or AOT From: pthreads@pthreads.org (Joe Watkins) --001a11c28f6c7ed6a4050f2fff52 Content-Type: text/plain; charset=UTF-8 > I would be glad, if later we'll combine our experience and work on JIT/AOT together. This is obviously something I look forward too :) Cheers Joe On Mon, Feb 16, 2015 at 8:00 AM, Joe Watkins wrote: > It's Monday morning, maybe I'm misunderstanding ... > > > 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 ? It's > knowing the types at the location being called that is important, > and needed in order to eliminate checks, isn't it ? > > 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 >> >>> > >> >>> >> >> >> >> >> > > --001a11c28f6c7ed6a4050f2fff52--