Skip to content
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

Merged
merged 1 commit into from Oct 28, 2016

Conversation

@hkaiser
Copy link
Member

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

@hkaiser hkaiser added this to the 1.0.0 milestone Sep 23, 2016

@hkaiser hkaiser force-pushed the datapar_boost_simd branch 2 times, most recently from c9a2837 to 7f9d236 Sep 23, 2016

include_directories(SYSTEM ${BOOST_SIMD_ROOT}/include)

hpx_add_config_define(HPX_HAVE_DATAPAR)
hpx_add_config_define(HPX_HAVE_DATAPAR_BOOST_SIMD)

This comment has been minimized.

Copy link
@sithhell

sithhell Oct 4, 2016

Member

What about special compile flags? How will the intrinsics get enabled for the compiler (usually require special compiler switches)?

This comment has been minimized.

Copy link
@hkaiser

hkaiser Oct 4, 2016

Author Member

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.

This comment has been minimized.

Copy link
@hkaiser

hkaiser Oct 13, 2016

Author Member

@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>

This comment has been minimized.

Copy link
@sithhell

sithhell Oct 4, 2016

Member

shouldn't this include just one of those?

This comment has been minimized.

Copy link
@hkaiser

hkaiser Oct 4, 2016

Author Member

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]

Implemented all existing datapar algorithms using 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

@hkaiser hkaiser force-pushed the datapar_boost_simd branch from 7f9d236 to 9713b58 Oct 13, 2016

@hkaiser

This comment has been minimized.

Copy link
Member Author

commented Oct 14, 2016

@sithhell can this go ahead now?

@hkaiser

This comment has been minimized.

Copy link
Member Author

commented Oct 23, 2016

@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.

@sithhell

This comment has been minimized.

Copy link
Member

commented Oct 25, 2016

What happens when we include the Boost.SIMD datapar component without any additional compile flags? Will it still compile? What's the effect then?

@hkaiser

This comment has been minimized.

Copy link
Member Author

commented Oct 25, 2016

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.

@sithhell

This comment has been minimized.

Copy link
Member

commented Oct 25, 2016

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?

@jfalcou

This comment has been minimized.

Copy link

commented Oct 25, 2016

The real culprit is that each OS/compiler have a different default behavior :

  • MSVC in 32 bits doesn't use any SIMD
  • MSVC in 64 bits use SSE2 by default without needing any option to be set
  • gcc/clang generates scalar code on 32bits LINUX
  • gcc/clang generates SSE2 automatically on 64 bits LINUX

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.

@sithhell

This comment has been minimized.

Copy link
Member

commented Oct 26, 2016

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.

@hkaiser hkaiser merged commit 4cacfa0 into master Oct 28, 2016

1 check passed

ci/circleci Your tests passed on CircleCI!
Details

@hkaiser hkaiser deleted the datapar_boost_simd branch Oct 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.