View mode: basic / threaded / horizontal-split · Log in · Help
April 10, 2012
Re: Small Buffer Optimization for string and friends
Le 08/04/2012 16:52, Andrei Alexandrescu a écrit :
> On 4/8/12 4:54 AM, Manu wrote:
>> On 8 April 2012 12:46, Vladimir Panteleev <vladimir@thecybershadow.net
>> <mailto:vladimir@thecybershadow.net>> wrote:
>>
>> On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote:
>>
>> Walter and I discussed today about using the small string
>> optimization in string and other arrays of immutable small objects.
>>
>> On 64 bit machines, string occupies 16 bytes. We could use the
>> first byte as discriminator, which means that all strings under
>> 16 chars need no memory allocation at all.
>>
>>
>> Don't use the first byte. Use the last byte.
>>
>> The last byte is the highest-order byte of the length. Limiting
>> arrays to 18.37 exabytes, as opposed to 18.45 exabytes, is a much
>> nicer limitation than making assumptions about the memory layout.
>>
>>
>> What is the plan for 32bit?
>
> We can experiment with making strings shorter than 8 chars in-situ. The
> drawback will be that length will be limited to 29 bits, i.e. 512MB.
>
> Andrei
>
>

As it is a flag, why not limit the string size to 2GB instead of 512MB ?
April 10, 2012
Re: Small Buffer Optimization for string and friends
Am Tue, 10 Apr 2012 10:50:24 +0200
schrieb Artur Skawina <art.08.09@gmail.com>:

> Obviously, yes, but should wait until enough attribute support is in place and
> not be just a @inline hack.

If you refer to the proposed user attributes, they wont change the operation of the compiler. Only your own program code will know how to use them. @inline, @safe, @property, final, nothrow, ... on the other hand are keywords that directly map to flags and hard wired logic in the compiler. Correct me if I'm wrong.

-- 
Marco
April 10, 2012
Re: Small Buffer Optimization for string and friends
On 04/10/12 19:25, Marco Leise wrote:
> Am Tue, 10 Apr 2012 10:50:24 +0200
> schrieb Artur Skawina <art.08.09@gmail.com>:
> 
>> Obviously, yes, but should wait until enough attribute support is in place and
>> not be just a @inline hack.
> 
> If you refer to the proposed user attributes, they wont change the operation of the compiler. Only your own program code will know how to use them. @inline, @safe, @property, final, nothrow, ... on the other hand are keywords that directly map to flags and hard wired logic in the compiler. Correct me if I'm wrong.

I'm saying that introducing new function attributes like @inline to the language,
when there's a real possibility of "generic" attributes being invented in the near
future, may not be a good idea. Any generic scheme should also work for @inline and
the many other attrs that i've mentioned before - there's no reason to artificially
limit the support to *just* user attributes.

artur
April 10, 2012
Re: Small Buffer Optimization for string and friends
Am Tue, 10 Apr 2012 20:52:56 +0200
schrieb Artur Skawina <art.08.09@gmail.com>:

> I'm saying that introducing new function attributes like @inline to the language,
> when there's a real possibility of "generic" attributes being invented in the near
> future, may not be a good idea. Any generic scheme should also work for @inline and
> the many other attrs that i've mentioned before - there's no reason to artificially
> limit the support to *just* user attributes.
> 
> artur

I had to read up on your older posts again. So you are not expecting compiler hooks that allow to change the language semantics and code gen through user attributes, but a common syntax especially for bundling multiple compiler/user attributes like "@attr(safe, nothrow, userattr(abc), inline, ...) my_attr_alias" in the event that there will be a lot of platform specific and other pragmas/attributes/keywords like in GCC in the future? Then I tend to agree.

-- 
Marco
Next ›   Last »
2 3 4 5 6
Top | Discussion index | About this forum | D home