Recursive LAUUM - #1402
Conversation
…lauum is a dispatch to the varint of choice. We are defaulting to recursive, but could be blocked as well
…how ilaenv parses names, any lauum routine that queries for nx will return the same value.
❌ 8 Tests Failed:
View the top 3 failed test(s) by shortest run time
View the full list of 76 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
|
Hi @jprhyne, could you please merge the current master back into all your PRs? We fixed numerical issues and errors on all platforms that are tested in CI, and the CI jobs are now configured to fail if new errors occur. That will help us to quickly determine if the changes in the PRs introduce new errors or can be merged. |
|
I don't have visibility of the setting for this PR, but the default on this repo is to give permission to those with write permission, to push (including force-push) to a PR branch. That would mean that someone with permissions on this repo could rebase this branch past the |
Description
As discussed in PR #1373, here is the implementation of a recursive LAUUM. Since some may prefer a blocked algorithm, we are proposing that we use
*lauum.fas a dispatch to whatever implementation is desired in a given environment. It's possible to somehow utilizeilaenvto do the dispatch or to have this logic insidelauum.fdirectly.In addition, since it is hardware dependent, I default to NX=64 as a crossover to lauu2. Due to how ILAENV parses the (sub)-routine names, any LAUUM routine that queries for NX will return the same value. This could be relevant if an NX parameter is to be introduced into the blocked variant. I'm not sure what the preferred method to deal with this is, so I propose that we defer this decision until it becomes relevant.
But, if it is better to solve this issue now, I propose adding another variable that checks for whatever comes after underscores in ILAENV. However, since this type of naming is not convention, I do not believe it is a good idea unless there becomes a standardized way of having different variant names in the main source directory.
Since this is a change to an auxiliary routine without a change in any public facing APIs, I do not think it is important to solve at this moment.
Checklist