Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74357
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLu8tgsitvZ0DUCqE8ahQPwE9rDhL9JVzQ5P6meVut4H_w@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>
Date: Mon, 19 May 2014 14:59:15 +0300
Message-ID: <CAL0xaBHtsKZr=9V7GLg=K=EjMzObnxUoxjNCd_am7nqFZR1vqA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1170837ce3604f9bf7f8a
Subject: Re: [PHP-DEV] Re: 64bit and phpng, votes and plans
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a11c1170837ce3604f9bf7f8a
Content-Type: text/plain; charset=UTF-8

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.

--001a11c1170837ce3604f9bf7f8a--