Re: Re: [RFC] Union Types v2

Hi Nikita, in your results, assignment to typed reference is ~3 time slower without JIT and ~10 times slower with JIT. But this is not the worst case. I can simple craft a script where single assignment will lead to hundreds type checks. <?php class A { public ?A $ref; function __construct(&$ref = null) { $this->ref =& $ref; } } for ($i = 0; $i < 100; $i++) { $a[$i] = new A($ref); } $ref = new A; // <= 100 type checks on a single assignment ?> In case we add union types, we can make 200, 300 check... The worst thing, for me, is variance together with union of multiple class types. Each such method compatibility check is going to be a puzzle solving, and I imagine people, proud of writing "complex pearls". My main concern, I don't like to complicate the language with features that shouldn't be often used, and I don't like to complicate implementation and reduce performance without real need. In my opinion, union of standard types and single class or null should be enough for most typing use cases. Thanks. Dmitry. ________________________________ From: Nikita Popov <nikita.ppv@gmail.com> Sent: Friday, October 25, 2019 13:22 To: Dmitry Stogov <dmitry@zend.com> Cc: PHP internals <internals@lists.php.net> Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2 On Wed, Oct 23, 2019 at 5:42 PM Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> wrote: Hi Nikita, I checked the Union Type implementation, and it more or less good. I mean, it implements the RFC in almost the best way. However, as I don't like the RFC itself. Especially, unions of multiple classes and interference with type variance, I'll vote against this. Actually, I think PHP already took wrong direction implementing "typed references" and "type variance". Introducing more "typing", we suggest using it, but this "typing" comes with a huge cost of run-time checks. From 10% (scalar type hint of argument) to 3 times (typed reference assignment) performance degradation. Anyone may rerun my benchmarks https://gist.github.com/dstogov/fb32023e8dd55e58312ae0e5029556a9 Thanks. Dmitry. For reference, here are the results I get with/without JIT: https://gist.github.com/nikic/2a2d363fffaa3aeb251da976f0edbc33 I think that union types don't really change much in terms of the performance calculus of type checking, because type checking is equally fast (or slow) for a single scalar type, and 5 different scalar types: they are all handled in a single bit check. The only case that is indeed somewhat slow is if multiple class types are used in the union, because we actually have to check each one until we find a match. I do hope that having unions with a large number of classes will not be common. Generally, this area could use some more optimization from the implementation side. I spent a bit of time yesterday optimizing how we perform instanceof checks (the implementation was quite inefficient, especially for interfaces), which had a large positive impact on class type checks. There's more low hanging fruit like this, for example verify_return_type has no JIT implementation yet (which is why with JIT simple arg type checks have nearly zero overhead, while return type checks have a large overhead). Assignments to typed properties are also badly optimized, because everything is punted to the slow path, while we should be able to handle the simple cases with just one extra bit check, without going through the complex implementation that deals with things like weak typing coercions. I do think that performance considerations are important when it comes to new typing features (which is why, for example, we have categorically rejected a "typed arrays" implementation that has to check all array elements), but don't see union types are particular problematic in that regard, beyond what we already have. Nikita ________________________________ From: Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> Sent: Tuesday, October 22, 2019 15:38 To: Nikita Popov <nikita.ppv@gmail.com<mailto:nikita.ppv@gmail.com>>; PHP internals <internals@lists.php.net<mailto:internals@lists.php.net>> Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2 Hi Nikita, Can you please give me one/two days, before starting the voting, for implementation review (at least until October 25), Thanks. Dmitry. ________________________________ From: Nikita Popov <nikita.ppv@gmail.com<mailto:nikita.ppv@gmail.com>> Sent: Tuesday, October 22, 2019 12:36 To: PHP internals <internals@lists.php.net<mailto:internals@lists.php.net>> Subject: [PHP-DEV] Re: [RFC] Union Types v2 On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov <nikita.ppv@gmail.com<mailto:nikita.ppv@gmail.com>> wrote: > Hi internals, > > I'd like to start the discussion on union types again, with a new proposal: > > Pull Request: https://github.com/php/php-rfcs/pull/1 > Rendered Proposal: > > https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md > > As an experiment, I'm submitting this RFC as a GitHub pull request, to > evaluate whether this might be a better medium for RFC proposals in the > future. It would be great if we could keep the discussion to the GitHub > pull request for the purpose of this experiment (keep in mind that you can > also create comments on specific lines in the proposal, not just the > overall discussion thread!) Of course, you can also reply to this mail > instead. The final vote will be held in the wiki as usual. > > Relatively to the previous proposal by Bob&Levi ( > https://wiki.php.net/rfc/union_types), I think the main > differences in > this proposal are: > * Updated to specify interaction with new language features, like full > variance and property types. > * Updated for the use of the ?Type syntax rather than the Type|null > syntax. > * Only supports "false" as a pseudo-type, not "true". > * Slightly simplified semantics for the coercive typing mode. > > Regards, > Nikita > An implementation of this proposal is now available at https://github.com/php/php-src/pull/4838. As the implementation didn't turn up any new issues, I think it's time to move this RFC forward to voting. Nikita CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.