[ofiwg] allowing aliasing in fetch atomics?

[Sur, Sayantan]

In either case, we should clarify in the man pages (if not already clear) about aliasing. I agree with Jeff that if there is no need for atomics using aliased buffers, then we shouldn’t define it either. I know the check for aliased buffers is cheap, but why have that check at all, if no use case exists?

From: <ofiwg-bounces at lists.openfabrics.org<mailto:ofiwg-bounces at lists.openfabrics.org>> on behalf of Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>>
Date: Wednesday, November 11, 2015 at 12:07 PM
To: "Dave Goodell (dgoodell)" <dgoodell at cisco.com<mailto:dgoodell at cisco.com>>
Cc: "ofiwg at lists.openfabrics.org<mailto:ofiwg at lists.openfabrics.org>" <ofiwg at lists.openfabrics.org<mailto:ofiwg at lists.openfabrics.org>>
Subject: Re: [ofiwg] allowing aliasing in fetch atomics?

Sure, and every C compiler out there can do multiple version code generation such that no code should ever show a benefit with restrict.

The fundamental idea here is that allowing aliasing is a bad semantic and there should be a compelling reason for supporting it.  The higher level models that informed the design of OFI either explicitly prohibit aliasing (MPI RMA and UPC) or their APIs make it impossible (SHMEM).

If there is client that requires this semantic, I'd like to understand why it is permitted to burden OFI rather than requiring that client to do its own buffering.

I am still investing Jianxin's comment on the ticket wherein MPI was affected by this.  I do not understand how a correct MPI program would encounter an issue here.

Jeff

On Wed, Nov 11, 2015 at 11:34 AM, Dave Goodell (dgoodell) <dgoodell at cisco.com<mailto:dgoodell at cisco.com>> wrote:
On Nov 11, 2015, at 2:01 PM, Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>> wrote:
>
> Why do memcpy and memmove both exist?  Why did C99 introduce restrict?  Why does Fortran prohibit aliasing?
>
> I have measured the benefits of restrict semantics w.r.t. vectorization many times in the past, enough that I did not bother to benchmark this specific case.

But you already offered a fix for that issue, which was to just have two versions of the implementation to handle aliased/non-aliased.  The overlap check is pretty cheap.

-Dave




--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/