On Fri, August 29, 2014 19:41, Andrea Faulds wrote: > > On 29 Aug 2014, at 17:39, Anatol Belski <anatol....@belski.net> wrote: > > >> On Fri, August 29, 2014 17:54, Andrea Faulds wrote: >> >> >>> I’d just leave things as they are… though I suppose there might be >>> some benefit to switching to size_t for string offsets. Does that >>> avoid a > cast >>> in the generated assembly? >> My point is just that it should be consistent as we have it, in less or >> > or >> prefferably more plausible way. Though i didn't quite understand the >> question about the compiled assembly - you mean whether it'll be binary >> compatible with the previous bins? then no. > > If I recall correctly, one of the reasons to use size_t for string > lengths was avoid casts in the generated machine code. That’s what I was > referring to: on 64-bit platforms, you’d need to do a 32-bit to 64-bit > cast.
Generally this is true - when only 64 bit types are used, then twice fewer operations are necessary. Despite that, some cases might show 64 bit slower than 32 bit because of cache misses. Still, highly dependent on concrete case. With size_t it's additionally the security as it cannot be overflown. Currently, we still mix 32 and 64 bit integers to reduce the memory consumption on the internal structures and keep the efficiency. So using a very fine comb to touch the places really relevant. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
