Re: [PHP-DEV] Introduction

[Gina P. Banyard]

On Tuesday, 4 June 2024 at 12:57, Bilal Gültekin  wrote:

> Hello,
>
> I'm Bilal Gultekin (wiki username: bilal). I have almost 20 years of PHP 
> experience. I'd like to follow up on proposed RFCs, comment on them, and 
> maybe create one myself.
>
> I'm from Istanbul, Turkey. You can check out my GitHub 
> (https://github.com/bgultekin) and LinkedIn 
> (https://www.linkedin.com/in/bilalgultekin/) profiles.
>
> Thanks!
> --
>
> Bilal Gültekin

Hello Bilal,

Thank you for your interest!
As Tim said, you can comment on RFCs by just replying to the relevant email 
thread.
Be aware that we have some rules to participate on the mailing list listed on 
GitHub: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
The main one is to *not* top post (which most email clients seem to do by 
default annoyingly enough).

Unless you already have an RFC in mind, and possibly a draft (can be a gist, 
github repo, whatever) we don't generally grant Wiki editing rights.

Feel free to ask any more questions!

Best regards,
Gina P. Banyard

Re: [PHP-DEV] Introduction

[Bilal Gültekin]

Hi Tim,

Thanks for the clarification. I don’t have something for which I’d create
an RFC right away. I’m fine with not having edit permission if it is given
only in that case.

Best
*Bilal Gültekin*


4 Haz 2024 Sal, saat 20:48 tarihinde Tim Düsterhus  şunu
yazdı:

> Hi
>
> On 6/4/24 13:57, Bilal Gültekin wrote:
> > I'm Bilal Gultekin (wiki username: bilal). I have almost 20 years of PHP
> > experience. I'd like to follow up on proposed RFCs, comment on them, and
> > maybe create one myself.
>
> Commenting on RFCs is done purely on this mailing list. Just chime in
> whenever you have something useful to add. You don't need a Wiki account
> for that.
>
> The approved Wiki account is only required to edit pages on the Wiki,
> i.e. to create your own RFC. Do have already have something in mind?
>
> Best regards
> Tim Düsterhus
>

Re: [PHP-DEV] Introduction

[Tim Düsterhus]

Hi

On 6/4/24 13:57, Bilal Gültekin wrote:

I'm Bilal Gultekin (wiki username: bilal). I have almost 20 years of PHP
experience. I'd like to follow up on proposed RFCs, comment on them, and
maybe create one myself.


Commenting on RFCs is done purely on this mailing list. Just chime in 
whenever you have something useful to add. You don't need a Wiki account 
for that.


The approved Wiki account is only required to edit pages on the Wiki, 
i.e. to create your own RFC. Do have already have something in mind?


Best regards
Tim Düsterhus

[PHP-DEV] Introduction

[Bilal Gültekin]

Hello,

I'm Bilal Gultekin (wiki username: bilal). I have almost 20 years of PHP
experience. I'd like to follow up on proposed RFCs, comment on them, and
maybe create one myself.

I'm from Istanbul, Turkey. You can check out my GitHub (
https://github.com/bgultekin) and LinkedIn (
https://www.linkedin.com/in/bilalgultekin/) profiles.

Thanks!

-- 
*Bilal Gültekin*

Re: [PHP-DEV] Introduction - SuitespaceRnD

[Garet Claborn]

Thanks for all the tips and feedback so far. I will try to respond to
clarify each so far.

> On Sun, Apr 23, 2023 at 12:53 PM Rowan Tommins 
wrote:
> - If the aim is to allow array keys to be enum cases themselves (or
>   objects in general), you'll likely need at least a partial
>   implementation before taking it to a vote, as the impact on the rest of
>   the engine, in terms of performance and complexity, will be a major
>   deciding factor. You can still draft the RFC beforehand to judge the
>   interest, however.
>
>   - If the aim is to automatically cast the enum cases to ordinary strings
>   or ints, expect some scepticism. I for one believe that it is an
>   essential property of enums that Day::Monday == Month::January should be
>   false, and it follows that array_key_exists(Day::Monday, [Month::January
>   => true]) should be false as well.

First, we are indeed placing resources on getting this implementation on
our end (though any guidance is more than welcome as this is my first
attempt with the internals)

Niels Dossche also mentions we should request RFC karma.
I was unclear if I should wait until we have implemented further before
posting, however a simple text version exists already. Happy to do so now.

To your main point; I do agree with the general thrust of feedback on the
enum implementation given in that issue thread, which aligns more closely
to your second case. While the direction I presented in that issue
regarding the meaning and purpose of enumerations in programming and more
broadly did overwhelmingly outweigh dissent, there has been considerable
pushback about typing so far. However I would suggest that this can be
roadmapped into a win-win scenario rather than an A vs B scenario and the
RFC tries to reflect this.

Whereas object keys are a whole other can of worms at the moment, the RFC
makes recommendations which would align with both of these cases. For as
long as object keys do not exist, the value semantic would apply. Once
object keys do exist the only difference between the typesafe goal you are
looking for and our recommended implementation would be that

*Day::Monday == Month::January *would be true *but*
*Day::Monday === Month::January *would be false

Similarly with ArrayAccess, if we ever get more type resolution in the
context of keys this can be conveyed simply by strongly typing the function
parameters rather than current string or int types. As soon as PHP keys
accept object types, or even just a third enum type, this would immediately
enable the desirable


*$current_month = $month[Day::Monday]; // Error*
Assuming you indeed typed your getting such as *offsetGet(Month $offset)*


*Lynn *mentioned, "  I am also interested to see where this goes,
especially beyond the scope of just enums."
This relates to the further roadmap concept I am referencing -- which is
not fully detailed but noted in the initial RFC, and the RFC is designed as
a useful milestone towards that roadmap.

We and many other PHP < 8 projects have usage patterns already established
with class constants which should rightly be seen as "hold ups" in
promoting the use of enums over the old way. By incentivizing such code to
make the switch to enums and providing a behavior which has no side effects
on existing code, other than removing an error, this is a benefit.

Finally because I am familiar with the case of labeling indices especially,
I am aware of methods that will help bridge the gap to eventual object
keys. Though out of scope for this first iteration that is a large part of
the purpose. If implemented, a follow-up RFC can go into more detail; but
the gist is: existing object key RFCs have discovered ways to implement
this for select types of objects but not the general case. With value
semantics implemented, and some glue code in userland, we have recovered
the ability to overload array mechanics further already to allow type
checks.

If this use pattern were further enabled - even the simple value semantics,
we can then use enums as aliases to type checking mechanics for object keys
purely in user land. From there it becomes a simple matter of closing the
gap until at least enums can be a third type of key which provides a type
safety proxy to related objects. This in turn could be further contracted
if full object keys become available - which is enabled by the use patterns
preexisting in userland.


Though I am working along this line of reasoning above to edit the need for
that debate out of the roadmap, I will reiterate my original reasoning for
favoring the second case, prioritizing value semantics.

First because we don't really have an option as long as key contexts such
as ArrayAccess only support int and string at present.

More strongly: Enumerations are constructs which span many disciplines for
which strong assertions can be made about their correlation to lists and
coverage of such lists. Even in cases where an enumeration's order does not
have a numeric 

Re: [PHP-DEV] Introduction - SuitespaceRnD

[Lynn]

On Sun, Apr 23, 2023 at 1:23 PM Niels Dossche 
wrote:

> Hi
>
> Good luck with the RFC, I'm also quite interested in this feature so I'm
> interested to see where it goes.
> You might also want to explicitly ask for RFC karma so that you can create
> a wiki page for the RFC, if you haven't done that already :)
>
> Kind regards
> Niels
>

I am also interested to see where this goes, especially beyond the scope of
just enums.

Re: [PHP-DEV] Introduction - SuitespaceRnD

[Rowan Tommins]

On 19/04/2023 16:11, Garet Claborn wrote:

Specifically I finally registered
as I have written up an RFC in response to this issue thread
  on GitHub.



Welcome, and in case you haven't found it already, here's the guide to 
the RFC process: https://wiki.php.net/rfc/howto


I'll wait with interest to see the RFC, but would note two things:

- If the aim is to allow array keys to be enum cases themselves (or 
objects in general), you'll likely need at least a partial 
implementation before taking it to a vote, as the impact on the rest of 
the engine, in terms of performance and complexity, will be a major 
deciding factor. You can still draft the RFC beforehand to judge the 
interest, however.


- If the aim is to automatically cast the enum cases to ordinary strings 
or ints, expect some scepticism. I for one believe that it is an 
essential property of enums that Day::Monday == Month::January should be 
false, and it follows that array_key_exists(Day::Monday, [Month::January 
=> true]) should be false as well.



On 23/04/2023 17:01, Robert Landers wrote:

Even if it
has to be something 'ugly' to keep people from using that itself as a
value (similar to how js symbol types work -- a one-way cast).



As far as I understand, Symbols in JS are entirely their own type, and 
the definition of objects directly allows property keys to be either a 
String or a Symbol; so it is equivalent to PHP allowing enum cases, but 
not other objects, to be array keys.


> Properties are identified using key values. A property key value is 
either an ECMAScript String value or a Symbol value. All String and 
Symbol values, including the empty String, are valid as property keys.


https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-object-type


Regards,

--
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Introduction - SuitespaceRnD

[Robert Landers]

On Sun, Apr 23, 2023 at 1:57 PM Lokrain  wrote:
>
> Hello,
>
> For me, this is just a wrong way of using enums for the sake of opinionated
> solution of specific problem.
>
> Regards,
> Dimitar
>
> On Sun, 23 Apr 2023 at 14:23, Niels Dossche  wrote:
>
> > Hi
> >
> > On 4/19/23 17:11, Garet Claborn wrote:
> > > Hello PHP Internals,
> > >
> > > I am Garet Claborn, CTO for Suitespace Inc
> > > , leading
> > > up our R team. Just registered and my PHP Wiki username is:
> > > *suitespacernd*
> > >
> > > We use PHP extensively in our projects. Specifically I finally registered
> > > as I have written up an RFC in response to this issue thread
> > >  on GitHub. While I am
> > notably
> > > attached to said issue, I hope to provide useful feedback in general from
> > > our case studies.
> > >
> > > Feel free to reach out for whatever reason.
> > >
> > > Cheers,
> > > Garet Claborn
> > >
> > > CTO, Suitespace Inc
> > > ga...@suiteux.com
> > >
> >
> > Good luck with the RFC, I'm also quite interested in this feature so I'm
> > interested to see where it goes.
> > You might also want to explicitly ask for RFC karma so that you can create
> > a wiki page for the RFC, if you haven't done that already :)
> >
> > Kind regards
> > Niels
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >

> For me, this is just a wrong way of using enums for the sake of opinionated
> solution of specific problem.

That seems a bit of a strong reaction, though I agree that this can be
solved fairly easily in user-land:

trait ArrayKey {
  public function key(): string {
return get_class($this) . '::' . $this->name;
  }
}
enum T { use ArrayKey; case A; case B; }
echo T::A->key();
// outputs: T::A

or even set it up in the constructor.

If you don't have control over the enums, you can write a simple
function to the same. As a side-note, I would rather have enums able
to be casted to a string than to change how arrays work. Even if it
has to be something 'ugly' to keep people from using that itself as a
value (similar to how js symbol types work -- a one-way cast).

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Introduction - SuitespaceRnD

[Lokrain]

Hello,

For me, this is just a wrong way of using enums for the sake of opinionated
solution of specific problem.

Regards,
Dimitar

On Sun, 23 Apr 2023 at 14:23, Niels Dossche  wrote:

> Hi
>
> On 4/19/23 17:11, Garet Claborn wrote:
> > Hello PHP Internals,
> >
> > I am Garet Claborn, CTO for Suitespace Inc
> > , leading
> > up our R team. Just registered and my PHP Wiki username is:
> > *suitespacernd*
> >
> > We use PHP extensively in our projects. Specifically I finally registered
> > as I have written up an RFC in response to this issue thread
> >  on GitHub. While I am
> notably
> > attached to said issue, I hope to provide useful feedback in general from
> > our case studies.
> >
> > Feel free to reach out for whatever reason.
> >
> > Cheers,
> > Garet Claborn
> >
> > CTO, Suitespace Inc
> > ga...@suiteux.com
> >
>
> Good luck with the RFC, I'm also quite interested in this feature so I'm
> interested to see where it goes.
> You might also want to explicitly ask for RFC karma so that you can create
> a wiki page for the RFC, if you haven't done that already :)
>
> Kind regards
> Niels
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Introduction - SuitespaceRnD

[Niels Dossche]

Hi

On 4/19/23 17:11, Garet Claborn wrote:
> Hello PHP Internals,
> 
> I am Garet Claborn, CTO for Suitespace Inc
> , leading
> up our R team. Just registered and my PHP Wiki username is:
> *suitespacernd*
> 
> We use PHP extensively in our projects. Specifically I finally registered
> as I have written up an RFC in response to this issue thread
>  on GitHub. While I am notably
> attached to said issue, I hope to provide useful feedback in general from
> our case studies.
> 
> Feel free to reach out for whatever reason.
> 
> Cheers,
> Garet Claborn
> 
> CTO, Suitespace Inc
> ga...@suiteux.com
> 

Good luck with the RFC, I'm also quite interested in this feature so I'm 
interested to see where it goes.
You might also want to explicitly ask for RFC karma so that you can create a 
wiki page for the RFC, if you haven't done that already :)

Kind regards
Niels

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Introduction - SuitespaceRnD

[Garet Claborn]

Hello PHP Internals,

I am Garet Claborn, CTO for Suitespace Inc
, leading
up our R team. Just registered and my PHP Wiki username is:
*suitespacernd*

We use PHP extensively in our projects. Specifically I finally registered
as I have written up an RFC in response to this issue thread
 on GitHub. While I am notably
attached to said issue, I hope to provide useful feedback in general from
our case studies.

Feel free to reach out for whatever reason.

Cheers,
Garet Claborn

CTO, Suitespace Inc
ga...@suiteux.com

[PHP-DEV] Introduction

[Peter]

Hello

New to PHP internals. Keen on fixing a bug or two where I can.

Warm Regards

Peter Chaula

Re: [PHP-DEV] Introduction and first (codebase related - FZPP - but wiki unrelated) question

[marius adrian popa]

FAST_ZPP is here to stay , see the discussion
https://externals.io/thread/200

And fallback code elimination
https://github.com/php/php-src/pull/2118

On Tue, Apr 25, 2017 at 6:20 PM, Martin "eto" Misuth 
wrote:

> Username: eto
>
> Hello, after lot of pondering, I finally decided to register to mailing
> list
> & wiki. Reading wiki registration page, I am supposed to announce my
> registration here.
>
> I registered mainly for (possible) RFC proposals (none prepared yet) and
> to ask some questions about php codebase - using more lasting medium
> than irc is.
>
> I am sysadmin/PHP "developer" from Slovak Republic with focus on php
> "services" (aka daemons), php backends and such. My main php related
> timesink currently is messing with PHP 7.1.
>
> For few years now, I have been experimenting with extension writing, some
> of
> which I deployed internally. Being sysadmin I am not entirely confident
> with my
> code yet, but I plan to share most of my stuff eventually.
>
> Before that though, I would like to produce few microscopic patches to
> normal php distribution, to ease some miniscule pain points I am
> constantly hitting.
>
> For that, I would first like to ask clarification about FAST_ZPP maco "API"
> from Dmitry Stogov & Bob Weinand.
>
> In my extensions/experiments I am using solely this API for accessing
> php:function() call parameters, not providing any "fallback"
> through zend_parse_parameters() when #ifndef FAST_ZPP.
>
> Skimming through codebase, it seems that few, 'often called', functions
> were
> converted into FZPP style, but they still preserve 'legacy parsing style'
> implemented as well.
>
> Let's say, depending on how my currents attempts end up working, I want to
> modify few bundled extension functions, is it okay to rewrite them to use
> solely FAST_ZPP?
>
> Or does have zend_parse_parameters() codepath to be preserved for years to
> come?
>
>   eto
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Introduction and first (codebase related - FZPP - but wiki unrelated) question

[Martin "eto" Misuth]

Username: eto

Hello, after lot of pondering, I finally decided to register to mailing list
& wiki. Reading wiki registration page, I am supposed to announce my
registration here.

I registered mainly for (possible) RFC proposals (none prepared yet) and 
to ask some questions about php codebase - using more lasting medium 
than irc is.

I am sysadmin/PHP "developer" from Slovak Republic with focus on php
"services" (aka daemons), php backends and such. My main php related 
timesink currently is messing with PHP 7.1.

For few years now, I have been experimenting with extension writing, some of
which I deployed internally. Being sysadmin I am not entirely confident with my 
code yet, but I plan to share most of my stuff eventually. 

Before that though, I would like to produce few microscopic patches to 
normal php distribution, to ease some miniscule pain points I am
constantly hitting.

For that, I would first like to ask clarification about FAST_ZPP maco "API"
from Dmitry Stogov & Bob Weinand.

In my extensions/experiments I am using solely this API for accessing
php:function() call parameters, not providing any "fallback"
through zend_parse_parameters() when #ifndef FAST_ZPP.

Skimming through codebase, it seems that few, 'often called', functions were
converted into FZPP style, but they still preserve 'legacy parsing style'
implemented as well.

Let's say, depending on how my currents attempts end up working, I want to
modify few bundled extension functions, is it okay to rewrite them to use 
solely FAST_ZPP? 

Or does have zend_parse_parameters() codepath to be preserved for years to come?

  eto

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Introduction

[Ondřej Šimon]

Username: simon.ondrej

Hey, I registered on PHP wiki and saw that I was supposed to send an 
email. I registered mainly for RFC proposal. I am a PHP developer from 
the Czech republic with focus on backend. Currently mostly working with 
PHP 7.0 and PHP 7.1.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Introduction to the PHP source code

[Sara Golemon]

On 29/12/16 16:17, ilija.tov...@me.com wrote:
> Looking at the giant repository I feel a little overwhelmed. Is there a
> place where I can get started and learn more about the architecture of the
> interpreter before diving into the source code itself? I’m sorry if this
> question has been asked before.
>
phpinternalsbook.com is a start, but bear in mind it's PHP5 focused
and while the general concepts are the same, a lot of important
specifics have changed in 7.

Broadly speaking:  ext/$1/*.c <--- extension code, where $1 is the
extension name (roughly).

zend_module_entry is the "start point" that everything else bubbles
out from.  All the zend_*() APIs are in Zend/ and (most) of the others
are in main/

You can follow repos like https://github.com/sgolemon/2016-sfmeetup
which are concept-by-concept walkthroughs of the most essential
basics.

Focus on extensions to start, once you're comfortable with those, you
can move confidently onto the scripting engine, sapis, etc...


On Thu, Dec 29, 2016 at 10:42 AM, Bradley Weston  wrote:
> I'm trying to do the same thing.
>
> I've tried to fix a bug in SPL iterators. However the code is not documented
> anywhere and the guys on IRC aren't able to help much without dedicating
> their time.
>
You can also try http://chat.stackoverflow.com/rooms/11/php

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Introduction to the PHP source code

[Bradley Weston]

I'm trying to do the same thing.


I've tried to fix a bug in SPL iterators. However the code is not 
documented anywhere and the guys on IRC aren't able to help much without 
dedicating their time.



Maybe we can try figure it out together?

https://bugs.php.net/bug.php?id=73471

Issue is at: 
https://github.com/php/php-src/blob/master/ext/spl/spl_iterators.c#L3385


But like I said kind of obscure.


On 29/12/16 16:17, ilija.tov...@me.com wrote:

Hi everyone!

I’d like to get familiar with the PHP C code base so that I can contribute back 
to the community and maybe even implement a small RFC at some point when I feel 
comfortable enough.

Looking at the giant repository I feel a little overwhelmed. Is there a place 
where I can get started and learn more about the architecture of the 
interpreter before diving into the source code itself? I’m sorry if this 
question has been asked before.

Any tips would be greatly appreciated.

Thank you!

Regards,
Ilija




--

--


*Bradley Weston [bweston.me]*

Telephone: 0845 004 0662

Mobile: +44 (0) 7902 672289

This message is intended only for the use of person(s) (\"the Intended 
Recipient\") to whom it is addressed. It may contain information that is 
privileged and confidential within the meaning of applicable law. 
Accordingly any dissemination, distribution, copying or other use of 
this message or any of its content by any other person may constitute a 
breach of civil or criminal law and is strictly prohibited. If you are 
not the Intended Recipient please contact the sender as soon as 
possible. Any views expressed in this message are those of the 
individual sender and may not necessarily reflect the views of Legalwebb 
UK Ltd or any of its subsidiary businesses. Legalwebb UK Limited is 
Registered in Cardiff. Company Number 03874311. Registered for VAT 
Number 803886708. Registered Office: 169 London Road, Leicester. LE2 1EG.

[PHP-DEV] Introduction to the PHP source code

[ilija . tovilo]

Hi everyone!

I’d like to get familiar with the PHP C code base so that I can contribute back 
to the community and maybe even implement a small RFC at some point when I feel 
comfortable enough.

Looking at the giant repository I feel a little overwhelmed. Is there a place 
where I can get started and learn more about the architecture of the 
interpreter before diving into the source code itself? I’m sorry if this 
question has been asked before.

Any tips would be greatly appreciated.

Thank you!

Regards,
Ilija

Re: [PHP-DEV] Introduction

[Tobias Nyholm]

I would of course not plan a new summer of code. That is, as you say, a
huge project. I’ll just make sure the Wiki is up to date.

The heading "Current happenings (2010)” is quite sad to see.



Regards
Tobias Nyholm

From: Kalle Sommer Nielsen <ka...@php.net> <ka...@php.net>
Reply: Kalle Sommer Nielsen <ka...@php.net> <ka...@php.net>
Date: 19 november 2016 at 10:53:11
To: Tobias Nyholm <tobias.nyh...@gmail.com> <tobias.nyh...@gmail.com>
Cc: Internals <internals@lists.php.net> <internals@lists.php.net>
Subject:  Re: [PHP-DEV] Introduction

Hi Tobias

2016-11-18 15:04 GMT+01:00 Tobias Nyholm <tobias.nyh...@gmail.com>:
> Hey.
> I’m nyholm.
> I want to update the Google Summer of code page on the wiki to be more
> accurate.
> https://wiki.php.net/gsoc

Sadly we have not had anyone active to organize the GSoC for quite
some years now. You should do a full introduction on the webmasters
list (php-webmas...@lists.php.net)[1] and describe your plan and
intentions for future participation with the GSoC, remember it is a
heavy one man project to do, but hopefully you can build up some
momentum for once again making PHP participate.

[1] http://news.php.net/php.webmaster


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

Re: [PHP-DEV] Introduction

[Kalle Sommer Nielsen]

Hi Tobias

2016-11-18 15:04 GMT+01:00 Tobias Nyholm :
> Hey.
> I’m nyholm.
> I want to update the Google Summer of code page on the wiki to be more
> accurate.
> https://wiki.php.net/gsoc

Sadly we have not had anyone active to organize the GSoC for quite
some years now. You should do a full introduction on the webmasters
list (php-webmas...@lists.php.net)[1] and describe your plan and
intentions for future participation with the GSoC, remember it is a
heavy one man project to do, but hopefully you can build up some
momentum for once again making PHP participate.

[1] http://news.php.net/php.webmaster


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Introduction

[Tobias Nyholm]

Hey.
I’m nyholm.
I want to update the Google Summer of code page on the wiki to be more
accurate.
https://wiki.php.net/gsoc



Regards
Tobias Nyholm

[PHP-DEV] Introduction

[Noah Overcash]

Hi,
I'm Noah Overcash, and want to help the PHP community.  I've been actively 
using PHP in most of my projects for some time now, and thought it was time for 
me to help the language itself rather than just having the language help me.

-Noah Overcash
(803) 238-0451
smileytech...@smileytechguy.com
smileytechguy.com

--
If you see a file named "smime.p7s" attached, it means that your mail client 
does not support secure email signing, and can be ignored



smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Introduction for wilkesreid

[Kalle Sommer Nielsen]

2016-11-02 21:04 GMT+01:00 Samuel Reid :
> I would simply like the opportunity to vote on RFCs. My name is Samuel Reid, 
> and I’m a PHP developer for Bureau Gravity (http://www.bureaugravity.com).
>

It is a privilege to be able to vote on RFCs, see
http://php.net/get-involved.php for how you can contribute to PHP.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Introduction for wilkesreid

[Samuel Reid]

I would simply like the opportunity to vote on RFCs. My name is Samuel Reid, 
and I’m a PHP developer for Bureau Gravity (http://www.bureaugravity.com).

[PHP-DEV] Introduction

[Christopher Owen]

Hello PHP Internals.

I would like to introduce myself in order to validate a wiki account for the 
purposes of proposing an RFC.

Thank you for reading this note.

Regards,
 Christopher Owen.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Introduction and some opcache SSE related stuff

[Dmitry Stogov]

I can confirm minor but consistent speed up on applications with big code
base.
The PR was merged into master.

Thanks. Dmitry.

On Fri, Jul 31, 2015 at 5:26 PM, Andone, Bogdan bogdan.and...@intel.com
wrote:

  Running php-cgi -T1 on WordPress4.1/index.php I see ~1%
 performance
  increase for the new version of fast_memcpy() compared with the
 generic
  memcpy(). Same result using a full load test with http_load on a
 Haswell EP
  18 cores.
 
 
  1% is really big improvement.
  I'll able to check this only on next week (when back from vacation).
 
 
  Well, he talks like he was comparing to *generic* memcpy(), so...?  But
 not sure how that would have been accomplished.
 
  BTW guys, I was wondering before why fast_memcpy() only in this opcache
 area?  For the prefetch and/or cache pollution reasons?
  Just because, in this place we may copy big blocks, and we also may
 align them properly, to use compact and fast Inlined code.

 Yeah... in fact all my numbers are against the current fast_memcpy()
 implementation, not against generic memcpy(). Sorry for the misleading
 information... :-/. I was playing in my corner with some SSE4.2 experiments
 and I wasn’t aware that SSE2 is enabled by default without any need of
 compiler switch.

 Coming back to the issue and trying to answer also to laruence’s request
 for more numbers:

 I am running php-cgi -T1 on a Haswell having 45MB L3 cache:
 The improvement is visible for scenarios where the amount of data loaded
 via opcache is significant while the real execution time is not so big;
 this is the case of real life scenarios:
 - WordPress 4.1  MediaWiki 1.24: ~1% performance increase
 - Drupal 7.36: ~0.6% performance increase
 - The improvement is not visible on synthetic benchmarks (mandelbrot,
 micro_bench, …) which load a small amount of bytecode and are computing
 intensive.

 The explanation stays in data cache misses. I did a deeper analysis on
 Wordpress 4.1 using perf tool:
 - _mm_stream based implementation: ~3x10^-4 misses/instruction = 1.023
 instructions/cycle
 - _mm_store based implementation: ~9x10^-6 misses/instruction (33x less)
 = 1.035 instructions/cycle

 So the overall performance gain is fully explained by the increase of
 instructions/cycle due to lower cache misses; copying the opcache data is a
 kind of software prefetcher for further execution. This phenomenon is
 most visible on processors with big caches. If I go to a lower L3 cache
 size (45MB - 6.75MB) 1% WP gain became 0.6% gain (as the cache capability
 to keep prefetched opcahe data without polluting the execution path
 become smaller).

 Coming back to generic memcpy(), the fast_memcpy() implementation seems to
 be a very little bit smaller in terms of executed instructions (hard to
 measure the real IR data due to run to run variations). Doing a couple of
 measurements for absorbing run to run effect I see ~0.2% perfo increase in
 favor of fast_memcpy w/ mm_store; it is the same increase I see in the
 implementation w/ SW prefetchers compared with the case of no SW prefetch
 in place. So the gain we see might be explained by the fact that memcpy()
 do not use SW prefetching - just a guess...

 Kind Regards,
 Bogdan

RE: [PHP-DEV] Introduction and some opcache SSE related stuff

[Andone, Bogdan]

 Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
 increase for the new version of fast_memcpy() compared with the generic
 memcpy(). Same result using a full load test with http_load on a Haswell EP
 18 cores.


 1% is really big improvement.
 I'll able to check this only on next week (when back from vacation).


 Well, he talks like he was comparing to *generic* memcpy(), so...?  But not 
 sure how that would have been accomplished.

 BTW guys, I was wondering before why fast_memcpy() only in this opcache 
 area?  For the prefetch and/or cache pollution reasons?
 Just because, in this place we may copy big blocks, and we also may align 
 them properly, to use compact and fast Inlined code.

Yeah... in fact all my numbers are against the current fast_memcpy() 
implementation, not against generic memcpy(). Sorry for the misleading 
information... :-/. I was playing in my corner with some SSE4.2 experiments and 
I wasn’t aware that SSE2 is enabled by default without any need of compiler 
switch.

Coming back to the issue and trying to answer also to laruence’s request for 
more numbers:

I am running php-cgi -T1 on a Haswell having 45MB L3 cache:
The improvement is visible for scenarios where the amount of data loaded via 
opcache is significant while the real execution time is not so big; this is the 
case of real life scenarios:
- WordPress 4.1  MediaWiki 1.24: ~1% performance increase
- Drupal 7.36: ~0.6% performance increase
- The improvement is not visible on synthetic benchmarks (mandelbrot, 
micro_bench, …) which load a small amount of bytecode and are computing 
intensive.

The explanation stays in data cache misses. I did a deeper analysis on 
Wordpress 4.1 using perf tool:
- _mm_stream based implementation: ~3x10^-4 misses/instruction = 1.023 
instructions/cycle
- _mm_store based implementation: ~9x10^-6 misses/instruction (33x less) = 
1.035 instructions/cycle

So the overall performance gain is fully explained by the increase of 
instructions/cycle due to lower cache misses; copying the opcache data is a 
kind of software prefetcher for further execution. This phenomenon is most 
visible on processors with big caches. If I go to a lower L3 cache size (45MB 
- 6.75MB) 1% WP gain became 0.6% gain (as the cache capability to keep 
prefetched opcahe data without polluting the execution path become smaller).

Coming back to generic memcpy(), the fast_memcpy() implementation seems to be a 
very little bit smaller in terms of executed instructions (hard to measure the 
real IR data due to run to run variations). Doing a couple of measurements for 
absorbing run to run effect I see ~0.2% perfo increase in favor of fast_memcpy 
w/ mm_store; it is the same increase I see in the implementation w/ SW 
prefetchers compared with the case of no SW prefetch in place. So the gain we 
see might be explained by the fact that memcpy() do not use SW prefetching - 
just a guess...

Kind Regards,
Bogdan

RE: [PHP-DEV] Introduction and some opcache SSE related stuff

[Anatol Belski]

Hi Bogdan,

 -Original Message-
 From: Andone, Bogdan [mailto:bogdan.and...@intel.com]
 Sent: Wednesday, July 29, 2015 4:22 PM
 To: internals@lists.php.net
 Subject: [PHP-DEV] Introduction and some opcache SSE related stuff
 
 Hi Guys,
 
 My name is Bogdan Andone and I work for Intel in the area of SW
performance
 analysis and optimizations.
 We would like to actively contribute to Zend PHP project and to involve
 ourselves in finding new performance improvement opportunities based on
 available and/or new hardware features.
 I am still in the source code digesting phase but I had a look to the
 fast_memcpy() implementation in opcache extension which uses SSE
intrinsics:
 
 If I am not wrong fast_memcpy() function is not currently used, as I
didn't find
 the -msse4.2 gcc flag in the Makefile. I assume you probably didn't see
any
 performance benefit so you preserved generic memcpy() usage.
 
 I would like to propose a slightly different implementation which uses
 _mm_store_si128() instead of _mm_stream_si128(). This ensures that copied
 memory is preserved in data cache, which is not bad as the interpreter
will start
 to use this data without the need to go back one more time to memory.
 _mm_stream_si128() in the current implementation is intended to be used
for
 stores where we want to avoid reading data into the cache and the cache
 pollution; in opcache scenario it seems that preserving the data in cache
has a
 positive impact.
 
 Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
 increase for the new version of fast_memcpy() compared with the generic
 memcpy(). Same result using a full load test with http_load on a Haswell
EP 18
 cores.
 
 Here is the proposed pull request:
https://github.com/php/php-src/pull/1446
 
 Related to the SW prefetching instructions in fast_memcpy()... they are
not
 really useful in this place. There benefit is almost negligible as the
address
 requested for prefetch will be needed at the next iteration (few cycles
later),
 while the time needed to get data from RAM is 100 cycles usually..
 Nevertheless... they don't heart and it seems they still have a very small
benefit
 so I preserved the original instruction and I added a new prefetch request
for the
 destination pointer.
 
AFAIR we always rely on the standard features, thus SSE2 in this particular
case, for better compatibility. IMHO using newer things should be done more
carefully. Having more stats could be not bad, from what I see at least here
http://store.steampowered.com/hwsurvey it's still not safe to just switch
away from SSE2. Maybe  introducing some flexible solution like compile time
switches for people who want to exhaust features of the modern hardware, or
specific features available from vendors, could be an approach.  But it all
is of course a project definition.

Regards

Anatol


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Introduction and some opcache SSE related stuff

[Xinchen Hui]

Hey:


On Thu, Jul 30, 2015 at 8:24 PM, Joe Watkins pthre...@pthreads.org wrote:
 Hi Andone,

 I'm not sure why nobody has replied to you yet, we've all looked at the
 PR and spent a lot of the day yesterday discussing it.

 I've CC'd Dmitry, he doesn't always read internals, so this should get
 his attention.
Sorry for late response, and Dmitry is on vacation now. so, he
probably not be able to reply this soon.

anyway, is the performance improvement is consistently be seen?

have you tested it with some profiling tool? IR reduced or cache misses reduced?

thanks

 Lastly, very cool ... I look forward to some more cleverness ...

 Cheers
 Joe

 On Wed, Jul 29, 2015 at 3:22 PM, Andone, Bogdan bogdan.and...@intel.com
 wrote:

 Hi Guys,

 My name is Bogdan Andone and I work for Intel in the area of SW
 performance analysis and optimizations.
 We would like to actively contribute to Zend PHP project and to involve
 ourselves in finding new performance improvement opportunities based on
 available and/or new hardware features.
 I am still in the source code digesting phase but I had a look to the
 fast_memcpy() implementation in opcache extension which uses SSE intrinsics:

 If I am not wrong fast_memcpy() function is not currently used, as I
 didn't find the -msse4.2 gcc flag in the Makefile. I assume you probably
 didn't see any performance benefit so you preserved generic memcpy() usage.

 I would like to propose a slightly different implementation which uses
 _mm_store_si128() instead of _mm_stream_si128(). This ensures that copied
 memory is preserved in data cache, which is not bad as the interpreter will
 start to use this data without the need to go back one more time to memory.
 _mm_stream_si128() in the current implementation is intended to be used for
 stores where we want to avoid reading data into the cache and the cache
 pollution; in opcache scenario it seems that preserving the data in cache
 has a positive impact.

 Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
 increase for the new version of fast_memcpy() compared with the generic
 memcpy(). Same result using a full load test with http_load on a Haswell EP
 18 cores.

 Here is the proposed pull request:
 https://github.com/php/php-src/pull/1446

 Related to the SW prefetching instructions in fast_memcpy()... they are
 not really useful in this place. There benefit is almost negligible as the
 address requested for prefetch will be needed at the next iteration (few
then maybe we don't need this in fast_memcpy? I mean it maybe used
widely if is is proven to be faster, which will be out of this
context.

thanks
 cycles later), while the time needed to get data from RAM is 100 cycles
 usually.. Nevertheless... they don't heart and it seems they still have a
 very small benefit so I preserved the original instruction and I added a
 new prefetch request for the destination pointer.

 Hope it helps,
 Bogdan




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Introduction and some opcache SSE related stuff

[Joe Watkins]

Hi Andone,

I'm not sure why nobody has replied to you yet, we've all looked at the
PR and spent a lot of the day yesterday discussing it.

I've CC'd Dmitry, he doesn't always read internals, so this should get
his attention.

Lastly, very cool ... I look forward to some more cleverness ...

Cheers
Joe

On Wed, Jul 29, 2015 at 3:22 PM, Andone, Bogdan bogdan.and...@intel.com
wrote:

 Hi Guys,

 My name is Bogdan Andone and I work for Intel in the area of SW
 performance analysis and optimizations.
 We would like to actively contribute to Zend PHP project and to involve
 ourselves in finding new performance improvement opportunities based on
 available and/or new hardware features.
 I am still in the source code digesting phase but I had a look to the
 fast_memcpy() implementation in opcache extension which uses SSE intrinsics:

 If I am not wrong fast_memcpy() function is not currently used, as I
 didn't find the -msse4.2 gcc flag in the Makefile. I assume you probably
 didn't see any performance benefit so you preserved generic memcpy() usage.

 I would like to propose a slightly different implementation which uses
 _mm_store_si128() instead of _mm_stream_si128(). This ensures that copied
 memory is preserved in data cache, which is not bad as the interpreter will
 start to use this data without the need to go back one more time to memory.
 _mm_stream_si128() in the current implementation is intended to be used for
 stores where we want to avoid reading data into the cache and the cache
 pollution; in opcache scenario it seems that preserving the data in cache
 has a positive impact.

 Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
 increase for the new version of fast_memcpy() compared with the generic
 memcpy(). Same result using a full load test with http_load on a Haswell EP
 18 cores.

 Here is the proposed pull request:
 https://github.com/php/php-src/pull/1446

 Related to the SW prefetching instructions in fast_memcpy()... they are
 not really useful in this place. There benefit is almost negligible as the
 address requested for prefetch will be needed at the next iteration (few
 cycles later), while the time needed to get data from RAM is 100 cycles
 usually.. Nevertheless... they don't heart and it seems they still have a
 very small benefit so I preserved the original instruction and I added a
 new prefetch request for the destination pointer.

 Hope it helps,
 Bogdan

Re: [PHP-DEV] Introduction and some opcache SSE related stuff

[Dmitry Stogov]

Hi Bogdan,

On Wed, Jul 29, 2015 at 5:22 PM, Andone, Bogdan bogdan.and...@intel.com
wrote:

 Hi Guys,

 My name is Bogdan Andone and I work for Intel in the area of SW
 performance analysis and optimizations.
 We would like to actively contribute to Zend PHP project and to involve
 ourselves in finding new performance improvement opportunities based on
 available and/or new hardware features.
 I am still in the source code digesting phase but I had a look to the
 fast_memcpy() implementation in opcache extension which uses SSE intrinsics:

 If I am not wrong fast_memcpy() function is not currently used, as I
 didn't find the -msse4.2 gcc flag in the Makefile. I assume you probably
 didn't see any performance benefit so you preserved generic memcpy() usage.


This is not SSE4.2 this is SSE2.
Any X86_64 target implements SSE2, so it's enabled by default on x86_64
systems (at least on Linux).
It also may be enabled on x86 targets adding -msse2 option.



 I would like to propose a slightly different implementation which uses
 _mm_store_si128() instead of _mm_stream_si128(). This ensures that copied
 memory is preserved in data cache, which is not bad as the interpreter will
 start to use this data without the need to go back one more time to memory.
 _mm_stream_si128() in the current implementation is intended to be used for
 stores where we want to avoid reading data into the cache and the cache
 pollution; in opcache scenario it seems that preserving the data in cache
 has a positive impact.


_mm_stream_si128() was used on purpose, to avoid CPU cache pollution,
because data copied from SHM to process memory is not necessary used before
eviction.
By the way, I'm not completely sure. May be _mm_store_si128() can provide
better result.



 Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
 increase for the new version of fast_memcpy() compared with the generic
 memcpy(). Same result using a full load test with http_load on a Haswell EP
 18 cores.


1% is really big improvement.
I'll able to check this only on next week (when back from vacation).



 Here is the proposed pull request:
 https://github.com/php/php-src/pull/1446

 Related to the SW prefetching instructions in fast_memcpy()... they are
 not really useful in this place. There benefit is almost negligible as the
 address requested for prefetch will be needed at the next iteration (few
 cycles later), while the time needed to get data from RAM is 100 cycles
 usually.. Nevertheless... they don't heart and it seems they still have a
 very small benefit so I preserved the original instruction and I added a
 new prefetch request for the destination pointer.


I also didn't see significant difference from software prefetching.

Thanks. Dmitry.



 Hope it helps,
 Bogdan

Re: [PHP-DEV] Introduction and some opcache SSE related stuff

[Dmitry Stogov]

On Jul 31, 2015 2:12 AM, Matt Wilmas php_li...@realplain.com wrote:

 Hi Dmitry, Bogdan,


 - Original Message -
 From: Dmitry Stogov
 Sent: Thursday, July 30, 2015

 Hi Bogdan,

 On Wed, Jul 29, 2015 at 5:22 PM, Andone, Bogdan bogdan.and...@intel.com
 wrote:

 Hi Guys,

 My name is Bogdan Andone and I work for Intel in the area of SW
 performance analysis and optimizations.
 We would like to actively contribute to Zend PHP project and to involve
 ourselves in finding new performance improvement opportunities based on
 available and/or new hardware features.
 I am still in the source code digesting phase but I had a look to the
 fast_memcpy() implementation in opcache extension which uses SSE
intrinsics:

 If I am not wrong fast_memcpy() function is not currently used, as I
 didn't find the -msse4.2 gcc flag in the Makefile. I assume you
probably
 didn't see any performance benefit so you preserved generic memcpy()
usage.


 This is not SSE4.2 this is SSE2.
 Any X86_64 target implements SSE2, so it's enabled by default on x86_64
 systems (at least on Linux).
 It also may be enabled on x86 targets adding -msse2 option.


 Right, I was gonna say, I think that was a mistake, and all x86_64 should
be using it at least...

 Of course, using anything newer that needs special options is nearly
useless, since I guess the vast majority aren't building themselves, but
using lowest-common-denominator repos.  I had been wondering about speeding
up some other things, maybe taking advantage of SSE4.x (string stuff, I
don't know), but... like I said.  Runtime checks would be awesome, but
except for the recent GCC, the intrinsics aren't available unless the
corresponding SSE option is enabled (lame!).  So requires a separate
compilation unit. :-/

 Of course I guess if the intrinsic maps simply to the instruction, could
just do it with inline asm, if wanted to do runtime CPU checking.


 I would like to propose a slightly different implementation which uses
 _mm_store_si128() instead of _mm_stream_si128(). This ensures that
copied
 memory is preserved in data cache, which is not bad as the interpreter
will
 start to use this data without the need to go back one more time to
memory.
 _mm_stream_si128() in the current implementation is intended to be used
for
 stores where we want to avoid reading data into the cache and the cache
 pollution; in opcache scenario it seems that preserving the data in
cache
 has a positive impact.


 _mm_stream_si128() was used on purpose, to avoid CPU cache pollution,
 because data copied from SHM to process memory is not necessary used
before
 eviction.
 By the way, I'm not completely sure. May be _mm_store_si128() can provide
 better result.


 Interesting (that _stream was used on purpose). :-)


 Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
 increase for the new version of fast_memcpy() compared with the generic
 memcpy(). Same result using a full load test with http_load on a
Haswell EP
 18 cores.


 1% is really big improvement.
 I'll able to check this only on next week (when back from vacation).


 Well, he talks like he was comparing to *generic* memcpy(), so...?  But
not sure how that would have been accomplished.

 BTW guys, I was wondering before why fast_memcpy() only in this opcache
area?  For the prefetch and/or cache pollution reasons?

Just because, in this place we may copy big blocks, and we also may align
them properly, to use compact and fast Inlined code.


 Because shouldn't the library functions in glibc, etc. already be using
versions optimized for the CPU at runtime?  So is generic memcpy() already
fast?  (Other than overhead for a function call.)

glibc already uses optimized memcpy(), but this is universal  function,
that has to check for different conditions, like allignment of source and
distination and length.



 Here is the proposed pull request:
 https://github.com/php/php-src/pull/1446

 Related to the SW prefetching instructions in fast_memcpy()... they are
 not really useful in this place. There benefit is almost negligible as
the
 address requested for prefetch will be needed at the next iteration (few
 cycles later), while the time needed to get data from RAM is 100 cycles
 usually.. Nevertheless... they don't heart and it seems they still have
a
 very small benefit so I preserved the original instruction and I added a
 new prefetch request for the destination pointer.


 I also didn't see significant difference from software prefetching.


 So how about prefetching further/more interations ahead...?

I tried, but didn't see difference as well.

Thanks. Dmitry.



 Thanks. Dmitry.



 Hope it helps,
 Bogdan


 - Matt

Re: [PHP-DEV] Introduction and some opcache SSE related stuff

[Matt Wilmas]

Hi Dmitry, Bogdan,

- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 30, 2015


Hi Bogdan,

On Wed, Jul 29, 2015 at 5:22 PM, Andone, Bogdan bogdan.and...@intel.com
wrote:


Hi Guys,

My name is Bogdan Andone and I work for Intel in the area of SW
performance analysis and optimizations.
We would like to actively contribute to Zend PHP project and to involve
ourselves in finding new performance improvement opportunities based on
available and/or new hardware features.
I am still in the source code digesting phase but I had a look to the
fast_memcpy() implementation in opcache extension which uses SSE 
intrinsics:


If I am not wrong fast_memcpy() function is not currently used, as I
didn't find the -msse4.2 gcc flag in the Makefile. I assume you 
probably
didn't see any performance benefit so you preserved generic memcpy() 
usage.




This is not SSE4.2 this is SSE2.
Any X86_64 target implements SSE2, so it's enabled by default on x86_64
systems (at least on Linux).
It also may be enabled on x86 targets adding -msse2 option.


Right, I was gonna say, I think that was a mistake, and all x86_64 should be 
using it at least...


Of course, using anything newer that needs special options is nearly 
useless, since I guess the vast majority aren't building themselves, but 
using lowest-common-denominator repos.  I had been wondering about speeding 
up some other things, maybe taking advantage of SSE4.x (string stuff, I 
don't know), but... like I said.  Runtime checks would be awesome, but 
except for the recent GCC, the intrinsics aren't available unless the 
corresponding SSE option is enabled (lame!).  So requires a separate 
compilation unit. :-/


Of course I guess if the intrinsic maps simply to the instruction, could 
just do it with inline asm, if wanted to do runtime CPU checking.



I would like to propose a slightly different implementation which uses
_mm_store_si128() instead of _mm_stream_si128(). This ensures that copied
memory is preserved in data cache, which is not bad as the interpreter 
will
start to use this data without the need to go back one more time to 
memory.
_mm_stream_si128() in the current implementation is intended to be used 
for

stores where we want to avoid reading data into the cache and the cache
pollution; in opcache scenario it seems that preserving the data in cache
has a positive impact.



_mm_stream_si128() was used on purpose, to avoid CPU cache pollution,
because data copied from SHM to process memory is not necessary used 
before

eviction.
By the way, I'm not completely sure. May be _mm_store_si128() can provide
better result.


Interesting (that _stream was used on purpose). :-)


Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
increase for the new version of fast_memcpy() compared with the generic
memcpy(). Same result using a full load test with http_load on a Haswell 
EP

18 cores.



1% is really big improvement.
I'll able to check this only on next week (when back from vacation).


Well, he talks like he was comparing to *generic* memcpy(), so...?  But not 
sure how that would have been accomplished.


BTW guys, I was wondering before why fast_memcpy() only in this opcache 
area?  For the prefetch and/or cache pollution reasons?


Because shouldn't the library functions in glibc, etc. already be using 
versions optimized for the CPU at runtime?  So is generic memcpy() already 
fast?  (Other than overhead for a function call.)



Here is the proposed pull request:
https://github.com/php/php-src/pull/1446

Related to the SW prefetching instructions in fast_memcpy()... they are
not really useful in this place. There benefit is almost negligible as 
the

address requested for prefetch will be needed at the next iteration (few
cycles later), while the time needed to get data from RAM is 100 cycles
usually.. Nevertheless... they don't heart and it seems they still have a
very small benefit so I preserved the original instruction and I added a
new prefetch request for the destination pointer.



I also didn't see significant difference from software prefetching.


So how about prefetching further/more interations ahead...?


Thanks. Dmitry.




Hope it helps,
Bogdan


- Matt 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Introduction and some opcache SSE related stuff

[Andone, Bogdan]

Hi Guys,

My name is Bogdan Andone and I work for Intel in the area of SW performance 
analysis and optimizations.
We would like to actively contribute to Zend PHP project and to involve 
ourselves in finding new performance improvement opportunities based on 
available and/or new hardware features.
I am still in the source code digesting phase but I had a look to the 
fast_memcpy() implementation in opcache extension which uses SSE intrinsics:

If I am not wrong fast_memcpy() function is not currently used, as I didn't 
find the -msse4.2 gcc flag in the Makefile. I assume you probably didn't see 
any performance benefit so you preserved generic memcpy() usage.

I would like to propose a slightly different implementation which uses 
_mm_store_si128() instead of _mm_stream_si128(). This ensures that copied 
memory is preserved in data cache, which is not bad as the interpreter will 
start to use this data without the need to go back one more time to memory. 
_mm_stream_si128() in the current implementation is intended to be used for 
stores where we want to avoid reading data into the cache and the cache 
pollution; in opcache scenario it seems that preserving the data in cache has a 
positive impact.

Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance 
increase for the new version of fast_memcpy() compared with the generic 
memcpy(). Same result using a full load test with http_load on a Haswell EP 18 
cores.

Here is the proposed pull request: https://github.com/php/php-src/pull/1446

Related to the SW prefetching instructions in fast_memcpy()... they are not 
really useful in this place. There benefit is almost negligible as the address 
requested for prefetch will be needed at the next iteration (few cycles later), 
while the time needed to get data from RAM is 100 cycles usually.. 
Nevertheless... they don't heart and it seems they still have a very small 
benefit so I preserved the original instruction and I added a new prefetch 
request for the destination pointer.

Hope it helps,
Bogdan

[PHP-DEV] Introduction and patches

[Henrique do N. Angelo]

Hi,

My name is Henrique do N. Angelo and I'm currently working on the
implementation of Unicode into PHP 6 as a Google Summer of Code 2008
project, mentored by Scott MacVicar. Scott has been helping me for the past
few weeks and, so far, I've got a couple patches done.

Following Philip's advice, I'm sending here some of the patches I've written
so far and soon I will be requesting a cvs account.

If you want to contact me directly, feel free to send me an email or talk to
me at #php.pecl at efnet, I'm hnangelo.

Cheers
Henrique
Index: ext/date/php_date.c
===
RCS file: /repository/php-src/ext/date/php_date.c,v
retrieving revision 1.187
diff -u -r1.187 php_date.c
--- ext/date/php_date.c 20 May 2008 12:07:13 -  1.187
+++ ext/date/php_date.c 31 May 2008 03:36:17 -
@@ -1214,7 +1214,7 @@
 }
 /* }}} */
 
-/* {{{ proto string date(string format [, long timestamp])
+/* {{{ proto string date(string format [, long timestamp]) U
Format a local date/time */
 PHP_FUNCTION(date)
 {
@@ -1222,7 +1222,7 @@
 }
 /* }}} */
 
-/* {{{ proto string gmdate(string format [, long timestamp])
+/* {{{ proto string gmdate(string format [, long timestamp]) U
Format a GMT date/time */
 PHP_FUNCTION(gmdate)
 {
@@ -1230,7 +1230,7 @@
 }
 /* }}} */
 
-/* {{{ proto int idate(string format [, int timestamp])
+/* {{{ proto int idate(string format [, int timestamp]) U
Format a local time/date as integer */
 PHP_FUNCTION(idate)
 {
@@ -1292,7 +1292,7 @@
 /* }}} */
 
 
-/* {{{ proto int strtotime(string time [, int now ])
+/* {{{ proto int strtotime(string time [, int now ]) U
Convert string representation of date and time to a timestamp */
 PHP_FUNCTION(strtotime)
 {
@@ -1453,7 +1453,7 @@
 }
 /* }}} */
 
-/* {{{ proto int mktime([int hour [, int min [, int sec [, int mon [, int day 
[, int year]])
+/* {{{ proto int mktime([int hour [, int min [, int sec [, int mon [, int day 
[, int year]]) U
Get UNIX timestamp for a date */
 PHP_FUNCTION(mktime)
 {
@@ -1461,7 +1461,7 @@
 }
 /* }}} */
 
-/* {{{ proto int gmmktime([int hour [, int min [, int sec [, int mon [, int 
day [, int year]])
+/* {{{ proto int gmmktime([int hour [, int min [, int sec [, int mon [, int 
day [, int year]]) U
Get UNIX timestamp for a GMT date */
 PHP_FUNCTION(gmmktime)
 {
@@ -1470,7 +1470,7 @@
 /* }}} */
 
 
-/* {{{ proto bool checkdate(int month, int day, int year)
+/* {{{ proto bool checkdate(int month, int day, int year) U
Returns true(1) if it is a valid date in gregorian calendar */
 PHP_FUNCTION(checkdate)
 {
@@ -1578,7 +1578,7 @@
 }
 /* }}} */
 
-/* {{{ proto string strftime(string format [, int timestamp])
+/* {{{ proto string strftime(string format [, int timestamp]) U
Format a local time/date according to locale settings */
 PHP_FUNCTION(strftime)
 {
@@ -1586,7 +1586,7 @@
 }
 /* }}} */
 
-/* {{{ proto string gmstrftime(string format [, int timestamp])
+/* {{{ proto string gmstrftime(string format [, int timestamp]) U
Format a GMT/UCT time/date according to locale settings */
 PHP_FUNCTION(gmstrftime)
 {
@@ -1595,7 +1595,7 @@
 /* }}} */
 #endif
 
-/* {{{ proto int time(void)
+/* {{{ proto int time(void) U
Return current UNIX timestamp */
 PHP_FUNCTION(time)
 {
@@ -1603,7 +1603,7 @@
 }
 /* }}} */
 
-/* {{{ proto array localtime([int timestamp [, bool associative_array]])
+/* {{{ proto array localtime([int timestamp [, bool associative_array]]) U
Returns the results of the C system call localtime as an associative array 
if the associative_array argument is set to 1 other wise it is a regular array 
*/
 PHP_FUNCTION(localtime)
 {
@@ -1650,7 +1650,7 @@
 }
 /* }}} */
 
-/* {{{ proto array getdate([int timestamp])
+/* {{{ proto array getdate([int timestamp]) U
Get date/time information */
 PHP_FUNCTION(getdate)
 {
@@ -1678,8 +1678,8 @@
add_ascii_assoc_long(return_value, mon, ts-m);
add_ascii_assoc_long(return_value, year, ts-y);
add_ascii_assoc_long(return_value, yday, timelib_day_of_year(ts-y, 
ts-m, ts-d));
-   add_ascii_assoc_string(return_value, weekday, 
php_date_full_day_name(ts-y, ts-m, ts-d), 1);
-   add_ascii_assoc_string(return_value, month, mon_full_names[ts-m - 
1], 1);
+   add_ascii_assoc_ascii_string(return_value, weekday, 
php_date_full_day_name(ts-y, ts-m, ts-d), 1);
+   add_ascii_assoc_ascii_string(return_value, month, 
mon_full_names[ts-m - 1], 1);
add_index_long(return_value, 0, timestamp);
 
timelib_time_dtor(ts);
@@ -2028,7 +2028,7 @@
MAKE_STD_ZVAL(zv);
switch (dateobj-time-zone_type) {
case TIMELIB_ZONETYPE_ID:
-   ZVAL_STRING(zv, dateobj-time-tz_info-name, 
1);
+   ZVAL_ASCII_STRING(zv, 
dateobj-time-tz_info-name, 1);
break;
case TIMELIB_ZONETYPE_OFFSET: {

Re: [PHP-DEV] Introduction and patches

[Marcus Boerger]

Hello Henrique,

  this all looks fine.Can you apply for an account directly?

marcus

Saturday, June 7, 2008, 8:25:19 AM, you wrote:

 Index: bug34704.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/bug34704.phpt,v
 retrieving revision 1.5
 diff -u -r1.5 bug34704.phpt
 --- bug34704.phpt   2 Jun 2006 22:22:42 -   1.5
 +++ bug34704.phpt   7 Jun 2008 02:31:14 -
 @@ -13,51 +13,22 @@
  ===DONE===
  --EXPECTF--
  array(7) {
 -  [FileName]=
 -  string(12) bug34704.jpg
 -  [FileDateTime]=
 -  int(%d)
 -  [FileSize]=
 -  int(9976)
 -  [FileType]=
 -  int(2)
 -  [MimeType]=
 -  string(10) image/jpeg
 -  [SectionsFound]=
 -  string(4) IFD0
 -  [COMPUTED]=
 -  array(5) {
 -[html]=
 -string(24) width=386 height=488
 -[Height]=
 -int(488)
 -[Width]=
 -int(386)
 -[IsColor]=
 -int(1)
 -[ByteOrderMotorola]=
 -int(0)
 -  }
 -}
 -===DONE===
 ---UEXPECTF--
 -array(7) {
[uFileName]=
 -  string(12) bug34704.jpg
 +  unicode(12) bug34704.jpg
[uFileDateTime]=
 -  int(1128867104)
 +  int(%d)
[uFileSize]=
int(9976)
[uFileType]=
int(2)
[uMimeType]=
 -  string(10) image/jpeg
 +  unicode(10) image/jpeg
[uSectionsFound]=
 -  string(4) IFD0
 +  unicode(4) IFD0
[uCOMPUTED]=
array(5) {
  [uhtml]=
 -string(24) width=386 height=488
 +unicode(24) width=386 height=488
  [uHeight]=
  int(488)
  [uWidth]=
 Index: exif001.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/exif001.phpt,v
 retrieving revision 1.6
 diff -u -r1.6 exif001.phpt
 --- exif001.phpt27 May 2008 18:16:00 -  1.6
 +++ exif001.phpt7 Jun 2008 02:31:14 -
 @@ -19,7 +19,7 @@
[uFILE]=
array(6) {
  [uFileName]=
 -string(9) test2.jpg
 +unicode(9) test2.jpg
  [uFileDateTime]=
  int(%d)
  [uFileSize]=
 @@ -27,14 +27,14 @@
  [uFileType]=
  int(2)
  [uMimeType]=
 -string(10) image/jpeg
 +unicode(10) image/jpeg
  [uSectionsFound]=
 -string(33) ANY_TAG, IFD0, THUMBNAIL, COMMENT
 +unicode(33) ANY_TAG, IFD0, THUMBNAIL, COMMENT
}
[uCOMPUTED]=
array(12) {
  [uhtml]=
 -string(20) width=1 height=1
 +unicode(20) width=1 height=1
  [uHeight]=
  int(1)
  [uWidth]=
 @@ -44,26 +44,26 @@
  [uByteOrderMotorola]=
  int(1)
  [uUserComment]=
 -string(16) Exif test image.
 +unicode(16) Exif test image.
  [uUserCommentEncoding]=
 -string(5) ASCII
 +unicode(5) ASCII
  [uCopyright]=
 -string(41) Photo (c) M.Boerger, Edited by M.Boerger.
 +unicode(41) Photo (c) M.Boerger, Edited by M.Boerger.
  [uCopyright.Photographer]=
 -string(19) Photo (c) M.Boerger
 +unicode(19) Photo (c) M.Boerger
  [uCopyright.Editor]=
 -string(20) Edited by M.Boerger.
 +unicode(20) Edited by M.Boerger.
  [uThumbnail.FileType]=
  int(2)
  [uThumbnail.MimeType]=
 -string(10) image/jpeg
 +unicode(10) image/jpeg
}
[uIFD0]=
array(2) {
  [uCopyright]=
 -string(19) Photo (c) M.Boerger
 +unicode(19) Photo (c) M.Boerger
  [uUserComment]=
 -string(5) ASCII
 +unicode(5) ASCII
}
[uTHUMBNAIL]=
array(2) {
 @@ -75,10 +75,10 @@
[uCOMMENT]=
array(3) {
  [0]=
 -string(11) Comment #1.
 +unicode(11) Comment #1.
  [1]=
 -string(11) Comment #2.
 +unicode(11) Comment #2.
  [2]=
 -string(13) Comment #3end
 +unicode(13) Comment #3end
}
  }
 Index: exif004.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/exif004.phpt,v
 retrieving revision 1.5
 diff -u -r1.5 exif004.phpt
 --- exif004.phpt4 Jan 2003 19:19:59 -   1.5
 +++ exif004.phpt7 Jun 2008 02:31:14 -
 @@ -22,17 +22,17 @@
  ?
  --EXPECT--
  array(5) {
 -  [Subject]=
 -  string(10) Subject...
 -  [Keywords]=
 -  string(11) Keywords...
 -  [Author]=
 -  string(9) Rui Carmo
 -  [Comments]=
 -  string(29) Comments
 +  [uSubject]=
 +  unicode(10) Subject...
 +  [uKeywords]=
 +  unicode(11) Keywords...
 +  [uAuthor]=
 +  unicode(9) Rui Carmo
 +  [uComments]=
 +  unicode(29) Comments
  Line2
  Line3
  Line4
 -  [Title]=
 -  string(8) Title...
 +  [uTitle]=
 +  unicode(8) Title...
  }
 Index: exif005.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/exif005.phpt,v
 retrieving revision 1.8
 diff -u -r1.8 exif005.phpt
 --- exif005.phpt27 May 2008 18:16:00 -  1.8
 +++ exif005.phpt7 Jun 2008 02:31:14 -
 @@ -16,7 +16,7 @@
  --EXPECT--
  array(2) {
[uImageDescription]=
 -  string(11) Ifd0009
 +  unicode(11) Ifd0009
[uDateTime]=
 -  string(19) 2002:10:18 20:06:00
 +  unicode(19) 2002:10:18 20:06:00
  }



Best regards,
 Marcus


-- 
PHP Internals - 

Re: [PHP-DEV] Introduction and patches

[Marcus Boerger]

Hello Marcus,

  feel free to commit these. Please stay in touch with your mentor and the
rest of the team to discuss especially larger changes.

marcus

Saturday, June 7, 2008, 4:41:50 PM, you wrote:

 Hello Henrique,

   this all looks fine.Can you apply for an account directly?

 marcus

 Saturday, June 7, 2008, 8:25:19 AM, you wrote:

 Index: bug34704.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/bug34704.phpt,v
 retrieving revision 1.5
 diff -u -r1.5 bug34704.phpt
 --- bug34704.phpt   2 Jun 2006 22:22:42 -   1.5
 +++ bug34704.phpt   7 Jun 2008 02:31:14 -
 @@ -13,51 +13,22 @@
  ===DONE===
  --EXPECTF--
  array(7) {
 -  [FileName]=
 -  string(12) bug34704.jpg
 -  [FileDateTime]=
 -  int(%d)
 -  [FileSize]=
 -  int(9976)
 -  [FileType]=
 -  int(2)
 -  [MimeType]=
 -  string(10) image/jpeg
 -  [SectionsFound]=
 -  string(4) IFD0
 -  [COMPUTED]=
 -  array(5) {
 -[html]=
 -string(24) width=386 height=488
 -[Height]=
 -int(488)
 -[Width]=
 -int(386)
 -[IsColor]=
 -int(1)
 -[ByteOrderMotorola]=
 -int(0)
 -  }
 -}
 -===DONE===
 ---UEXPECTF--
 -array(7) {
[uFileName]=
 -  string(12) bug34704.jpg
 +  unicode(12) bug34704.jpg
[uFileDateTime]=
 -  int(1128867104)
 +  int(%d)
[uFileSize]=
int(9976)
[uFileType]=
int(2)
[uMimeType]=
 -  string(10) image/jpeg
 +  unicode(10) image/jpeg
[uSectionsFound]=
 -  string(4) IFD0
 +  unicode(4) IFD0
[uCOMPUTED]=
array(5) {
  [uhtml]=
 -string(24) width=386 height=488
 +unicode(24) width=386 height=488
  [uHeight]=
  int(488)
  [uWidth]=
 Index: exif001.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/exif001.phpt,v
 retrieving revision 1.6
 diff -u -r1.6 exif001.phpt
 --- exif001.phpt27 May 2008 18:16:00 -  1.6
 +++ exif001.phpt7 Jun 2008 02:31:14 -
 @@ -19,7 +19,7 @@
[uFILE]=
array(6) {
  [uFileName]=
 -string(9) test2.jpg
 +unicode(9) test2.jpg
  [uFileDateTime]=
  int(%d)
  [uFileSize]=
 @@ -27,14 +27,14 @@
  [uFileType]=
  int(2)
  [uMimeType]=
 -string(10) image/jpeg
 +unicode(10) image/jpeg
  [uSectionsFound]=
 -string(33) ANY_TAG, IFD0, THUMBNAIL, COMMENT
 +unicode(33) ANY_TAG, IFD0, THUMBNAIL, COMMENT
}
[uCOMPUTED]=
array(12) {
  [uhtml]=
 -string(20) width=1 height=1
 +unicode(20) width=1 height=1
  [uHeight]=
  int(1)
  [uWidth]=
 @@ -44,26 +44,26 @@
  [uByteOrderMotorola]=
  int(1)
  [uUserComment]=
 -string(16) Exif test image.
 +unicode(16) Exif test image.
  [uUserCommentEncoding]=
 -string(5) ASCII
 +unicode(5) ASCII
  [uCopyright]=
 -string(41) Photo (c) M.Boerger, Edited by M.Boerger.
 +unicode(41) Photo (c) M.Boerger, Edited by M.Boerger.
  [uCopyright.Photographer]=
 -string(19) Photo (c) M.Boerger
 +unicode(19) Photo (c) M.Boerger
  [uCopyright.Editor]=
 -string(20) Edited by M.Boerger.
 +unicode(20) Edited by M.Boerger.
  [uThumbnail.FileType]=
  int(2)
  [uThumbnail.MimeType]=
 -string(10) image/jpeg
 +unicode(10) image/jpeg
}
[uIFD0]=
array(2) {
  [uCopyright]=
 -string(19) Photo (c) M.Boerger
 +unicode(19) Photo (c) M.Boerger
  [uUserComment]=
 -string(5) ASCII
 +unicode(5) ASCII
}
[uTHUMBNAIL]=
array(2) {
 @@ -75,10 +75,10 @@
[uCOMMENT]=
array(3) {
  [0]=
 -string(11) Comment #1.
 +unicode(11) Comment #1.
  [1]=
 -string(11) Comment #2.
 +unicode(11) Comment #2.
  [2]=
 -string(13) Comment #3end
 +unicode(13) Comment #3end
}
  }
 Index: exif004.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/exif004.phpt,v
 retrieving revision 1.5
 diff -u -r1.5 exif004.phpt
 --- exif004.phpt4 Jan 2003 19:19:59 -   1.5
 +++ exif004.phpt7 Jun 2008 02:31:14 -
 @@ -22,17 +22,17 @@
  ?
  --EXPECT--
  array(5) {
 -  [Subject]=
 -  string(10) Subject...
 -  [Keywords]=
 -  string(11) Keywords...
 -  [Author]=
 -  string(9) Rui Carmo
 -  [Comments]=
 -  string(29) Comments
 +  [uSubject]=
 +  unicode(10) Subject...
 +  [uKeywords]=
 +  unicode(11) Keywords...
 +  [uAuthor]=
 +  unicode(9) Rui Carmo
 +  [uComments]=
 +  unicode(29) Comments
  Line2
  Line3
  Line4
 -  [Title]=
 -  string(8) Title...
 +  [uTitle]=
 +  unicode(8) Title...
  }
 Index: exif005.phpt
 ===
 RCS file: /repository/php-src/ext/exif/tests/exif005.phpt,v
 retrieving revision 1.8
 diff -u -r1.8 exif005.phpt
 --- exif005.phpt27 May 2008 18:16:00 -  1.8
 +++ exif005.phpt7 Jun 2008 02:31:14 -
 @@ -16,7 +16,7 @@
  --EXPECT--
  array(2) {

[PHP-DEV] Introduction

[Weyert de Boer]

Hello!

I would like to introduce myself on this internals list, as you can read my name is Weyert de Boer and a flying dutchman. My goal is help PHP development, and learning more about compiler development. 


My first question to start my fame on this list is, does anyone on this list 
happen to have the grammar of PHP language?

--
Yours,

Weyert de Boer ([EMAIL PROTECTED])
innerfuse*

http://www.innerfuse.biz/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Introduction

[Marcus Boerger]

Hello Weyert,

  look into Zend/*.l and Zend/*.y. Further more several things in php are
done using re2c. SQLite uses its own stuff, lemon. And the engine uses a
script zend_vm_gen.php to generate the engine code. Have fun by looking
into all that stuff.

marcus

Tuesday, July 19, 2005, 8:46:19 PM, you wrote:

 Hello!

 I would like to introduce myself on this internals list, as you can
 read my name is Weyert de Boer and a flying dutchman. My goal is help PHP
 development, and learning more about compiler development. 

 My first question to start my fame on this list is, does anyone on this
 list happen to have the grammar of PHP language?

 -- 
 Yours,

 Weyert de Boer ([EMAIL PROTECTED])
 innerfuse*

 http://www.innerfuse.biz/




-- 
Best regards,
 Marcusmailto:[EMAIL PROTECTED]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Introduction

[Ondrej Ivanič]

Weyert de Boer wrote:
My first question to start my fame on this list is, does anyone on this 
list happen to have the grammar of PHP language?


I think, you can start with zend_language_parser.y in Zend 
subdirectory in tar ball.


Rules in section 'Rules' :) can be easy rewritten into BNF or whatever 
you want.


--
Ondrej Ivanic
([EMAIL PROTECTED])

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php