Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> OK. In my opinion, if something is defined as "int" should be always
> "int". Nor "null" neither "undefined".
> This is good for programmers who think like me, for compiler and for
> hardware CPU :)

I understand why it's good, and I agree. The harder question is whether
we can deliver on that, and whether we can deliver on that without
introducing limitations that do not make semantic sense. unset is just
the start of it, initialization/unserialization/etc. issues are part of
it too.

> You have another opinion, and we won't persuade each other.

I think you slightly misunderstand my opinion - I don't say "always int,
never undefined" is not good, I say it might be good in theory but it
looks practically impossible, we should prepare for the other
possibility. Of course, it may be that I am completely wrong and it is
practically possible, in which case - once that practicality is proven -
I would agree with you. That would be the way to persuade me :)
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/19/2016 10:53 PM, Stanislav Malyshev wrote:

Hi!


More properly - PHP is done in a way that doesn't allow big data
processing yet :)

LuaJIT may be used for in-kernel packet filtering...

But we're not targeting PHP for in-kernel packet filtering. And we
should not sacrifice language semantics for minuscule gains in
performance. Especially given that banning unset by itself will achieve
nothing - you also have to deal with lots of other ways object can be
initialized.
OK. In my opinion, if something is defined as "int" should be always 
"int". Nor "null" neither "undefined".
This is good for programmers who think like me, for compiler and for 
hardware CPU :)

You have another opinion, and we won't persuade each other.
Lets stop this discussion, because everyone who read already understood 
both point of views.





Run bench.php with CALL and GOTO VM.
You'll see 20-30% performance difference caused by branch miss-prediction.

That's whole VM, not one branch which is never taken.
Yes, this is just an example how branch miss-prediction may affect 
performance.






I think, If we may eliminate checks we should do it (at type-system
design level).

I don't think we really can without introducing some very strange
limitations, like banning unsets or limiting serialization or
introducing special magic methods that are optimized differently, etc.

Personally, I think we can,
but if we can't provide type safety for all cases, we shouldn't try to 
do this for some case, shouldn't name this "typing" and shouldn't 
perform type checks at all.
Lets name this "type annotations" and don't perform run-time type checks 
(like HHVM Hack do).


Thanks. Dmitry.


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

Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> More properly - PHP is done in a way that doesn't allow big data
> processing yet :)
> 
> LuaJIT may be used for in-kernel packet filtering...

But we're not targeting PHP for in-kernel packet filtering. And we
should not sacrifice language semantics for minuscule gains in
performance. Especially given that banning unset by itself will achieve
nothing - you also have to deal with lots of other ways object can be
initialized.

> Run bench.php with CALL and GOTO VM.
> You'll see 20-30% performance difference caused by branch miss-prediction.

That's whole VM, not one branch which is never taken.

> I think, If we may eliminate checks we should do it (at type-system
> design level).

I don't think we really can without introducing some very strange
limitations, like banning unsets or limiting serialization or
introducing special magic methods that are optimized differently, etc.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/18/2016 09:37 PM, Stanislav Malyshev wrote:

Hi!


right.
I don't see any reasons for types, if they are not guaranteed anyway.

Well, we already have parameter types, and they are not guaranteed
either - you can reassign variables.

They guarantee the type of argument on function entry.




This depends on use case.
Just imagine matrix multiplication (or something similar).
Few additional instructions would decrease the speed significantly.

I think this is a very narrow use case. If somebody does large data
processing (like large matrix multiplication) in pure PHP, they are
doing it wrong anyway.
More properly - PHP is done in a way that doesn't allow big data 
processing yet :)


LuaJIT may be used for in-kernel packet filtering...


  So trying to optimize for their use case I think
is not a high priority. I would say for any typical PHP app cost of one
unexpected branch is negligible.

One is not, but 100 matters.
Run bench.php with CALL and GOTO VM.
You'll see 20-30% performance difference caused by branch miss-prediction.

Now think about JIT, and "code-bloat" caused by additional type checks.

I think, If we may eliminate checks we should do it (at type-system 
design level).


Thanks. Dmitry.


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

Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> right.
> I don't see any reasons for types, if they are not guaranteed anyway.

Well, we already have parameter types, and they are not guaranteed
either - you can reassign variables.

> This depends on use case.
> Just imagine matrix multiplication (or something similar).
> Few additional instructions would decrease the speed significantly.

I think this is a very narrow use case. If somebody does large data
processing (like large matrix multiplication) in pure PHP, they are
doing it wrong anyway. So trying to optimize for their use case I think
is not a high priority. I would say for any typical PHP app cost of one
unexpected branch is negligible.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/15/2016 11:07 PM, Stanislav Malyshev wrote:

Hi!


In most cases we avoid IS_UNDEF checks, verifying the most probable expected 
types first.

But that's for something like ADD, not for property fetches, so I'm not
sure I understand how properties fit there yet. Does the optimization
also track the variable after fetching?

In any case, to use this without any UNDEF/NULL checks, you need to be
absolutely sure the value is always initialized to the right type. I.e.
if you have a class like:

class Point {
public int $x;
public int $y;
}

Then you need to request the following:

- Always require the default. Otherwise, even in ctor, you could use $x
in expression before it is initialized and assume it is long where it is
in fact null. For many classes, the default would be completely
arbitrary (e.g. 0 is not always a natural default).

- Somehow handle unserialization in order to ensure what is put into $x
is always int. Moreover, unserialization may involved __wakeup which
sets up some properties, and before those properties are set up, how do
we ensure they have the right types without checking? Unserialize data
can contain anything, we had enough trouble with this unserializing
internal objects.

- Ensure that no extension manually creates objects without properly
initializing the typed variables. Extensions can easily create objects
right now and they can put anything in the object's hashes, can we trust
that every extension does the right thing?


right.
I don't see any reasons for types, if they are not guaranteed anyway.



The cost of getting any of these wrong may be high - it's not just
getting weird conversion, if the engine assumes something is LONG or
STRING without checking, it can be memory corruption or even RCE if
we're particularly unlucky.

So I am very skeptical right now about the possibility of making
optimizations based on using property type without checking based on
just declared type in the class.

then, why do we need them at all?



Additionally, if we *do* allow the possibility of NULL/UNDEF, the
performance loss would be quite minimal - we could still do
specialization based on assumed type, but then just insert something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
   op1 = _as_long;
}

for types that have natural default for longs, or something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
zend_error("Undefined value where object is expected");
}

if we expected object. The cost of one branch that is almost never taken
should be quite minimal, and we avoid a lot of trouble on the way.


This depends on use case.
Just imagine matrix multiplication (or something similar).
Few additional instructions would decrease the speed significantly.

Thanks. Dmitry.






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

Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> In most cases we avoid IS_UNDEF checks, verifying the most probable expected 
> types first.

But that's for something like ADD, not for property fetches, so I'm not
sure I understand how properties fit there yet. Does the optimization
also track the variable after fetching?

In any case, to use this without any UNDEF/NULL checks, you need to be
absolutely sure the value is always initialized to the right type. I.e.
if you have a class like:

class Point {
public int $x;
public int $y;
}

Then you need to request the following:

- Always require the default. Otherwise, even in ctor, you could use $x
in expression before it is initialized and assume it is long where it is
in fact null. For many classes, the default would be completely
arbitrary (e.g. 0 is not always a natural default).

- Somehow handle unserialization in order to ensure what is put into $x
is always int. Moreover, unserialization may involved __wakeup which
sets up some properties, and before those properties are set up, how do
we ensure they have the right types without checking? Unserialize data
can contain anything, we had enough trouble with this unserializing
internal objects.

- Ensure that no extension manually creates objects without properly
initializing the typed variables. Extensions can easily create objects
right now and they can put anything in the object's hashes, can we trust
that every extension does the right thing?

The cost of getting any of these wrong may be high - it's not just
getting weird conversion, if the engine assumes something is LONG or
STRING without checking, it can be memory corruption or even RCE if
we're particularly unlucky.

So I am very skeptical right now about the possibility of making
optimizations based on using property type without checking based on
just declared type in the class.

Additionally, if we *do* allow the possibility of NULL/UNDEF, the
performance loss would be quite minimal - we could still do
specialization based on assumed type, but then just insert something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
  op1 = _as_long;
}

for types that have natural default for longs, or something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
zend_error("Undefined value where object is expected");
}

if we expected object. The cost of one branch that is almost never taken
should be quite minimal, and we avoid a lot of trouble on the way.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

Stas, you have to look into "master" branch code.

In most cases we avoid IS_UNDEF checks, verifying the most probable expected 
types first.

ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
{
USE_OPLINE
zend_free_op free_op1, free_op2;
zval *op1, *op2, *result;

op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
fast_long_add_function(result, op1, op2);
ZEND_VM_NEXT_OPCODE();

We also have specialized handlers that don't check for types at all (they are 
used, if we know types at optimization time).

ZEND_VM_TYPE_SPEC_HANDLER(ZEND_ADD, (res_info == MAY_BE_LONG && op1_info == 
MAY_BE_LONG && op2_info == MAY_BE_LONG), ZEND_ADD_LONG_NO_OVERFLOW, 
CONST|TMPVARCV, CONST|TMPVARCV, SPEC(NO_CONST_CONST,COMMUTATIVE))
{
USE_OPLINE
zval *op1, *op2, *result;

op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
result = EX_VAR(opline->result.var);
ZVAL_LONG(result, Z_LVAL_P(op1) + Z_LVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}

The second technique won't work for typed properties if they might be turned 
into IS_UNDEF. 

Thanks. Dmitry. 


From: Stanislav Malyshev <smalys...@gmail.com>
Sent: Thursday, April 14, 2016 20:26
To: Dmitry Stogov; Joe Watkins
Cc: internals; Zeev Suraski; Nikita Popov
Subject: Re: [PHP-DEV] Re: Typed properties patch

Hi!

> I didn't understand.
> Of course we keep a class definition, where the type of property "$a" -
> IS_LONG, but the actual value of "$a" may become IS_UNDEF.

What I'm saying is maybe it's fine.

> In PHP-7 we check for IS_LONG without type hint.
> With type hint and ability to unset(), we will have to check for IS_LONG
> anyway.

Well, we'd have to check for IS_UNDEF, but we won't have to choose
between IS_LONG, IS_OBJECT and IS_RESOURCE.

> So type hinting won't improve reading performance, but writing is going
> to be slower, because we have to perform type check.
> So even theoretically this approach couldn't make any improvement.

Maybe I misunderstand what performance improvements there are. Do we do
different things when reading a variable depending on type? I thought
it's for *operations* with variables, but for just reading them it
doesn't matter. For operations, we could have instead of function
handling all types just function handling IS_LONG and a small check for
UNDEF inside.

I think it is mych better than a weird concept of non-unsettable variable.
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> I didn't understand.
> Of course we keep a class definition, where the type of property "$a" -
> IS_LONG, but the actual value of "$a" may become IS_UNDEF.

What I'm saying is maybe it's fine.

> In PHP-7 we check for IS_LONG without type hint.
> With type hint and ability to unset(), we will have to check for IS_LONG
> anyway.

Well, we'd have to check for IS_UNDEF, but we won't have to choose
between IS_LONG, IS_OBJECT and IS_RESOURCE.

> So type hinting won't improve reading performance, but writing is going
> to be slower, because we have to perform type check.
> So even theoretically this approach couldn't make any improvement.

Maybe I misunderstand what performance improvements there are. Do we do
different things when reading a variable depending on type? I thought
it's for *operations* with variables, but for just reading them it
doesn't matter. For operations, we could have instead of function
handling all types just function handling IS_LONG and a small check for
UNDEF inside.

I think it is mych better than a weird concept of non-unsettable variable.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/13/2016 10:31 PM, Stanislav Malyshev wrote:

Hi!


Because if you unset() a property it's type is not guaranteed anymore.

Can't we fix it? I mean, when we unset property on an object, we're
still keeping the definition in the class, right? Can't we use it?

I didn't understand.
Of course we keep a class definition, where the type of property "$a" - 
IS_LONG, but the actual value of "$a" may become IS_UNDEF.



x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use
optimized code */

Can't we assume $a->x is still "int" here in a way - I mean, we'd still
have to allow for the possibility of null, but if we say that any one
could be null it's just one easy check, so it won't hurt performance too
much, not?

In PHP-7 we check for IS_LONG without type hint.
With type hint and ability to unset(), we will have to check for IS_LONG 
anyway.
So type hinting won't improve reading performance, but writing is going 
to be slower, because we have to perform type check.

So even theoretically this approach couldn't make any improvement.

Thanks. Dmitry.







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

Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> Because if you unset() a property it's type is not guaranteed anymore.

Can't we fix it? I mean, when we unset property on an object, we're
still keeping the definition in the class, right? Can't we use it?

> 
>  class Foo () {
>   int $a = 0;
> }
> $a = new Foo();
> $b = $a->x + 5; /* we know $a->x is "int" and may use optimized code */
> unset($a->x);
> $b = $a->x + 5; /* $a->x is not "int" any more  and we can't use
> optimized code */

Can't we assume $a->x is still "int" here in a way - I mean, we'd still
have to allow for the possibility of null, but if we say that any one
could be null it's just one easy check, so it won't hurt performance too
much, not?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

We are talking only about unsettling of typed properties



From: guilhermebla...@gmail.com <guilhermebla...@gmail.com>
Sent: Wednesday, April 13, 2016 16:08
To: Dmitry Stogov
Cc: Nikita Popov; Stanislav Malyshev; internals; Joe Watkins; Zeev Suraski
Subject: Re: [PHP-DEV] Re: Typed properties patch


Hi,

Unsetting properties is used by a range of libraries I am aware of, including 
Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative though, which would help: property getter/setter would 
not only address the unsetting hack, but also allow read only properties (final 
properties). IMHO, we should look back at that implementation (it was mainly 
rejected because of the patch complexity (not the idea), which would kill two 
birds with one stone.

Cheers,

On Apr 13, 2016 2:59 AM, "Dmitry Stogov" 
<dmi...@zend.com<mailto:dmi...@zend.com>> wrote:


On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:
Hi!

 Thanks for your time reviewing the patch, appreciated.

 > 1) nullable properties

 I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.
I think this is an attempt to achieve more type safety than even fully
typed languages like Java, and it will only get in the way in PHP.

 > 3) disable unset
This sounds very weird. Why I would suddenly unable to unset a property?

Because if you unset() a property it's type is not guaranteed anymore.

x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use optimized code 
*/
?>

As we can't be sure where the property may be unset(), we won't be able to use 
optimized code at all (even in first place).

Thanks. Dmitry.





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

Re: [PHP-DEV] Re: Typed properties patch

[guilhermebla...@gmail.com]

Hi,

Unsetting properties is used by a range of libraries I am aware of,
including Doctrine (actually any project that relies on proxy generation).
Breaking this "feature" would be a catastrophe to a lot of projects.
There is an alternative though, which would help: property getter/setter
would not only address the unsetting hack, but also allow read only
properties (final properties). IMHO, we should look back at that
implementation (it was mainly rejected because of the patch complexity (not
the idea), which would kill two birds with one stone.

Cheers,
On Apr 13, 2016 2:59 AM, "Dmitry Stogov"  wrote:



On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:

> Hi!
>
>  Thanks for your time reviewing the patch, appreciated.
>>
>>  > 1) nullable properties
>>
>>  I agree that we need a way to that, but I would rather see it
>> covered by nullable types rfc.
>>
> I think this is an attempt to achieve more type safety than even fully
> typed languages like Java, and it will only get in the way in PHP.
>
>  > 3) disable unset
>>
> This sounds very weird. Why I would suddenly unable to unset a property?
>

Because if you unset() a property it's type is not guaranteed anymore.

x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use optimized
code */
?>

As we can't be sure where the property may be unset(), we won't be able to
use optimized code at all (even in first place).

Thanks. Dmitry.



>

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

Re: [PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

On 04/13/2016 07:33 AM, Stanislav Malyshev wrote:

Hi!


 Thanks for your time reviewing the patch, appreciated.

 > 1) nullable properties

 I agree that we need a way to that, but I would rather see it
covered by nullable types rfc.

I think this is an attempt to achieve more type safety than even fully
typed languages like Java, and it will only get in the way in PHP.


 > 3) disable unset

This sounds very weird. Why I would suddenly unable to unset a property?


Because if you unset() a property it's type is not guaranteed anymore.

x + 5; /* we know $a->x is "int" and may use optimized code */
unset($a->x);
$b = $a->x + 5; /* $a->x is not "int" any more  and we can't use 
optimized code */

?>

As we can't be sure where the property may be unset(), we won't be able 
to use optimized code at all (even in first place).


Thanks. Dmitry.






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

Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> Thanks for your time reviewing the patch, appreciated.
> 
> > 1) nullable properties
> 
> I agree that we need a way to that, but I would rather see it
> covered by nullable types rfc.

I think this is an attempt to achieve more type safety than even fully
typed languages like Java, and it will only get in the way in PHP.

> > 3) disable unset

This sounds very weird. Why I would suddenly unable to unset a property?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Typed properties patch

[Lester Caine]

On 06/04/16 10:19, Joe Watkins wrote:
> > 1) nullable properties
> 
> I agree that we need a way to that, but I would rather see it
> covered by nullable types rfc.
> 
> > 2) concerns about default values
> 
> Implicit defaults would only allow us to reduce read checks, it
> can't eliminate them in all cases, magic can return value for declared
> property, and an overloaded zend object doesn't necessarily use inline
> properties at all, but there can still be a declared type in the user
> class ... think class User extends Internal {} where Internal uses
> object handlers to change the way properties are stored ...
> 
> I'm persuaded by the chance to reduce instructions anyway ... let me
> think about that ...

This does seem still to be creating two types of PHP. One which plays
transparently with the initialization data returned from a database and
one where initialization is forced on less flexible variables? We
actually have typed variables returned from the database, if that is the
appropriate way of working, but the default is NULL unless a specific
default is included as part of the schema. Some databases also provide
other restrictions on this data which may be hidden by applying some new
arbitrary default in PHP?

There are a number of well established standards and all of these
attempts to add yet another 'simplified' type system is simply not helpful.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

[PHP-DEV] Re: Typed properties patch

[Joe Watkins]

Morning Dmitry,

Thanks for your time reviewing the patch, appreciated.

> 1) nullable properties

I agree that we need a way to that, but I would rather see it covered
by nullable types rfc.

> 2) concerns about default values

Implicit defaults would only allow us to reduce read checks, it can't
eliminate them in all cases, magic can return value for declared property,
and an overloaded zend object doesn't necessarily use inline properties at
all, but there can still be a declared type in the user class ... think
class User extends Internal {} where Internal uses object handlers to
change the way properties are stored ...

I'm persuaded by the chance to reduce instructions anyway ... let me
think about that ...

> 3) disable unset

An early version of the patch did disable unset, Marcus came and said
he needed the ability to unset so that magic was invoked ... this is
horrible, I'm aware ...

There doesn't seem to be a consensus on this.

If we have default values, then the problem with optimization goes away
... so maybe 2) is the solution to this and not disabling unset ?

> 4) performance

It got more complicated in the last couple of days, let us asses
performance again when the patch has had some more work.

> because definition and usage are in different PHP scripts.

This is not a limitation of Zend, this is a limitation of opcache ...
which should probably be lifted before we look to do things like inlining
functions, and optimizing access to properties.

Let me think about and discuss all of this with some other people ...
and let me work on the patch some more  ...

I'll ping again when I've solved some of these problems ...

Cheers
Joe

On Wed, Apr 6, 2016 at 9:45 AM, Dmitry Stogov  wrote:

> Hi Jow,
>
>
> First of all, I appreciate the amount of effort you already invested into
> this idea.
>
> Anyway, I still don't agree with the following terms of RFC and
> corresponding implementation:
>
>
> 1) While parameters allow null to be accepted as the default value, null
> is never a valid value for a typed property.
>
>
> I think we must have a way to make properties explicitly nullable.
> Otherwise we won't be able to define even simple binary tree...
>
>
> class Node {
>
>   public Node $left = null;
>
>   public Node $right = null;
>
> }
>
> 2) The implementation will raise an exception where a typed property is
> accessed before being initialized: 
>
>
> This makes unnecessary complication, and opens thousands possibilities to
> cheat the engine.
>
>
> class A {
>
>   public int $x;
>
> }
>
> $a = new A;
>
> var_dump($a->x++); // prints NULL (according to RFC, this should raise
> Exception)
>
>
> I propose to initialize typed properties with the value of corresponding
> type (if default value is omitted).
>
> boolean => false
>
> int => 0
>
> double => 0.0
>
> string => ""
>
> array => []
>
> object, resource, callable => null
>
> Actually, I propose implicit default values if they are not specified.
>
> This will always guarantee the type and eliminate run-time checks on read.
>
>
> 3) It is possible to unset typed properties, and return them to the same
> state as a property that was never set.
>
>
> This mean that properties types are not guaranteed, and
> Optimizer/Compilers/JIT won't be able to generate the best code performing
> type check on every read.
>
> I would prefer to disable unset() of typed properties.
>
>
> 4) Checking the type of a zval is an extremely cheap operation, there may
> be some very minor performance impact only when typed properties are used.
>
>
> The patch makes some slowdown even if typed properties are not used (0.5%
> more instruction retired on 100 requests to Wordpress according to
> callgrind)
>
>
> 5) In principle, knowing the type of a variable in advance allows you to
> make optimizations, and in the long term, there is good reason to think
> that typed properties will allow us to improve performance.
>
>
> This is an optimistic assumption [image: ]
>
> For now typed-parameters make slowdown except of expected speedup,
> properties are not going to change this.
>
>
> Actually the type of property may make some gain only if we know the type
> of object and its definition at compile-time, but in most cases we do't
> know the class definition, because definition and usage are in different
> PHP scripts.
>
> Especially with (2) and (3), even if we know type of object and property,
> we'll still have to check if property is initialised on each usage.
>
>
> Thanks. Dmitry.
>
>
> --
> *From:* Dmitry Stogov
> *Sent:* Wednesday, April 6, 2016 10:32
> *To:* Joe Watkins
> *Subject:* Typed properties patch
>
>
> Ho Joe,
>
>
> I see some tests failures (SIGSEGV)
>
>
> > Test typed properties float widen at runtime
> [Zend/tests/type_declarations/typed_properties_027.phpt]
> > Test typed properties respect strict types (off)

[PHP-DEV] Re: Typed properties patch

[Dmitry Stogov]

Hi Jow,


First of all, I appreciate the amount of effort you already invested into this 
idea.

Anyway, I still don't agree with the following terms of RFC and corresponding 
implementation:


1) While parameters allow null to be accepted as the default value, null is 
never a valid value for a typed property.


I think we must have a way to make properties explicitly nullable. Otherwise we 
won't be able to define even simple binary tree...


class Node {

  public Node $left = null;

  public Node $right = null;

}


2) The implementation will raise an exception where a typed property is 
accessed before being initialized:


This makes unnecessary complication, and opens thousands possibilities to cheat 
the engine.


class A {

  public int $x;

}

$a = new A;

var_dump($a->x++); // prints NULL (according to RFC, this should raise 
Exception)


I propose to initialize typed properties with the value of corresponding type 
(if default value is omitted).

boolean => false

int => 0

double => 0.0

string => ""

array => []

object, resource, callable => null


Actually, I propose implicit default values if they are not specified.

This will always guarantee the type and eliminate run-time checks on read.


3) It is possible to unset typed properties, and return them to the same state 
as a property that was never set.


This mean that properties types are not guaranteed, and Optimizer/Compilers/JIT 
won't be able to generate the best code performing type check on every read.

I would prefer to disable unset() of typed properties.


4) Checking the type of a zval is an extremely cheap operation, there may be 
some very minor performance impact only when typed properties are used.


The patch makes some slowdown even if typed properties are not used (0.5% more 
instruction retired on 100 requests to Wordpress according to callgrind)


5) In principle, knowing the type of a variable in advance allows you to make 
optimizations, and in the long term, there is good reason to think that typed 
properties will allow us to improve performance.


This is an optimistic assumption []

For now typed-parameters make slowdown except of expected speedup, properties 
are not going to change this.


Actually the type of property may make some gain only if we know the type of 
object and its definition at compile-time, but in most cases we do't know the 
class definition, because definition and usage are in different PHP scripts.

Especially with (2) and (3), even if we know type of object and property, we'll 
still have to check if property is initialised on each usage.


Thanks. Dmitry.



From: Dmitry Stogov
Sent: Wednesday, April 6, 2016 10:32
To: Joe Watkins
Subject: Typed properties patch


Ho Joe,


I see some tests failures (SIGSEGV)


> Test typed properties float widen at runtime 
> [Zend/tests/type_declarations/typed_properties_027.phpt]
> Test typed properties respect strict types (off) 
> [Zend/tests/type_declarations/typed_properties_028.phpt]
> Test typed properties unset __get magical magic 
> [Zend/tests/type_declarations/typed_properties_030.phpt]


valgrind shows problems on every 4-rd test at Zend/tests (454 of 1668 tests), 
but it seems like a single problem


$ cat ../Zend/tests/add_002.mem
==26053== Conditional jump or move depends on uninitialised value(s)
==26053==at 0x8627895: _zend_object_has_type_hints (zend_execute.h:367)
==26053==by 0x8629098: zend_std_write_property (zend_object_handlers.c:674)
==26053==by 0x85FA1B5: zend_update_property (zend_API.c:3894)
==26053==by 0x85FA38E: zend_update_property_string (zend_API.c:3952)
==26053==by 0x860F8DB: zend_default_exception_new_ex (zend_exceptions.c:222)
==26053==by 0x860F96F: zend_default_exception_new (zend_exceptions.c:236)
==26053==by 0x85F347E: _object_and_properties_init (zend_API.c:1303)
==26053==by 0x85F34B5: _object_init_ex (zend_API.c:1311)
==26053==by 0x86124F4: zend_throw_exception (zend_exceptions.c:881)
==26053==by 0x85EF256: zend_throw_error (zend.c:1316)
==26053==by 0x85E4622: add_function (zend_operators.c:969)
==26053==by 0x868824E: ZEND_ADD_SPEC_CV_CV_HANDLER (zend_vm_execute.h:44246)


Thanks. Dmitry.