Too bad, didn't think Bucket->key->h was so ubiquitous that it actually kills the benefit of less memory allocation and tighter cache alignment in bucket.
========== Original ========== From: Xinchen Hui <xinche...@zend.com> To: Dmitry Stogov <dmi...@zend.com> Date: Thu, 22 Jan 2015 08:52:35 +0100 Subject: Re: [PHP-DEV] Improvements to Hastable Bucket structure Hey: On Thu, Jan 22, 2015 at 3:36 PM, Dmitry Stogov <dmi...@zend.com> wrote: > Hi, > > Xinchen already tried something similar, but it made PHP slower, because it > made access to Bucket->key->h more expensive - two loads with most probably > two CPU cache misses instead of one. yes, the patch is here: https://github.com/laruence/php-src/tree/union-hash-key thanks > > Thanks. Dmitry. > > On Thu, Jan 22, 2015 at 9:43 AM, Benjamin Coutu <ben.co...@zeyos.com> wrote: >> >> Hi, >> >> Currently a hashtable bucket has to store both, the numeric index "h" and >> a potential pointer to a string key "key". >> >> There is room for improvement here because "h" and "key" are conceptually >> mutually exclusive. I therefore propose to unionize "h" and "key" to >> effectively save the overhead of having to reserve space for both. >> >> Now, in order to still be able to distinguish between an integer key and a >> pointer to a string key, one could use either of two approaches. >> >> === 1. Use flags of embedded zval (maybe _zval_struct.u1.v.*) === >> >> If the is-key-flag is set in the embedded zval then its a string key, if >> not then its an integer. This is of course only possible if _zval_struct.u1 >> is usable for this (I could not quickly tell). >> >> === 2. Pointer tagging === >> >> On a 64/32-bit machine all pointers will be aligned to 8/4 bytes meaning >> that their last 3/2 bits will always be zero. We can exploit this to >> effectively store information about the pointer in those bits. >> >> We will use the last bit to distinguish between a pointer and an 63/31-bit >> integer, and the second last bit to distinguish between a pointer to a >> string key or pointer to the overflowing integer (64/32 bit). Here is a >> (8-bit) sample: >> >> LLLLLLL1: integer (effectively 63/31) >> PPPPPP00: pointer to zend_string (string key) >> PPPPPP10: pointer to zend_ulong (in case integer key is > 63/31 bit) >> >> One will then be able to use simple shifting and bitwise operations to >> extract the correct meaning. >> >> Please let me know your thoughts! >> >> Cheers, >> >> Ben >> >> -- >> >> Benjamin Coutu >> Zeyon Technologies Inc. >> http://www.zeyos.com >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
