Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74360
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.181 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAL0xaBHtsKZr=9V7GLg=K=EjMzObnxUoxjNCd_am7nqFZR1vqA@mail.gmail.com>
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>
Date: Mon, 19 May 2014 16:12:09 +0400
Message-ID: <CA+9eiLucJVWvfFVybWHyfDyfmuWtPW=apFRNh_7zUEcFcRoBVw@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013a1d7029613304f9bfacf3
Subject: Re: [PHP-DEV] Re: 64bit and phpng, votes and plans
From: dmitry@zend.com (Dmitry Stogov)

--089e013a1d7029613304f9bfacf3
Content-Type: text/plain; charset=UTF-8

In few words today CPU may work much faster than main memory.
We may save one cycle, but a cache ot TLB miss would add hundred stall
cycles.
In this situation compact data structures designed with data locality in
mind  may bring much more effect.
On very first steps phpng used more CPU cycles but worked faster out of the
box, see https://wiki.php.net/phpng#performance_evaluation

Thanks. Dmitry.


On Mon, May 19, 2014 at 3:59 PM, Arvids Godjuks <arvids.godjuks@gmail.com>wrote:

> Hello internals!
>
> I was following this 64 bit stuff from the get go, and been monitoring the
> PHPNG stuff as it was announced, so I think I have a pretty clear picture
> of what's happening. At least I belive so :) And I'm a userland developer,
> so I'm not into compilers and low-level C stuff, just have the basic
> understanding and principles at hand.
>
> So, to the point of my message.
>
> I have a question that is nugging me for weeks now about the 64 bit stuff
> and how 64 bit processors are handling things. There is no debate that a 64
> bit pointer or integer takes double the memory than a 32 bit one, and
> actually direct comparation gives us a frightening answer - it's doubled!
> In reality 10 years later we know that it's not that bad (it's common
> knowlege).
>
> My main question is - isn't 2 32 bit integers, stuck into one 64 bit
> register, handled slower than 2 64 bit integer each occupying it's own
> register?
>
> I'm concerned with the fact, that some of you are so fixated on the memory
> consumption aspect without any regard to the CPU cycle part of the
> equasion. It was pointed out by Pierre, and largely ignored, by the vocal
> advocates for the PHPNG, that despite the change of many 32 bit types to 64
> bit it not just didn't degrade the performance (hello, 64 bit processors,
> no? They by design are more efficient with 64 bit than with 2 32 bit
> numbers stuck into a 64 bit register), but actually improved it. IMPROVED
> THE PERFORMANCE. This is logical, this is what you expect optimizing for 64
> bit mode. And because of the PHP 5.4 memory reduction (interned strings, if
> i'm not mistaken?) memory growth is almost non-existent. A 2% to 5%
> increase in memory usage agains 5.5 after a 30% to 70% memory usage drop in
> 5.4 is, from my point of view, a drop in the ocean.
>
> And PHPNG is a PoC at this point: not optimized, no advanced features
> implemented, etc. Hell, it's a JIT engine, maybe after initial release you
> will find a way to minimize thouse ZVAL structures in a way, that it will
> cut down the memory usage on them much more that you have introduced with
> 64 bit patch with those size_t types.
>
> The future proofing side was mentioned only a few times and I actually want
> to point this out - memory is growing like crazy - DDR4 is already being
> shipped, server platforms for DDR4 are being introduced this summer. First
> DDR4 modules are already surpasing the DDR3 capacity with ease. And data
> amounts, we are handling in our PHP applications, also grows a lot. Yes, I
> agree that an array of 2^64 bit elements probably will not be handled by
> PHP anytime soon, but did you concider the fact that an array's key,
> indexed by an ID column from the database, can easilly be bigger than 32
> bit unsigned integer (I tend to put 64 bit integers as my primary keys
> these days)? Will it error out if you use a 32 bit array length integer or
> should you actually use a 64 bit one in this case?  At least no one is
> objecting that we need > 4GB file support.
>
> For me, as a userland developer, this future proofing and concictensy, with
> the slight performance speedup, is much more important that a 2 to 5%
> memory usage increase. And PHPNG, when actually done and optimized, will
> bring much more improvement than cutting down this 64 bit patch in half.
> Most of us have memory to spare on our servers, especially when running a
> nginx + php-fpm setup. And those, who have memory problems, probably use
> wrong tool for the job (or poorly designed software). The history shows,
> that PHP had it's major problems with half-baked solutions or cut down
> implementations due to politics and obsessive behaviour over some parts of
> it. I though PHP had it's share of trouble with register_globals and many
> other bad decisions and now, at least from my point of view, another bad
> decision is forced on, this time by the Zend itself (at least it looks that
> way). For god's sake - you make a JIT for PHP. Implement god damn typehints
> for scalars and optimize the memory usage with JIT optimizations, but leave
> the room for the manouver for the future. Think also about the extensions -
> from their point of view using a consistent type is much easier across the
> board.
>
> My 0.02$, thanks.
>

--089e013a1d7029613304f9bfacf3--