Re: New ABI NSConstantString

[Stefan Bidigaray]

Hi David,

I forgot to make a comment when you originally posted the idea, and I think this would be a great time to add my 2 cents.

Regarding the structure:

* Would it not be better to add the flags bit field immediately after the isa pointer? My thought here is that it can be checked for if different versions of the structure exist. This is important for CoreBase since it does not have the luxury of real classes.

* Would it be possible to make the hash variable a NSUInterger? The output of -hash is an NSUInterger, and that would allow the value to be expanded in the future.

* Why have both count and length? Would it not make more sense to keep a single variable here called count and define it as, "The count/number of code units"? For ASCII and UTF-8 this would be # of bytes, and for UTF-16 it would be the # of 16-bit codes. The Apple documentation states "The number of UTF-16 code units in the receiver", making at least the ASCII and UTF-16 numbers correct. The way I understand the current implementation, the value for length would return the UTF-32 # of characters, which is inconsistent with the docs.

* I would also think that it makes more sense to have the length/count variable before the data pointer. I don't have a strong opinion about this one, but it just makes more sense in my head.

Regarding the hash function:

Why are we using Murmur3 hash? I know it is significantly more efficient than our current one-at-a-time approach, but how much better is it to competing hash functions? Is there a bench mark out there comparing some of the major ones? For example, how does it compare with lookup3 or SpookyHash. If we are storing the hash in the string structure, the speed of calculating the hash is not as important as the spread. Additionally, Murmur3 seems ill suited if NSUInteger is used to store the hash value since, as far as I could tell, it only outputs 32-bit and 128-bit hashes. Lookup3 and SpookyHash, for example, output 64-bit values (2 32-bit words in the case of lookup3), as well.

I'm late for work, so I have to wrap up.

Stefan

On Thu, Apr 5, 2018 at 11:24 AM, David Chisnall <address@hidden> wrote:

On 1 Apr 2018, at 14:06, Richard Frith-Macdonald <richard.frith-macdonald@theengagehub.com> wrote:
>
>
> I wasn't aware of that ... it would make sense for your new ABI, when individual bits, to have them specified as particular bits rather than as a bitfield, avoiding the possibility of problems with different compilers.
>
> I don't think you should feel constrained to follow the current layout ... IMO the current one is good for years yet but probably not for decades.
> However, I do think that it's more sensible to have pointer, count, hash, and flags similar to the current GNUstep layout than to follow Apple (and to bear in mind that its convenient for mutable strings to share a layout with constant ones).

How about this:

struct {
        // Class pointer
        id isa;
        // Pointer to the buffer.  ro_data section, so immutable.  NULL-terminated
        const char *data;
        // Number of characters, not including the null terminator
        long count;
        // Number of bytes in the encoding, not including the null terminator.
        long length;
        // Murmur 3 hash
        uint32_t hash
        // Flags bitfield:
        // Low 2 bits, enum with values:
        //   0: ASCII string
        //   1: UTF-8 but not ASCII string
        //   2: UTF-16 string
        //   3: Reserved for future encodings
        // (1<<2): has mumur3 hash
        // (1<<3) to (1<<15): Reserved for future compiler-defined flags
        // (1<<16) to (1<<31): Reserved for use by the constant string class
}

I think that this should give everything that we need, plus room for easy future expansion.

David

_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev