220 38155 article Path: news.gmane.org!.POSTED!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: memcpy/memset/etc overloads for volatile memory Date: Wed, 23 May 2018 10:31:15 -0300 Lines: 248 Approved: news@gmane.org Message-ID: References: <2300193.1RphyUdPvq@tjmaciei-mobl1> <5B0520CD.30204@gmx.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a1e528056cdf8c8f" X-Trace: blaine.gmane.org 1527082153 11964 195.159.176.226 (23 May 2018 13:29:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 May 2018 13:29:13 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBJO2SXMAKGQEIM6BDSA@isocpp.org Wed May 23 15:29:09 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fLTpD-0002uI-1W for gclcip-std-proposals@m.gmane.org; Wed, 23 May 2018 15:29:07 +0200 Original-Received: by mail-qt0-f200.google.com with SMTP id m20-v6sf20982817qtm.6 for ; Wed, 23 May 2018 06:31:18 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1527082278; cv=pass; d=google.com; s=arc-20160816; b=RYrSJZ9mAMxB0w6nNehVTMLXV82WbdIsJYaLFqN7UAHCDVSGAeepiZEcgu5o0GmkAI f+BFVtWhBVNxafnGSs5nv+DjjxYVo6Ftxtg/qEsjyAL2TMyBcg+1TlQakzhSTFL24eys U4wC5GhlYYTc0wI542yfOvQb2ICfoCCa5XhFjefJvp/ifa9SMBvJTLG3pea/Zixs1Bq+ KK78DsdLT++qgsgA6ihJMy5z/a5yPp91wWJXhGgFYBXNhKg2NGjnfmNMW3WFTW2mCmcf bGaUw/I/N9zT8cf0POFCHAOlGXtSNDcCPEeMWXJwtqjlsmV9RgZgNmB4vdXvwL+mmEwn Xy1A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=nbEC4R4HV/LpObSKsxvH5FXG0cenXnx2/vDD82yTPcw=; b=w0Ldcjn3zfxBjLnJBHCaLaM+Qvkmo5Yb0je6eGpC3P0BLLhzbovbGoGuUX0ZY6R93H eA9mosDobN/kBxWUelBaJ3MZ6B83P+V+I8c+u/Kx2K8giB6X8vzOE5mmpLNbldQ1gZNe u/kKqiotMPgNcHKYX8aYs9pl+VpDvC8NxJjHWg56ZU/nUyZah+fxk9Nqrv2pPeh423l3 p8w0lV7Zz1TEEmu0Yr8//A0kGXvCK56mfpxhs3ndi+CRvlWh1EF5aQPDMjc6J9QTjlzB hzPdil71Bmtivw0FJJiHF6swisZbvvPM6D++J8YdEnz9vb4atQiTKMQCcTGuX1rS2bI0 pq/g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jrtWJmkG; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=nbEC4R4HV/LpObSKsxvH5FXG0cenXnx2/vDD82yTPcw=; b=IaOMWw66gpOBS8hdTOHGfvyeXiKA0t5617LZaUJfRdY6ACLWXyxUV8m3vbrA5Mdshm uLJ8NDtrwEyFDzIuRPnXJ1Tt0/5YtoFJLQs1PbL1LHfwhXfSZYzySVmRQZwtQX9DRkJr noji8jk2m9AMFgm0zKTYhjIInFhjWlvgpZv8VObm6TwyDqePEWfahK0sp7kv/Y9QTdrz S7M5AXSk5Ym8WwzF8k/RxNZUtjMXqU0slGyP3ENODA1AGsAIBh/2v3LusTAxnQdbsbKP zePkIwsICSPY6GKOP/sTjzKeNc92VhrRR8cPwNBKi7ola9ARGFEup/vQCt+tO9TsJqBx ouew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=nbEC4R4HV/LpObSKsxvH5FXG0cenXnx2/vDD82yTPcw=; b=ZMo2cuJpm/zW4jiIPkyMTeUF6R+xbSJc8SM118zSuHzqhx/0jO6wvISR8yj5Q/xTYt tURR3gBav271NRn9QcmD0d/dVxw8SPFMIYDVLQRq3ExvGifQszlbVkMC/K1yOBNSccKH xrT2eC6ASEfuhFfb9VlMd7KhuLTLIlvEXShJ6cthahdIaFrjwtEYCeTWT1pweO09qa1M xJpi4uPWLGRnPQbpnV46wDStszrmcNLD/5uhqVYN4VwViL/4cxJCx4TaQlKxOpkV8oQu X5SB6VEGpgaUfSbvkr1GQH7Swy7iQYFCPxIyapZOk4ULxgYQu3+udmaXJGB0NoJX7Au9 9gmA== X-Gm-Message-State: ALKqPwe3fL2SoUurk2S22ngWXr9d+G1dC5T7ibjq/Rp/pLXy5s3R6Qs0 EVS6UQeOEy87jVtTJGHzYZRDoQ== X-Google-Smtp-Source: AB8JxZpw6qw5gNQeGGrCtjig1jlYfSrMusWqVhxJzsPDEIKB5lala3mrhEWTC1zQasYhURYhmtMD5A== X-Received: by 2002:a0c:fac3:: with SMTP id p3-v6mr1398254qvo.23.1527082277983; Wed, 23 May 2018 06:31:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0c:9653:: with SMTP id 19-v6ls8762636qvy.3.gmail; Wed, 23 May 2018 06:31:17 -0700 (PDT) X-Received: by 2002:a0c:d243:: with SMTP id o3-v6mr2531222qvh.180.1527082277047; Wed, 23 May 2018 06:31:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527082277; cv=none; d=google.com; s=arc-20160816; b=Pd/6jNZ421mo6ZfAKIS4OGeHROiZpl9nzqREfeyymU43grxlzZGwf9op1UuqpC5oJy HVHNJWbbGQedRr+dAJuOq52qwXdJxCGZXx2+a53bxpkG64VEYVoiNV78IF+chb61vUIr JBfQo0jE0A9uAxiR2ae9sdVal+HTHtNQKruRGT11vhKFFlLJty6sXpYhiPhsWQ64l/qg 2TCjku0DjVbrElvJ5SA2yHQIipTfHdVomIBZZLqqXT/UcSI6psU25qsryavmROD77S49 Yo9rhZLI1fNhtuY3CetBPP23OdmQCUyIwaN3MEk73oJ81UyfgCH6F/ThHwc/Qsot/Ti8 ASxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=WqOVjXWdjvo83nWneNKLQTUCcI9yKKIBSfCuOo8YdQ8=; b=BGR3zuGoOS/l6KEbPiGt1Xl6IYZV+gNNICuVDEMD4pp2mrPKpD+phvFrpxhfTI8JLz ELV7medNBFHAkt3z0GKRrV4EymqgMVO9BsGP98LpMBTddwQR9WHM/tbctV2HMlQ1LP45 P4lbXj1pKC6ObborIHvBCLTXC45NL5EvCIZDPqyEuRPuv8cz74wHpVriCSdCFf6Fbavy DQEnhVaAx8NI1rqR0STOO/XdtzdnKHOtY6yTh+zqYm7+8VNnu4YEbLposYWpa+N2zNWB eUkn+GF+zykMmh/PGWSn+7Wni2clLdaTlVhIkFiQSzuitEBLqppbd6kDSHFQAb/mSsUX oWHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jrtWJmkG; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r16-v6sor11305724qkk.35.2018.05.23.06.31.16 for (Google Transport Security); Wed, 23 May 2018 06:31:17 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a37:e10b:: with SMTP id c11-v6mr2287056qkm.253.1527082276478; Wed, 23 May 2018 06:31:16 -0700 (PDT) Original-Received: by 2002:a0c:acac:0:0:0:0:0 with HTTP; Wed, 23 May 2018 06:31:15 -0700 (PDT) In-Reply-To: <5B0520CD.30204@gmx.net> X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jrtWJmkG; spf=pass (google.com: domain of danielgutson@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:38155 Archived-At: --000000000000a1e528056cdf8c8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 5:05 AM, Jens Maurer wrote: > On 05/19/2018 03:24 AM, dgutson . wrote: > > > > > > El vie., 18 de mayo de 2018 21:16, Thiago Macieira > escribi=C3=B3: > > > > On Friday, 18 May 2018 14:13:15 PDT Andrey Semashev wrote: > > > What is "the right thing"? Does it have to be a byte-granular > operation? > > > Does it have to be a forward iteration? Is this behavior the same > on all > > > implementations? You have to answer on all these questions in the > > > standard wording so that everyone can rely on the exact memory > access > > > pattern, which is important in case of volatile memory. > > > > > > If it is not important in your case then you don't need volatile > and > > > hence the overload. > > > > On the other hand, if your memory storage requires a specific > behaviour which > > cannot be standardised, maybe you should implement the copying > directly in > > your code. It's not like bytewise memcpy and memset are particularl= y > difficult > > to implement... > > > > > > Oh yes you don't know how hard it can get... :) avoid prefetching, avoi= d > SSE/vectorization, ensure right order of operations (WC regions). > > So there are lots of details that a too smart toolchain may mess. > > However I will think if an execution policy can help here in copy. I'm > not talking about copying but also memsetting. > > The linux kernel has a nice memcpy_toio/fromio worth to look at. > > "volatile" only conveys a single bit of information, but > modern architectures need a lot more data to actually do > what you want if the "memory" isn't your usual kind of > RAM with a cache hierarchy on top. For example, it might > make a difference whether you copy bytewise or wordwise (and > both options might be useful in different circumstances). > For example, you might need to expressly synchronize writes > with later reads. > > Since you mention the Linux kernel, note that it has a lot > more than just a volatile memcpy to deal with all these > issues. Maybe there's a general enough abstraction hidden > in there somewhere that we could eventually standardize, but > just having a volatile memcpy is neither here nor there. > OK, agree. To provide some context to other readers: (despite these are kernel-space issues, but it should apply) https://lwn.net/Articles/698014/ https://wiki.gentoo.org/wiki/MTRR_and_PAT I think that we could think about some requirements packed in something like a memory_traits, where it would specify: - pointer type (optionally volatile-qualified) - alignment requirements - memory synchronization needs / specifications (an enumerator) - vectorization habilities The challenge is to turn this implementation agnostic enogh so implementations can fill in the values. Then we could provide memory primitives overloads (memcpy, memset, or std::copy, etc.) receiving the memory_traits type as template argument. This is related to transactional memory, std::memory_order, and other fences and memory barriers. So maybe the traits would pack this information plus other bits? > > Jens > > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit https://groups.google.com/a/ > isocpp.org/d/msgid/std-proposals/5B0520CD.30204%40gmx.net. > --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck? --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAFdMc-3mTTm5hUovuzz51TrJKW8HhVRBjt8kf1obvN0g%3D= %2BOMhg%40mail.gmail.com. --000000000000a1e528056cdf8c8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 5:05 AM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
On= 05/19/2018 03:24 AM, dgutson . wrote:
>
>
> El vie., 18 de mayo de 2018 21:16, Thiago Macieira <thiago@macieira.org <mailto:thiago@macieira.org>> escribi=C3=B3:
>
>=C2=A0 =C2=A0 =C2=A0On Friday, 18 May 2018 14:13:15 PDT Andrey Semashev= wrote:
>=C2=A0 =C2=A0 =C2=A0> What is "the right thing"? Does it h= ave to be a byte-granular operation?
>=C2=A0 =C2=A0 =C2=A0> Does it have to be a forward iteration? Is thi= s behavior the same on all
>=C2=A0 =C2=A0 =C2=A0> implementations? You have to answer on all the= se questions in the
>=C2=A0 =C2=A0 =C2=A0> standard wording so that everyone can rely on = the exact memory access
>=C2=A0 =C2=A0 =C2=A0> pattern, which is important in case of volatil= e memory.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> If it is not important in your case then you d= on't need volatile and
>=C2=A0 =C2=A0 =C2=A0> hence the overload.
>
>=C2=A0 =C2=A0 =C2=A0On the other hand, if your memory storage requires = a specific behaviour which
>=C2=A0 =C2=A0 =C2=A0cannot be standardised, maybe you should implement = the copying directly in
>=C2=A0 =C2=A0 =C2=A0your code. It's not like bytewise memcpy and me= mset are particularly difficult
>=C2=A0 =C2=A0 =C2=A0to implement...
>
>
> Oh yes you don't know how hard it can get... :) avoid prefetching,= avoid SSE/vectorization, ensure right order of operations (WC regions). > So there are lots of details that a too smart toolchain may mess.
> However I will think if an execution policy can help here in copy. I&#= 39;m not talking about copying but also memsetting.
> The linux kernel has a nice memcpy_toio/fromio worth to look at.

"volatile" only conveys a single bit of information, but modern architectures need a lot more data to actually do
what you want if the "memory" isn't your usual kind of
RAM with a cache hierarchy on top.=C2=A0 For example, it might
make a difference whether you copy bytewise or wordwise (and
both options might be useful in different circumstances).
For example, you might need to expressly synchronize writes
with later reads.

Since you mention the Linux kernel, note that it has a lot
more than just a volatile memcpy to deal with all these
issues.=C2=A0 Maybe there's a general enough abstraction hidden
in there somewhere that we could eventually standardize, but
just having a volatile memcpy is neither here nor there.

OK, agree.

To provide some conte= xt to other readers: (despite these are kernel-space issues, but it should = apply)

I think that we could think = about some requirements packed in something like a memory_traits, where it = would specify:
=C2=A0 - pointer type (optionally volatile-qualifi= ed)
=C2=A0 - alignment requirements
=C2=A0 - memory syn= chronization needs / specifications (an enumerator)
=C2=A0 - vect= orization habilities

The challenge is to turn this= implementation agnostic enogh so implementations can fill in the values.

Then we could provide memory primitives overloads (= memcpy, memset, or std::copy, etc.) receiving the memory_traits type as tem= plate argument.

This is related to transactional m= emory, std::memory_order, and other fences and memory barriers. So maybe th= e traits would pack this information plus other bits?

<= div>

=C2=A0

Jens

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-propo= sals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.o= rg/d/msgid/std-proposals/5B0520CD.30204%40gmx.net.



--
Who=E2=80=99s got the sweetest disposition?
One gue= ss, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
= Who never shows a bit of temperament?
Who's never wrong but always r= ight?
Who'd never dream of starting a fight?
Who get stuck with a= ll the bad luck?

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3mTTm5= hUovuzz51TrJKW8HhVRBjt8kf1obvN0g%3D%2BOMhg%40mail.gmail.com.
--000000000000a1e528056cdf8c8f-- .