30 ms·
PHP 8 to Add a JIT
- dexen 8y agoThere is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand. The way I see it was PHP captured the vector of change, and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countless built in classes and functions). Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup. Worse is better.
- wbl 8y agoPHP also didn't make the mistake Perl did. A shame because Perl tried very hard to make the right thing easy with security.
- dexen 8y agomake 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
- ptx 8y agoPHP 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.
- pjmlp 8y agoJust like C grew accidentenly from a language created to bootstrap compilers and JavaScript was a hacky 10 day solution.
- ptx 8y agoWikipedia quotes[1] Rasmus Lerdorf as saying: "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." Another relevant quote: "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests." And: "For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :) " ...which is probably true, but all the more reason to use tools that work properly rather than encouraging me to build more poorly thought-out stuff on top of a broken hack. [1] https://en.wikipedia.org/wiki/PHP#cite_ref-itconversations_16-0 https://en.wikipedia.org/wiki/PHP#cite_ref-itconversations_1... [2] https://en.wikiquote.org/wiki/Rasmus_Lerdorf https://en.wikiquote.org/wiki/Rasmus_Lerdorf
- cutler 8y agoPerl's decline relative to PHP is a bit more nuanced. With mod_perl you had to be really careful with global variables otherwise another process could access them in memory. Mod_php did a better job of isolating processes so mod_perl gained a reputation as a security headache which most cheap hosting companies were not prepared to deal with. It's often overlooked that a lot of cheap hosts only offer PHP as a CGI so the benefits over Perl/CGI appear, at first glance, to be minimal but even as a CGI PHP has templating built-in where Perl, Python and Ruby don't. Perl only has CGI.pm when limited to CGI. Sure, you can try to run Perl web frameworks such a Mojolicious, Dancer and Catalyst under CGI but they're not going to compete with PHP since they don't run as drop-in templated pages. Perl did have a PHP clone - HTML::Mason - but it wasn't worth using unless you ran it with mod_perl. That's where Perl lost to PHP. When PHP gained full OOP support with PHP5 the Perl community was still tearing itself apart over introducing a MOP and which of the dozen Moose clones should reign supreme. That was the final nail in Perl's coffin, at least in it's bid to compete with PHP.
- simias 8y agoWhat's that mistake?
- wbl 8y agoPerl 6. You think Python 3 was bad?
- lizmat 8y agoHave you looked at Perl 6 recently?
- wbl 8y agoThe issue isn't the language which is great. The issue is with the development hell sapping resources from the community
- arbie 8y agoI think it's a given that Perl6 will not achieve the prevalence that Perl5 has.
- b2gills 8y agoIt's pretty much a given that no language will ever be able to achieve that again.
- simias 8y agoAh, of course. But IIRC Perl usage on the web already started to decline (mainly in favor of PHP) before the whole Perl 6 debacle. I think PHP's strength was also its weakness: an amalgamation of specialized functions thrown into a global namespace without having to bother with modules, CPAN or anything. If you're an experienced dev it looks like a huge mess but if you're a complete beginner it makes it easier to work with.
- kaoD 8y ago> URLs aren't uniformly routable from either end What do you mean?
- dexen 8y agoHaving a single, uniform router (function/class/whatever) is only valid for trivial software. Any non-trivial system is better off with multiple independent URL routers with different semantics.
- coldtea 8y agoAnd yet lots of non-trivial systems have a single uniform router and are just fine with that. So there's that.
- petepete 8y agoI agree with just about all of your post except using Rails as an example of something that burnt out quickly. It was the most popular web framework around for the best part of a decade and is still being chosen for new projects.
- wolco 8y agoRails was never the most popular framework. But for a certain geography it was. Those were the anti-java crowd.
- pjmlp 8y agoRails was popular among those that never saw such approaches before, like on AOLServer and Zope. I just kept using Java, .NET and C++, while enjoying their performance, IDE tooling, and whatever ideas they could bring into their web stacks. Nowadays most cool companies that were pushing Ruby, are on JVM languages.
- petepete 8y agoI think your view is skewed and doesn't reflect what actually happened in the mid-00s.
- wolco 8y agoAll views are correct. Look at the number of jobs in cities around the world. Ruby was 1 in California but no where else during that time period.
- pjmlp 8y agoSkewed from European enterprises point of view. I only got to know one start-up doing Ruby (not Rails), which happened to rewrite our Perl deployment scripts as a project subcontractor, as they didn't had anyone with Perl knowledge.
- the_trapper 8y agoI think PHP endures because it does one thing and does it exceptionally well. There is no other tool that makes the creation of simple dynamic server side web sites as easy and accessible. Simple FTP/SCP deployment to the server is such a killer feature. It is also one of the few choices available on cheap shared hosting sites.
- kijin 8y agoPHP was practically "serverless" before serverless was even a thing. You just deploy your code with ftp, rsync, git, or whatever. There's no step 2.
- michaelmrose 8y agoHow is syncing your PHP code with the server serverless?
- ronsor 8y agoand now you see why "serverless" is misleading. "serverless" now means you don't run your own web server, you use someone else's.
- daeken 8y agoThat'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 onto a webserver when it's needed, and not before.
- captn3m0 8y agoserverless and compute-on-edge are different things.
- yllus 8y agoI think PHP had a couple of obvious advantages - it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way - plus Drupal and WordPress being PHP projects. But to me, one of the most significant advantages PHP has is that its documentation is terrific. PHP.net is simple, clear about parameters and return values (as clear as PHP lets it be anyways) and best of all has a terrific comments / examples section for each function. Better documented is better.
- pushpop 8y agoThings may have changed since v7 but historically I’ve not found PHPs documentation any better than any other language. In fact I remember a few occasions where I’ve ended up going by the advice of the comments rather than the documentation itself because the documentation was either out dated or just plain wrong.
- chiefalchemist 8y agoPerhaps not better, but there certainly have been worse. As for the comments. Yes. But at least they're there, and quite often helpful. Plenty of times I've read other docs where I wished they had commenting but alas didn't.
- ptx 8y agoThe comments are only needed because the documentation is often wrong or confused. And, of course, usually most of the comments are wrong too. Other languages don't need comments because they at least aim to have documentation that's correct.
- chiefalchemist 8y agoI don't see it that way. The comments are there to prevent others from re-inventing the wheel, to share insights, etc. Yes, sometimes that also highlights a "bug" or some other "flaw" but that's the rare exception. Maybe it would help if you listed some links to language docs that you feel the rest should use as benchmarks?
- ChrisSD 8y agoPart 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.
- lucb1e 8y agoI 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 learning it). The switch from, uh, I don't know what came before (Perl? Or just a jumble of different languages called by CGI?), to PHP as universal dynamic hosting language, is before my time though.
- ChrisSD 8y agoFrom my memory (which is not the most reliable source) it was a co-dependent relationship initially. PHP gained acceptance as a language for open source web projects, which lead to the likes of phpBB and Wordpress which in turn lead to PHP gaining even more presence on the web. I think the staying power of php is at least in part due to the continued success of popular projects that rely on it, whoever was responsible for its initial successes.
- cthalupa 8y agoAs 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.
- deleted 8y ago[deleted]
- dmortin 8y ago> There is something to be said about PHP's staying power. The only reason I use php for my own sites is because I don't want to administer any server and I don't want to be tied to a provider. PHP is a good fit for this, because it's available at practically all cheap hosting providers (I don't need to administer the server with shared hosting) and I'm not tied to a single provider, because I can switch to an other hosting provider without too much effort. With other langauges I either have to manage my own VPS (I don't want to pay for managed VPS), or I'm tied to a provider (Appengine, etc.).
- pjmlp 8y agoSame here, I used to wrestle with PHP, then I just accepted that the best path to make a productive use of my time was just to use it, the same way as you do.
- amelius 8y agoAnother thing PHP had was good reference documentation with a comments section for every function.
- inoop 8y agoSystems that are difficult to reason about are difficult to replace.
- chungleong 8y agoI once wrote a post comparing PHP to the Zerg in StarCraft. It's ugly as hell yet manages to spread everywhere. Purity of Essence trumps Purity of Form. PHP let you defeat competitors wielding superior technology through rapid time to market. A zergling rush, if you will.
- int_19h 8y agoIt wasn't right, no. I remember going "WTF" repeatedly even back in 2000, while first learning it and then using it in a commercial project. It's mostly that everything else was either worse (ASP), or insanely overengineered (JSP), or both (ColdFusion). Also, with LAMP, you had a stack that was free top-to-bottom. Back then, it still wasn't as common as it is in the industry today, and that especially helped it in the hobbyist and small business niche.
- chrisseaton 8y agoThis is the RFC with more technical details https://wiki.php.net/rfc/jit https://wiki.php.net/rfc/jit. I believe their plan is to emit low-level code directly via DynAsm, without their own intermediate representation. This kind of approach has been tried again and again and again and every project doing this either not got the results they wanted and given up or has had to go back and add a proper intermediate representation. Examples include Rust adding MIR before emitting LLVM, Rubinius trying to emit LLVM directly from Ruby and not getting good results so giving up, JRuby adding an IR before emitting Java byte code, Dropbox's Pyston implementation of Python that emitted LLVM directly where they gave up entirely, etc, etc, etc. Low level backends are not going to do the kind of key optimisations such as scalar replacement of aggregates that are table stakes for making a dynamic language perform well - they just don't have the high-level semantic model of the language needed to do it. Maybe they've got some new ideas, or maybe simplicity is a key constraint for them, but I predict from experience that they will need an intermediate representation to get the results that they want.
- dman 8y agoChris - any recommendations on a good simple IR to study?
- chrisseaton 8y agoMIR is probably a good example as it solves the problem I'm suggesting they'll encounter https://blog.rust-lang.org/2016/04/19/MIR.html https://blog.rust-lang.org/2016/04/19/MIR.html. Ideal is also a classic https://www.oracle.com/technetwork/java/javase/tech/c2-ir95-150110.pdf https://www.oracle.com/technetwork/java/javase/tech/c2-ir95-....
- dman 8y agoThanks!
- beberlei 8y agoNot sure if this qualifies as intermediate representation in the LLVM sense, but PHP has opcodes already, it is not fully interpreted anymore (like it was in PHP 3). These opcodes are used for optimizations and cached for the lifetime of the PHP process (across multiple requests).
- bratao 8y agoOne very important motivation what I do not see clearly delineated in this post is for Event-driven applications. Swoole[1] is an example of a PHP framework which enable some very interesting uses such as Websocket services. In those long lived processes, a JIT really shines! [1] https://www.swoole.co.uk/ https://www.swoole.co.uk/
- kyriakos 8y agoKnow any production grade projects using swoole? I was looking at it in the past but looks very early to trust a business on it.
- bogdanu 8y agoAfaik the project is pretty old. Never heard of anyone using it in production. There are a few integrations with popular frameworks but nothing production ready because there werent made to live in a eventloop - so, a lot of memory leaks.
- bogdanu 8y agoDo 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.
- kyriakos 8y agoin 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.
- beberlei 8y agoThat 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_extensions.html 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.
- maxxxxx 8y agoI 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.
- justinator 8y agoI think the problem with PHP is that it's a mature language that is aggressively incorporating modern features, yet still is a mess.
- maxxxxx 8y agoIt's definitely not my language of choice but I commend them for making good progress from a bad starting point.
- welly 8y agoWhat are the messy bits? I know they are there but how is it a mess in your opinion? There seems to be a lot of "PHP is a mess/garabage/whatever else" hyperbole in this thread with no actual explanations why.
- pathartl 8y agoI for one would rather see common utilities move into proper naming and static classing with proper returns. For instance, strpos(string haystack, string needle) will return the position of needle in haystack as an int if found. If not, it returns false. To me, the proper thing in this scenario is to either return an int (even -1 is fine for not found) or throw an exception. There's inconsistencies in typing of what is returned. There's nothing wrong with loose typing, especially in the place that PHP is used. It's just that the PHP API regularly returns not what you'd expect. Throw into the mix that the built in simple-functions are all over the place (https://www.php.net/manual/en/ref.strings.php https://www.php.net/manual/en/ref.strings.php). Seriously, there's str_replace, strpos, and parse_str. These could easily be solved by doing something similar to C#'s naming by changing it to something like String.Replace, String.IndexOf, String.Parse.
- tyingq 8y agoArticle appears to be from the same person that maintains apcu, a very popular user space kv memory cache for PHP. https://github.com/krakjoe/apcu https://github.com/krakjoe/apcu
- dumitrupetrov 8y agoI believe that he is a contributor to PHP itself.
- inglor 8y agoJoe Watkins is a really nice person and contributed a lot to php including the thread support (php-pthreads) the debugger (php-dbg) and other really impressive stuff. The nice story here is when he was in financial trouble (because of a bad employer) the community stepped up and donated to him ( https://www.gofundme.com/b9dfcg https://www.gofundme.com/b9dfcg ). He has constantly been useful and a positive force of change and any language ecosystem would be happy to have him.
- howiroll 8y agoIf PHP does not succeed to completely drop backwards support, they will fail anyway.
- gambit186 8y agoThe article says that this will help PHP in areas outside of the web. But what others areas actually want PHP? Even in its niche, the web, it has fallen out of grace for new projects.
- desas 8y agoWeb PHP projects that want to move some stuff out of a web request? Like delayed_job Web PHP projects that want to add some command line programs for doing maintenance tasks etc
- wolco 8y agoReal time processing of Garmin fitness data takes a lot of cpu. We had to use a c module to handle this can't wait to try php 8.
- kibibu 8y agoDon't believe it. Maybe in SV it's out of grace, but it gets plenty of use.
- cutler 8y agoApart from ubiquitous cheap hosting another big factor in PHP's early success was the numerous magazines pumping out "Build X with PHP and MySQL" articles. The shelves of newsagents were full of them in the early 2000s, some devoted purely to PHP development. Dreamweaver also adopted PHP for its dynamic site generator which made it accessible to front-end developers.
- bitt 8y agoPHP is doing great! I like the direction it is going in. PHP 7.4 also introduced nice features to improve static typing. The FFI is pretty cool too. You also get free performance improvements while remaining mostly backward compatible. It is trying very hard to stay relevant and I believe it is succeeding.
- bogdanu 8y agoAnd dont forget about preloading - an OPCache improvement, also available from 7.4.
- dboreham 8y agoFor a second I read that as "PDP 8..."
- doener 8y agoI already submitted that: https://news.ycombinator.com/item?id=19531611 https://news.ycombinator.com/item?id=19531611
- kuroguro 8y agoLove 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 citizen like goroutines for go or similar.
- beberlei 8y agoJoe (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://github.com/krakjoe/parallel - https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter.html https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter...
- EB66 8y agoWow, that looks incredible. Thank you for linking it.
- no_wizard 8y agoI agree. PHP needs 1st party support for proper threading and asynchronous programming. This would speed up applications more than a JIT would for most. Though I’m very pleased that this made it to PHP 8
- sickcodebruh 8y agoMy 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.
- drubenstein 8y agoI'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.
- legohead 8y agodo you care about performance? PHP, Go, C# you'll "figure it out later"? anything else that floats your boat
- godot 8y agoFor majority of backend web project, in 2019, there should be nearly no technical advantage re: one language over another among all the popular ones. (i.e. the ones you listed: PHP, Ruby, Python. I would argue to use pure nodejs over Typescript though. Most people underestimate the dev flow speed it gives you to not to have a compile/transpile step. Refresh and rerun is part of what made PHP so popular years ago.) In short, use whatever you're comfortable with. If you're super proficient with PHP, keep using it. If Python is that language for you, use Python.
- h1d 8y ago> Refresh and rerun I don't understand how this isn't easy on other platforms. This is such a huge advantage of PHP that somehow isn't easy to do elsewhere. I am using pm2 to restart ts-node on file change to get around it but it does take a second or 2 or else I get hit with 502 Bad Gateway on browser reload which is sometimes annoying. rails also does it automatically but this is not instant and sometimes shows me an old version, so I restart the rails instance manaually in case when I want to make sure which is a sad additional step that no PHP dev ever does.
- stesch 8y agoI care enough to click the link. But I don't care enough to know anything about PHP 8. Why is the author insulting me with the intro?
- halfnibble 8y agoI felt the intro was a little off too. I hadn't even heard of PHP 8 until today.
- joseph8th 8y agoPHP has made huge strides with 7.0+ but honestly a JIT was nowhere on my list of feature requests. We use it at work (with CodeIgniter) and it gives the company a big pool of reasonably qualified talent. For anything outside our web apps, we switch to Python. I find it unlikely that new PHP shops are going to use it to do all the CPU-bound things we aren't using it for now. But who knows? I wouldn't have thought it would be as popular as it is now, if you'd asked me 5 years ago.
- the_fonz 8y agoDoesn't this duplicate the effort of HHVM?
- deleted 8y ago[deleted]
- duskwuff 8y agoNope! As of last year, HHVM no longer targets PHP [1]; instead, it targets a Facebook-specific variant of PHP called "Hack". It will still run some PHP code, but that's on its way out. Even better/worse, PHP 7.2 with an opcode cache can actually outperform HHVM on many practical benchmarks [2], and 7.3 is faster still. [1]: https://hhvm.com/blog/2018/09/12/end-of-php-support-future-of-hack.html https://hhvm.com/blog/2018/09/12/end-of-php-support-future-o... [2]: http://web.archive.org/web/20180305000053/https://kinsta.com/blog/php-7-hhvm-benchmarks/ http://web.archive.org/web/20180305000053/https://kinsta.com...
- AstroJetson 8y agoNeed some love here for AOLServer and TCL. Got "Philip & Alex's Guide to Web Publishing" and within two weeks had a major Mutual Fund company up on the web. The CICS interface was a little wonky, but it worked and worked well. I do things now with Wordpress, since that grew and was maintained past AOL server. I always look forward to improvements in PHP, the last few releases have made huge strides in page load times
- antirez 8y agoI'm happy PHP is still there, because other much better languages missed a lot of good things that PHP got right immediately (in the context of web development): 1. You may add complexity if you want but the bare metal of web is that you have some printf() like output construct plus a trivial <? ?> interpolation thing. Then who wants more can add more, but this should be what you get immediately for free, without template languages. 2. Languages, even high level ones, should be reasonably fast. 3. Setting up an environment should be trivial. 4. By default things are created and die in the context of a page load. Then if you want to optimize things, you may have additional constructs to create persistent connections, objects, whatever. But give me this huge garbage collector that is a stateless execution, by default. 5. A set of libraries already included so that for most things I don't have to go and find some solution. Many other competitors failed so big in that regards that I really wanted PHP to get better as a language (like it is doing) so that it was not a so bad experience like at the start, because I was pretty sure the others would hardly fix the above points.
- aasasd 8y agoNow, the actual tragedy of PHP isn't that coding in it feels soul-drainingly tainted, but that it was always ‘good enough’ for armies of people. Because, as a result, there wasn't any incentive to add features outside of the paradigm of one-shot scripts. E.g. there are at least three async frameworks, with barely any adoption―and this new ‘Swole’ one is advertised like ReactPHP never existed, with its promises and everything. Meanwhile, somehow, the poster notion of PHP's versatility is that it's purportedly just fine for desktop GUI programming, of all things―while being single-threaded (its ‘pthreads’ aren't threads). The topic of UI freezes never comes up in these pamphlets, for some reason.
- nzd 8y agoSo if JIT involves compiling into native machine code, can we expect that in the future JIT capability would help PHP devs implement compiling whole PHP project into native (like a single .exe binary for Windows)?