RE: [PHP-DEV] Make PHP JIT to generate AVX2/AVX3 for performance improvement?
> > > Hi Guys, > > > > > > A quick question: is it possible to enable AVX2/AVX3 in PHP JIT > generated > > > code, and hence can get some performance improvement? > > > Just check the community first: if anyone has already tried that or > got > > > some experiences? before we dive into this investigation. > > > We are discussing if we could get some extra performance via new > AVX > > > instructions in PHP program execution. > > > > > > Thanks. > > > > > > > AVX3 might be too new to just flat out generate for it. But > > It can be quite simple for the JIT compiler to be aware of what > > features flags are enabled on a CPU and generate compatible > > instructions that will run on that CPU. > > > > it is not really new, however the gain for most cases are not necessarily > significant but for specific cases. > > For most usages in php, at a request level, the gain will be barely > measurable. > > Also for latest avx, most hosting servers won't have them anyway. > > I would think some specific APIs to prepare specific data to be > processed > using the best available runtime intrinsics would bring much more than > in > JIT. > > As a sidenote, most libraries used by php, where larger intrinsics > vectors > bring something, implement them already. > > > best, > Pierre > Thanks Pierre and tag? (apologize if I take your name wrongly) for the hint and information. We will carefully think about them... So far, we are still in early investigation stage and would like to hear opinions and ideas from our community. Best, Tony Su
Re: [PHP-DEV] Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Hi Derick On Wed, Oct 18, 2023 at 6:10 PM Derick Rethans wrote: > On Fri, 13 Oct 2023, Ilija Tovilo wrote: > > > https://wiki.php.net/rfc/rfc1867-non-post > > The only comment I would have is that I probably would be in favour of > not leaving the "config" argument (to over ride per call the > post_max_size settings etc) to a future scope. > > Having to do ini_get/ini_set/ini_set(old) to override these settings > seems clunky. As per request I've included an $options parameter to override the relevant INI values for the duration of the function call. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: New RFC : empty() function
Hi Mr. Wetherington,
thanks for appreciating my proposal.
According to the contents of my RFC under discussion,
I suppose my version works better than the code you presented.
The RFC contents do illustrate the details of the performance as well as
some examples have been included.
For what concerns the implementation, I __just__ suggested deprecation.
Both empty() and is_empty() may co-live.
Regards,
Alessandro Rosa
Il giorno mar 31 ott 2023 alle ore 17:08 Brady Wetherington via internals <
internals@lists.php.net> ha scritto:
> > I have posted a new RFC at this link
> https://wiki.php.net/rfc/empty_function
> > where I suggested some improvements to the standard built-in empty()
> > function and provided a number of examples.
>
> Is your "is_empty()" function equivalent to something like:
>
> function is_empty($param = null)
> {
> return empty($param) && $param !== false && $param !== 0 && $param !==
> 0.0;
> }
>
> If so, that might actually be kinda nice? I was looking for something
> like that the other day.
>
> Regardless, I wouldn't do the BC-break; I'd be more inclined to (very
> begrudgingly) leave empty() and warn against its use, and have
> is_empty() as a new thing. Maybe for some future deprecation or
> removal?
>
> I also do like the idea that someone else mentioned here about being
> able to possibly start to get away from @'ing variables with a
> solution like this.
>
> -B.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Il giorno mar 31 ott 2023 alle ore 17:08 Brady Wetherington via internals <
internals@lists.php.net> ha scritto:
> > I have posted a new RFC at this link
> https://wiki.php.net/rfc/empty_function
> > where I suggested some improvements to the standard built-in empty()
> > function and provided a number of examples.
>
> Is your "is_empty()" function equivalent to something like:
>
> function is_empty($param = null)
> {
> return empty($param) && $param !== false && $param !== 0 && $param !==
> 0.0;
> }
>
> If so, that might actually be kinda nice? I was looking for something
> like that the other day.
>
> Regardless, I wouldn't do the BC-break; I'd be more inclined to (very
> begrudgingly) leave empty() and warn against its use, and have
> is_empty() as a new thing. Maybe for some future deprecation or
> removal?
>
> I also do like the idea that someone else mentioned here about being
> able to possibly start to get away from @'ing variables with a
> solution like this.
>
> -B.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
[PHP-DEV] Re: New RFC : empty() function
> I have posted a new RFC at this link https://wiki.php.net/rfc/empty_function
> where I suggested some improvements to the standard built-in empty()
> function and provided a number of examples.
Is your "is_empty()" function equivalent to something like:
function is_empty($param = null)
{
return empty($param) && $param !== false && $param !== 0 && $param !== 0.0;
}
If so, that might actually be kinda nice? I was looking for something
like that the other day.
Regardless, I wouldn't do the BC-break; I'd be more inclined to (very
begrudgingly) leave empty() and warn against its use, and have
is_empty() as a new thing. Maybe for some future deprecation or
removal?
I also do like the idea that someone else mentioned here about being
able to possibly start to get away from @'ing variables with a
solution like this.
-B.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Make PHP JIT to generate AVX2/AVX3 for performance improvement?
On Tue, Oct 31, 2023, 3:57 PM tag Knife wrote: > > Hi Guys, > > > > A quick question: is it possible to enable AVX2/AVX3 in PHP JIT generated > > code, and hence can get some performance improvement? > > Just check the community first: if anyone has already tried that or got > > some experiences? before we dive into this investigation. > > We are discussing if we could get some extra performance via new AVX > > instructions in PHP program execution. > > > > Thanks. > > > > AVX3 might be too new to just flat out generate for it. But > It can be quite simple for the JIT compiler to be aware of what > features flags are enabled on a CPU and generate compatible > instructions that will run on that CPU. > it is not really new, however the gain for most cases are not necessarily significant but for specific cases. For most usages in php, at a request level, the gain will be barely measurable. Also for latest avx, most hosting servers won't have them anyway. I would think some specific APIs to prepare specific data to be processed using the best available runtime intrinsics would bring much more than in JIT. As a sidenote, most libraries used by php, where larger intrinsics vectors bring something, implement them already. best, Pierre >
Re: [PHP-DEV] New RFC : empty() function
Hi Alessandro, I would still advise to just let this empty() construct die a natural death. If you want to change anything, you must remember that it's basically a syntactic sugar for `@!$var` For example if(empty($var)) is just if(@!$var) To change this function would require changing the rules for type juggling.
Re: [PHP-DEV] New RFC : empty() function
Thank you, G.P.B. for editing and for sharing your honest viewpoint. I saw your corrections and already fixed some flaws in the RFC text. I raised issues that are critical on my modest viewpoint. I see languages as an optimal mix between semantics, grammar and performance. The built-in empty() functions really needs to be revisited along these directions. Sincerely, Alessandro Rosa Il giorno mar 31 ott 2023 alle ore 12:34 G. P. B. ha scritto: > > On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa > wrote: > >> Hi Marcos, >> >> thanks for feedback. >> Could you be clearer about your advice and gimme an example please? >> > > I have edited the RFC content to add highlighting, hopefully you can now > use that to improve the RFC text. > > However, I'm not very convinced at the moment that such a function is > truly useful. > > Best regards, > > Gina/George P. Banyard > > > >
Re: [PHP-DEV] New RFC : empty() function
On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa wrote: > Hi Marcos, > > thanks for feedback. > Could you be clearer about your advice and gimme an example please? > I have edited the RFC content to add highlighting, hopefully you can now use that to improve the RFC text. However, I'm not very convinced at the moment that such a function is truly useful. Best regards, Gina/George P. Banyard
Re: [PHP-DEV] New RFC : empty() function
Hi Marcos, thanks for feedback. Could you be clearer about your advice and gimme an example please? Alessandro Il giorno mar 31 ott 2023 alle ore 11:59 Marcos Marcolin < marcolin...@gmail.com> ha scritto: > Hi Alessandro, > > It would be better to add syntax highlighting to the code examples of > your RFC, it is not legal to read/understand the texts as if they were > just texts. > > --- > Marcos Marcolin > Software Engineer | PHP > www.marcosmarcolin.com.br >
Re: [PHP-DEV] New RFC : empty() function
Hi Alessandro, It would be better to add syntax highlighting to the code examples of your RFC, it is not legal to read/understand the texts as if they were just texts. --- Marcos Marcolin Software Engineer | PHP www.marcosmarcolin.com.br
Re: [PHP-DEV] New RFC : empty() function
Hi Mr. Tommins,
thank you very much for all your very valuable advices.
You can read a more robust discussion about my RFC at
https://wiki.php.net/rfc/empty_function
Regards,
Alessandro Rosa
Il giorno lun 30 ott 2023 alle ore 23:54 Rowan Tommins <
rowan.coll...@gmail.com> ha scritto:
> On 30/10/2023 12:24, Alessandro Rosa wrote:
> > I have posted a new RFC at this link
> > https://wiki.php.net/rfc/empty_function where I suggested some
> > improvements to the standard built-in empty() function and provided a
> > number of examples.
>
>
> Hi, and welcome!
>
>
> First, regarding the clarity of the proposal.
>
> You have a few pieces of sample code in the RFC, but the "expected
> value" comments don't actually match what that code would output. Rather
> than inline comments on each line, I suggest you give the current output
> of the whole code, followed by the expected / desired output. I would
> also suggest replacing "" with "\n", to keep the code smaller.
>
> Similarly, your PHP-implemented version of the function is trying to be
> far too clever. If you want to illustrate what you think the rules
> should be, you need a clear, well-commented function implementing those
> rules. The first if statement, for instance, is just a very confusing
> way to write "if ( $input === null ) { return true; }"
>
> Neither style of example really explains why you think your proposed
> rules make sense. *Why* should boolean true be considered empty? In what
> situation would you call the function with no arguments and expect a
> meaningful response?
>
>
> Second, regarding timescales.
>
> As documented at https://wiki.php.net/rfc/releaseprocess the official
> policy of the project is that backwards compatibility can only be broken
> in a major version - that is, the next chance to break compatibility is
> in 9.0, not 8.anything. While there are often grey areas around this
> rule, there is absolutely no question that empty() could be removed any
> time before that. If anything, proposing removal in 10.0 might be more
> reasonable.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Make PHP JIT to generate AVX2/AVX3 for performance improvement?
> Hi Guys, > > A quick question: is it possible to enable AVX2/AVX3 in PHP JIT generated > code, and hence can get some performance improvement? > Just check the community first: if anyone has already tried that or got > some experiences? before we dive into this investigation. > We are discussing if we could get some extra performance via new AVX > instructions in PHP program execution. > > Thanks. > AVX3 might be too new to just flat out generate for it. But It can be quite simple for the JIT compiler to be aware of what features flags are enabled on a CPU and generate compatible instructions that will run on that CPU.
[PHP-DEV] Make PHP JIT to generate AVX2/AVX3 for performance improvement?
Hi Guys, A quick question: is it possible to enable AVX2/AVX3 in PHP JIT generated code, and hence can get some performance improvement? Just check the community first: if anyone has already tried that or got some experiences? before we dive into this investigation. We are discussing if we could get some extra performance via new AVX instructions in PHP program execution. Thanks.
