Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96498
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zeyos.com designates 89.163.237.165 as permitted sender)
Date: Wed, 19 Oct 2016 20:58:01 +0200
To: Dmitry Stogov <dmitry@zend.com>,  	Xinchen Hui <xinchen.h@zend.com>,  	Nikita Popov <nikita.ppv@gmail.com>,  	Joe Watkins <pthreads@pthreads.org>,  	Bob Weinand <bobwei9@hotmail.com>,  	Andrea Faulds <ajf@php.net>
Cc: PHP Internals <internals@lists.php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <20161019185802.B88FE5FAC0@mx.zeyos.com>
Subject: Re: [PHP-DEV] Exploit fully packed array/hash property
From: ben.coutu@zeyos.com (Benjamin Coutu)

Hi Dmitry,=0A=0AOn second thought, I might have dismissed your HASH_FLAG_*_=
KEYS idea prematurely.

Of course we will have to set/unset the flag in parts of the code that are =
very hot and naturally that will lead to a regression in terms of CPU instr=
uctions. But in regards to your idea of possibly eliminating redundant chec=
ks on every loop iteration, I think it could be interesting. It's a tradeof=
f between maintaining the necessary flags and avoiding repeatedly iterating=
 over branches. Given that bitwise operations on these flags are just about=
 the cheapest operations the CPU can perform (no pipeline stalls and flags =
usually already in L1 cache at that point), and branching inside a loop bei=
ng extremely costly (with the risk of pipeline stalls caused by branch miss=
 prediction, which might even happen repeatedly, and EXPECTED/UNEXPECTED ma=
cros undesirable in most of these cases), choosing to maintain those flags =
on write operations in order to speed up read operations suddenly looks muc=
h more appealing. In many operations that deal with the hash table in bulk =
we might even be able to set the flag just once upfront. So maybe we should=
 investigate further. Your quick test is not conclusive because you have ef=
fectively only benchmarked the negatives without settling it with the posit=
ives.=0A=0AI don't know wether the additional code complexity is worth the =
effort though. Personally I'd like to focus on getting more out of the pack=
ed hash table case, meaning trying to preserve the packed characteristics a=
nd utilizing dedicated code paths as much as possible throughout the entire=
 code base while using the existing infrastructure to do so without additio=
nal overhead. Packed arrays are very ubiquitous after all, and as HT_IS_PAC=
KED always implicates HASH_FLAG_LONG_KEYS, there is not that great of a nee=
d for the latter if we can ensure to use packed arrays wherever possible.=
=0A=0AOn another note, and this comes without any caveats, we could at leas=
t use HT_IS_WITHOUT_HOLES to get rid of repeated checks for Z_TYPE(p->val) =
=3D=3D IS_UNDEF inside loops. This would not entail any overhead on write. =
What do you think?=0A=0ACheers,=0A=0ABenjamin=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D Original =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AFrom: Dmitry Stogov <dmitr=
y@zend.com>=0ATo: Benjamin Coutu <ben.coutu@zeyos.com>, Xinchen Hui <xinche=
n.h@zend.com>, Nikita Popov <nikita.ppv@gmail.com>, Joe Watkins <pthreads@p=
threads.org>, "Bob Weinand" <bobwei9@hotmail.com>, Andrea Faulds <ajf@php.n=
et>=0ADate: Wed, 19 Oct 2016 18:02:53 +0200=0ASubject: Re: [PHP-DEV] Exploi=
t fully packed array/hash property=0A=0AThis is an option.=0A=0AIf nobody p=
ropose a better solution, I'll prepare the patch tomorrow (this solution wo=
n't make BC breaks at all).=0A=0ABTW: I think, HASH_FLAG_*_KEYS may be used=
 to eliminate redundant checks on every loop iteration in some functions.=
=0A=0AThanks. Dmitry.