Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74393
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 32179 invoked from network); 20 May 2014 22:57:58 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 20 May 2014 22:57:58 -0000
Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.173 cause and error)
X-PHP-List-Original-Sender: rasmus@lerdorf.com
X-Host-Fingerprint: 209.85.216.173 mail-qc0-f173.google.com  
Received: from [209.85.216.173] ([209.85.216.173:45744] helo=mail-qc0-f173.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id C1/31-24198-4FDDB735 for <internals@lists.php.net>; Tue, 20 May 2014 18:57:57 -0400
Received: by mail-qc0-f173.google.com with SMTP id i8so1861524qcq.4
        for <internals@lists.php.net>; Tue, 20 May 2014 15:57:54 -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=n9JONKnQGyblJKwq/IlK3G5BferUjfIYiWX6gwNcBmw=;
        b=HpwJH1QsRebiJIoF/zXzACNHmhzgVZK2pCbNLeiqZjfogIqWPlQaO3ZqTurUzfkF36
         +5JW5uWEJeE/HYyB0kR6983CAfiU6BavjmDjeNA0zaeIq03sj79j1zP14EdJ6n6obYVK
         Ri1n2I+HSDYC4BPLfpehzcSYxCnx5t1zZHDOnhmC5LWYOXwk+wGoWk0Lg7Tiiaq/b3Is
         qGQbagclrm6aNKzlOwPqZ1+9ZpucaJjl+R14ZCW9j1FCgcDlPqEZHepZll053asE7JmH
         8//wMgfVgEJrOW6S0/xL5+p8c/C6Xwk/mMPrQiz1htfCGuSNxvfnJ2a6qDJoux2PzgCw
         z7Vg==
X-Gm-Message-State: ALoCoQlGeqdmor79r1Q5K+WtgXglRLaGMieqSDL6zFvA7X7Q0Z70YXeEX26g889jhYPhyg0/kDsK
X-Received: by 10.140.34.228 with SMTP id l91mr61562575qgl.85.1400626674072;
        Tue, 20 May 2014 15:57:54 -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 d110sm13688781qge.17.2014.05.20.15.57.52
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Tue, 20 May 2014 15:57:53 -0700 (PDT)
Message-ID: <537BDDEF.9070107@lerdorf.com>
Date: Tue, 20 May 2014 15:57:51 -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: Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 Stas Malyshev <smalyshev@sugarcrm.com>
CC: Nikita Popov <nikita.ppv@gmail.com>, 
 Arvids Godjuks <arvids.godjuks@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAEZPtU4mrOiBzbqZdvxbgxseGo3ZzwgiinkqsgLQEZebrAke6w@mail.gmail.com> <CA+9eiLsMtcYVSvzHW_oc1dXNrDBH8RQ-cb1MgKB5ef2i2mQX7g@mail.gmail.com> <CAEZPtU7Tacn2GS0REbikcn8XKQr04vve=LsGQJZrkUh2oHZsuA@mail.gmail.com> <CA+9eiLu8tgsitvZ0DUCqE8ahQPwE9rDhL9JVzQ5P6meVut4H_w@mail.gmail.com> <CAL0xaBHtsKZr=9V7GLg=K=EjMzObnxUoxjNCd_am7nqFZR1vqA@mail.gmail.com> <CAGa2bXZUCtswupfixjpu7=BG0_dajApxmF8vEWUdZs9mtPnn_w@mail.gmail.com> <CAF+90c85gpvXheKuLtPYs0TN7E=ynb9ALqMuckT60zVWXYZoGg@mail.gmail.com> <CAGa2bXZFiJCasezvuuBc+K67j4W5dCgMVartEUqZrZp+z0JrBA@mail.gmail.com> <CAGa2bXbb6YjTXrL61C0cshXEBBbzYg8HQb7MocJ0GsmAy9sz9w@mail.gmail.com> <537BC669.2030704@sugarcrm.com> <CAGa2bXa1L4-ok-i8k3W-7zbpea-AU0fYJq0bY32fqEbh4DMFVA@mail.gmail.com>
In-Reply-To: <CAGa2bXa1L4-ok-i8k3W-7zbpea-AU0fYJq0bY32fqEbh4DMFVA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="DQWooV6AlAClvpCsrt8ThgIDHRh9XFfkN"
Subject: Re: [PHP-DEV] Re: 64bit and phpng, votes and plans
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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

On 5/20/14, 3:35 PM, Yasuo Ohgaki wrote:
> Hi Stas,
>=20
> On Wed, May 21, 2014 at 6:17 AM, Stas Malyshev <smalyshev@sugarcrm.com>=
wrote:
>=20
>>> 64bit int if int is 64bit. I prefer consistency, so array int key is
>> better
>>> to support
>>> 64bit int key. IMHO.
>>
>> Given that 99.9999% of PHP users will never need it, but 100% of PHP
>> users will pay in performance for each size increase, we need to be
>> careful here. "Consistency" is not more magic word than "security".
>>
>>> Similar argument applies to string also. It would be WTF, when users =
try
>> to
>>> access string offset over 32bit values. Data dealt with PHP is gettin=
g
>>> larger
>>> and larger. It would be an issue sooner or later.
>>
>> Not likely, unless somehow PHP becomes language of choice for processi=
ng
>> big data. Which I don't see exactly happening. But if it ever happens,=

>> we can deal with it then.
>=20
>=20
> I think many people don't like PHP and/or switching to other languages =
are
> concerned
> about consistency as language. Users will just switch tool, so these wo=
uld
> be issues.
> We just loose users(I mean we loose developers).
>=20
> I'm really concerned about performance as much as security/consistency =
like
> you.
> However, average web developers are not. Most developers prefer large a=
nd
> slow
> web app frameworks. This is the reality. I think we must face our
> users(developers).

While it is hard to argue with that given the number of large and slow
frameworks out there, there are also many large sites (I have worked for
or helped a bunch of them) that care a *lot* about performance. They
tend to be under-represented both here and in the blogosphere in general
because they don't like to draw attention to any specifics of their
particular technology stacks. Instead they tend to come to me or some of
the other core guys and ask for direct help.

So let's not assume that just because one segment of the userbase
screams the loudest that this segment is representative. We have a large
and diverse userbase and we need to make balanced decisions.

For this particular case of >32-bit string offsets, that would mean that
there is a string in memory that is longer than 4G. It's not like you
can have a sparse string, so you would actually have to fill it beyond
4G. That is an extremely rare use-case and chances are that manipulating
>4G blobs of data is way more efficiently implemented through some sort
of streamed/chunked mechanism as opposed to pulling the entire thing
into memory at once. If we could support it with 0 performance penalty,
ok, but given that there is a penalty we have to weigh the likelihood of
someone needing this in the next 5-8 years against the cost. To me this
is an obvious case that I would balance towards performance.

-Rasmus


--DQWooV6AlAClvpCsrt8ThgIDHRh9XFfkN
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

iEYEARECAAYFAlN73e8ACgkQlxayKTuqOuBn/ACfaCVp8w9TjVpnPs/x+M3HfJHh
KRYAnAzAqG9tpeVSH0jxo1WuMT8TRibm
=sLpo
-----END PGP SIGNATURE-----

--DQWooV6AlAClvpCsrt8ThgIDHRh9XFfkN--