[Rd] Why does an empty vector occupy 40 bytes?

[peter dalgaard]

Whoops, yes. As Brian reminded me, it was probably double alignment, not pointers, that was the issue on the old Suns.

-pd

On Aug 29, 2013, at 21:11 , peter dalgaard wrote:

> 
> On Aug 29, 2013, at 20:37 , Hadley Wickham wrote:
> 
>>> Not to be picky, but that is not the point. The alignment is due to the attrib pointer which is at offset 8 despite the fact that there is only a 4-byte element in front of it. Maybe for better illustration, this is the layout on 64-bit machines:
>> 
>> Ok, thanks for the clarification.
>> 
>>> 
>>> * 4 bytes: sxpinfo header (= 32 bits)
>>> * 4 bytes: --- padding so next ptr is aligned ---
>>> * 8 bytes: pointer to attributes
>>> * 8 bytes: pointer to next node
>>> * 8 bytes: pointer to previous node
>>> * 4 bytes: length
>>> * 4 bytes: true length
>>> 
>>> = 40 bytes
>>> 
>>> This is already aligned so the payload alignment doesn't any extra padding so that has no effect at all.
>> 
>> Do pointers always have to be aligned?
> 
> I think that is architecture/compiler specific, but usually aligned pointers are loaded into memory in one clock cycle whereas unaligned ones take two, insofar as the architecture allows it at all. 
> 
> Back in the days when Sun machines went 64 bit (1993 or so?), there was an issue with dyn.loading into Splus, where it was passing unaligned pointers and gcc was expecting them to be aligned. Basically, it became a toss-up whether dyn.load calls would work or not... 
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com