[PHP-INTERNALS] 64bit and phpng, votes and plans

Hi Pierre,

I appreciate your professionalism in helping with phpng.

I object against the proposal, because in my opinion, it makes significant
degradation even for master.
(Please don't argue about it again. You have your opinion, I have mine, we
already wrote a lot).

I also think, it makes sense to target at least IS_LONG part of this patch
to phpng.

Other changes are questionable. In phpng we may relatively easy check the
impact of 64-bit string size on performance and memory consumption to make
a decision. I don't have any special opinion right now.

I didn't get your position about zend_size_t in all core structures. And
this is the main question.

Thanks. Dmitry.

I think I was again not clear. This is the part we will drop. We
simply can't do it now for the reasons I explained in the mail. But as
I and Nikita said earlier there are areas for improvements and tweaks,
only the right time to do it is debatable, I prefer to have a stable,
testable branch before going to change these parts again with the risk
of making the whole thing hard to test, debug or improve. Is it
something you can live with?

Cheers,

yes.

Thanks. Dmitry.

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.

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.

Hi Arvids,
Interesting point. I would not do this since I know the current limitation,
but
this is perfectly valid and practical usage.

Regards,

You can already use a key larger than 32 bits to index an array. The
limitation only applies if you want to actually store more than 2^32 (or
2^31 depending on the exact implementation) elements. That's the beauty of
a hashtable: The allowed key domain is totally independent of the hashtable
size ;)

Nikita

Hi Nikita,
Right and wrong.
When key is string, key can be anything. However, when it is int, it's not.

$ php -r '$arr[9999999999999999999999999999999]="abc";var_dump($arr);'
array(1) {
   [-4571153621781053440]=>
   string(3) "abc"
}
$ php -r '$arr["9999999999999999999999999999999"]="abc";var_dump($arr);'
array(1) {
   ["9999999999999999999999999999999"]=>
   string(3) "abc"
}

This is the reason why convert DB data values and Web inputs should not be
converted to native PHP data type blindly :)
It could work, but it cannot with 64bit int.

Regards,

It may be changed not to use int key (use string key) when int key
overflows,
then it would work.

However, many users are trying to use strict type. Users may experience
data validation errors for large int with 32bit int key. It would be better
to allow
64bit int if int is 64bit. I prefer consistency, so array int key is better
to support
64bit int key. IMHO.

Similar argument applies to string also. It would be WTF, when users try to
access string offset over 32bit values. Data dealt with PHP is getting
larger
and larger. It would be an issue sooner or later.

Regards,

Hi!
Given that 99.9999% of PHP users will never need it, but 100% of PHP
users will pay in performance for each size increase, we need to be
careful here. "Consistency" is not more magic word than "security".
Not likely, unless somehow PHP becomes language of choice for processing
big data. Which I don't see exactly happening. But if it ever happens,
we can deal with it then.

Consistency is the main problem here. Most database engines use 64bit
unique identifiers for SEQUENCE values. Upgrading systems that have been
using 32bit integer values for this to support 64bit ones is the problem
I've been living with. 32bit client apps get a string value where
previously it was a simple integer.
It is here today and has been for many years now. While the number of
records may not be large, using large offsets can result in passing the
32bit boundary and what was an integer flips ...

Any app which deals with Twitter is dealing with large, 64-bit numbers.

Hi Stas,

I think many people don't like PHP and/or switching to other languages are
concerned
about consistency as language. Users will just switch tool, so these would
be issues.
We just loose users(I mean we loose developers).

I'm really concerned about performance as much as security/consistency like
you.
However, average web developers are not. Most developers prefer large and
slow
web app frameworks. This is the reality. I think we must face our
users(developers).

Regards,

While it is hard to argue with that given the number of large and slow
frameworks out there, there are also many large sites (I have worked for
or helped a bunch of them) that care a *lot* about performance. They
tend to be under-represented both here and in the blogosphere in general
because they don't like to draw attention to any specifics of their
particular technology stacks. Instead they tend to come to me or some of
the other core guys and ask for direct help.

So let's not assume that just because one segment of the userbase
screams the loudest that this segment is representative. We have a large
and diverse userbase and we need to make balanced decisions.

For this particular case of >32-bit string offsets, that would mean that
there is a string in memory that is longer than 4G. It's not like you
can have a sparse string, so you would actually have to fill it beyond
4G. That is an extremely rare use-case and chances are that manipulating
of streamed/chunked mechanism as opposed to pulling the entire thing
into memory at once. If we could support it with 0 performance penalty,
ok, but given that there is a penalty we have to weigh the likelihood of
someone needing this in the next 5-8 years against the cost. To me this
is an obvious case that I would balance towards performance.

-Rasmus

Handling BIGINT variables as a single 64bit number rather than as a
string of characters would seem to be the more productive way of
working, but is incompatible with 32bit platforms? It's working out
exactly which path is the most productive which is the current question.
If a 64bit integer is supported as a native variable, would it be
practical to have it available on a 32bit platform? Having potentially
to have to code for two different scenarios is not the best way of
moving forward?

That has absolutely nothing to do with 64-bit string offsets which is
what we are discussing here.

-Rasmus

But integer is wrapped up in the very same RFC ... and the handling of
that is just as important ...

Hello Yasuo,

I know a lot of companies that switched (or plan to switch) to 5.5 only because of better performance.

Regards,
Thomas


Yasuo Ohgaki wrote on 21.05.2014 00:35:

Hi Thomas,

I know such companies, too. Company does not care much what
language is used for there application.

I'm worried about users who are willing to write PHP codes.
Especially for hackers who write great codes.

Regards,

FWIW, I've never come across companies who cared about 64-bit
anything, except for integer sizes. Now array sizes, string offsets
or integer array offsets. Even those who care about 64-bit binaries
typically do it due to being misinformed that it's somehow help them,
when in reality it'll give them nothing but reduced performance and
increased memory footprint.

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.

Zeev

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.

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.

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.



I think we’ve spent enough on this topic, and I don’t us want to get
carried into it yet again. Consistency is not an ultimate goal that gives
us a carte blanche to do whatever changes necessary regardless of the
cost. It’s one factor out of several. Its weight depends on **what** kind
of consistency we’re talking about, and whether it makes sense for the
majority of our userbase.



Performance isn’t an ultimate goal either. I am absolutely *not* thinking
about performance alone, nor do all of the core devs that opposed many of
the ‘consistency changes’ that were proposed. If we did we’d oppose any
and all elements of the patch, which isn’t the case. But performance is
another extremely important factor, which is why we weighed the benefit
versus cost of each part of the change and framed our opinions about it.
Nikita came up with a sensible compromise – which was the goal all along -
and it gained consensus very quickly.



Last, there’s nothing slippery about *thinking about performance*. We
should always think about performance with whatever we do. Much like
consistency or security, performance isn’t the one and only factor and
should be weighed against other factors, but it must be on the discussion
table on each and every thing we do. Also, performance is not at all
inherently contradictory to consistency, security or even code quality.
PHP 5.6 is almost twice as fast as PHP 5.0, and I’d argue the codebase is
better and just as secure and consistent if not more. phpng is another
textbook example of how we (aka Dmitry, Xinchen and Nikita) managed to get
10-30% gains in real world performance without reducing the quality of the
code in any way, and arguably – making it better. All this 100%+
performance gains between 5.0 and phpng is tedious, extremely complex work,
where individual changes rarely result in a boost of more than 3-5%. You
can imagine how much work it is to get to 100%+ improvements, and you
should therefore imagine why we don’t take lightly a change that will undo
some of these gains unless we reach the conclusion they’re truly justified,
as opposed to just being a matter of principle, or even being interesting
in rare uncommon cases.



Zeev

What you totally forget to mention:

- we cannot refactor the core in a stable branch, not even using
(much) better types
   remember? That's why you rejected and argued very hard against the
64bit RFC for 5.6, saying
   that it is all good for next (we can happily see the reasoning now...)

- The next major version is a 2+ years effort. What does it mean?
   . open doors for deeper work and redesign than what we have done in
the last decade
   . consistency and long due internals APIs and implementations
cleanup is possible

Now, one can still argue that it is still possible with phpng. But
given the amount of changes brought by phpng, I have to say that the
method used to implement it is by far not optimal. It not only causes
a total freeze of any improvement (features or APIs) in the core until
it reaches an alpha state, but it will also double the amount of work
necessary to finalize it. A little cleanup of the core would have
reduced the amount of work necessary to actually implement the ideas
behind phpng, even more once you have seen that they are working well
and are more than promising. This kind of things could have been
avoided or done faster if Zend would have been more open about its
current work.

And one day, I will understand why NDAs and all this crap are
necessary to work on php. Or maybe not. All in all it is bad for the
php project (again, the project, not the results of what is being
done), no matter the outcome of this patch.

Having been looking at the hardware side of things again, even older
32bit processors support the MMX/SSX registers and instructions which
provide 64bit maths on these processors and the latest AVX extensions
already provide 256bit maths on more modern processors since 2011. These
registers also provide parallel processing of smaller data sizes being
part of the SIMD facility,

Compatibility across processors is a problem, but even the higher spec
VIA processors support it ... along with support for hardware SHA
hashing. If performance is critical, then targeting a specific hardware
configuration may help, but there may also be opportunities for
selective improvements targeting the available hardware.

As I have already said: 64bit (or rather 63bit) integer keys are already
supported on LP64 and ILP64 platforms. This proposal supports them on LLP64
as well. The issue you're hitting has nothing to do with 64bit integers -
you are using a key that is *way* larger than that, i.e. a double key.
Double keys are handled by converting them to integers frist. This
conversion is a wraparound conversion, not a clamp conversion, so you end
up with some meaningless negative number.

If you want to change the handling of double keys, that is - as far as I
can see - an entirely different proposal, that's only tangentially related
to 64bit support.

Nikita

Hi Nikita,

It was wrong example. However, if array int key size is 32bit, 64bit value
would never fit.

I agree Rasmus's argument about string offset. If anyone would
like to deal with extremely large data, they should use stream or like.
It just wouldn't work well without it now.

Regardless of this RFC acceptance or not, it's nice if all of these
limitations
are documented in the manual under single section. Perhaps, new
appendix?

Regards,

Of cause what adds to the fun here is the mixing of 'array' keys and
'string' keys in some of the recent 'improvements' to the language. If
the array keys allow for 64bit integer values because 'integer' is a 64
bit value, then the mixing of string location as an additional dimension
of the array should ideally match that? Personally I don't think the two
have any place in the same context, but this has been added and now the
additional fallout needs documenting? That a string integer index is
different to an array integer index is the potential problem.

Personally I would prefer that the use of the string index in this way
was deprecated, and the nature of the string object was maintained
within that object. Which would allow additional performance
improvements if a string object limited to 16bit was also allowed? The
string object would also then allow for UTF-8 support because the
problem of string offsets are eliminated from the array indexing
calculations?

Will discussions in isolation are all very well, many of these elements
are all interrelated ...