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

intrinsics module with alternative implementations #915

Open
wants to merge 30 commits into
base: master
Choose a base branch
from

Conversation

jalvesz
Copy link
Contributor

@jalvesz jalvesz commented Jan 3, 2025

Add intrinsics module containing replacements for intrinsic function where some feature is found interesting: faster implementation, better accuracy, both simultaneously.

This PR follows the discussion in discourse https://fortran-lang.discourse.group/t/lfortran-now-supports-all-intrinsic-functions/8844/41 and it's based on https://github.com/jalvesz/fast_math

  • sum: 2 options (stdlib_sum and stdlib_sum_kahan)
  • dot_product: 2 options (stdlib_dot_product and stdlib_dot_product_kahan)

cc: @fortran-lang/stdlib @perazz @certik @jvdp1

@jalvesz jalvesz changed the title feate: intrinsics module with alternative implementations intrinsics module with alternative implementations Jan 4, 2025
@jalvesz
Copy link
Contributor Author

jalvesz commented Jan 7, 2025

One philosophical question: should the fsum interface be renamed to sum to enable direct replacement of the intrinsic? Keep this name? Or yet something like stdlib_sum? (Same for fprod->dot_product)

Regarding the kahan versions, given that the accuracy gains are close between the pure chunked version and the kahan one, I'm wondering which level of support should be enabled to switch between them?

@jalvesz jalvesz marked this pull request as ready for review January 12, 2025 10:32
@perazz
Copy link
Member

perazz commented Jan 30, 2025

IMHO shorter names are better, and don't see a problem if they overlap with the intrinsics. First, because one can always pick the right version:

use stdlib_intrinsics, only: dot_product

vs.

! Force using intrinsic
intrinsic :: dot_product

And then because they can be augmented by more/different arguments

c = dot_product(a,b) ! intrinsic
c = dot_product(a,b,mode='kahan') ! stdlib
c = dot_product(a,b,mode='blocked') ! stdlib
...

I find this more elegant and definitely not confusing.
This PR also reminds me that it would be worthwhile to also augment the matmul intrinsic via calls to the gemm backend

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

Successfully merging this pull request may close these issues.

2 participants