Exposing 128-bit aligned datatype

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Exposing 128-bit aligned datatype

Václav Šmilauer
I am exposing a struct which is 128-bit aligned to python; it is always
constructed dynamically in c++ code, hence there is no trouble that the
alignment is correct. I was getting errors on compilation and had to add this
bit to my code:

namespace boost {
        namespace align { struct __attribute__((__aligned__(128))) a128 {};}
        template<> class type_with_alignment<128> { public: typedef align::a128 type; };
};

The wrapper works correctly. For some reason
boost/type_traits/type_with_alignment.hpp only defines alignment > 32 only for
MSVC or Intel compilers. I am not sure where to ask for fix, can someone forward
this to the right place?

The aligned type is cl_double16, compiling with gcc.

Cheers, Vaclav


_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: Exposing 128-bit aligned datatype

Jim Bosch-2
I think this is probably a topic to take to the boost lists (or possibly
the boost ticket system, if you're pretty sure it's not intentional).

Jim


On 02/20/2012 05:13 AM, VáclavŠmilauer wrote:

> I am exposing a struct which is 128-bit aligned to python; it is always
> constructed dynamically in c++ code, hence there is no trouble that the
> alignment is correct. I was getting errors on compilation and had to add this
> bit to my code:
>
> namespace boost {
> namespace align { struct __attribute__((__aligned__(128))) a128 {};}
> template<>  class type_with_alignment<128>  { public: typedef align::a128 type; };
> };
>
> The wrapper works correctly. For some reason
> boost/type_traits/type_with_alignment.hpp only defines alignment>  32 only for
> MSVC or Intel compilers. I am not sure where to ask for fix, can someone forward
> this to the right place?
>
> The aligned type is cl_double16, compiling with gcc.
>
> Cheers, Vaclav
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/cplusplus-sig

_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: Exposing 128-bit aligned datatype

Niall Douglas
In reply to this post by Václav Šmilauer
Aligning to 128 bits is surely __attribute__((__aligned__(16)))?

You also can inherit from an aligned base class even if that base
class contains no items and the alignment passes down just fine.

BTW alignment isn't reliable as soon as something leaves static
storage e.g. goes through a parameterisation via being given to a
function. This is extremely hard to control in C++03 metaprogramming.
C++11 makes this much easier as you have rvalues.

Also, MSVC is less reliable than GCC with alignment. Use with extreme
caution! Generally I have found that the unaligned SSE load ops are
sufficiently quick during the occasional misalignment that there's no
point being overexact - if misaligned (test via if(addr & 15)), just
unaligned load instead of aligned load before executing.

Niall


On 20 Feb 2012 at 10:13, VáclavSmilauer wrote:

> I am exposing a struct which is 128-bit aligned to python; it is always
> constructed dynamically in c++ code, hence there is no trouble that the
> alignment is correct. I was getting errors on compilation and had to add this
> bit to my code:
>
> namespace boost {
> namespace align { struct __attribute__((__aligned__(128))) a128 {};}
> template<> class type_with_alignment<128> { public: typedef align::a128 type; };
> };
>
> The wrapper works correctly. For some reason
> boost/type_traits/type_with_alignment.hpp only defines alignment > 32 only for
> MSVC or Intel compilers. I am not sure where to ask for fix, can someone forward
> this to the right place?
>
> The aligned type is cl_double16, compiling with gcc.
>
> Cheers, Vaclav
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/cplusplus-sig


--
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
472909.



_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: Exposing 128-bytes aligned datatype

Václav Šmilauer

> Aligning to 128 bits is surely __attribute__((__aligned__(16)))?

Oops, I wrote it wrong in the title, it is 128-bytes aligned, double[16] with
natural alignment, i.e. __attribute__((aligned(128))).

Thanks for comments, I will try to put it into the bugtracker.


_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: Exposing 128-bytes aligned datatype

Niall Douglas
On 21 Feb 2012 at 10:39, VáclavSmilauer wrote:

> > Aligning to 128 bits is surely __attribute__((__aligned__(16)))?
>
> Oops, I wrote it wrong in the title, it is 128-bytes aligned, double[16] with
> natural alignment, i.e. __attribute__((aligned(128))).
>
> Thanks for comments, I will try to put it into the bugtracker.

128 *byte* alignment? Wow. No, no compiler will support that legally
as it would crap all over your stack frame. I vaguely remember that
GCC caps alignment to 40 bytes due to some supported architecture's
stack frame being incapable of going higher.

If you're aligning to 128 bytes then you almost certainly need to
revisit how your code is designed and what algorithms are being used.
I can think of two occasions ever in my life where I have seen an
alignment larger than 32 bytes being a reasonably good idea, and one
of those was in ptmalloc2 (which masks off the bottom megabyte of
bits as a very fast way of finding the segment for a pointer). And
even in ptmalloc2 I am unconvinced that approach was wise due to many
reasons unimportant to mention here.

Niall

--
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
472909.



_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: Exposing 128-bytes aligned datatype

Václav Šmilauer

> 128 *byte* alignment? Wow. No, no compiler will support that legally
> as it would crap all over your stack frame. I vaguely remember that
> GCC caps alignment to 40 bytes due to some supported architecture's
> stack frame being incapable of going higher.
> If you're aligning to 128 bytes then you almost certainly need to
> revisit how your code is designed and what algorithms are being used.

I did not design the OpenCL standard (see
http://www.khronos.org/registry/cl/api/1.2/cl_platform.h at the end, there is
cl_double16). Just to assure you, those types are never ever passed on stack.
That header works just fine with gcc.




_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: Exposing 128-bytes aligned datatype

Niall Douglas
On 21 Feb 2012 at 16:46, VáclavSmilauer wrote:

> > 128 *byte* alignment? Wow. No, no compiler will support that legally
> > as it would crap all over your stack frame. I vaguely remember that
> > GCC caps alignment to 40 bytes due to some supported architecture's
> > stack frame being incapable of going higher.
> > If you're aligning to 128 bytes then you almost certainly need to
> > revisit how your code is designed and what algorithms are being used.
>
> I did not design the OpenCL standard (see
> http://www.khronos.org/registry/cl/api/1.2/cl_platform.h at the end, there is
> cl_double16). Just to assure you, those types are never ever passed on stack.
> That header works just fine with gcc.

I agree that GCC/MSVC needs two alignment specifiers, one for static
data alignment and another for everything else.

This would be a good candidate for inclusion into the C programming
language actually. I may propose it to WG14.

Niall

--
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
472909.



_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig