

Internal value representation in PHP 7, part 1 - nikic
http://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html

======
userbinator
Seeing the very large amounts of alignment padding really makes me wonder if
aligning data structures (and CPUs that require it) is an increasingly
obolescent practice; it wastes space, making less useful data fit in the
caches, and as far as I can tell was only necessary because some CPU designers
wanted to save the - comparatively tiny relative to the cache - bit of logic
to extract the right set of bytes from the cache line and bring in another one
if the access spans two of them.

[http://lemire.me/blog/archives/2012/05/31/data-alignment-
for...](http://lemire.me/blog/archives/2012/05/31/data-alignment-for-speed-
myth-or-reality/)

I know that you can arrange structures in an attempt to minimise any padding,
like what's been done here, but that doesn't always work out so perhaps it
would've been better to pack everything together.

~~~
wvenable
x86 CPUs have always been forgiving of unaligned access. So while modern x86
CPUs might have resolved this performance issue, if you ever want to run your
software on ARM, for example, you're still going to have to align everything.

~~~
gsnedders
FWIW, since ARMv6 unaligned access has been supported on ARM.

------
mordae
There is another reason for moving type tags outside of allocated blocks,
albeit possibly not very relevant to PHP; for some local variables, type tags
can be removed by constant propagation altogether.

~~~
TazeTSchnitzel
Unboxed variables is a possibility some people have thought about, and I think
HHVM does it. Given PHP 7'a parameter type hints it might be practical to do.
Though a problem would be that if you strip off the type tag, you have to add
it back again whenever you pass the value anywhere.

