[ofiwg] allowing aliasing in fetch atomics?
jeff.science at gmail.com
Wed Nov 11 12:41:56 PST 2015
It is cheap for contiguous buffers. It may not be cheap for iovecs. I
don't know what the restrictions on iovecs are, but I wonder if the alias
check is O(count^2) for the iov functions. Jim Dinan wrote an optimized
version of alias checking in ARMCI-MPI; it may be better than O(n^2). In
any case, it is added complexity for a questionable use case.
On Wed, Nov 11, 2015 at 12:12 PM, Sur, Sayantan <sayantan.sur at intel.com>
> 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> on behalf of Jeff Hammond <
> jeff.science at gmail.com>
> Date: Wednesday, November 11, 2015 at 12:07 PM
> To: "Dave Goodell (dgoodell)" <dgoodell at cisco.com>
> Cc: "ofiwg at lists.openfabrics.org" <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.
> On Wed, Nov 11, 2015 at 11:34 AM, Dave Goodell (dgoodell) <
> dgoodell at cisco.com> wrote:
>> On Nov 11, 2015, at 2:01 PM, Jeff Hammond <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.
> Jeff Hammond
> jeff.science at gmail.com
jeff.science at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ofiwg