On Friday 19 April 2013 01:21:58 Marc Glisse wrote:

On Thu, 18 Apr 2013, Andrey Semashev wrote:

...

3. It supports division and modulus for integers?

Why not?

...

Is it supported by any hardware?

At least some special cases are, like division by a power of 2.

I think these special cases are better coded explicitly.

And if the divisor is constant, you can also let the implementation handle turning it into a multiplication.

Does the compiler do that with user-defined operators (which are user-defined in case of packs)? Or do you mean the implementation of the operator will handle that? The latter means that the division will be very slow, but ok, since the division is slow even in hardware...

...

4. How would advanced operations be implemented, such as FMA and integer madd? Is it through additional library provided functions? IMHO, the availability of these operations is often crucial for performance of the user's algorithm, if it is more complicated than just accumulating integers. If you only want fma as a fast way to compute a+b*c, you could just let your compiler optimize an addition and a multiplication to fma. They are not bad at that. If you rely on the extra accuracy of fma, then library functions seem necessary.

According to my experience, compilers are reluctant at pattern matching the intrinsics and replacing them with other intrinsics (which is a good thing). So if the user's code a*b+c*d is equivalent to two _mm_mullo_epi16/_mm_mulhi_epi16 and _mm_add_epi32 then that's what you'll get in the output instead of a single _mm_madd_epi16. Note also that _mm_madd_epi16 requires a special layout of its operands in xmm register elements, which is also a blocker for the compiler optimization. Regarding FMA, this is probably easier for compilers, but due to the difference in accuracy I don't expect compilers to perform this optimization lightly (i.e. without a specific compiler switch explicitly allowing it). And a switch, being a global option, may not be suitable in every place of the application. So having a way to explicitly express programmer's intention is useful here too. I think special opreations like FMA, madd, hadd/hsub, avg, min/max should be provided as functions. Also, it might be helpful to be able to convert packs to the compiler-specific types, like __m128i, and back to be able to use other more special intrinsics that are not available as functions or interoperate with inline assembler. What I also forgot to ask is how the paper and Boost.SIMD handle overflowing and saturating integer arithmetics? I assume, the operators on packs implement overflowing operations since that's how scalar operations work. Is it possible to do saturating operations then?

On 19/04/13 06:55, Andrey Semashev wrote:

According to my experience, compilers are reluctant at pattern matching the intrinsics and replacing them with other intrinsics (which is a good thing). So if the user's code a*b+c*d is equivalent to two _mm_mullo_epi16/_mm_mulhi_epi16 and _mm_add_epi32 then that's what you'll get in the output instead of a single _mm_madd_epi16. Note also that _mm_madd_epi16 requires a special layout of its operands in xmm register elements, which is also a blocker for the compiler optimization.

_mm_madd_epi16 is not a vertical operation, so it's a fairly special function, and you can't expect the compiler to recognize cases where it can use it. _mm_macc_epi16 is the vertical one (XOP only), and quite more easy on the optimizer. There are fma and correct_fma functions in any case.

Regarding FMA, this is probably easier for compilers, but due to the difference in accuracy I don't expect compilers to perform this optimization lightly (i.e. without a specific compiler switch explicitly allowing it).

They do. A compiler is allowed to use higher precision for intermediate results whenever it wants. This is what also allows compilers to use 80-bit of precision for operations on float or double.

I think special opreations like FMA, madd, hadd/hsub, avg, min/max should be provided as functions. Also, it might be helpful to be able to convert packs to the compiler-specific types, like __m128i, and back to be able to use other more special intrinsics that are not available as functions or interoperate with inline assembler.

What I also forgot to ask is how the paper and Boost.SIMD handle overflowing and saturating integer arithmetics? I assume, the operators on packs implement overflowing operations since that's how scalar operations work. Is it possible to do saturating operations then?

The standard proposal tried to keep things simple, the library itself has quite a few more things.

Andrey Semashev writes:

4. How would advanced operations be implemented, such as FMA and integer madd? Is it through additional library provided functions? IMHO, the availability of these operations is often crucial for performance of the user's algorithm, if it is more complicated than just accumulating integers.

I have a more fundamental question. How will you handle vector masks? You aren't going to get performance on future implementations without it. -David

On 18/04/13 14:29, Evgeny Panasyuk wrote:

For instance, there is FMA instruction "d=a+b*c" - yes, your proposal have appropriate fma function in <cmath>. But imagine that some new architecture would have "double FMA" instruction like: "f=a+b*c+d*e", or even more complex instruction: "2x2 matrix multiplication".

It is relatively easy for compilers to transform a*b+c to fma(a,b,c) (even if the operations involved are SIMD intrinsics). As a matter of fact, compilers already do it.

On 21/04/13 14:01, Evgeny Panasyuk wrote:

And what is your point? Do you mean that we should rely on auto-vectorizer?

This has nothing to do with auto-vectorization.

On 22/04/13 16:03, Andrey Semashev wrote:

I think the argument was that in one regard you point out that we cannot rely on compiler to optimize the code and in the other you suggest the opposite.

Some optimizations are trivial, some require complex analysis and transformation algorithms. I don't think there is anything wrong with relying on the former.

Although I admit that expression transform to FMA is simpler for the compiler to handle, I would still prefer to explicitly spell it out as a function call.

You can still spell it out explicitly if you want to.

On 19/04/13 00:29, Marc Glisse wrote:

On Thu, 18 Apr 2013, Mathias Gaunard wrote:

...

Development of Boost.SIMD will still proceed, aiming for integration in Boost, but standardization appears to be definitely out of the question. Any feedback of the API presented in the proposal is welcome. http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3571.pdf

Copying here my earlier comments so they are in the same place as others'. Some of them are only relevant for standardization, not for a boost library.

I wasn't subscribed to c++-lib-ext at the time, so I missed them.

Hello,

a few comments while reading N3571.

pack seems more similar to std::array than std::tuple to me.

It's statically-sized, so both runtime and compile-time access are possible. Compile-time access could be significantly more efficient.

We could even dream of merging pack and array into a single type.

I don't think that's a good idea, pack has a very strong numerical semantic. You don't really want to do +, * or / on arrays. Plus pack requires N to be a power of 2.

As much as possible, I would like to avoid having a different interface for vectors and scalars. We have std::min for scalars, we can overload it for vectors instead of having simd::min.

The idea is that any SIMD code should be valid scalar code as well. I'm not sure whether we want the selection for functions to use ADL or whether it should be std::min. I have no strong opinion on this.

We have ?: for scalars, you don't need to restrict yourself to a pure library

Overloading ?: would probably have to be a standalone language extension to core no?

Masking: it is a bit strange to be able to do pack<double> & int but not double & int. Currently in gcc we require that you (reinterpret) cast the pack<double> to a pack<some integer>, do the masking and go back.

It was a wish from my colleague; I personally think it might be better to align the pack operators to be the same as the scalar equivalents, and therefore not allow it without a cast.

Any policy on reinterpret_cast-ing a pack to a pack of a different type?

In Boost.SIMD there is a bitwise_cast<To>(from) function, which is essentially the same as To to; memcpy(&to, &from, sizeof(from)); return to; This can be optimized to a reinterpret_cast in some cases, but reinterpret_cast itself is dangerous because of aliasing issues. ass T , std :: size_t N = unspecified >

struct alignas ( sizeof ( T ) * N ) pack

Do you really want to specify that large an alignment? You give examples with N=100...

N can never be 100, it's a power of 2. It would be possible to relax the alignment requirement somewhat however.

Maybe operator[] const could return by value if it wants to?

Yes.

Since the splat constructor is implicit, you may not need to document all the mixed operations.

It was to make things clearer, but I guess it might not be necessary.

Any notion of a subvector?

No, though it would probably be useful to be able to split any vector in two. Duly noted.

For gather and others, the proposal accepts mixing vector sizes.

For scatter/gather, it doesn't accept a number of indices different than the size of the vectors being loaded. Conversions are allowed to happen however, you can load from a uint8* to a vector of int32.

cmath functions: it is not clear what signatures are supported, in particular for functions that use several types (ldexp has double and int). The list doesn't seem to exactly match cmath, actually. frexp takes an int*, does the vector version take a pointer to a vector, or some scatter-like vector?

We have some equivalents in Boost.SIMD, to make things simpler we use int32 for float and int64 for double, so that the sizes of vectors are the same.

Traits: are those supposed to be template aliases? Or to derive from what they are supposed to "return"? Or have a typedef ... type; inside?

They're metafunctions, i.e. classes with a type member typedef.

For transform and accumulate, I have seen other proposals that specify new versions more in terms of permissions (what the compiler is allowed to do) and less implementation. Depending on the tag argument you pass to transform/accumulate, you give the compiler permission to reorder the operations, or do other transformations and it then deduces that it can parallelize and/or vectorize. Looks nice. Note that it doesn't contradict this proposal, simd::transform can always forward to std::transform(..., vectorizable_tag()) (or in the reverse direction).

simd::transform takes a function object that must be valid with both scalar and pack values; std::transform only requires that the function object be valid with scalar values. That's the main difference between the two functions.