GNU bug report logs - #14599
An option to make vector allocation aligned

Previous Next

Package: guile;

Reported by: Jan Schukat <shookie <at> email.de>

Date: Wed, 12 Jun 2013 13:38:02 UTC

Severity: wishlist

Full log


Message #22 received at 14599 <at> debbugs.gnu.org (full text, mbox):

From: Jan Schukat <shookie <at> email.de>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 14599 <at> debbugs.gnu.org
Subject: Re: bug#14599: An option to make vector allocation aligned
Date: Thu, 13 Jun 2013 09:07:41 +0200
Hello again :)


On 06/12/2013 10:37 PM, Andy Wingo wrote:
> On Wed 12 Jun 2013 15:37, Jan Schukat <shookie <at> email.de> writes:
>
>> If you want to access native uniform vectors from c, sometimes you
>> really want guarantees about the alignment.
> 16 bytes I guess?  Guile's uniforms are 8-byte-aligned by default, as
> you probably know.

Yes, 16 bytes. But more could be useful too. And as I have stated in my 
previous mail, the first element of the vector is guaranteed to be 4 
byte aligned on 32 bit machines, because it starts directly after the 3 
word header, which is allocated at 8 byte boundaries. And yes, I have 
tested this, but should be obvious from the code too.



>
> Just wondering if there is a better default.
>
>> +#ifdef SCM_VECTOR_ALIGN
>> +      contents = scm_gc_malloc_pointerless (SCM_BYTEVECTOR_HEADER_BYTES
>> + c_len + SCM_VECTOR_ALIGN,
>> +                        SCM_GC_BYTEVECTOR);
>> +      ret = PTR2SCM (contents);
>> +      contents += SCM_BYTEVECTOR_HEADER_BYTES;
>> +      contents += (addr + (SCM_VECTOR_ALIGN - 1)) & -SCM_VECTOR_ALIGN;
>> +#else
>>         contents = scm_gc_malloc_pointerless (SCM_BYTEVECTOR_HEADER_BYTES
>> + c_len,
>>                           SCM_GC_BYTEVECTOR);
>>         ret = PTR2SCM (contents);
>>         contents += SCM_BYTEVECTOR_HEADER_BYTES;
>> +#endif
> This is somewhat dangerous, as you could lose the pointer to the start,
> and then the contents get collected.
>
> I guess this can be fixed in master, if you set the "holder" field on a
> bytevector to the actual memory that you allocate.
>

Don't really understand the danger here, isn't this allocated as a whole 
block and only collected as a whole block too? What am I missing?

Having the arrays aligned according to their type by default could be a 
nice option, i.e. a word of padding for long and doubles on 32 bit 
machines, and then also introducing a new 16byte simd128 and 32 byte 
simd256 type id and their respective creation functions.


Regards

Jan Schukat




This bug report was last modified 12 years and 62 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.