Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104424 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 15340 invoked from network); 15 Feb 2019 01:21:54 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 15 Feb 2019 01:21:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1550786722; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=tVw15b2o2CnaiS8/FXYUPR 7Zag53DZjGGdmStsbP21M=; b=mB3aKI8iOsnrNNcZZianw090yTDY3Uo7VYgNF0 geS2Hzbn5CesYeivKwo2AzDpzZyw6J99+2PXvSXAQDLusJqKMZNmNfLKL9V9n6I7 wHrluA/Lo9rkuYarrLrlCDv7bmETnPi4FuvOQ1SCjb5mqiIzYtjhqe3OoCagVpTM P9uqc= 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=wkNcHcTqdE29WS2WQFKCIqpUugcCgtlMgunA+btq80wynD3Mi2iWuyDWQ82XNk 1iz67Dn0nMWeegLcELQDETXGMfrbJrpNGgKY3dNT3bssJ2LBAoJFbUsHSgahr/e+ hBUCYlzqzLz2kiJG+mF2S9CPyp29qpJxpJF+kAm9Y6tBU=; Received: (qmail 4943 invoked from network); 14 Feb 2019 22:05:22 -0000 Received: X-TurboSMTP-Tracking: 4853749259 X-Gm-Message-State: AHQUAuaStyCzRaVf/0bXM4NTItVp2HpwP+jsqHcwAySHMbIkrLen2dvX 63lson7QsHV2ONsXUJ9YniLp2SuktdCKuT2r/eI= X-Google-Smtp-Source: AHgI3Ibh5TugnAqHjfrPrFKBa7B3qzlCw9kBVF00r/m9t/5r+ss+86vvz24qIpMbPKjgd/NHljDGoodzf/nod9F+Hhc= X-Received: by 2002:ac8:2598:: with SMTP id e24mr5121345qte.27.1550181922026; Thu, 14 Feb 2019 14:05:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 15 Feb 2019 00:05:10 +0200 X-Gmail-Original-Message-Id: Message-ID: To: Levi Morrison Cc: Joe Watkins , Rowan Collins , PHP internals Content-Type: multipart/alternative; boundary="000000000000ccbb990581e1dada" Subject: Re: [PHP-DEV] Re: ZTS improvement idea From: zeev@php.net (Zeev Suraski) --000000000000ccbb990581e1dada Content-Type: text/plain; charset="UTF-8" On Thu, Feb 14, 2019 at 7:27 PM Levi Morrison wrote: > To all internals, but especially to Zeev and Dmitry, > > Having a JIT which does not support ZTS is a bit short-sighted. I don't think anybody's advocating for not having ZTS support for JIT. I am questioning the portof the absence of ZTS support in the current JIT as an absolute deal breaker. The question is do we need ZTS support for JIT in February 2019, ~2 years before PHP 8 comes out, or is it OK that it will be implemented a bit further down the line? Is it a horrific crime to include an experimental version in 7.4 that won't have ZTS support? > Think > about it. You want to add a JIT partly so that PHP will be better at > non-web, CPU intensive tasks. If the JIT is successful, eventually you > will want parallelism in that domain, and if you are going to use > threading then something like ZTS is required. > Multithreading isn't the way of choice today for scalable parallelism. Again, it doesn't mean that ZTS shouldn't be supported - but between Swoole support and ZTS support - I would rate Swoole as a lot more strategic. Additionally, a lot of people are using ZTS builds today. Which they can continue doing, even if we fast forward to 2020, JIT is in, and it doesn't support ZTS. It seems as if people think that if JIT doesn't support ZTS, it means ZTS is no longer viable. That's obviously not the case. You will be able to continue using PHP just fine with JIT disabled. You can > argue all you want, we can't remove it easily. Imagine if I proposed a > breaking change in the language that would affect these same users. > Unless we got a *lot* of value out of it, I don't think it would pass. > I'm not campaigning for the removal of ZTS; The fact I wouldn't go about implementing it from scratch today, doesn't mean we need to axe it. There are two discussions, that kind of got intermixed in this thread: - How high should we prioritize ZTS build support for JIT? I admit I have a very hard time accepting that it's as critical as some here portray it. That said, Dmitry actually started doing some thinking about how we could improve ZTS to make it friendlier to JIT. So I guess the ZTS crowd got its way, as it's been de-facto prioritized as high priority, although he seems to want to get some help there. - Separate thread, that spun off from Joe's comment that lots of people use ZTS builds under Windows. I asked a simple question - why he thinks that is, because to me it sounded anachronistic. While Joe didn't respond, others did, suggesting that it's because windows.php.net mistakenly tells people that the only way to run PHP under Apache on Windows, while there's a much better way of doing it that's both faster and more reliable (FastCGI). To me, that's something that we should tackle, and it's completely independent from the JIT discussion. And no offense, but in its current state the JIT does not have a lot > of value. None taken. I do think it has a lot of value (covered in the RFC), but as I've said numerous times in various places - it's not quite the no-brainer that phpng was (twice the speed, half the memory consumption, no downsides). > It's a promising prototype, but it's not going to help the > vast majority of our users. > That's something I think people don't seem to understand. It's not really a prototype, and arguably, if you don't like it the way it is - I'm not sure it would hold much promise from your point of view. It's not a prototype, but rather the intended base implementation of the feature if we were to accept it. It's the 3rd attempt at doing this, and I don't believe there are any intentions to try a 4th (nor should we expect any radically different results if we were to do a 4th). At this point we don't believe we'll be able to evolve significantly beyond where we are in terms of performance, although we can improve things in the way of fixing bugs, and maybe refactoring certain elements to make it more portable. And of course there's always room for improvement - but nothing that would radically change the high level characteristics of this feature. It's not going to make WordPress - or any other conventional PHP Web app - go 2x faster in the sense that PHP 7 did. So, respectfully, I hope we can quit talking about removing ZTS. Again, I'm not arguing for the removal of ZTS. ZTS was born to do one thing - which is allow PHP to run within a multithreaded Web server. However, it evolved to do something else - which is allow thread usage from within PHP. These are distinct, and almost inherently separate use cases. I have nothing against the latter - but I do think the former is outdated and should be discouraged. Much like we discontinued the ISAPI module, we may want to discontinue support for mod_php under Windows and point people to use FastCGI instead (which, in turn, can be a ZTS build, it's completely orthogonal). Like I mentioned before, today, mod_php is hard to find in any modern deployment, it's been pretty much exclusively replaced by fpm and for very good reasons. All these reasons apply in Windows as well, and they're supplemented by improved stability and robustness. There's ALWAYS the possibility that I'm missing something, I sent a note to one of the XAMPP maintainers to understand their rationale on this, as well as their take on what we should consider doing in this front. I think it is fair to say that in all likelihood, most people who use ZTS today do so because they think they have to, and not because they are users of the pthreads extension. It's the former group that I think we should tackle, in the exact same way that today, not a single person on the planet is running ISAPI and they've all moved to use FastCGI (or so I hope, at least, it's been gone for ages). This is something we ought to consider doing completely independent from this whole JIT discussion. > It is > required for the present, and it will probably be desirable in the > future. No argument here. > Therefore, *some* mechanism for a thread-safe JIT code > generation is a requirement. I don't see how one leads to the other. The fact PHP is being used on a certain platform or in a certain mode by does not inherently mean that JIT must support it, certainly not in this early, pre-approval stage. If we can indeed do away with the bogus perception that you must use ZTS in order to use PHP under Apache/Windows, and change XAMPP's deployment model to use FastCGI (which again we should probably try to do *independently* from this whole JIT discussion), it would in turn radically reduce the size of the applicable ZTS install base, and indirectly make this less of a priority for JIT. Of course, one thing that can change this whole thing is if we start shipping internal functions that are implemented in PHP, while relying on the performance of JIT to make them sufficiently fast. If that happens, our platform support, as well as ZTS support, must be a lot more exhaustive than it is today. But we're far from being there at this point. Zeev --000000000000ccbb990581e1dada--