Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74177
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.128.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <537333BF.7070106@lsces.co.uk>
References: <e5f19ac0089d24adc695fce93ad9bd9c.squirrel@webmail.klapt.com>
	<db6f4b4c2d10f343d4c30ee66d82b0eb@mail.gmail.com>
	<4ED7146272E04A47B986ED49E771E347BBDA6AAA06@Ikarus.ameusgmbh.intern>
	<CA+9eiLuqXs4f87bLb-vGL6AB=eEbR5khR1WtoVLwS0au7EpCOg@mail.gmail.com>
	<537333BF.7070106@lsces.co.uk>
Date: Wed, 14 May 2014 13:24:37 +0400
Message-ID: <CA+9eiLttV=68o37X-desnhQ9UD=GA1uwQwv4AVYrRgbXyGU3bw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122f332d98e2d04f958bf27
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: dmitry@zend.com (Dmitry Stogov)

--089e0122f332d98e2d04f958bf27
Content-Type: text/plain; charset=UTF-8

Ah, you are on windows and lack 64-bit IS_LONG.
This is the part of the patch that should be accepted.
I mentioned it on original email.

The "bad" thing that this patch did, it changed all C data structures to
use 64-bit string lengths and it means that each such data sructure would
take more memory. Even zend_op becames bigger and as it's used for VM
byte-code representation you may just multiply the difference to number of
opcodes in application (that might be millions).

Unfortunately, phpng don't support firebird yet and it's not in our
priority list.

Thanks. Dmitry.


On Wed, May 14, 2014 at 1:13 PM, Lester Caine <lester@lsces.co.uk> wrote:

> On 14/05/14 09:21, Dmitry Stogov wrote:
>
>> yes. We discussed that patch with Pierre for hours, and I always told that
>> I afraid about memory consumption overhead.
>> my tests showed it clearly
>>
>> phpng was started as closed project, because we didn't know if we'll able
>> to succeed at all (it's not a first attempt) and we liked to move fast.
>> Once, we got useful results we opened it.
>> seehttps://wiki.php.net/phpng#performance_evaluation
>>
>
> Dmitry
> As all of my systems are based on Firebird, I can't currently test even if
> I did have the time. One area that I have problems with is the fact that 64
> bit numbers are a key element of SEQUENCE/GENERATOR values which PHP does
> not support well and which I'd like to see fixed, but I can understand your
> concern over 64bit strings increasing memory consumption. This is why I
> think that lumping several 64bit related items together does not make
> sense? Looking at this from the hardware side, some 64bit processes will be
> faster on a 64bit machine, but also supporting 32bit builds simply adds to
> the overheads. I'd prefer to see better coverage of benchmarking since I
> don't think limited testing gives the whole picture? But I don't see 64/32
> changes having a substantial effect. Do we need 64bit long strings - not
> generally - but the facility should be covered properly while still
> retaining 32bit operations?
>
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0122f332d98e2d04f958bf27--