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

Defaulting layout to Right versus following Kokkos' default #34

Open
kaschau opened this issue Feb 23, 2022 · 2 comments
Open

Defaulting layout to Right versus following Kokkos' default #34

kaschau opened this issue Feb 23, 2022 · 2 comments

Comments

@kaschau
Copy link

kaschau commented Feb 23, 2022

Is there a reason layouts are defaulted to LayoutRight for kokkos.arrays instead of being exec space preference based like native Kokkos?

Currently, if one creates a CudaSpace array without specifying LayoutLeft, a LayoutRight array is created, and the predictable performance hit is experienced. We could add some simple logic to the array creation like is already done if a numpy array is passed. Or better yet just access the space's preferred layout straight from kokkos source (nor sure if that's feasible or not). I guess at this point its more or less as simple as GPU <-> Left CPU <-> Right so its not too tedious to just specify on the python side.

@jrmadsen
Copy link
Contributor

Is there a reason layouts are defaulted to LayoutRight for kokkos.arrays instead of being exec space preference based like native Kokkos?

No, it was just an oversight.

Or better yet just access the space's preferred layout straight from kokkos source (nor sure if that's feasible or not).

It wouldn't be terribly difficult to create a get_default_layout(<memory-space>) function which accepts a memory space enum in enumeration.cpp which returns the preferred layout -- as long as you can follow along with the existing template metaprogramming. Then you could just change the default param to None in utility.py and make that call when it is None.

Unfortunately, I am no longer actively handling this sort of development. If you can't, ping @crtrott and @dalg24 and they might be able to find a core dev that can do it.

@jrmadsen
Copy link
Contributor

@NaderAlAwar it looks like the modifications in #32 are similar to the request here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants