Do people want to know something particular about #php?
Be that internals, documentation, whatever insanity or pet peeve that goes through my mind (although that feels more like a regular podcast segment).
@derickr thanks, I think I read this back in the day :)
It didn't really help me understand why people don't use it and the project defaults don't activate it.
Or explain the tradeoffs or the regular web application behaviors.
So getting a gimpse into where this is going might still be useful.
@derickr@sebastian@edorian@Girgias Oh good, so you can either have code that's fast with the JIT off (hands off most work to C functions), or fast with the JIT on (does everything itself in PHP), but not both. Lovely.
@Crell that wasn't necessary my reading and a couple years have passed as well, but the uncertainty around this between seasoned PHPeople seems to suggest we could use a more comprehensive analysis :)
@edorian@Crell A secondary problem is that only really one active person knows thr JIT well enough to debug problems with it. And he's now working on a second JIT.
@derickr@edorian@Crell Ok thanks, wanted to make sure I read what was out there before asking questions like "Is this a good thing, and what benefits will it have?" 😅
@Crell@derickr@edorian@Girgias So let's rewrite ext/standard in PHP to reduce the amount of boundary crossings and remove the barrier of entry for maintenance (PHP instead of C).
A solution for a shared space for cli scripts to store optimizations feels long overdue anyways, for opcache alone.
Also having more of PHP written in PHP would surely (at least that's my guess) ease maintainance and allow for more contribution. (No idea how that would look like of course or how it could perform)
@edorian@sebastian@Crell@Girgias JIT only kicks in after the first runs of a function — something unlikely to happen on CLI. Adding a file cache brings a whole other set of issues.
JITted code might not behave as un-JITted (bugs).
It is also possible that some PHP implementations can never be as performant as a C implementation, because the latter has access to internal structures.
And adding a PHP implementation of internal functions, just means there is one more thing that can have bugs.
@edorian This is not my domain of expertise at all but Dmitry has been working on a new IR which should hopefully make it easier to maintain and less buggy:
@Girgias I don’t know about suggestions, but if you’d like to test some new material at PHP Sussex in Brighton at some point, let me know! Older talks work too 😉
@Girgias it’s usually on the second Wednesday of the month. Earliest slot would be December 13, otherwise we’re looking at first half of next year (I’ve got some speakers pre-booked for the first few months but not confirmed yet, although May is available for sure. It’s quite far off though 😄)
@awoodsnet I have a bag of mistakes where they have provided no benefit :D but that sounds kinda "boring" for a main conference? Fun for a meetup I suppose.
Which feels in the same vein as the PHP Dreams one.
Or a podcast show again (if anyone wants to invite me on one feel free).
And for the last one, I can't even tell you really lol me being insane and wanting to "fix" PHP? One part was me being too lazy to learn a new ecosystem for features, but I don't write that much PHP atm. :(
Add comment