Re: [boost] [gsoc] Interest check for 3d geometry proposal

Subject: Re: [boost] [gsoc] Interest check for 3d geometry proposal
From: Kornel Kisielewicz (kornel.kisielewicz_at_[hidden])
Date: 2009-03-27 12:33:19

On Fri, Mar 27, 2009 at 4:50 PM, Phil Endecott
<spam_from_boost_dev_at_[hidden]> wrote:
> Kornel Kisielewicz wrote:
>>> - Although I doubt that wasting a word on a size field has much effect on
>>> speed, I would want to avoid it when dealing with large collections of
>>> points because of the memory overhead.
>>
>> I'm not too much worried about the memory, as I am about data
>> alignment.
>
> Why?  Do you have some motivating application where memory doesn't matter
> but unaligned accesses are expensive?  If you have a motivating application
> please tell us about it.  My comment that _I_ would want to avoid wasting
> memory is because I have a memory-constrained application in front of me.
>  Code for a library like Boost will end up in lots of different applications
> with different constraints, and it really ought to be "good all round" to
> satisfy all potential users.

You misunderstood me. What I meant that out of the two problems,
having 25% more memory usage, and having to deal with structures that
don't align to architecture standards, the latter is more disturbing
to me. Not that I like the former, memory is also an important issue
here.

>> Also, in the case of 4d vectors, you'd have 5 values, which
>> doesn't scale well ( 4*32 bits = 128bits which is nice -- an addition
>> would ruin this niceness ).
>
> Multiplication by 4 faster than multiplication by 5?  Maybe, but probably
> premature optimisation :-)

This comes specifically from the architectural point of view. In this
case it's about alignment for SIMD instructions, and cache/bus size
issues. 128bits is nice, more without a serious reason is not.
-- 
regards,
Kornel Kisielewicz