Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8 to Add a JIT

blog.krakjoe.ninja

Post reply on HN
Print view View original

101–110 of 190 posts

Re: PHP 8 to Add a JIT

#101

Post by rujuladanh »

viraptor wrote: post #97
wvenable wrote: post #76

Earlier quoted context omitted.

It can. Python, for example, builds up classes at runtime. PHP builds up classes at compile time. There are plenty of other examples. PHP is really dynamic through eval() but that's more rare. Although PHP does support the above syntax, it's actually pretty rare in production code. PHP can be optimized like JavaScript is: perform direct variable/member access but provide a slow path for these kinds of dynamic lookups…

You can't just wave away the impact of having eval though. Just the fact that it exists means you need to keep around some supporting state like variable names. You can't do full constant folding and eliminate all intermediate steps for example if there a chance a runtime-created code will reach into your frame and want them back.

Similar things are done by JS engines and others nowadays. They optimize and keep the original stuff in case assumptions stop holding.

Re: PHP 8 to Add a JIT

#102

Post by ptx »

dexen wrote: post #7
wbl wrote: post #3

Earlier quoted context omitted.

PHP also didn't make the mistake Perl did. A shame because Perl tried very hard to make the right thing easy with security.

make the right thing easy with security. All other things being equal, security is usability[1] anti-pattern. You don't get to make clever hacks (in the original sense) on a secure system. Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn -- [1] at the very least for a power user or a developer

PHP was not really designed, though. It grew accidentally from a templating system. When other systems are said to be more secure, I think it's meant in the sense of not being horrifically broken and routinely injecting untrusted input into namespaces, markup and SQL queries.

Re: PHP 8 to Add a JIT

#104

Post by beberlei »

daeken wrote: post #72
ronsor wrote: post #45

Earlier quoted context omitted.

and now you see why "serverless" is misleading. "serverless" now means you don't run your own web server, you use someone else's.

That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes…

PHP hosters have been doing this for 20 years. You have 100s of customers on a single machine, running with a single Apache/PHP process (and child forks), and only if that Host+URL of a customer is requested that PHP code actually gets executed, then completely discarded from memory after its finished.

PHP is very much comparable to serverless. All that talk about bootstrapping costs in serverless is something PHP developers have been tackling forever.

Re: PHP 8 to Add a JIT

#105

Post by beberlei »

kyriakos wrote: post #36
bogdanu wrote: post #33

Earlier quoted context omitted.

Do you happen to have any benchmarks with JIT and libries like swoole? I thought the same some days ago, but in theory, the output from JIT lives across requests so it shouldn't matter if its a long lived process or simply a normal PHPfpm process. Also, the usual bottleneck in PHP is I/O.

in long running processes like Swoole, there is no web server running in front of PHP meaning PHP does some more heavy lifting which could benefit from JIT.

That is not entirely correct. Swoole already takes away a lot of the CPU heavy code, like HTTP protocol parsing by providing it in its C extension.

For one of my PHP extensions I benchmarked the C level implementation to be 5x faster than Jitted PHP code: https://beberlei.de/2019/03/25/the_jit_in_relation_to_php_ex...

So no, if your Swoole application does a lot of async I/O and its only in CPU code to delegate between I/O, then it will not benefit from the JIT.

"Long-Running process" alone doesn't mean that its CPU bound.

Re: PHP 8 to Add a JIT

#106

Post by beberlei »

kuroguro wrote: post #91

Love what they've been doing on PHP lately :) > However, this in fact opens the door on things such as machine learning, 3d rendering, 2d (gui) rendering, and data analysis, to name just a few. Shouldn't we get decent threading built in before we consider most of those? I've hit that wall many times when processing larger amounts of data w/ php scripts. I know about the pthreads plugin but nothing beats a first class…

Joe (the author of this post and pthreads extension) has been working on a new threading extension in the last months that looks extremely promising and more along the lines of goroutines than Java style threading:

- https://github.com/krakjoe/parallel - https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter...

Re: PHP 8 to Add a JIT

#107

Post by drubenstein »

sickcodebruh wrote: post #100

My feelings about PHP are stuck in what I remember from 2004. If I’m starting a new backend web project in 2019, should I be considering PHP over Ruby, Python, or TypeScript? Why or why not? I’m curious to hear from anyone who’s used it professionally in the last couple years.

I've had a reasonably good time with Laravel (versions 5.x), although not having a lot of experience with other stacks (say, django), ymmv.

That said, I don't think it's so profoundly amazing as to be worth learning PHP if 1) you're not already somewhat exposed to it or 2) the place where you work doesn't already use a lot of PHP.

Re: PHP 8 to Add a JIT

#108

Post by ptx »

maxxxxx wrote: post #23

I am pretty impressed with the path PHP has been taking lately. They have moved the language from being a mess into aggressively incorporating modern features at a very rapid pace. Especially PHP7 is a really nice language.

On the other hand, they have been moving to frameworks with separate templates and long-lived processed serving multiple requests - just like every other languange. But mod_php and logic mixed directly into the templates were the two main things that made it so easy to get started with, so with PHP moving to the same model as other languages, why not use another (even nicer) language?

Re: PHP 8 to Add a JIT

#109

Post by cthalupa »

lucb1e wrote: post #13
ChrisSD wrote: post #11

Earlier quoted context omitted.

Part of its staying power is also due to Wordpress. If you're looking for an off the shelf CMS you'll almost certainly be considering Wordpress, Drupal, Joomla, et al.

I could be wrong, but I think the ubiquity of those frameworks/CMSes is rather due to the language's success rather than vice versa. Web hosts made the near universal decision to support PHP as a dynamic language at some point, and the frameworks that were built in PHP then thrived on that. Wordpress wasn't that popular back when I started out with PHP, but PHP was already universally supported by web hosts (hence my…

As someone who worked in the hosting industry before moving to supporting and consulting on cloud stuff, it's a couple of things.

A handful of projects really are the driving reason for PHP's ubiquity.

Wordpress/Joomla, phpBB/Invision/vBulletin, Magento...

The demand for support for these and some smaller and similar projects really drove webhosts to need to support PHP, and for a lot of the standardized tooling webhosts used, such as cPanel/WHM and Plesk, to support not only PHP, but the automated installation of these projects.

Sure, WordPress wasn't the first - phpNuke, Postnuke, etc, were really popular CMS tools before WP, but if we're talking staying power, you really can look at the stuff I listed as being why it has stuck around.

Re: PHP 8 to Add a JIT

#110

Post by sk5t »

beberlei wrote: post #104
daeken wrote: post #72

Earlier quoted context omitted.

That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes…

PHP hosters have been doing this for 20 years. You have 100s of customers on a single machine, running with a single Apache/PHP process (and child forks), and only if that Host+URL of a customer is requested that PHP code actually gets executed, then completely discarded from memory after its finished. PHP is very much comparable to serverless. All that talk about bootstrapping costs in serverless is something PHP de…

This is a very silly equivalence--you're just glorifying vhosts and method dispatch.
Post reply on HN