Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76959
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <85579a59f1466c1ec754c78a978f82d8.squirrel@webmail.klapt.com>
In-Reply-To: <AA8DDBC3-35EF-4A2A-8D63-0A521086D240@ajf.me>
References: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
    <38C2ECB6-F38E-47C2-8C34-640FF0271FF7@ajf.me>
    <34613a1e18d788b25345d0227cdc1d2c.squirrel@webmail.klapt.com>
    <AA8DDBC3-35EF-4A2A-8D63-0A521086D240@ajf.me>
Date: Fri, 29 Aug 2014 23:40:43 +0200
To: "Andrea Faulds" <ajf@ajf.me>
Cc: "Anatol Belski" <anatol.php@belski.net>,
 internals@lists.php.net,
 "Nikita Popov" <nikita.ppv@gmail.com>,
 "Pierre Joye" <pierre.php@gmail.com>,
 "Dmitry Stogov" <dmitry@zend.com>,
 "Laruence" <laruence@php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] 64 bit string offsets
From: anatol.php@belski.net ("Anatol Belski")

On Fri, August 29, 2014 19:41, Andrea Faulds wrote:
>

> On 29 Aug 2014, at 17:39, Anatol Belski <anatol.php@belski.net> wrote:
>
>
>> On Fri, August 29, 2014 17:54, Andrea Faulds wrote:
>>
>>
>>> I’d just leave things as they are… though I suppose there might be
>>> some benefit to switching to size_t for string offsets. Does that
>>> avoid a
> cast
>>> in the generated assembly?
>> My point is just that it should be consistent as we have it, in less or
>>
> or
>> prefferably more plausible way. Though i didn't quite understand the
>> question about the compiled assembly - you mean whether it'll be binary
>>  compatible with the previous bins? then no.
>
> If I recall correctly, one of the reasons to use size_t for string
> lengths was avoid casts in the generated machine code. That’s what I was
> referring to: on 64-bit platforms, you’d need to do a 32-bit to 64-bit
> cast.

Generally this is true - when only 64 bit types are used, then twice fewer
operations are necessary. Despite that, some cases might show 64 bit
slower than 32 bit because of cache misses. Still, highly dependent on
concrete case. With size_t it's additionally the security as it cannot be
overflown.

Currently, we still mix 32 and 64 bit integers to reduce the memory
consumption on the internal structures and keep the efficiency. So using a
very fine comb to touch the places really relevant.

Regards

Anatol