[J3] [EXTERNAL] Re: Proposals for new intrinsic procedures

[Carlson, Neil]

Tom Clune wrote:

> [...] In that regard the COSCAN would be a higher priority in my book.

I have a work/remote-read efficient implementation of "COSCAN" here<https://github.com/nncarlson/coarray-collectives/blob/master/src/coarray_collectives.f90> that requires 2 log2(N) additions / reads from remote images.   I regularly encounter the need for prefix scans, mostly in connection with ragged arrays packed into a rank-1 array, especially in SMP contexts.  However these always seem to be 1-off uses during setup phases, so frankly the parallel performance of the scans isn't particularly important.  I can't think of any use cases off the top of my head where scans are used intensively, but I expect they exist.

-Neil
________________________________
From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org>
Sent: Friday, January 6, 2023 6:45 AM
To: General J3 interest list
Cc: Clune, Thomas L. (GSFC-6101)
Subject: Re: [J3] [EXTERNAL] Re: Proposals for new intrinsic procedures


Brad – I think it is premature to worry about precise names.   As Bill suggested, the focus should be on use cases.  If we move forward, JOR can compose a straw vote at the appropriate stage.



Bill – scan() is something like sort() in that you can spend a lot of time writing HPC software and never encounter the need for either of them.     But there are compelling use cases out there.    A serial implementation is almost trivial, but efficient parallel implementations have a healthy amount of literature.  In that regard the COSCAN would be a higher priority in my book.  But even within a single image, a vendor might use threads to implement a local scan.



My encounter with scan() occurred ~4 years ago when I was working on a simulation that needed to know the amount of mass in overlapping cells of randomly aligned grids.  With scan() I only needed to know the location of the top and bottom of each intersection.    For just two such grid this would not be a win, but there are O(20) grids so that the scan() calculation is amortized.    But I’m sure there are much better/clearer use cases out there.



Cheers,



  *   Tom



From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Thursday, January 5, 2023 at 6:35 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: [EXTERNAL] Re: [J3] Proposals for new intrinsic procedures



Thanks all for the suggestions, direction and background. I'll do scan

(or whatever we end up calling it) as one paper, and the other IEEE

procedures as one paper. If anybody has suggestions for the spelling of

INCLUSIVE_SCAN and EXCLUSIVE_SCAN let me know. I'll definitely have it

as a straw vote.



Regards,

Brad



On Thu, 2023-01-05 at 19:35 +0000, Brad Richardson via J3 wrote:

Hi all,



Would proposals for new intrinsic functions be acceptable to submit

for

the upcoming meeting? Specifically I've been asked to write up the

papers for:



* prefix sum (commonly known as scan, but of course that name's

already

taken), both inclusive and exclusive

* All functions recommended by IEEE-754, most of which Fortran

already

has, but the whole list is reproduced below



exp

expm1

exp2

exp2m1

exp10

exp10m1

log

log2

log10

logp1

log2p1

log10p1

hypot

rSqrt

compound

rootn

pown

sin

cos

tan

sinPi

cosPi

tanPi

asin

acos

atan

atan2

sinh

cosh

tanh

acosh

atanh



Some points of order questions also. Which subgroup is in charge of

the

intrinsic procedures so that I can coordinate with them? Would it be

best to write a separate paper for each new procedure, put them all

in

a single paper, or some scheme for grouping certain subsets? And

whilst

we don't have final version of F2023 to draft the edits against,

would

it be worthwhile to go ahead and detail out what they will look like?



Thanks in advance for any feedback.



Regards,

Brad








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230106/374175a4/attachment.htm>