Re: [PHP-DEV] BLAKE3 hash
On Thu, 25 Jan 2024, 06:22 Hans Henrik Bergan, wrote:
> On Wed, 24 Jan 2024 at 17:59, Marco Pivetta wrote:
> >
> > Depends on the actual numbers: is there any way to make a comparison that
> > is relatively stable across architectures?
> >
> > Would it be feasible to start with the
> > cross-platform-let-the-compiler-do-its-job version (that somebody may
> > actually be capable of auditing), and then introduce other versions when
> > the jump is significant enough?
> >
>
> don't know about "relatively stable across architectures" but wrote
> some benchmarking code, keep reading.
>
>
>
> On Wed, 24 Jan 2024 at 17:55, tag Knife wrote:
> > Should we even be considering the specific instruction implementations?
> > I've always been in the camp
> > of you are not smarter than the compiler. As even the best human written
> > ASM code can be slower
> > than the obscure instructions the compiler might choose to use in a weird
> > and wonderful way.
>
> The BLAKE3 team is smarter than GCC11.4, even with -march=native
> -mtune=native, which is *not* commonly used in PHP,
> the compiler didn't stand a chance against the hand-optimized assembly
> versions,
>
> wrote some benchmarks, but the TL;DR is:
> portable -O2 usually used by PHP managed 1126MB/s,
> portable -O2 -march=native managed 533MB/s (wtf? gcc obviously got
> something wrong here),
> hand-written -O2 SSE2 managed 3144MB/s,
> hand-written -O2 SSE41 managed 3332MB/s,
> hand-written -O2 avx2 managed 6554MB/s,
> hand-writen -O2 AVX512 managed 8913MB/s,
> on my AMD Ryzen 9 7950x,
> benchmarking code:
> https://gist.github.com/divinity76/5729472dd5d77e94cd0acb245aac2226
> raw output:
> array(6) {
> ["O2-portable-march"]=>
> array(2) {
> ["microseconds_for_16_kib"]=>
> int(29295)
> ["mb_per_second"]=>
> float(533.3674688513398)
> }
> ["O2-portable"]=>
> array(2) {
> ["microseconds_for_16_kib"]=>
> int(13876)
> ["mb_per_second"]=>
> float(1126.0449697319111)
> }
> ["O2-sse2"]=>
> array(2) {
> ["microseconds_for_16_kib"]=>
> int(4969)
> ["mb_per_second"]=>
> float(3144.4958744214127)
> }
> ["O2-sse41"]=>
> array(2) {
> ["microseconds_for_16_kib"]=>
> int(4688)
> ["mb_per_second"]=>
> float(3332.977815699659)
> }
> ["O2-avx2"]=>
> array(2) {
> ["microseconds_for_16_kib"]=>
> int(2384)
> ["mb_per_second"]=>
> float(6554.1107382550335)
> }
> ["O2-avx512"]=>
> array(2) {
> ["microseconds_for_16_kib"]=>
> int(1753)
> ["mb_per_second"]=>
> float(8913.291500285226)
> }
> }
>
Oh yes, the AVX jump is impressive
Re: [PHP-DEV] BLAKE3 hash
On Wed, 24 Jan 2024 at 17:59, Marco Pivetta wrote:
>
> Depends on the actual numbers: is there any way to make a comparison that
> is relatively stable across architectures?
>
> Would it be feasible to start with the
> cross-platform-let-the-compiler-do-its-job version (that somebody may
> actually be capable of auditing), and then introduce other versions when
> the jump is significant enough?
>
don't know about "relatively stable across architectures" but wrote
some benchmarking code, keep reading.
On Wed, 24 Jan 2024 at 17:55, tag Knife wrote:
> Should we even be considering the specific instruction implementations?
> I've always been in the camp
> of you are not smarter than the compiler. As even the best human written
> ASM code can be slower
> than the obscure instructions the compiler might choose to use in a weird
> and wonderful way.
The BLAKE3 team is smarter than GCC11.4, even with -march=native
-mtune=native, which is *not* commonly used in PHP,
the compiler didn't stand a chance against the hand-optimized assembly versions,
wrote some benchmarks, but the TL;DR is:
portable -O2 usually used by PHP managed 1126MB/s,
portable -O2 -march=native managed 533MB/s (wtf? gcc obviously got
something wrong here),
hand-written -O2 SSE2 managed 3144MB/s,
hand-written -O2 SSE41 managed 3332MB/s,
hand-written -O2 avx2 managed 6554MB/s,
hand-writen -O2 AVX512 managed 8913MB/s,
on my AMD Ryzen 9 7950x,
benchmarking code:
https://gist.github.com/divinity76/5729472dd5d77e94cd0acb245aac2226
raw output:
array(6) {
["O2-portable-march"]=>
array(2) {
["microseconds_for_16_kib"]=>
int(29295)
["mb_per_second"]=>
float(533.3674688513398)
}
["O2-portable"]=>
array(2) {
["microseconds_for_16_kib"]=>
int(13876)
["mb_per_second"]=>
float(1126.0449697319111)
}
["O2-sse2"]=>
array(2) {
["microseconds_for_16_kib"]=>
int(4969)
["mb_per_second"]=>
float(3144.4958744214127)
}
["O2-sse41"]=>
array(2) {
["microseconds_for_16_kib"]=>
int(4688)
["mb_per_second"]=>
float(3332.977815699659)
}
["O2-avx2"]=>
array(2) {
["microseconds_for_16_kib"]=>
int(2384)
["mb_per_second"]=>
float(6554.1107382550335)
}
["O2-avx512"]=>
array(2) {
["microseconds_for_16_kib"]=>
int(1753)
["mb_per_second"]=>
float(8913.291500285226)
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Basic Type Alias
I have been so busy lately, which gave me no time to work on the type alias
implementation. but I will be happy if anyone can volunteer/help in
implementing this feature so that it can be introduced in PHP 8.4 or 9.0,
as this will help optimise a lot of people and codebase out there.
On Monday, October 30, 2023, Larry Garfield wrote:
> On Sun, Oct 29, 2023, at 9:52 PM, Jorg Sowa wrote:
> > I really like the idea and I would love to see it in PHP. I'm wondering
> > however, what would be the scope of the feature and how complex would be
> > designed type system. Examples I saw in this thread could be easily
> > replaced with union and intersection types (i.e. numeric as int|float).
> In
> > my opinion, there is a little benefit implementing in this shape making
> the
> > PHP core more complex.
> >
> > The two use cases of user defined types in PHP which would benefit a lot
> > IMO, would be:
> > 1. Typed arrays similar to Typescript.
> > 2. Semantic types which would increase the security of systems. Example:
> > type UserId = int;
> >
> > function setUserId_1(int $userId){}
> >
> > function setUserId_2(UserId $userId){}
> >
> > setUserId_1(5); // OK
> > setUserId_2(5); // TypeError
> >
> > setUserId_1(UserId(5)); // OK
> > setUserId_2(UserId(5)); // OK
> >
> > Kind regards,
> > Jorg
>
> Simple unions are the easiest to talk about in quick examples, but the
> real benefit of type aliases is in other cases, some of which they would
> enable.
>
> Example:
>
> I have a real parameter defined in my attributes library like this:
>
> \ReflectionProperty|\ReflectionMethod|\ReflectionClassConstant $subject
>
> And it appears several times, I believe. That would definitely be nicer
> if simplified to an alias.
>
> Example:
>
> There's general consensus that callable types would be beneficial:
> callable(RequestInterface, string): string or similar. But inline, that
> gets long and complicated fast. Type aliases would allow simplifying that
> to
>
> type callable(RequestInterface, string): string as PropertyRetriever
>
> function foo(PropertyRetriever $c) { ... }
>
> Example:
>
> As in the above example, type aliases serve as documentation for callables
> or complex types, explaining what that complex ruleset actually means,
> semantically.
>
> Example:
>
> If generics or typed arrays ever happen, they'd probably be useful here,
> too.
>
> Note that using type aliases in a required-fashion is a different matter,
> and potentially not feasible. Free standing variables are untyped, which
> means setUserId(UserId $id) could not require a UserId, because there's no
> way to define a variable as being a UserId, not an int. While I can
> definitely see a value in that kind of restriction, in practice I don't
> think PHP is capable of it without vastly larger changes.
>
> --Larry Garfield
>
--
Best Regards,
O. Vincent
Re: [PHP-DEV] RFC - foreach
Le mer. 24 janv. 2024 à 18:13, Mönôme Epson a écrit : > No, I hadn't seen it. Sorry, it was marked on it : "Status: Implemented" > > It's because of this kind of code confused me: https://3v4l.org/s8h2l > > Everything is back to normal. > > Thanks > > Le mer. 24 janv. 2024 à 17:09, Marco Pivetta a > écrit : > >> Hey Mönôme, >> >> On Wed, 24 Jan 2024 at 17:07, Mönôme Epson wrote: >> >>> Hello internals, >>> My best wishes for 2024 >>> >>> I just read this RFC: >>> https://wiki.php.net/rfc/php7_foreach#foreach_by_reference_over_arrays >>> Does anyone remember why this RFC remained? >>> Since 2015 ... 97% Yes >>> >> >> Seen this? >> >> https://github.com/php/php-src/pull/1034#issuecomment-74066967 >> >> Marco Pivetta >> >> https://mastodon.social/@ocramius >> >> https://ocramius.github.io/ >> >> > Gmail is not practical for post. Which client do you use?
Re: [PHP-DEV] RFC - foreach
No, I hadn't seen it. Sorry, it was marked on it : "Status: Implemented" It's because of this kind of code confused me: https://3v4l.org/s8h2l Everything is back to normal. Thanks Le mer. 24 janv. 2024 à 17:09, Marco Pivetta a écrit : > Hey Mönôme, > > On Wed, 24 Jan 2024 at 17:07, Mönôme Epson wrote: > >> Hello internals, >> My best wishes for 2024 >> >> I just read this RFC: >> https://wiki.php.net/rfc/php7_foreach#foreach_by_reference_over_arrays >> Does anyone remember why this RFC remained? >> Since 2015 ... 97% Yes >> > > Seen this? > > https://github.com/php/php-src/pull/1034#issuecomment-74066967 > > Marco Pivetta > > https://mastodon.social/@ocramius > > https://ocramius.github.io/ > >
Re: [PHP-DEV] BLAKE3 hash
On Wed, 24 Jan 2024 at 17:55, tag Knife wrote: > Should we even be considering the specific instruction implementations? > I've always been in the camp > Depends on the actual numbers: is there any way to make a comparison that is relatively stable across architectures? Would it be feasible to start with the cross-platform-let-the-compiler-do-its-job version (that somebody may actually be capable of auditing), and then introduce other versions when the jump is significant enough? Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/
Re: [PHP-DEV] BLAKE3 hash
On Wed, 24 Jan 2024 at 16:27, Hans Henrik Bergan wrote: > Maybe vote on it? (that was suggested in the PR too, > https://github.com/php/php-src/pull/13194#issuecomment-1900430400 ) > > Can think of 6 things > > 1: Should BLAKE3 be added to PHP? yes/no > 2: Should ARM Neon (2007) optimized implementation be bundled? yes/no > 3: Should x86_64 SSE2 (2000) optimized implementation be bundled? yes/no > 4: Should x86_64 SSE4.1 (2007) optimized implementation be bundled? yes/no > 5: Should x86_64 AVX2 (2011) optimized implementation be bundled? yes/no > 6: Should x86_64 AVX512 (2016) optimized implementation be bundled? yes/no > > (wrote the year processors were actually released, not the year > instructions were proposed/announced) > > Arguments against SSE2 and SSE4.1: pretty much all modern CPUs supporting > SSE2/SSE4.1 also support AVX2. > > Argument against AVX512: CloudFlare said in a blogpost that when a core > starts executing AVX512 instructions, it decreases the clock speed of > neighboring cores so much that, quote: > >OpenSSL serves 10% fewer requests per second. And that is a huge number! > It is equivalent to giving up on two cores, for nothing > > and another quote: > > >If you do not require AVX-512 for some specific high performance tasks, I > suggest you disable AVX-512 execution on your server or desktop, to avoid > accidental AVX-512 throttling. > > (ref > https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling > ) > that AVX512 issue is probably cpu-specific and will probably be mitigated > in newer CPU releases > (idk if AMD is even affected, or if it is purely a Intel issue) > > thus they may be worthy of a vote > Should we even be considering the specific instruction implementations? I've always been in the camp of you are not smarter than the compiler. As even the best human written ASM code can be slower than the obscure instructions the compiler might choose to use in a weird and wonderful way.
Re: [PHP-DEV] BLAKE3 hash
Maybe vote on it? (that was suggested in the PR too, https://github.com/php/php-src/pull/13194#issuecomment-1900430400 ) Can think of 6 things 1: Should BLAKE3 be added to PHP? yes/no 2: Should ARM Neon (2007) optimized implementation be bundled? yes/no 3: Should x86_64 SSE2 (2000) optimized implementation be bundled? yes/no 4: Should x86_64 SSE4.1 (2007) optimized implementation be bundled? yes/no 5: Should x86_64 AVX2 (2011) optimized implementation be bundled? yes/no 6: Should x86_64 AVX512 (2016) optimized implementation be bundled? yes/no (wrote the year processors were actually released, not the year instructions were proposed/announced) Arguments against SSE2 and SSE4.1: pretty much all modern CPUs supporting SSE2/SSE4.1 also support AVX2. Argument against AVX512: CloudFlare said in a blogpost that when a core starts executing AVX512 instructions, it decreases the clock speed of neighboring cores so much that, quote: >OpenSSL serves 10% fewer requests per second. And that is a huge number! It is equivalent to giving up on two cores, for nothing and another quote: >If you do not require AVX-512 for some specific high performance tasks, I suggest you disable AVX-512 execution on your server or desktop, to avoid accidental AVX-512 throttling. (ref https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling ) that AVX512 issue is probably cpu-specific and will probably be mitigated in newer CPU releases (idk if AMD is even affected, or if it is purely a Intel issue) thus they may be worthy of a vote
Re: [PHP-DEV] RFC - foreach
Hey Mönôme, On Wed, 24 Jan 2024 at 17:07, Mönôme Epson wrote: > Hello internals, > My best wishes for 2024 > > I just read this RFC: > https://wiki.php.net/rfc/php7_foreach#foreach_by_reference_over_arrays > Does anyone remember why this RFC remained? > Since 2015 ... 97% Yes > Seen this? https://github.com/php/php-src/pull/1034#issuecomment-74066967 Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/
[PHP-DEV] RFC - foreach
Hello internals, My best wishes for 2024 I just read this RFC: https://wiki.php.net/rfc/php7_foreach#foreach_by_reference_over_arrays Does anyone remember why this RFC remained? Since 2015 ... 97% Yes Best regards, SVGAnimate
Re: [PHP-DEV] Re: Wiki Access request
On Wed, Jan 24, 2024 at 1:22 PM Ilija Tovilo wrote: > > Thank you for the list. It looks more digestible, and most of it is > already congruent with CONTRIBUTING.md. > > * https://www.zend.com/resources/writing-php-extensions requires > sharing your contact infomation to obtain. I'm not sure how other > people feel about this. Oh, nevermind. That sidebar is clickable. I missed that there's an online version. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Wiki Access request
Hi Carlos On Wed, Jan 24, 2024 at 12:29 PM Barel wrote: > > > Feel free to share this list here, on GitHub or otherwise. I'm > > skeptical whether throwing partially outdated resources at people is > > actually helpful. > > I trimmed the list that I collected so that it only included the most > significant items which have a lot of information. This list would be: > - https://www.phpinternalsbook.com/ PHP Internals book > - https://phpinternals.net/ PHP Internals web site with documentation about > a lot of the structures and macros used in the code > - https://www.npopov.com/ Nikita Popov's blog > - http://blog.jpauli.tech/ Julien Pauli's blog > - https://phpinternals.news/ Derick Rethans' podcast > - https://www.zend.com/resources/writing-php-extensions Zend's guide about > writing PHP extensions > - https://wiki.php.net/internals The internals page in the wiki > - https://www.informit.com/store/extending-and-embedding-php-9780672327049 > Sara Golemon's printed book > > Do you think this sounds good? If you do, I will create the PR to update > the contributing doc Thank you for the list. It looks more digestible, and most of it is already congruent with CONTRIBUTING.md. * Juliens blog is a bit large, but contains some very detailed posts that should still be relevant. It might make sense to list them explicitly. * https://www.zend.com/resources/writing-php-extensions requires sharing your contact infomation to obtain. I'm not sure how other people feel about this. * https://www.informit.com/store/extending-and-embedding-php-9780672327049 might be outdated, as it was published back in the PHP 5.1 era. I'll leave it up to Sara whether she thinks the book should be recommended at this time. The rest seems to be already listed. Regards, Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Wiki Access request
> > > Feel free to share this list here, on GitHub or otherwise. I'm > skeptical whether throwing partially outdated resources at people is > actually helpful. > > > - Add a new page in the Github repo with all these links and link to that > > page from the contributing page > > - Keep the list in the wiki and link to that page from the contributing > page > > One of the reasons I'd like to move off of the wiki for these things > is that there is no review process. We highly value volunteer work, > but trusting new contributors to blindly make changes to official > guides is obviously somewhat problematic. > > I'd prefer to make CONTRIBUTING.md the "official list" for now. This > file is allowed to be long. And as mentioned, I suspect that the list > of 20+ items may be trimmed. > > Ilija > > Ilija, I trimmed the list that I collected so that it only included the most significant items which have a lot of information. This list would be: - https://www.phpinternalsbook.com/ PHP Internals book - https://phpinternals.net/ PHP Internals web site with documentation about a lot of the structures and macros used in the code - https://www.npopov.com/ Nikita Popov's blog - http://blog.jpauli.tech/ Julien Pauli's blog - https://phpinternals.news/ Derick Rethans' podcast - https://www.zend.com/resources/writing-php-extensions Zend's guide about writing PHP extensions - https://wiki.php.net/internals The internals page in the wiki - https://www.informit.com/store/extending-and-embedding-php-9780672327049 Sara Golemon's printed book Do you think this sounds good? If you do, I will create the PR to update the contributing doc Cheers Carlos
Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs
Hi Sara Thank you for your feedback. On Tue, Jan 23, 2024 at 8:41 PM Sara Golemon wrote: > > On Mon, Jan 22, 2024 at 1:24 AM Ilija Tovilo wrote: > > > I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC. > > https://wiki.php.net/rfc/rfc1867-non-post > > > > 1/ This function reaches into the SAPI to pull out the "special" body > data. That's great, but what about uses where providing an input string > makes sense. For that, and for point 2, I'd suggest > `http_parse_query(string $query, ?array $options = null): array|object`. The RFC previously included support for the $input_stream variable (string is not very appropriate for multipart because the input may be arbitrarily large). The implementation wasn't complex, but it required duplication of all the reads to support both a direct read from the SAPI and a read from the stream, duplication of some limit checks and special passing of the streams to avoid SAPI API breakage. As for actual use cases, I found limited evidence that this function would be useful for worker-based services _right now_. Most services handle request parsing in some other layer. For example, RoadRunner has a Go server that stores the file to disk, and then just passes the appropriate path to PHP in the $_FILES array. It seems to me that a custom input would be useful exclusively for a web server written in PHP. The one that was pointed out to me (AdapterMan) handles requests as strings, which would not scale for multipart requests. I don't mind getting back to this if AdapterMan rewrites request handling to use streams. Adding back the $input_stream parameter can be done with no BC breaks. But for the time being, I don't think the motivation is big enough to justify the added complexity. Additionally, because multipart is used exclusively as a request content type, it isn't useful in a general sense either, because a PHP request will typically only receive one request (but potentially multiple responses, in case it communicates with other servers). > 2/ `request_` represents a new psuedo-namespace, functions are easier to > find and associate if we keep them grouped. I recommend 'http_` because it > compliments the very related function `http_build_query()`, and for the > version of this function which refers directly to the request: > `http_parse_request(?array $options = null) : array|object`. That's fair. If the name bothers you I can create an amendment RFC. I think http_parse_body() would be a bit more appropriate, because request implies more than just the body. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
