220 38161 <1802764.OhHZxBL3Cz@tjmaciei-mobl1> article Path: news.gmane.org!.POSTED!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: memcpy/memset/etc overloads for volatile memory Date: Wed, 23 May 2018 13:05:07 -0300 Lines: 58 Approved: news@gmane.org Message-ID: <1802764.OhHZxBL3Cz@tjmaciei-mobl1> References: <1695197.Kxq4M8jdJr@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1527091386 23165 195.159.176.226 (23 May 2018 16:03:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 May 2018 16:03:06 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBOFCS3MAKGQEY37MWSQ@isocpp.org Wed May 23 18:03:02 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fLWE9-0005r1-Iv for gclcip-std-proposals@m.gmane.org; Wed, 23 May 2018 18:03:01 +0200 Original-Received: by mail-qk0-f198.google.com with SMTP id o97-v6sf12050829qkh.14 for ; Wed, 23 May 2018 09:05:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1527091512; cv=pass; d=google.com; s=arc-20160816; b=RR56NWLN98OPKeROqRda5ajnpbjAhheD/XZ2INa1rkkb9uelqiVawoZA0wL0NwFmPb zaZftvLsdeJWaKtPBD7J1mdiAS0eeGlxXTxKGCE9eOtvUXV3gAIcrOL1SUUuXRgAoQ6e jSf8n9oMJxvKEH7ZqqGu3FlpB7CqvnSZLNxiJ2jdPsxJjNvdo8CJPdy8fU98rL7v6Q5N uHGuhtJ2NoSB2Ydy+Y1iiKl18AYUFX1huwJN4Ar40Ba2UGyHiROFTWg8Ctq4UfZ9Tyty 6vzpj8pp/EzvQrDZlRMQic6+Y7+aG85ErDQG+hbYkHK7q4O4vPREtPJywYk6rAiL1ox+ 60rw== 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:mime-version:references :in-reply-to:message-id:date:subject:to:from :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=GbrJN+PR3Ldv+K+1imfzBp3RqJ4I2+u2BJ1QBMmLzmI=; b=UrRqLPqQzMB7TSeWpMOlTuagt0DvnApFBTYj+gZ1IwPgKduuGv/kiHQ7o7Ip9xnaPu 9LXUF1cti0I9gbPv4URv+3V6P2MFiwehMNZg3Pzd2VmTXnvJjFzYbjUawZZGBdjOnXZb YmyFQX20Icwc5ERNZ+A1dVc83zzC6dm6PEFiTimSwSFdShCYbho8QQpl8FMLY47a12Z4 N1C7Cj4u4cojqqBjmBLbgYWMoAWmdVRzHpMuqXyOH0Ao0dKzVkn6XOKp808z7HVy7qsP j0BlQ2LBiqqncMCjCV7tSo+laJTkEKX/g5oZI0KwNQhRbYKBbShYyqNk1Kc6kT1KouFP mKRg== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 2001:19f0:5:2221::1:3 as permitted sender) smtp.mailfrom=thiago@macieira.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :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=GbrJN+PR3Ldv+K+1imfzBp3RqJ4I2+u2BJ1QBMmLzmI=; b=J3IwVUuc9s5kzajStgAeWqIy8g91wQZSiePwLmj18a4m+fQbUg4vgnrk8hBrEBnFw6 jqWZ5ZoxbDojUUbgL/8ibHqK6yQoexne2qMHhrmbC/jVGoRY3yrbFqbKeF/imPviZfIX YAzDPzChR1OUQg7OBH/s08DD2mJ1/JHkxxZDZN9I4IIFEed4gutp2m+s0ZAzROIfTmk9 ZOcka7bMzbiNdtcIpopC+a0ZpJyb/pZLNwjsIOo/utt1k+162xGxVG6P2Sf+lQzRYZfk opPzQDD6kW/YTddyoT2KXAmzoY5/A4Xz1q7xngTGQlDnw9093jLYMgZijEE+zluTR9z3 2V0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version: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=GbrJN+PR3Ldv+K+1imfzBp3RqJ4I2+u2BJ1QBMmLzmI=; b=ChwbyKtgWz+SSWjGz1QWquTQAjyzutObBg3D68DW1M99ES/vXlo+hZnbHvoWhOnfO6 q8s501DlucPkxojkp12TmkeDZSbE/jLabdktaYKC8h5/YnlQMr+SFxekKrXVsrcuxPSQ Mc1UFmzZTrfycZ1t1Cv5zdalRIWKB/s1yfXRnnArQIpGWw3CQSRlQnlXEWiWamYlggPH Vo2D7vZd8t+4ZboPYGDT/tuFeXhlkN7lds4X7SunWh9HX4Ox1RSRe8DMSMOEO/4NVr08 amqJ/S677pxP5CvQujyE9TMeYqSr7TLZfdbH09COPLSxUf5QaD7587qJ5IOqXIFZO17/ jLRg== X-Gm-Message-State: ALKqPwev2KqJ9btpvFgTX7VdJNLlrytj1JbOw6bCUGcLEpyENpURSaw/ TwT4Zc+19EY3KuPfN+BWm0FW9w== X-Google-Smtp-Source: AB8JxZpfZ4m0tuB8vAQXAUbsexY4QVDK03FhEyECXobWN3+kO2l3jIdKXuOWiZk6BGrRmSN5eS6CLA== X-Received: by 2002:ac8:68a:: with SMTP id f10-v6mr1845785qth.9.1527091512679; Wed, 23 May 2018 09:05:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:ac8:2ec5:: with SMTP id i5-v6ls10092444qta.1.gmail; Wed, 23 May 2018 09:05:11 -0700 (PDT) X-Received: by 2002:ac8:1725:: with SMTP id w34-v6mr3383113qtj.64.1527091511848; Wed, 23 May 2018 09:05:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527091511; cv=none; d=google.com; s=arc-20160816; b=zOVwVhclGCRNin6d/g3ePORaX7E5e2GjKmCiWTJ7NMMGpTRTt9RnOWAz3b5Bv8pfJl xAV707mx+4tTgVhqr8r6QBDPKpCSEgRAHUaB+ldahBSnsMmkbFLRwIuDtT55gL8N6ciH ITuuA6CwlpUVVzVSY0CVEOkDQzIvFTfon5+aXQ14Ezc51t7bP7ptgaSn6uRDSvJg++YW +shrvraHp3EpE48PFXkdy4+dihFFe+X0B/wuLgYgkgucg122WH56XomzATd+drx6b9uP 2mjrOfW+XvMCU4sA1Kr0szkRD6PvHpILYmTwfD6lb+IO9T3ugcZclYpwBgMLaPHVPxKZ Z0sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:arc-authentication-results; bh=9Lj5676nJuvii1rZg0q+3pTEnM86mDrGniAW4D1LMi4=; b=g/VRo6EfrpOHAFK9oEUw4mybQWX3R7Uqd66fYbU+0yfFJMZpx1AcX+52wOtBZmpwMq 9HhxZ4C7GEJDWIIV6fs2cfsg3BgzIwhGYkkbgqBz6DXA+FkMn4DafZsKCxDyuJN09qwo Uy6OVDYnv6Qx4+vYlNffpyuxCNa4SGQUzqYi9V40xj2vpFWHHxQrSXvYfarPTGS06lp4 HvlixEHz9s3eUGY7o4mZE+j7z43B8pMh5nf2peJ70043k/Igyp3UZSgRRBIyp1HU80O3 SK7Yz3dMyTrUbLKEmfD3CxXPqEHA8b+spZKGv05wG1rj8lzdCEPLCIh4ZmvLd9ia16us lQuQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 2001:19f0:5:2221::1:3 as permitted sender) smtp.mailfrom=thiago@macieira.org Original-Received: from smtp.macieira.info (smtp.macieira.info. [2001:19f0:5:2221::1:3]) by mx.google.com with ESMTPS id v7-v6si1797522qve.259.2018.05.23.09.05.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 09:05:11 -0700 (PDT) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 2001:19f0:5:2221::1:3 as permitted sender) client-ip=2001:19f0:5:2221::1:3; Original-Received: from tjmaciei-mobl1.localnet (189-69-95-251.dsl.telesp.net.br [189.69.95.251]) by smtp.macieira.info (Postfix) with ESMTPSA id 6D328EDC0 for ; Wed, 23 May 2018 09:05:10 -0700 (PDT) In-Reply-To: X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 2001:19f0:5:2221::1:3 as permitted sender) smtp.mailfrom=thiago@macieira.org 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:38161 Archived-At: On Wednesday, 23 May 2018 12:33:02 -03 dgutson . wrote: > > Or, like I said, you can roll out your own memcpy or memset (which are > > quite > > trivial) if you have specific requirements. > > I propose to leave "triviality" out of the discussion, since this can get > combinatoric complex, and there is no metric of "triviality" either. Sorry, but my point is that to write: for (size_t i = 0; i < n; ++i) dst[i] = src[i]; is quite trivial and does implement the most basic memcpy for byte-wise, volatile data. This is what such a generic, volatile memcpy would do and I see no use in providing it in the standard library since it can't differ from that. There is no room for optimisation to be applied, unlike the normal memcpy. When you start adding requirements, this gets out of hand. The permutations will explode: - memory fence or no? - how often should the memory fence be done? Is it per time, per address or per cumulative bytes copied? - which memory fence (load, store or full)? - which pointer controls the fence, source or destination? - can it read more than two bytes at a time? If so, must reads be aligned? - can it read four bytes at a time? If so, must 4-byte reads be aligned? - can it read eight... sixteen, thirty-two, sixty four? - can misaligned reads cross a cacheline? can they cross a page boundary? - repeat the read questions by replacing with write - can it read more than one element (whichever size) before writing it (i.e., can it pipeline)? - should the stores use non-temporal cache hints? Which cache level? My point is that the moment you need anything from that list above, you should roll out your own code, for your own purposes. The operating system kernels can have shared functions for this because they know which hardware they're going to run on and thus what types of volatile memory behaviour they're going to face. That is not the case for the C++ standard library. However, if you want to provide this volatile memcpy as a library, you're welcome to. You can limit your needs to modern architectures or just one (your employer's), which should cut down the permutations from millions of possibilities to just tens. The problem becomes manageable. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center -- 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/1802764.OhHZxBL3Cz%40tjmaciei-mobl1. .