Albin Ahlbäck
Albin Ahlbäck
Personally, I am a big fan of attributes since that hints the compiler that it can assume even more things. Of course, one should still try to optimize the code...
That's true.
Hmm, I think I agree. What about this: - (At least at first,) do not try to provide a "base ring interface". Instead focus on low-level arithmetic on arrays. -...
At least at first, a base ring interface doesn't give us anything (apart from a coherent interface) since it is not what is usually performance-critical.
@fredrik-johansson this is a pretty good draft for tuning, I believe. I think I will remove the `n_mod` stuff from `Makefile.in`, but keep them in this commit. Perhaps I could...
You can now run `make tune` and then `./build/tuneup`. This will print what should be pushed into `flint-mparam.h`. I don't know if the current timer is the best for Arm...
> Why the new `src/tune` instead of following the existing convention of using `src/MODULE/tune`? The command `make tune` already exists, and it is annoying to have directories in `src` that...
> For `n_mod`, there needs to be a plan to migrate existing `nmod` functions and types instead of having duplicate implementations. > > I'd consider doing 8-bit, 16-bit and 32-bit...
But why does it yield NaN though? Perhaps one should stick with the unsecure option for Arm64, and instruct the user on how to minimize the risk while doing so.
I see. I intend to support running tests longer in order to improve precision, but of those architectures where we really intend to optimize (Aarch64 and x86), it is nice...