[J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

Wed Dec 20 15:08:16 UTC 2023

Brad,

Ugh.   I’d not thought it through.   So you are suggesting the trig functions are not SIMPLE because their arithmetic depends on changeable params?

  *   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: Wednesday, December 20, 2023 at 9:50 AM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

I don't see a way to do it with the procedures I listed without crossing a change team or end team statement, but apparently there's another way to do it, as pointed out by Aury.

$ cat example.f90
program rounding
  use ieee_arithmetic
  implicit none
  call ieee_set_rounding_mode(ieee_up)
  print *, sin(1.2)
  call ieee_set_rounding_mode(ieee_down)
  print *, sin(1.2)
end program
$ gfortran example.f90 && ./a.out
0.932039083
0.932039082

Now, all of the functions that return real results are (I think) defined as "approximations", so maybe that applies here, but I'm not 100% sure where that leaves us.

Regards,
Brad

On Wed, 2023-12-20 at 14:19 +0000, Clune, Thomas L. (GSFC-6101) wrote:
Brad,

I suppose the question is whether one can construct a higher level (user) SIMPLE procedure that plays games with TEAMS under the hood.    If _that_ procedure can produce different results on subsequent calls without changing its arguments _and_ not moving across a segment boundary.    My co-array-fu is weak, and can easily believe that this is not possible.

· 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: Wednesday, December 20, 2023 at 8:48 AM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

> Simple procedures cannot refer to variables that are not in the argument list.

This is exactly the kind of simple and intuitive way I like to think about SIMPLE procedures. However, the current team is "a thing that varies" (albeit not declared as a variable anywhere), and it is clearly referred to in the procedures I listed (assuming the team and team_number arguments are not present).

I would have thought the implication of "cannot refer to variables that are not in the argument list" is that a call to such a procedure with the same argument values returns exactly the same result values, but the procedures I listed violate that expectation. I believe that is confusing and thus those procedures should not be listed as SIMPLE, just PURE. If all the vendors can say "we totally wouldn't have expected 'cannot refer to variables that are not in the argument list' to imply 'a call to such a procedure with the same argument values returns exactly the same result value'" I'll concede it was just me expecting too much and leave it at that. But I will point out that Wikipedia has the following to say on the subject in a general programming sense: https://en.wikipedia.org/wiki/Pure_function

> the function return values<https://en.wikipedia.org/wiki/Return_statement> are identical<https://en.wikipedia.org/wiki/Relational_operator#Location_equality_vs._content_equality> for identical arguments<https://en.wikipedia.org/wiki/Argument_of_a_function> (no variation with local static variables<https://en.wikipedia.org/wiki/Static_variable>, non-local variables<https://en.wikipedia.org/wiki/Non-local_variable>, mutable reference arguments<https://en.wikipedia.org/wiki/Value_type_and_reference_type> or input streams<https://en.wikipedia.org/wiki/Input/output>)

Regards,
Brad

On Wed, 2023-12-20 at 09:01 +0900, Malcolm Cohen via J3 wrote:
There is a lot of vague talk about “[conceptual] global state” in this thread, and it is unhelpful.

Simple procedures cannot refer to variables that are not in the argument list. That is an optimisation opportunity – e.g. in an elemental array assignment, a simple function cannot read the variable being assigned to, so no array temp or advanced analysis is needed.

That one cannot copy the evaluation of things that depend on the image number into/outof a CHANGE TEAM construct is kind of obvious, and does not obviate the usefulness of SIMPLE nor of CHANGE TEAM. There are lots of things one cannot move across any segment boundary actually – e.g. common subexpression elimination often cannot be done across one.

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org>On Behalf Of Brad Richardson via J3
Sent: Wednesday, December 20, 2023 7:37 AM
To: Steidel, Jon L <jon.l.steidel at intel.com>; General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

But we already had that for PURE procedures. What added benefit do you get from SIMPLE procedures if they can refer to global state?

On Tue, 2023-12-19 at 22:17 +0000, Steidel, Jon L wrote:
Hi Brad,

Knowing a procedure does not modify a COMMON or MODULE variable allows the compiler to hold values of COMMON and MODULE variables in registers across a call to a SIMPLE procedure, and not have to store to memory a locally modified COMMON or MODULE variable prior to the call, and reload the variable from memory upon return from the call.

-jon

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>>On Behalf OfBrad Richardson via J3
Sent: Tuesday, December 19, 2023 5:11 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Brad Richardson <everythingfunctional at protonmail.com<mailto:everythingfunctional at protonmail.com>>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

This was kind of my point. Yes I understand the argument that "intrinsics are allowed to do magic that user procedures are not", but this has broader reaching implications about the semantics of the language. If calls to simple procedures can actually return different outputs with the same arguments, what was the point of adding them?

Brad

On Tue, 2023-12-19 at 20:32 +0000, Clune, Thomas L. \(GSFC-6101\) via J3 wrote:
Reuben,

I think it is the other way around.   The definition of SIMPLE is missing a bit that might be hard to define in the standard.   If so then we need a more nuanced list of SIMPLE intrinsics.

The key thing with the “bad” intrinsic procedures is that there is an implicit context that is accessed when they run.   I strongly suspect that under-the-hood, there is the equivalent of COMMON/Save in the form of some private state inside the run-time library.

This is one of the reasons I was uncomfortable with the coarray approach of not passing an object to the intrinsics.   With MPI we have a “comm” object that  controls access.    (MPI has other sins, so just defending the value of biting the bullet and accepting another argument can be a good thing in an intrinsic.)

• Tom

From:J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Reply-To: j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: Tuesday, December 19, 2023 at 2:59 PM
To: j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: "Reuben D. Budiardja" <reubendb at ornl.gov<mailto:reubendb at ornl.gov>>
Subject: [BULK] Re: [J3] [EXTERNAL] Should all intrinsic functions be simple?

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

On 12/19/23 11:04, Brad Richardson via J3 wrote:

<snipped>

However, that would not
necessarily be true for all of the intrinsic functions. Take the
following example:

cur_team = get_team()
...
change team (new_team)
    cur_team = get_team()
    ...
end team

Clearly, it is intended that the two calls to get_team return different
results, so common subexpression elimination would not be valid here.
Also, conceptually, it would not be possible to implement this call in
a way that does "not contain a designator of a variable that is
accessed by use or host association" or "not contain a reference to a
variable in a common block" as it clearly must be accessing some global
state of the program.

Intrinsic functions which may be affected include:

* failed_images
* get_team
* image_index
* num_images
* stopped_images
* team_number
* this_image

I think this is conflating what a compiler may need to do with the
actual program. From the program standpoint, the example above does not
violate any of the simple-ness constraints (or any of the listed
function). So I still think they are SIMPLE.

Best,
Reuben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20231220/29d0c1aa/attachment-0001.htm>