Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71115
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <CAGa2bXbfpRriHzCTdFaboCfT_afH=0W2NsK0OJVBrHhdNLk5dQ@mail.gmail.com>
References: <fa05c43bc2fff5420759e05dee19c99f.squirrel@webmail.klapt.com>
	 <CAGa2bXbfpRriHzCTdFaboCfT_afH=0W2NsK0OJVBrHhdNLk5dQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 14 Jan 2014 00:05:19 +0100
Message-ID: <1389654319.6953.45.camel@ghost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: ab@php.net (Anatol Belski)

Hi Yasuo,

On Tue, 2014-01-14 at 06:57 +0900, Yasuo Ohgaki wrote: 
> Hi Anatol,
> 
> On Fri, Jan 10, 2014 at 11:58 PM, Anatol Belski <ab@php.net> wrote:
> 
> > https://wiki.php.net/rfc/size_t_and_int64
> >
> > The discussion time has come. The work on the feature branch continues.
> > The current patch is stable enough to be discussed.
> 
> 
> I haven't dive into details of this improvement, so
> I'm assuming the improvement is only for 64bit platforms from the title.
> 
> There are number of subsystems that supports 64bit int. e.g. file system,
> PostgreSQL large object, time, etc. It's nicer if 64bit int is supported on
> 32bit platforms.
> 
> What's the reason not to introduce larger int for 32bit platforms?
> Too much performance impact?
> 
thanks for the interest on this. Such an idea existed at the start among
others, as well as introducing a new zval member for 'int64' besides
'long'. The reasons for not doing it (now), also from the todays point
of view:

- much higher patch complexity
- with more complexity the risk of not finishing the patch grows
- worse compatibility with libraries
- worse compatibility with existing extensions 
- 64 bit processors are widely available
- well, the slowliness you mention, whereby i've no benchmarks at hand

I would describe the current patch already as a quantum jump for PHP,
whereby small steps are much safer. Having placeholders instead of fixed
types is a good base to do 64 bit int available on 32 bit platform.
However I guess bringing it up will take not less amount of woman/hours,
if not more. One can see the current state as an intermediate goal,
where it leads is another question.

What comes with the patch now:

- 64 bit int support across windows/linux
- 64 bit file operations across windows/linux
- size_t support for string length, that means string length can be
handled with userspace integers
- open perspectives for things like you mention

I've read your Postgres approach and that's doable even currently inside
32 bit, too. There is such functionality here and there, like ext/date.

Regards

Anatol