New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implemented all existing datapar algorithms using Boost.SIMD #2340
Conversation
hkaiser
commented
Sep 23, 2016
- factoring out code common to both backends
- adding build system support for Boost.SIMD
- unified configurations for Vc and Boost.SIMD
- flyby: cleaning up the Vc backend
c9a2837
to
7f9d236
Compare
include_directories(SYSTEM ${BOOST_SIMD_ROOT}/include) | ||
|
||
hpx_add_config_define(HPX_HAVE_DATAPAR) | ||
hpx_add_config_define(HPX_HAVE_DATAPAR_BOOST_SIMD) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about special compile flags? How will the intrinsics get enabled for the compiler (usually require special compiler switches)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is something Joel is still working on. He said they would provide a cmake macro for this information. For now this is all we can do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jfalcou: any news on this by any chance?
#include <hpx/parallel/datapar/detail/iterator_helpers.hpp> | ||
#if defined(HPX_HAVE_DATAPAR) | ||
#include <hpx/parallel/datapar/detail/transform_loop_vc.hpp> | ||
#include <hpx/parallel/datapar/detail/transform_loop_boost_simd.hpp> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this include just one of those?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have to include both as we don't know which of the libraries was configured by the user. The headers themselves have their own pp constants guarding (HPX_HAVE_DATAPAR_[VC|BOOST_SIMD]
- factoring out code common to both backends - adding build system support for Boost.SIMD - unified configurations for Vc and Boost.SIMD - flyby: cleaning up the Vc backend
7f9d236
to
9713b58
Compare
@sithhell can this go ahead now? |
@sithhell Can we merge this now? I really would like to get this in to be able to continue working on unifying the backend API. |
What happens when we include the Boost.SIMD datapar component without any additional compile flags? Will it still compile? What's the effect then? |
Good question. Why don't you tell me? It works out of the box for MSVC. |
I don't know enough about Boost.SIMD in order to know what happens when compiled without, for example, -mavx for gcc. Looking at the code, it seems that it just defaults to scalar code if the different SIMD flags aren't enabled. @jfalcou, can you clarify? |
The real culprit is that each OS/compiler have a different default behavior :
I would advice to use -march=native on gcc/clang by default so it selects the proper arch model and activates the proper SIMD level for the architecture (including SSE>2 and AVX). On MSVC, you need to put the proper /arch: option to get the proper level. |
I guess having it work (compile and run) with the default settings is good enough. Users can always tune the used flags as they like. |