Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7RtqL9j_bmd64B1QJLKc3uwrLpyqq3kM9Q4q47TSSZgQ@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>
 <CAGa2bXZUCtswupfixjpu7=BG0_dajApxmF8vEWUdZs9mtPnn_w@mail.gmail.com>
 <CAF+90c85gpvXheKuLtPYs0TN7E=ynb9ALqMuckT60zVWXYZoGg@mail.gmail.com>
 <CAGa2bXZFiJCasezvuuBc+K67j4W5dCgMVartEUqZrZp+z0JrBA@mail.gmail.com>
 <CAGa2bXbb6YjTXrL61C0cshXEBBbzYg8HQb7MocJ0GsmAy9sz9w@mail.gmail.com>
 <537BC669.2030704@sugarcrm.com> <CAGa2bXa1L4-ok-i8k3W-7zbpea-AU0fYJq0bY32fqEbh4DMFVA@mail.gmail.com>
 <20140520230249.E326826082D@dd15934.kasserver.com> <CAGa2bXYFUqRskjBL5ZwNQ_TfPJ9tO0Gqg=cn7Ws-j+qF3UCSTQ@mail.gmail.com>
 <266288285382887601@unknownmsgid> <CAEZPtU7RtqL9j_bmd64B1QJLKc3uwrLpyqq3kM9Q4q47TSSZgQ@mail.gmail.com>
Date: Wed, 21 May 2014 10:41:17 +0300
Message-ID: <CAL0xaBHBiaXB0x+qKX=oq3RX9cRB2FPk+8mGYP7gzV9+FOcYNw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	"mails@thomasbley.de" <mails@thomasbley.de>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a98e65ea47904f9e420dc
Subject: Re: [PHP-DEV] Re: 64bit and phpng, votes and plans
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a113a98e65ea47904f9e420dc
Content-Type: text/plain; charset=UTF-8

2014-05-21 9:23 GMT+03:00 Pierre Joye <pierre.php@gmail.com>:

> On Wed, May 21, 2014 at 8:18 AM, Zeev Suraski <zeev@zend.com> wrote:
>
> > On the flip side, I've come across countless companies (and
> > developers) who care about performance.  Actually it's rare to find
> > ones that don't.
>
> Right.
>
> And even more companies I meet care about clean APIs, stable releases,
> BC, clean and safe code, documentation (internals APIs too), etc. much
> more than performance as it costs them much more than adding hardware
> from a development and update processes point of view.
>
> Right now, you care only about performance, raw performance, this is
> good but it is by far not only what companies and users look for.
>
> --
> Pierre
>

Performance always had and will have the flipside - you either make an
extremely fast, but somewhat messy code, or you sacrifise some performance
and make a better code. same goes for consistensy - you have to sacrifise
some performance for it. The hard thing always is to balance it all. No
mere 2%-5% performance increase or decrease will affect a poorly written
system - it will probably get a tripple number performance improvement if
just redisigned and rebuilt.

Actually, vk.com (thats russiansocial network, vkontakte and they, they are
just as facebook - PHP based) gone the messy way - they absolutely excluded
OOP from their code base - it's all procedural and they made something
similar to a HipHop translator based on all that to get their performance
with additions like type hinting and other stuff.

I agree with Pierre here - thinking only about performance is a slippery
road to take. All that "incredible" performance is worth nothing if on a
native 64 bit system I suddenly hit a 32 bit limit on some part of the
language (good thing I don't have Windows servers, because I hit some of
those issues on my development PC that runs on 64 bit Win7, but that's
irrelevant, just to show that 32 bit integers are a limitation right now
right here. I needed to do financial stuff on bitcoins, that meant I needed
to floor($bitcoin_sum * pow(10, 8)), sum some numbers up and at this point
I got out of 32 bit signed integer range). And at that point I can't wait
for next major release for it to be fixed (if the bug report even will be
taken into considiration and not dissmissed as a rare case).

Sp, to sum it all up, this is a big change that will come only in major
verion numbers, like PHP.next. So, if right some part of the 64 bit patch
is throttled back to 32 bit int usage, you need to be damn sure that it's
limits will not be hit in near 7-10 years, because next major language
update probably will not happen earlier (2 years at least to get the
current PHP.next, then 4-5 minor releases with yearly cycle and a 2-3 more
years for PHP.next.next).

What worries me, reading this list, is I don't see a future proofing
attitude at all. And mostly people just ignore what the userland developers
say - you get just dismissed on the grounds that some enterprise shadowy
guys come up to you and say that they need perormance at all costs (I
readed just like that, sorry). Ok, I can use that card to - I'm currently
building a geo-replicated system for a bussiness that does not really want
to share it's guts, but in 2 years it will have millions of clients accros
the EU, handling a lot of data with global id's and so on. And though I do
care about the performance, I care a lot more about the consistency. That I
don't hit some stupid 32 bit limitation somewhere in the comming years
because right now someone decided that they should save 32 bits of memory
on the datatype in a certain structure. And at that point i'm just forced
to switch instruments. And I may not need to do that because of the
performance - if PHP history shows anything, it is it's ability to speed up
and actually having much better performance than expected. PHP 5.4 was a
big surprise, 5.5 did even more. Unoptimized PoC PHPNG shows 20% to 30%
performance increase even further. PHP is one of the fastest scripting
languages right now. With the tools to seriously to speed it up with
additional tools like HHVM or Zephyr. BTW, what about the Zephyr? I bet it
would be affected by all this too. It's basically C code when compiled -
and C code can do much more much faster than PHP does. Will I be able to
handle an array bigger than 2^32 elements cleanly so I can access it from
the userland?

I would like to see some thoughts on all those questions by everyone.
Because to be fair, it's not all about the performance and memory. Test
show, that 64 bit patch does not really affect those in any major way and
properly designed application with optimizations made in 5.4 in mind is
affected on mesurment leavay level and even has better performance (I don't
remember if actual numbers where provided - I think we need a spreadsheet
where to consolidate all that info).

What I actually would like also to see is a phpng tested with full
integration of 64 bit patch as it is now and the optimized version by the
authors of phpng as they see it. And compare it. Because there is no hard
facts about the performance of 64 bit vs 32 bit type usage - just
speculation about CPU cache misses and so on. And I learned over the years
that people, designing those CPU's, are sneaky and sometimes results defy
the logic. And there are hints that actually full 64 bit types may be
faster than 32 bit usage for memory optimization.

Thanks,
Arvids.

--001a113a98e65ea47904f9e420dc--