# ZTS improvement idea - Thread: https://externals.io/message/104378 - Original archive: https://news-web.php.net/php.internals/104378 - Started by Dmitry Stogov on 2019-02-13T08:26:22+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/104378.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #104378 — Dmitry Stogov — 2019-02-13T08:26:22+00:00 URL: https://externals.io/message/104378#104378 Hi, After JIT+ZTS related discussion with Joe and Bob, and some related analyzes. I came to more or less formed design idea and described it at https://wiki.php.net/zts-improvement This is not an RFC and I'm not sure, if I like to implement TSRM changes myself now. Comments are welcome. Thanks. Dmitry. --- ## #104379 — Nikita Popov — 2019-02-13T09:02:16+00:00 URL: https://externals.io/message/104378#104379 > Hi, > > > After JIT+ZTS related discussion with Joe and Bob, and some related > analyzes. > > I came to more or less formed design idea and described it at > https://wiki.php.net/zts-improvement > > This is not an RFC and I'm not sure, if I like to implement TSRM changes > myself now. > > > Comments are welcome. > Hi Dmitry, Thanks for looking into this issue. As a possible alternative I would like to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on Linux (on Windows this is not possible due to DLL linkage restrictions). __thread generates very good code (single load over %fs segment with constant address) if the global is defined and used in an executable. I'm not sure what kind of code it generates when TLS is declared in an executable and used in a shared object, but as direct access from extensions to the engine globals shouldn't be common, it's probably okay even if it uses __tls_get_addr. Nikita --- ## #104380 — Joe Watkins — 2019-02-13T09:26:35+00:00 URL: https://externals.io/message/104378#104380 Morning all, I'm very pleased to see effort going into this, and the resulting ideas. I don't have anything to add about the implementation. Since most people are not interested in ZTS, there aren't going to be many voices pushing you to actually make changes, so I want to be that voice. The ZTS build is very commonly used in Windows today, and I'm sure everyone doing that would appreciate you making these changes as soon as reasonable, which looks like 7.4, beyond that before we can talk about developing JIT support in Windows, ZTS support must be in place. Thanks for the effort so far. Cheers Joe > > > > […] > > Hi Dmitry, > > Thanks for looking into this issue. As a possible alternative I would like > to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on > Linux (on Windows this is not possible due to DLL linkage restrictions). > __thread generates very good code (single load over %fs segment with > constant address) if the global is defined and used in an executable. I'm > not sure what kind of code it generates when TLS is declared in an > executable and used in a shared object, but as direct access from > extensions to the engine globals shouldn't be common, it's probably okay > even if it uses __tls_get_addr. > > Nikita --- ## #104381 — Dmitry Stogov — 2019-02-13T09:35:09+00:00 URL: https://externals.io/message/104378#104381 Hi Nikita, > On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov > wrote: > > Hi, > > > After JIT+ZTS related discussion with Joe and Bob, and some related > analyzes. > > I came to more or less formed design idea and described it at > https://wiki.php.net/zts-improvement > > This is not an RFC and I'm not sure, if I like to implement TSRM > changes myself now. > > > Comments are welcome. > > > Hi Dmitry, > > Thanks for looking into this issue. As a possible alternative I would > like to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc > globals on Linux (on Windows this is not possible due to DLL linkage > restrictions). I played with __thread long time ago (may be 10 years), and that time it didn't work as expected. I can't remember the exact problems. May be it made troubles when used in DSO PHP build with DSO extensions, may be the size of "__thread" segment was limited, may be both. > __thread generates very good code (single load over %fs > segment with constant address) if the global is defined and used in an > executable. I suppose 2 loads: movq executor_globals@gottpoff(%rip), %rax movq %fs:field_offset(%rax), %rax > I'm not sure what kind of code it generates when TLS is > declared in an executable and used in a shared object, but as direct > access from extensions to the engine globals shouldn't be common, it's > probably okay even if it uses __tls_get_addr. The main problem with "__thread" might be portability. I especially thought about keeping TSRM layer with the same API, to avoid portability issues, but if "__thread" works fine, we definitely should use it. On the other hand, I'm not sure, who uses ZTS build today and if they need performance. Thanks. Dmitry. > > Nikita --- ## #104382 — Dmitry Stogov — 2019-02-13T09:43:42+00:00 URL: https://externals.io/message/104378#104382 Hi Joe, > Morning all, > > I'm very pleased to see effort going into this, and the resulting ideas. > > I don't have anything to add about the implementation. > > Since most people are not interested in ZTS, there aren't going to be > many voices pushing you to actually make changes, so I want to be that > voice. > > The ZTS build is very commonly used in Windows today, and I'm sure > everyone doing that would appreciate you making these changes as soon as > reasonable, which looks like 7.4, beyond that before we can talk about > developing JIT support in Windows, ZTS support must be in place. There are many things that would be great to get, but with very limited forces, we have to set priorities and select the most desired functionality, to work on it first. Thanks. Dmitry. > > Thanks for the effort so far. > > Cheers > Joe > > On Wed, 13 Feb 2019 at 10:02, Nikita Popov > wrote: > > On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov > wrote: > > Hi, > > > After JIT+ZTS related discussion with Joe and Bob, and some > related analyzes. > > I came to more or less formed design idea and described it at > https://wiki.php.net/zts-improvement > > This is not an RFC and I'm not sure, if I like to implement TSRM > changes myself now. > > > Comments are welcome. > > > Hi Dmitry, > > Thanks for looking into this issue. As a possible alternative I > would like to suggest the use of ZEND_TLS (__thread) for the > EG/CG/BG etc globals on Linux (on Windows this is not possible due > to DLL linkage restrictions). __thread generates very good code > (single load over %fs segment with constant address) if the global > is defined and used in an executable. I'm not sure what kind of code > it generates when TLS is declared in an executable and used in a > shared object, but as direct access from extensions to the engine > globals shouldn't be common, it's probably okay even if it uses > __tls_get_addr. > > Nikita --- ## #104403 — Zeev Suraski — 2019-02-14T11:56:50+00:00 URL: https://externals.io/message/104378#104403 > The ZTS build is very commonly used in Windows today > Any idea why? Zeev --- ## #104411 — Rowan Collins — 2019-02-14T15:22:03+00:00 URL: https://externals.io/message/104378#104411 > > > > […] > > Any idea why? > https://windows.php.net/ currently recommends using an NTS build with FastCGI, but there is (or was?) also an ISAPI module, i.e. the IIS equivalent of Apache mod_php. I think that requires / required ZTS, so that may be where the perception of "thread-safety is important for Windows users" comes from. Regards, -- Rowan Collins [IMSoP] --- ## #104412 — Zeev Suraski — 2019-02-14T15:28:05+00:00 URL: https://externals.io/message/104378#104412 On Thu, Feb 14, 2019 at 5:22 PM Rowan Collins wrote: > > > > […] > > > https://windows.php.net/ currently recommends using an NTS build with > FastCGI, but there is (or was?) also an ISAPI module, i.e. the IIS > equivalent of Apache mod_php. > Yep, well aware of it, I wrote it ages ago... I believe it's dead, and if it isn't, it should be... > I think that requires / required ZTS, so that may be where the perception > of "thread-safety is important for Windows users" comes from. It's definitely the original reason for wanting ZTS on Windows (which used to make sense, until we worked with Microsoft to bring FastCGI to IIS). But if that's still the only reason, it's a pretty bogus one - there's virtually nothing but downsides to using the ISAPI module (or ZTS under Windows in general), at least there aren't any tangible advantages I can think of. That's why I'm asking... Zeev --- ## #104413 — Joe Watkins — 2019-02-14T15:39:25+00:00 URL: https://externals.io/message/104378#104413 Packages such as xampp, which are very widely used, bundle a thread safe interpreter. It's a fact that ZTS is important on Windows. Cheers Joe > > > > […] > > > https://windows.php.net/ currently recommends using an NTS build with > FastCGI, but there is (or was?) also an ISAPI module, i.e. the IIS > equivalent of Apache mod_php. > > I think that requires / required ZTS, so that may be where the perception > of "thread-safety is important for Windows users" comes from. > > Regards, > -- > Rowan Collins > [IMSoP] --- ## #104414 — Christoph M. Becker — 2019-02-14T15:47:04+00:00 URL: https://externals.io/message/104378#104414 > > > > […] > > Any idea why? windows.php.net: | With Apache you have to use the Thread Safe (TS) versions of PHP. -- Christoph M. Becker --- ## #104415 — Zeev Suraski — 2019-02-14T15:58:55+00:00 URL: https://externals.io/message/104378#104415 On Thu, Feb 14, 2019 at 5:47 PM Christoph M. Becker wrote: > > > > […] > > windows.php.net: > > | With Apache you have to use the Thread Safe (TS) versions of PHP. > That's a great explanation (wasn't aware of it!), but that's actually not true, it's much better to use FastCGI instead (faster and definitely a lot more reliable and robust). Looks like XAMPP might be under the same false impression. Might be a good opportunity in PHP 8 to change these not-so-healthy defaults. After all, ISAPI used to be super popular too (under Windows) until worked with Microsoft to bring FastCGI into IIS. Zeev --- ## #104416 — Rowan Collins — 2019-02-14T15:59:18+00:00 URL: https://externals.io/message/104378#104416 > > > > […] > > windows.php.net: > > | With Apache you have to use the Thread Safe (TS) versions of PHP. > > Ah, that makes sense; the only Apache MPM supported on Windows is mpm_winnt, which is thread-based: http://httpd.apache.org/docs/2.4/mod/mpm_winnt.html Again, this only makes sense if using server modules (mod_php); anyone using FastCGI will presumably be unaffected. All that being said, it would be nice if ZTS became more mainstream, so more people had access to userland threading / parallel processing extensions. Regards, -- Rowan Collins [IMSoP] --- ## #104417 — Zeev Suraski — 2019-02-14T16:04:51+00:00 URL: https://externals.io/message/104378#104417 On Thu, Feb 14, 2019 at 5:59 PM Rowan Collins wrote: > All that being said, it would be nice if ZTS became more mainstream, so > more people had access to userland threading / parallel processing > extensions. I think the most promising parallel processing paradigms today are based on asynchronous IO and not threading. That's generally the direction the world is going in (Node.js / Swoole / etc.) Threading (ZTS) actually comes at a fairly high cost, primarily in terms of performance but also in terms of some implementation complexity, and has few advantages over async IO. Zeev --- ## #104418 — Joe Watkins — 2019-02-14T16:13:44+00:00 URL: https://externals.io/message/104378#104418 EXACTLY Sorry I didn't answer in full, but I've been listening to people say its not important for so long, I'm pretty tired of it by now. We are talking about merging a thing that has the ability to make some maths faster, at huge cost to the project, in two days I wrote a new extension called parallel that can make *any* code faster if you have the cores, which we all do, without complicating anything, and without cost. Just a bit of thinking necessary. I don't object to the JIT at all, but without zts it's a non starter for me. The fact that there are easy improvements that could be done for ZTS that we seem to being held to ransom for is just awful. I wish more people would really think ... https://gist.github.com/krakjoe/254897be71d23b5d5ac2d436f52e8d7d Cheers Joe > On Thu, 14 Feb 2019 at 15:47, Christoph M. Becker > wrote: > > > […] > wrote: > > […] > > Ah, that makes sense; the only Apache MPM supported on Windows is > mpm_winnt, which is thread-based: > http://httpd.apache.org/docs/2.4/mod/mpm_winnt.html > > Again, this only makes sense if using server modules (mod_php); anyone > using FastCGI will presumably be unaffected. > > > All that being said, it would be nice if ZTS became more mainstream, so > more people had access to userland threading / parallel processing > extensions. > > Regards, > -- > Rowan Collins > [IMSoP] --- ## #104419 — Zeev Suraski — 2019-02-14T16:25:19+00:00 URL: https://externals.io/message/104378#104419 > EXACTLY > > Sorry I didn't answer in full, but I've been listening to people say its > not important for so long, I'm pretty tired of it by now. > Joe, all, Again, ISAPI was super important until one day, it wasn't. If the main reason ZTS is important is because of a misperception, we need to fix the misperception instead of of just treating it as a God-given commandment. Perhaps there's a real mainstream use case for ZTS. Perhaps there isn't. Usage alone of things like mod_php under Windows - which isn't a very good idea - isn't strong enough an indicator. I created ZTS mode - taking a lot of trouble to do so, refactoring huge chunks of the PHP code base at the time, and also wrote the ISAPI module and IIRC, ported mod_php to Windows (not 100% sure about that last one, it was 20 years ago). If the technologies that exist today existed back then - I'm virtually certain I wouldn't have done it. FastCGI/FPM is superior in every possible way to thread-safe server plugins. Heck, today it's widely accepted that FPM is even superior to mod_php under Linux in pretty much every respect. Under Windows the advantages are a lot more significant, as they're not limited to performance - but also provide much better robustness/stability. Zeev --- ## #104420 — Levi Morrison — 2019-02-14T17:27:24+00:00 URL: https://externals.io/message/104378#104420 To all internals, but especially to Zeev and Dmitry, Having a JIT which does not support ZTS is a bit short-sighted. 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. Additionally, a lot of people are using ZTS builds today. 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. And no offense, but in its current state the JIT does not have a lot of value. It's a promising prototype, but it's not going to help the vast majority of our users. So, respectfully, I hope we can quit talking about removing ZTS. It is required for the present, and it will probably be desirable in the future. Therefore, *some* mechanism for a thread-safe JIT code generation is a requirement. It doesn't necessarily have to be the ZTS we have today, but it needs something. Regards, Levi Morrison --- ## #104421 — Anatol Belski — 2019-02-14T17:44:42+00:00 URL: https://externals.io/message/104378#104421 Hi Dmitry, > -----Original Message----- > From: Dmitry Stogov > Sent: Wednesday, February 13, 2019 12:26 AM > To: Joe Watkins ; Bob Weinand ; > Nikita Popov ; Anatol Belski (ab@php.net) ; > zeev@php.net > Cc: PHP internals > Subject: ZTS improvement idea > > Hi, > > > > > After JIT+ZTS related discussion with Joe and Bob, and some related > analyzes. > > I came to more or less formed design idea and described it at > https://wiki.php.net/zts-improvement > I thought about it as well. The reason for the additional dereference levels is probably ,that every globals structure has its own size. That way, it needs to go on the heap. What we indeed could do were handling some specific known structures a different way. It'd be like EG and others, that belong to the very core and are always available. Other globals, especially from extensions that can be built shared, would be probably still handled the old way. Maybe it would be a good start to speedup the very core as first. I'd wonder which particular data structures and mechanism you had in mind. > This is not an RFC and I'm not sure, if I like to implement TSRM changes > myself now. > Certainly not an RFC. I'm short of time as well, perhaps it will change in a couple of months. Thanks Anatol --- ## #104422 — Anatol Belski — 2019-02-14T17:55:24+00:00 URL: https://externals.io/message/104378#104422 Hi Nikita, > -----Original Message----- > From: Nikita Popov > Sent: Wednesday, February 13, 2019 1:02 AM > To: Dmitry Stogov > Cc: Joe Watkins ; Bob Weinand ; > Nikita Popov ; Anatol Belski (ab@php.net) ; > zeev@php.net; PHP internals > Subject: Re: ZTS improvement idea > > On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov > wrote: > > > Hi, > > > > > After JIT+ZTS related discussion with Joe and Bob, and some related > analyzes. > > I came to more or less formed design idea and described it at > https://wiki.php.net/zts-improvement > > This is not an RFC and I'm not sure, if I like to implement TSRM > changes myself now. > > > > > Comments are welcome. > > > Hi Dmitry, > > Thanks for looking into this issue. As a possible alternative I would like to > suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on > Linux (on Windows this is not possible due to DLL linkage restrictions). > __thread generates very good code (single load over %fs segment with > constant address) if the global is defined and used in an executable. I'm not > sure what kind of code it generates when TLS is declared in an executable > and used in a shared object, but as direct access from extensions to the > engine globals shouldn't be common, it's probably okay even if it uses > __tls_get_addr. > TLS data available across shared objects is a GNU extension and AFAIK there's a lot of black magic behind it. Thread local storage should be indeed local to some scope, be it a function or a binary unit, as per design. Like for C++11 as well, it's thread_local we currently use. It'd hurt the portability and likely introduce issues in the future, as it might affect any non GNU systems which we rarely test. Otherwise, of course it would be easy to say, we add ZEND_TLS to the definition, and be good :) Thanks Anatol --- ## #104423 — Larry Garfield — 2019-02-14T17:57:22+00:00 URL: https://externals.io/message/104378#104423 > > > […] > > Ah, that makes sense; the only Apache MPM supported on Windows is > mpm_winnt, which is thread-based: > http://httpd.apache.org/docs/2.4/mod/mpm_winnt.html > > Again, this only makes sense if using server modules (mod_php); anyone > using FastCGI will presumably be unaffected. > > > All that being said, it would be nice if ZTS became more mainstream, so > more people had access to userland threading / parallel processing > extensions. > > Regards, Data point: At Platform.sh (web host), we've been running ZTS builds of 7.1, 7.2, and 7.3 exclusively for a while now. We don't even offer non-ZTS versions of those releases. It's been quite solid, and mysteriously even slightly faster than the non-ZTS version of 7.1 on code that wasn't doing anything threaded at all (which surprised me, but hey). I have to agree with Joe's post yesterday on this front: https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter.html It's not threads that are unsafe for end users; it's badly designed thread APIs that start by pointing a gun at your foot. :-) A well-designed thread- backed concurrency model (Go routines being a good but not the only example) is way better, and at least from a user side I frankly prefer it to async IO. You get much of the same benefits with less need to restructure you're code, even with async/await. Plus you can parallelize CPU intensive tasks, something async IO simply cannot do. I'm not against the efforts to add async IO to PHP, but it's not an either/or with thread-safe code. I'd also love to see more non-IO-bound concurrency added to the language. --Larry Garfield --- ## #104424 — Zeev Suraski — 2019-02-14T22:05:10+00:00 URL: https://externals.io/message/104378#104424 > 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 --- ## #104425 — Zeev Suraski — 2019-02-14T22:33:27+00:00 URL: https://externals.io/message/104378#104425 On Thu, Feb 14, 2019 at 7:57 PM Larry Garfield wrote: > Data point: At Platform.sh (web host), we've been running ZTS builds of > 7.1, > 7.2, and 7.3 exclusively for a while now. We don't even offer non-ZTS > versions of those releases. I presume you haven't been using a threaded Web server module though, right? As I pointed out in my lengthy response to Levi, it's thread-safe Web server plugins that are bad news, not ZTS itself. It's been quite solid It would be solid as long as you don't use a thread-safe Web server plugin. Then, any slight thread-safety issue in any of the underlying libraries could result in your Web server process crashing in its entirety. > , and mysteriously even > slightly faster than the non-ZTS version of 7.1 on code that wasn't doing > anything threaded at all (which surprised me, but hey). > That is indeed curious. I'd be interested to follow up with you to better understand how you measured it, as it goes against both my expectations (ZTS code does more compared to non-ZTS code) and my experience. We can maybe take that offline... > I have to agree with Joe's post yesterday on this front: > > https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter.html > > It's not threads that are unsafe for end users; it's badly designed thread > APIs that start by pointing a gun at your foot. :-) A well-designed > thread- > backed concurrency model (Go routines being a good but not the only > example) > is way better, and at least from a user side I frankly prefer it to async > IO. > You get much of the same benefits with less need to restructure you're > code, > even with async/await. Plus you can parallelize CPU intensive tasks, > something async IO simply cannot do. > It's not just a matter of preference. Async IO is significantly more efficient than threads both in terms of speed and memory overhead. It's no coincidence that all high performance Web servers nowadays are async-IO based, and that the most scalable app delivery platforms are also async IO based. In addition to the underlying building blocks being more efficient, the async-IO model, where you have a long running process that is in fact directly responding to HTTP requests - is most likely in itself bringing the biggest performance gains - as effectively you have a 'hot', ready to execute app that can preload all sorts of elements into memory and be ready to go with little to no initialization (a direction we went in with the code preloading feature, but things like Node.js or Swoole go a lot farther than that). All that doesn't come to say we must not implement threads - not at all - just that they're probably not the preferred method of achieving in-request parallelism within the Web environment. Zeev --- ## #104427 — Larry Garfield — 2019-02-15T01:27:41+00:00 URL: https://externals.io/message/104378#104427 > On Thu, Feb 14, 2019 at 7:57 PM Larry Garfield > > wrote: > > […] > > I presume you haven't been using a threaded Web server module though, right? > As I pointed out in my lengthy response to Levi, it's thread-safe Web > server plugins that are bad news, not ZTS itself. > > It's been quite solid > > > It would be solid as long as you don't use a thread-safe Web server > plugin. Then, any slight thread-safety issue in any of the underlying > libraries could result in your Web server process crashing in its entirety. Right, we're using typical Nginx/FPM for web requests. ZTS is just there so that CLI users can run their own process that use pthreads. (I don't know if anyone has done so, but we support it, so yay.) > > […] > > That is indeed curious. I'd be interested to follow up with you to better > understand how you measured it, as it goes against both my expectations > (ZTS code does more compared to non-ZTS code) and my experience. We can > maybe take that offline... It's been a while since we ran the tests. I believe it was just for the 7.1 release, and we tested with normal ab or something. Happy to chat off-list if you want but I'm not sure that I can remember much at this point. :-) > > […] > > It's not just a matter of preference. Async IO is significantly more > efficient than threads both in terms of speed and memory overhead. It's no > coincidence that all high performance Web servers nowadays are async-IO > based, and that the most scalable app delivery platforms are also async IO > based. In addition to the underlying building blocks being more efficient, > the async-IO model, where you have a long running process that is in fact > directly responding to HTTP requests - is most likely in itself bringing > the biggest performance gains - as effectively you have a 'hot', ready to > execute app that can preload all sorts of elements into memory and be ready > to go with little to no initialization (a direction we went in with the > code preloading feature, but things like Node.js or Swoole go a lot farther > than that). All that doesn't come to say we must not implement threads - > not at all - just that they're probably not the preferred method of > achieving in-request parallelism within the Web environment. > > Zeev I'm not saying async IO doesn't have advantages, and having a "hot" running application that persists between requests is something I really want, too. However, async IO by definition doesn't help unless your blocker is IO. Often it is, but often you have a CPU bound problem. Even in PHP. (I used to work on Drupal, remember; it does a LOT of non-IO work...) Async IO isn't going to help you much if IO isn't your bottleneck. I think we're largely on the same page, though: Threads good, threaded webserver host bad. PHP should have good thread support in the future. Whether ZTS specifically counts as "good thread support" at the engine level I have no opinion, as I haven't been anywhere close to the engine to know what I'm talking about. --Larry Garfield --- ## #104428 — Pierre Joye — 2019-02-15T02:33:47+00:00 URL: https://externals.io/message/104378#104428 Good morning, Again a long reply from me, sorry :) There are a few things I would like to clarify from my perspective.On Windows, historically (for years), the only usable webserver was Apache. And the only way to work with it for years as well was mod_php. Given the Apache's design, it requires thread safety. As Zeev mentioned, ZTS was created to bring a thread safety framework for the engine and the extensions. It did not get updated for years and relies on old APIs or ways of doing it. On Windows the performance impact was even bigger. With the introduction of thread local storage support introduce (https://wiki.php.net/rfc/native-tls) things improved drastically. TLS solves many issues we had with the old ZTS version and also made it more stable. Stability improvement was not only due toTLS but also to the great work Anatol pushed into this RFC by reviewing the entire php code base and extensions (incl pecl). ZTS mode became quite solid. From a performance point of view, it matched or beat NTS on Windows, and in some cases by good margin. I do not have the numbers at hand but if someone is interested, looking at the discussions for this RFC should give them all the details. All this applied to ISAPI as well for the time it was still part of the core, only even less stable. Now, about ZTS usage on Windows being huge. This is correct. Is it a de-facto choice for Windows users? No. It is a communication and marketing issue. Microsoft introduce FCGI support to IIS long time ago and became a de facto standard for any kind of PHP (or other) support with IIS. Application pool and most of the IIS support are fully supported with PHP and FCGI. Many developers use ZTS with Apache thinking it will be better and faster, or comparable to FPM, because FPM is not supported on Windows.This is clearly something we need to communicate better. Keeping in mind that FPM (and its key features) are not possible to be ported to Windows due to the windows architecture. However, many webservers support similar features (IIS or other) natively and with php-FastCGI. From a strategy point of view, I agree with Zeev. With a slightly different approach. We need thread safety internally for many modern needs (async processing/IOs f.e. use threads internally). From an end user perspective, that should be transparent (easier said than done). That being threading in userland is complete different story. There are a few great things out there to make this case: - Joe made a great job with his parallel extension (https://github.com/krakjoe/parallel). - AMP has something similar (from a user perespective) with https://github.com/amphp/parallel. - Swoole, Zeev mentioned it and I highly recommend to look at it - many other projects trying to change the way we use PHP, ReactPHP f.e. You get the idea. There is a need. And I think we should provide the tool to help them to do it nicely and with good performance. ZTS is not going to help here, this is not adapted to where we have to go (or should be already). I would rather scratch it and discuss with Swoole, Joe, AMP or React teams, get inspirations in other languages to see what can be done at the engine level to make this kind of tasks possible, portable and fast. Best, > > On Thu, Feb 14, 2019 at 7:57 PM Larry Garfield > wrote: > > > […] > > > I presume you haven't been using a threaded Web server module though, right? > As I pointed out in my lengthy response to Levi, it's thread-safe Web > server plugins that are bad news, not ZTS itself. > > It's been quite solid > > > It would be solid as long as you don't use a thread-safe Web server > plugin. Then, any slight thread-safety issue in any of the underlying > libraries could result in your Web server process crashing in its entirety. > > > > […] > > That is indeed curious. I'd be interested to follow up with you to better > understand how you measured it, as it goes against both my expectations > (ZTS code does more compared to non-ZTS code) and my experience. We can > maybe take that offline... > > > > […] > > It's not just a matter of preference. Async IO is significantly more > efficient than threads both in terms of speed and memory overhead. It's no > coincidence that all high performance Web servers nowadays are async-IO > based, and that the most scalable app delivery platforms are also async IO > based. In addition to the underlying building blocks being more efficient, > the async-IO model, where you have a long running process that is in fact > directly responding to HTTP requests - is most likely in itself bringing > the biggest performance gains - as effectively you have a 'hot', ready to > execute app that can preload all sorts of elements into memory and be ready > to go with little to no initialization (a direction we went in with the > code preloading feature, but things like Node.js or Swoole go a lot farther > than that). All that doesn't come to say we must not implement threads - > not at all - just that they're probably not the preferred method of > achieving in-request parallelism within the Web environment. > > Zeev -- Pierre @pierrejoye | http://www.libgd.org --- ## #104429 — Dmitry Stogov — 2019-02-15T07:12:07+00:00 URL: https://externals.io/message/104378#104429 Hi Anatol, > Hi Dmitry, > > > […] > I thought about it as well. The reason for the additional dereference > levels is probably ,that every globals structure has its own size. > That way, it needs to go on the heap. Not necessary. In case all the structures are known at MINIT time, we may realloc()-ate the whole flattened tsrm_tls_entry and then access data faster. It may be a problem with `dl()`, but it must already be problematic in ZTS build. > What we indeed could do were handling some specific known structures > a different way. It'd be like EG and others, that belong to the very > core and are always available. Other globals, especially from extensions > that can be built shared, would be probably still handled the old way. > Maybe it would be a good start to speedup the very core as first. I'd > wonder which particular data structures and mechanism you had in mind. In https://wiki.php.net/zts-improvement I proposed: - make "executor_globals_id" to be constant (it's quite easy to do). - make all "...globals_id" to keep offsets instead if indexes (this is a bit more complex and require changes in TSRM implementation). Thanks. Dmitry. > > > > […] > Certainly not an RFC. I'm short of time as well, perhaps it will change in a couple of months. > > Thanks > > Anatol --- ## #104430 — Dmitry Stogov — 2019-02-15T07:21:25+00:00 URL: https://externals.io/message/104378#104430 > Hi Nikita, > > > […] > TLS data available across shared objects is a GNU extension and AFAIK there's a lot of black magic behind it. Thread local storage should be indeed local to some scope, be it a function or a binary unit, as per design. Like for C++11 as well, it's thread_local we currently use. It'd hurt the portability and likely introduce issues in the future, as it might affect any non GNU systems which we rarely test. Otherwise, of course it would be easy to say, we add ZEND_TLS to the definition, and be good :) In two words, if we make executor_glabal to be "__thread", we will get troubles accessing it from DSO extensions. Right? Thanks. Dmitry. > > Thanks > > Anatol --- Next page: https://externals.io/message/104378.md?page=2