[macstl-dev] Questions on valarray use : non-aligned buffers
lipovsky at skycomputers.com
Wed Sep 28 05:35:14 WST 2005
Glen Low wrote:
>> How about renaming the already existing refarray into
>> "aligned_refarray" and naming the upcoming one as "refarray".
>> Sometimes, I think, it's necessary to break the API (which should be
>> ok here as it's very recent) to do things right rather than be
>> constantly confused later on.
>> P.S. if not, then arbarray should do it. I don't think you want to
>> make the names similar (for the aligned and the "unknown alignment"
>> versions), since this can confuse future novices.
> I'm hoping to eliminate some epilogue code in the next version of
> macstl. Particular valarray expressions can stand to use all SIMD
> instead of wasting time in the tail of the array calling scalar
> functions -- e.g. where it can be established that there's enough
> "slop" in the source and target arrays. This would be true of valarray
> and statarray and all strictly parallel functions and operators, but
> unfortunately won't be true for refarray and arbarray/ urefarray -- I
> can't guarantee there's nothing "important" after the end of data in a
> refarray or arbarray/urefarray. I don't want a runtime check, not just
> because it's (slightly) slower but because I'm hoping to eventually
> target the Cell and other embedded scenarios where non-use/non-linking
> of the Standard Library would be an advantage.
> Not sure how to address that in the design of refarray. I'm now
> thinking it'd be better to use some default template non-type params
> (similar to policies) to do this e.g.
> refarray <float> -- non-aligned, no slop (the default case should be
> the hardest to stuff up, as per Ilya's thinking)
> refarray <float, aligned, sloppy>
> refarray <float, aligned>
> "sloppy" doesn't accurately capture what I'm thinking, I mean it's an
> assert that the data passed in will have a length divisible by 4 (for
> What do you think?
Maybe "native" is better? Some kind of an enum type of variable, perhaps?
More information about the macstl-dev