Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103987 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 19898 invoked from network); 1 Feb 2019 16:43:42 -0000 Received: from unknown (HELO mail-io1-f51.google.com) (209.85.166.51) by pb1.pair.com with SMTP; 1 Feb 2019 16:43:42 -0000 Received: by mail-io1-f51.google.com with SMTP id l14so5664507ioj.5 for ; Fri, 01 Feb 2019 05:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KZC1LD5hVxiqbfLNHj4rkvSmMMDocJwCvDbCARMNg+w=; b=vTUsjVCYBkIX76WGzaNWyP2QxDXld1nrO60ZAVAcESRJCKT/dl1b02qbIHJE+qZOop iNOgfjp7RGKpmmV35TvVHBB095OivHRqT2qaGcfjjuk3xbmN3UBh29UvPWhToC8BIRJg 7Ai0eBiuPLn1UaHSQmZnAThE4FnIrPQm3KYLvqVgABP2mRrEPQ5LceTef/kK2KdVyDYK +3i+obi/4ZCcVgIdNHQf5CbTFkw8iRbWVGTm2f1K2ALvBW9rZgI1t6egFwfknPVVZIQi 6pp87mtZT8VWlSxe1Z7bABQYK4Onysh8mHhZFhPrZ+BQo3014GBTZcR2+VJyj+pb1vPl jwCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KZC1LD5hVxiqbfLNHj4rkvSmMMDocJwCvDbCARMNg+w=; b=sORoGBRBr7MUYa/+GkLFWpw/1/EP6Y6R/KaH6DgQ4TQC/B8zXJJQQfrpoe74Z3XrRk vGWoAvAKonCySPX0svDrfdhVDN4zsNUqmx4fwXzpqXCkO5X8iAVOPpOPOqpej06KDkax BUbhRN28HlUtDkg0EQqFK5uu6Gu9JSx0kT+uKD07TWH3QGjkAZ+xGbId0figLgKR7Am/ YaX7hP3bSaZ1/tVnbjgmTapK3iIKxohrkvwkEf3VGUByYHZLFKQB/SzoHq0iSXUbNwAz PMzOMWCYFDZUTnZ8jfCAYx3gKM7LbXTZhWpU/dAAgWryIp0nb+/+wl2cK6lJyGtgkHEH yPWw== X-Gm-Message-State: AHQUAuYIYkqHod6EnDTluv3kQ+2KaPfhZi4gb0L2Ik1NzbMXU3dCa+Tk +AvWQWmOTFhej0DMszWTyrOrF4+btUtt1+49cODMm1Xg X-Google-Smtp-Source: AHgI3IaQ2ppLt0nKlgp9RQGSRzeO78G15PlfmeBKzyShJLfxlLsfQ7OxdqjSpWaTHr1Z6YfmhHGaq5o1ctXtdk2I73M= X-Received: by 2002:a5e:aa06:: with SMTP id s6mr22879109ioe.187.1549027430330; Fri, 01 Feb 2019 05:23:50 -0800 (PST) MIME-Version: 1.0 References: <2321148.uWQDsfDpJu@vulcan> <4df2d7cf-31dc-a9cf-eefe-d92bad199312@zend.com> In-Reply-To: Date: Fri, 1 Feb 2019 14:23:33 +0100 Message-ID: To: Dmitry Stogov Cc: Joe Watkins , Larry Garfield , "internals@lists.php.net" Content-Type: multipart/alternative; boundary="000000000000bb7ad40580d50dc5" Subject: Re: [PHP-DEV] [RFC] JIT From: nikita.ppv@gmail.com (Nikita Popov) --000000000000bb7ad40580d50dc5 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 1, 2019 at 2:12 PM Dmitry Stogov wrote: > > > On 2/1/19 11:55 AM, Joe Watkins wrote: > > Morning Dmitry, and internals, > > > > This is marvellous stuff, truly brilliant. I particularly appreciate the > > non-intrusive approach of setting jit'd code as the opcode handler, this > > makes life a little easier for hacky extension authors, I think. > > > > As others have said: > > > > I don't like the idea of omitting to support windows, less worried > > about fancy architectures. > > I can provide help to people who will going to implement JIT support for > Windows. This is not going to be easy, because MSVC doesn't support > "hybrid VM" and "global register variables", therefore the code is going > to be more expensive. > I think an important point here is that this issue affects not only Windows: It also affects any platform that uses clang as their compiler. Notably this includes MacOS. Clang theoretically supports global registers, but only for non-allocatable regs (rsp and rbp), which I think is not very useful for this purpose. So this problem needs to be solved not just for Windows support, but also for MacOS support (and also FreeBSD and other clang-using platforms). Nikita > > I'm not keen on the idea that there is no way to debug the code this > > generates outside of GDB, and I'm not sure how useful gdb will be: I've > > tried to debug JIT'd code in that before and it doesn't do so well, but > > I could easily have been doing it wrong. I'd be very happy to be > > corrected about this ? > > I'm not sure, what is wrong with GDB, and if any other debuggers have > special API for run-time generated code. > > > I'm not keen on the idea of merging this into 7.4, for various > > reasons that don't need to be repeated. > > OK. It's not only your opinion. > You may vote against, and persuade others. > > Thanks. Dmitry. > > > > > Bottom line though, I love it, it's brilliant, and look forward to PHP 8. > > > > Thank you, Dmitry. > > > > Cheers > > Joe > > > > > > On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov > > wrote: > > > > > > > > On 2/1/19 3:29 AM, Larry Garfield wrote: > > > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote: > > >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski > > wrote: > > >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen > > > > > >>> > > >>> wrote: > > >>>> Without my usual Windows bias, I do believe it is a > > considerable fact > > >>>> like Nikita pointed out as Windows is a first class citizen in > > terms > > >>>> of operating systems we support. While PHP on Windows may not > > have the > > >>>> speed that the Unix counterpart have, it is still a very > important > > >>>> development platform. Many developers develop on Windows and > > deploy on > > >>>> a Unix based system, being unable to test such an important > > feature in > > >>>> a development environment is also a large question mark. > > >>> > > >>> As long as we can agree that very few actually *deploy *on > > Windows, I > > >>> think > > >>> we're on solid grounds. > > >>> As the JIT implementation is likely to have at least *some* > > significant > > >>> differences compared to Linux, I'm not sure what testing it on > > Windows > > >>> would give you. JIT is supposed to be entirely transparent, > > and the > > >>> performance characteristics - as well as the bug patterns - are > > likely to > > >>> be quite different on Linux vs. Windows, at least in many cases. > > >>> Is it really that important to have? > > >>> > > >>> I'm honestly a bit perplexed by how many people here viewing > > Windows > > >>> support as a must have, while at the same time I think we all > > agree PHP is > > >>> very scarcely found on production Windows servers, and JIT is a > > >>> predominantly production feature. > > >>> > > >>> I'm personally interested in taking a look at it (and I'm > certain > > >>> > > >>>> Anatol does too), but simply dismissing is a no-go for me. > > >>> > > >>> It'd be interesting to evaluate the cost associated with > supporting > > >>> Windows. Bare in mind, we're proposing to vote on this as a > > production > > >>> feature for PHP 8 - which realistically means almost two years > > from now > > >>> *at > > >>> the earliest*. I'm sure we'd have Windows support a lot sooner > > than that > > >>> if we decide that it's a must have. I agree with Nikita that > > the key > > >>> question is in fact, do we or do we not want to introduce JIT > > in - with > > >>> the > > >>> main question being the maintenance cost. Let's tackle this > > question > > >>> first, otherwise - why send Dmitry (and maybe others) for doing > > more work > > >>> (Windows support) if we are likely to flush it all down the > toilet? > > >>> > > >> Maybe we're the only ones, but we run production PHP on Windows. > > I have no > > >> issues with the idea of not initially having support for > > Windows. I can > > >> probably even live with never having support for Windows - > > provided that we > > >> don't find ourselves in a situation like Nikita mentioned where > > features > > >> start getting developed in PHP instead of C and require JIT in > > order to > > >> function. > > > > > > 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. > > > > > > > > Is that a concern, or am I making things up? Or, is it a concern > > but we're > > > legit OK with that happening (which is also an entirely valid > > decision to > > > make)? > > > > > > --Larry Garfield > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > --000000000000bb7ad40580d50dc5--