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