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

Refactor batched serial pttrf implementation details and tests #2530

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

yasahi-hpc
Copy link
Contributor

This PR aims at improving the implementation and testing of serial pttrf.

  • Moving implementation details inside Impl namespace.
  • Remove using namespace KokkosBatched from the test code
  • Rename variables starting from underscores in the test code
  • Improve the analytical test to compare with the formula
  • Move test specializations from Test_Batched_SerialPttrf_Real.hpp and Test_Batched_SerialPttrf_Complex.hpp into Test_Batched_SerialPttrf.hpp.
  • Add docstring and assertion for Arg template parameters

@yasahi-hpc yasahi-hpc self-assigned this Mar 11, 2025
@yasahi-hpc yasahi-hpc added the Cleanup Code maintenance that isn't a bugfix or new feature label Mar 11, 2025
@yasahi-hpc yasahi-hpc requested a review from lucbv March 11, 2025 15:33
Copy link
Contributor

@lucbv lucbv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly good but I have a couple of questions, see below

@@ -270,13 +241,11 @@ void impl_test_batched_pttrf_quick_return(const int N, const int BlkSize) {
EXPECT_EQ(info, 0);
EXPECT_EQ(info2, expected_info2);

// this eps is about 10^-14
RealType eps = 1.0e3 * ats::epsilon();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is kind of bothering that there was no error analysis performed here to decide what the appropriate epsilon should be...

}

inline int run() {
using value_type = typename DViewType::non_const_value_type;
using value_type = typename EViewType::non_const_value_type;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am guessing that both D and E ViewType are actually storing the same scalars? Any reason why this needs to change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, E can be real or complex while D is always a real type. (see the implementation of zpttrf)
So, we need to use the value type of E here

Yuuichi Asahi added 4 commits March 12, 2025 21:40
Signed-off-by: Yuuichi Asahi <y.asahi@nr.titech.ac.jp>
Signed-off-by: Yuuichi Asahi <y.asahi@nr.titech.ac.jp>
Signed-off-by: Yuuichi Asahi <y.asahi@nr.titech.ac.jp>
Signed-off-by: Yuuichi Asahi <y.asahi@nr.titech.ac.jp>
@yasahi-hpc yasahi-hpc force-pushed the refactor-batched-serial-pttrf branch from 26a6dca to 4b006d1 Compare March 12, 2025 12:41
@yasahi-hpc
Copy link
Contributor Author

@lucbv
Thank you for your comments.
As for the error analysis, can I begin with simpler cases like gemv and gemm.

To me, the error analysis is more relevant in gemm testing for fp16.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cleanup Code maintenance that isn't a bugfix or new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants