Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74326
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5377D014.3020705@sugarcrm.com>
References: <CAF+90c8m8kMNjHOOKWs3iTxnLSVv41pk0mGjgzvvp2+Lieh+ig@mail.gmail.com>
 <5377D014.3020705@sugarcrm.com>
Date: Sun, 18 May 2014 01:21:38 -0400
Message-ID: <CAFp73Xs1ZSQ5ZqqmWACJ7nFoay5TZETmwfxKjku+vxD=q6xJBg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=485b397dd29968f3c604f9a5d35d
Subject: Re: [PHP-DEV] Rethinking 64bit sizes and PHP-NG
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--485b397dd29968f3c604f9a5d35d
Content-Type: text/plain; charset=UTF-8

Hi Nikita,

I really like the way you write because you put realistic approaches when
considering facts. I do miss a lot of this in here.
Like you said, it is completely feasible to add 64bit types where
applicable and not degrade performance that much as some people are flaming
internals@ lately.
As Pierre said on emails earlier on other threads, that initial patch was a
possible initial approach, not the actual final one since lots of tweaks on
memory improvement could/would be required to make it optimized as phpng.

For this exact reason I voted +1 on the initial idea, but not as a final
patch.

Cheers,


On Sat, May 17, 2014 at 5:09 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > Before going any further, it should be established that two aspects of
> the
> > 64 bit patch are, as far as I can see, acceptable to everyone: The
> > introduction of 64bit integers on Win64 and other LLP64 architectures and
> > the use of an unsigned integer type for lengths and sizes.
>
> I would add a third aspect - using a dedicated set of types to signify
> those, instead of relying on (potentially unportable) mishmash of
> standard ones. This is being overlooked, but I'd like to emphasize that
> I actually like the idea very much - with all the disruption that it
> brings - as a chance to weed out all these false assumptions and sloppy
> types still lurking in the guts of the engine and the extensions. I
> wonder if we can also make clang to tell us on such type conversions
> even if they match on specific system (I know there are hacks to do this
> but they are way uglier than I'd like to use).
>
> As for the rest, I think this is an excellent proposal and I agree with
> pretty much all of it. I am still not convinced of the need for 64-bit
> string sizes, but if we will be able to deal with much more important
> issues - such as hashtables, internal name lengths (function/class),
> etc. - I don't care, the difference is too small. I am not sure how the
> technical details with zend_string will work out but if we agree that's
> what we're doing and try to find the way to make it happen I'd think it
> worth a serious try.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--485b397dd29968f3c604f9a5d35d--