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

PERF: Use FixedArray for table within BSplineInterpolationWeightFunction #2721

Conversation

N-Dekker
Copy link
Contributor

@N-Dekker N-Dekker commented Sep 8, 2021

Replaced itk::Array2D by itk::FixedArray, used as private TableType
of BSplineInterpolationWeightFunction. This is the type of a table,
used internally by its Evaluate member function.

Declared this table const, and initialized the table by an in-class
default-member-initializer. Defaulted the default-constructor.

Follow-up to pull request #2712
commit bc7c5df
"PERF: Use FixedArray for BSplineBaseTransform ParameterIndexArrayType"
commit 9bf745b
"PERF: Use FixedArray for BSplineInterpolationWeightFunction OutputType"

@github-actions github-actions bot added area:Core Issues affecting the Core module type:Performance Improvement in terms of compilation or execution time labels Sep 8, 2021
@N-Dekker N-Dekker force-pushed the BSplineInterpolationWeightFunction-Table-FixedArray branch from 4a6a1de to ffc90b1 Compare September 8, 2021 08:25
Copy link
Member

@dzenanz dzenanz left a comment

Choose a reason for hiding this comment

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

I guess this exposes a need for more follow-up, Modules/Core/Transform/include/itkBSplineTransform.hxx:629:44: error: too many arguments to function call, expected single argument 'index', have 3 arguments

@N-Dekker
Copy link
Contributor Author

N-Dekker commented Sep 8, 2021

/azp run ITK.Linux

@N-Dekker N-Dekker marked this pull request as ready for review September 8, 2021 15:05
@N-Dekker N-Dekker force-pushed the BSplineInterpolationWeightFunction-Table-FixedArray branch from ffc90b1 to d1cb0ed Compare September 9, 2021 08:45
Replaced `itk::Array2D` by `itk::FixedArray`, used as private `TableType`
of `BSplineInterpolationWeightFunction`. This is the type of a table,
used internally by its `Evaluate` member function.

Declared this table `const`, and initialized the table by an in-class
default-member-initializer. Defaulted the default-constructor.

Follow-up to pull request InsightSoftwareConsortium#2712
commit bc7c5df
"PERF: Use FixedArray for BSplineBaseTransform ParameterIndexArrayType"
commit 9bf745b
"PERF: Use FixedArray for BSplineInterpolationWeightFunction OutputType"
@N-Dekker N-Dekker force-pushed the BSplineInterpolationWeightFunction-Table-FixedArray branch from d1cb0ed to 7f23f43 Compare September 9, 2021 10:12
@N-Dekker
Copy link
Contributor Author

N-Dekker commented Sep 9, 2021

@thewtex Would this PR still be in time for ITK 5.3? It would be nice to have it included in the same release as the other two BSpline "Use FixedArray for ..." commits, from pull request #2712, as they kinda belong together 😃

@dzenanz
Copy link
Member

dzenanz commented Sep 9, 2021

There is a greater chance of that if you merge it now, or as soon as the CI passes 😄

@N-Dekker
Copy link
Contributor Author

N-Dekker commented Sep 9, 2021

There is a greater chance of that if you merge it now, or as soon as the CI passes 😄

Thanks for the suggestion @dzenanz As you know I'd rather not merge my own PRs. But maybe, if this one gets one more approval, I'll just do it. 😸

@Leengit I feel your comment #2721 (comment) is relevant, but it's not a show-stopper to this particular PR. OK?

@Leengit
Copy link
Contributor

Leengit commented Sep 9, 2021

@Leengit I feel your comment #2721 (comment) is relevant, but it's not a show-stopper to this particular PR. OK?

Not a show stopper. Don't wait on account of me!

@hjmjohnson hjmjohnson merged commit 9745409 into InsightSoftwareConsortium:master Sep 9, 2021
@dzenanz
Copy link
Member

dzenanz commented Sep 9, 2021

I now see that Matt has tagged 5.3 RC1. This PR didn't make the cut 😞

@N-Dekker
Copy link
Contributor Author

N-Dekker commented Sep 9, 2021

I now see that Matt has tagged 5.3 RC1. This PR didn't make the cut 😞

@dzenanz @thewtex So sad for this lonely little PR to be apart from the other two BSpline "Use FixedArray for ..." commits 😢 Any chance that RC2 will bring them together again?

@dzenanz
Copy link
Member

dzenanz commented Sep 9, 2021

RC2 will be cut from master, so they will be reunited 💕

@thewtex
Copy link
Member

thewtex commented Sep 10, 2021

Yes, 5.3 RC 2 will include these. Before then, there are new dashboard errors to address https://open.cdash.org/viewBuildError.php?buildid=7449043 😸

TableType table;
// Note: Copied the constexpr value `SupportSize` to a temporary, `SizeType{ SupportSize }`, to prevent a GCC
// (Ubuntu 7.5.0-3ubuntu1~18.04) link error, "undefined reference to `SupportSize`".
std::copy_n(ZeroBasedIndexRange<SpaceDimension>(SizeType{ SupportSize }).cbegin(), NumberOfWeights, table.begin());
Copy link
Contributor

Choose a reason for hiding this comment

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

If it isn't making sense to defined SupportSize outside the class declaration so that references and pointers to it are enabled -- perhaps because we don't want to allocate that memory just to support the reference -- similar can be accomplished via a local variable to this lambda.

const auto supportSize {Self::SupportSize};

As to const vs. constexpr here, I think the former might work out better -- the latter might be interpreted as a hint to the compiler that we don't want the memory allocated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Leengit Indeed, it appears that the link error could also be avoided by a local const auto supportSize within the lambda. But personally I don't really like to have an extra local variable. For now I think the syntax SizeType{ SupportSize } is just fine.

In general, it might become cumbersome to spell out the type name of the constexpr data member every time it is passed by reference. Instead maybe a helper function could be useful:

auto CopyToNonConstexprValue(T value) { return value; }

The value of the constexpr SupportSize could then be passed to a function like ProcessSize(const SizeType&), as follows:

ProcessSize( CopyToNonConstexprValue(SupportSize) );

Do you like that? 😺

Copy link
Contributor

Choose a reason for hiding this comment

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

I fear that it will give the same errors that we are already / still seeing in cdash. But if it doesn't then I like it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Leengit Try it out at https://godbolt.org/z/YGTh9q1Po 😃 As follows (using GCC 10.3):

struct SizeType {};

struct Wrapper
{
  constexpr static SizeType ConstexprValue{};
};

void ProcessSize(const SizeType&) {}

template <typename T>
auto CopyToNonConstexprValue(T value) { return value; }

int main()
{
    ProcessSize(CopyToNonConstexprValue(Wrapper::ConstexprValue)); // OK
    ProcessSize(Wrapper::ConstexprValue); // <== error: undefined reference
}

Copy link
Contributor Author

@N-Dekker N-Dekker Sep 10, 2021

Choose a reason for hiding this comment

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

@Leengit Related section from https://github.com/cplusplus/draft/releases/download/n4892/n4892.pdf (C++ Working Draft, 2021-06-18):

D.7 Redeclaration of static constexpr data members [depr.static.constexpr]

1 For compatibility with prior revisions of C++, a constexpr static data member may be redundantly redeclared
outside the class with no initializer. This usage is deprecated.
[Example 1:

struct A {
  static constexpr int n = 5; // definition (declaration in C++2014)
};
constexpr int A::n; // redundant declaration (definition in C++2014)

— end example]

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like a good idea. Is this for C++23? Do they have an alternative way of making references and pointers work for class static constexpr members, or are they saying that the class declaration needs to be sufficient?

@Leengit
Copy link
Contributor

Leengit commented Sep 10, 2021

I didn't try your CopyToNonConstexprValue example but ... looks like it works!

@Leengit
Copy link
Contributor

Leengit commented Sep 10, 2021

I didn't try your CopyToNonConstexprValue example but ... looks like it works!

Like the use of a local variable, this will require the existence of a (implicit or explicit) copy constructor. The deprecated technique of redundantly declaring the member variable outside of the class declaration allows any constructor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:Core Issues affecting the Core module type:Performance Improvement in terms of compilation or execution time
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants