Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74372
Return-Path: <rasmus@lerdorf.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 18728 invoked from network); 19 May 2014 21:45:53 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 19 May 2014 21:45:53 -0000
Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.192.54 cause and error)
X-PHP-List-Original-Sender: rasmus@lerdorf.com
X-Host-Fingerprint: 209.85.192.54 mail-qg0-f54.google.com  
Received: from [209.85.192.54] ([209.85.192.54:65098] helo=mail-qg0-f54.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 78/63-33069-19B7A735 for <internals@lists.php.net>; Mon, 19 May 2014 17:45:53 -0400
Received: by mail-qg0-f54.google.com with SMTP id q108so9879316qgd.13
        for <internals@lists.php.net>; Mon, 19 May 2014 14:45:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
         :cc:subject:references:in-reply-to:content-type;
        bh=7sPfM8YSbc+f7Au8mnc2F0cpsBh0JFYFCchZQRViykk=;
        b=F9Xkt70A0fIcJFFBRdP4wMmwa12S/Vhzqh1baoJZjCSdkCdjB0PXe7kjaNgOpNMy4/
         ue5BbJRA6m1/njgAliXi+xHhb/mb4867uIOKQPq0HlNkU3K5tj4hBTJvcLgCDoy3kbI4
         lXT519DYpUBWRL+johSQOwj1s25H9DcMhbVwyJiLA6VtGg2PmrytuSQLxaxB+Vdi7sl5
         cgEN7Fkh46sZi5PNhwDo3hVzbjMHQyfq4yozNQnZbPNQYYqFU8jyIc6M7hKtGFn+BeKh
         pUk5chTlY6g/f0WYwBzqN1T99OCwqcEed4E0rGpn9Qw2j5qZALJxvoQpLqQ/ApMIufD7
         opSw==
X-Gm-Message-State: ALoCoQn5FaLMcN7CvFDxrpnSYQeHFOlKH7U9hnTuh/z1jWNL9nhsE9VSQTVWrtagDMApctglRPe/
X-Received: by 10.140.84.168 with SMTP id l37mr51863843qgd.104.1400535950913;
        Mon, 19 May 2014 14:45:50 -0700 (PDT)
Received: from [192.168.200.30] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225])
        by mx.google.com with ESMTPSA id r2sm18881012qal.42.2014.05.19.14.45.48
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Mon, 19 May 2014 14:45:49 -0700 (PDT)
Message-ID: <537A7B8B.9010907@lerdorf.com>
Date: Mon, 19 May 2014 14:45:47 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Anatol Belski <anatol.php@belski.net>
CC: Pierre Joye <pierre.php@gmail.com>, 
 Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c8m8kMNjHOOKWs3iTxnLSVv41pk0mGjgzvvp2+Lieh+ig@mail.gmail.com>    <53788337.9090006@lerdorf.com>    <CAEZPtU7XM3Sihz0KyEpfPpYMeLZXvrz-H8SmD4LnP9gDRjNXiA@mail.gmail.com>    <53789AD9.40109@lerdorf.com>    <CAEZPtU46qaKtUufaorcRp14_6wr1bHDVkJU5p+S0V+KzNF+jdg@mail.gmail.com>    <537A35D9.50807@lerdorf.com>    <CAEZPtU7QUL0Rb-DMFmaa7kw=MFgKUhmOwKw+PwbpDe-4_mt21g@mail.gmail.com>    <537A3756.4060900@lerdorf.com> <dcbd572482a25a46d8ae8d01cf755d73.squirrel@webmail.klapt.com>
In-Reply-To: <dcbd572482a25a46d8ae8d01cf755d73.squirrel@webmail.klapt.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="6OgafQqEnC1Eofa6Q0Uc7xCPWAIfllaOT"
Subject: Re: [PHP-DEV] Rethinking 64bit sizes and PHP-NG
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--6OgafQqEnC1Eofa6Q0Uc7xCPWAIfllaOT
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/19/14, 1:55 PM, Anatol Belski wrote:
> On Mon, May 19, 2014 18:54, Rasmus Lerdorf wrote:
>> On 5/19/14, 9:52 AM, Pierre Joye wrote:
>>
>>> On Mon, May 19, 2014 at 6:48 PM, Rasmus Lerdorf <rasmus@lerdorf.com>
>>> wrote:
>>>
>>>
>>>> But that is for minor tweaks and optimizations. In this case the way=

>>>> to optimize the patch is to undo the 64-bitness in a number of place=
s
>>>> where it doesn't make sense. Putting in a software-imposed limit on
>>>> class size names while still keeping it a 64-bit value in the struct=

>>>> makes no sense, for example. Same goes for lineno, line_start,
>>>> line_end, num_args and a couple more that Nikita pointed out.
>>>
>>> That's not what we discussed.
>>>
>>>
>>>> And as far as I am concerned this has nothing to do with phpng. I'd
>>>> still be voting no on it as a 4% memory increase, which, by the way,=

>>>> you don't even mention in the impacts section, is still too high for=

>>>> me when I know parts of the 4% are completely unnecessary.
>>>>
>>>
>>> We answer that already, be from Nikita, Dmitry or I. And yes, we agre=
e
>>> on these points already.
>>
>> Ok, then please update the RFC with what you see as the way forward,
>> including adding actual memory impacts to it and restart the vote when=
 the
>> RFC is ready.
>>
>>
>> -Rasmus
>>
> Confused about what is happening. I thought we reached the agreement ba=
sed
> on what Nikita has suggested, which is pretty simple.
>=20
> The points of the current patch which have to stay
>=20
> 1. 64 bit int in zval(no mem issue, no perf issue)
> 2. size_t in zend_string (.8% mem issue, no perf issue)
> 3. use 32 bit string length as much as possible everywhere else
>=20
> for myself i'd add also
> - several ini options (like content, post, etc length, memory_limit and=

> several other)
> - file cursor and stream positions (off_t family)
> That doesn't affect mem consumption much as Dmitry already mentioned.
>=20
> Everything else, say
>=20
> literal
> ini
> stack
> header
> lineno
> class names in structs
> path length in structs
> hash
> etc.
>=20
> has to be adjusted with 32 bit string length while merging with the php=
ng
> branch.
>=20
> So question - why there are voices like "you have to implement it for
> phpng and rewrite the RFC"? If there's the consent to take this RFC wit=
h
> regard to improvement suggestion listed in short above, so what is wron=
g
> again? Wasn't it said we do it collectively?

I am fine saying we have a consensus on doing it this way, but it is
quite different from what the current RFC says. At least make a note of
this in the RFC then since many people use accepted RFCs as a resource
later on to figure out what has changed.

-Rasmus


--6OgafQqEnC1Eofa6Q0Uc7xCPWAIfllaOT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlN6e4sACgkQlxayKTuqOuAUXACffNR5BCO7bBGUfbdeJMEJBCz3
rqQAniFcSDGBVu9/bxkjB4BIVyOuutAx
=Bxx3
-----END PGP SIGNATURE-----

--6OgafQqEnC1Eofa6Q0Uc7xCPWAIfllaOT--