220 37514 article Path: news.gmane.org!.POSTED!not-for-mail From: Kevin Fitch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Remove floating point requirement for unordered (multi) set/map Date: Wed, 28 Mar 2018 10:22:41 +0000 Lines: 169 Approved: news@gmane.org Message-ID: References: <4c98e549-8f0c-42e5-a054-0234f7cf1e46@isocpp.org> <9d4a8ea3-9e7d-4851-8b28-5cd67779081a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b9883505687663f3" X-Trace: blaine.gmane.org 1522232452 22939 195.159.176.226 (28 Mar 2018 10:20:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 10:20:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCNZV4UAUMBRB7OZ5XKQKGQETOTOOZI@isocpp.org Wed Mar 28 12:20:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f199.google.com ([74.125.82.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f18CE-0005qf-NX for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 12:20:47 +0200 Original-Received: by mail-ot0-f199.google.com with SMTP id l22-v6sf1079174otj.17 for ; Wed, 28 Mar 2018 03:22:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1522232574; cv=pass; d=google.com; s=arc-20160816; b=QqElryWfGYaI6jA4zLw2nO5oExHzdM5TSCAyMTxiAVrpa9Df5og2r5dbOTdJwy7kFP TQ8DkMiQyRWxChyl6II23do9xmJQOHba8jdR2sSCmuc3yYlVtgFSnW9eyN+zKyyY8z3l 8kc/lU0o8fwLRdgkJcPvzdIXZyo1G4E9PRvlWeSLpFyuoOX0wG/guPdg9wcuz0u6/9Wh egzQ6NyGXInRH/l6/1Z5yZTpxFe4vqYeNv9UusiicBTcEBQyP1GreD8O/LYAuW/jY8Fx cISWp0jqFByG5r2u4HhawiM0+OwsWxpysmTjKzvaQwNikIQb1sdy5OrRpMtCdlgPOUh6 nmOg== 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:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=GMVlnuXPY6wq2xm+HrPMRHeIdji29u/LlJKpdc5ZyBY=; b=KhIBJ2cS39anPeqPF4npMIGmw4x0USk4h4PX1QdDl0/Z9ybzVkbgLE0lRWRrwH1WyA jIlsU9O0P/6APSoCiezAYZbwt1LoYbLRjnFG6DJMz68bMAwRH+zSYwT2QcR93ceNiazm 8NUMYZL7OEnquyqoKXpUpzByuU5iY8dCUYBxUSPGWw7OD7Gl5VTlEzjjct+20e0LVTO3 8Yov6iNlZhQ0uoQEVqfMc7o3JwRcBYAhecrlZkOCfUaABHIVsKoBVT/CxPdUHe8/udFv YjJbAwFYkh09B2gx90msj7h3JVqae5y4eTaTLm1PUAK46t+2vYBXnYvhZdRyxvq7tDhC cPyQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dROhcJ7I; spf=pass (google.com: domain of kfitch42@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=kfitch42@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:references:in-reply-to: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=GMVlnuXPY6wq2xm+HrPMRHeIdji29u/LlJKpdc5ZyBY=; b=dgtz2UQCdzOmjKGl7Ybx5MV1Et5SqxhbIenXtlYGd5caftCG7cVvjRTVVSWzOaNv8s RMnhIGECb4qQjqBNd/dvpXiFOS1wTlPrHlbpS69da020shFoGjWYa715HviOBtQZPj0A EmDGlwPikKgY8iO9+N52X1zSB7Nuh3Zs5FzRzMR5sd/z/X2yW50Q6ZEAtvRuWujqd5Fs MPFKcJkUHL4U0umdUdx4TOpUER6dEeMV0m66vZ5Ef+/5ippWILQIzWvU9pi2VNMkwaNB FIdGak10VbyVPFJXMz9X5ZnKaKFGy0MESIPvE19yGQjQH+E2wELRXyqZD9jzbVay/zPu 3c2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=GMVlnuXPY6wq2xm+HrPMRHeIdji29u/LlJKpdc5ZyBY=; b=QJ/fggcbSLk8QMRMaft7DVBN725P7OMcKVU+9PklX2lfplaGDY4OR0OchkcGUe+pLg YuEuXbT/3aIYelh4FQoyXpBB8agIaIbKO/pXeioP6H8ZFluW0Ys6NfrLz3IIpYiHD0xv L0L8nQ9rNbbyQiBuhduDEBiOIo5wmQco31+Msh4uIy+/xpRarLAJh8uk9r7FgT8L3my6 oxrG/eZVw58dCTrGPZA3mRQbXoCRgbtgCXREQSfWguwZuLT/2j5bCb6Jhf0qjDr9CwKX eDwzA9OMU460eR1lmDHLTExGM76MVY61KOgBJ+wBmf4jjKViYTVY/TaravjxDfyd5VAe Rm9g== X-Gm-Message-State: AElRT7EwFOWfZ0AfJ/W45JGF+0mnmpJk5/AHgvk2QjfhoVBXlyjVCAHv RfcF3WaFpxZJ9V+y5PsKM0i1+Q== X-Google-Smtp-Source: AIpwx4+2H6D1SBR9rGJBotNO2GrerNvJ6MZfX+0Fz/Pb9rCnPvsq4eFt8+3QJQub+yPEn7Ks0S9XTA== X-Received: by 2002:a9d:734b:: with SMTP id l11-v6mr4977299otk.48.1522232574143; Wed, 28 Mar 2018 03:22:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:aca:4a49:: with SMTP id x70-v6ls477214oia.12.gmail; Wed, 28 Mar 2018 03:22:52 -0700 (PDT) X-Received: by 10.202.229.75 with SMTP id c72mr1519213oih.65.1522232572825; Wed, 28 Mar 2018 03:22:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522232572; cv=none; d=google.com; s=arc-20160816; b=vd0nJNUeB27CekSkFz5nM5LZ9CxCdgOBIy2G5CyLovvuJ2VyB877Yj7YlrpVRo3eV0 F4ljcuWUaplLl3HyZ7fX/yCoseN9pX7wk9LoRAjLm1Y78RwiZv2fwsIt9oLkDxRMsiGu tulBVI/Zk3LH/465CD/9OW6TBFF9ybS5Yf20zdMJGbvokj9MopFPvrEGVyq40ErLopGy CCYewG2TXnEKh64Ag5d2WXJThhxTN+yN0j44JBSTdIHkGOkMqelBr3JixwjzkHMKuXSk UScAIs4+KLNKVHqHIUeYj9NGASL/0uFzUU2fSt4CWcbY8A7hMi/F5sZhITJnFP0HtwUQ kzGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=IcJM+dTpWs/lpjfVTJ8jtrUFYH91Q1Kh3wQ+PCGPNn0=; b=Xj8r/2WttPi5HA9hdxBQrl/cvV9G03RbCo9oP7SzQXdlEoA+rMcy1vr8L/rGb8G2iz qTfN0j7NYiZecHLcIM0cDo9cnXPyTuz9kMq8i7pSikfhbCBuGZiJKhtyD6GSUw0zsNWM iWNsj9eIC6tXZXARmGm51rMmpdzIJzh8/QdZKllg9RscUDv6GFUz+bJ1wR4lbnMqAoYU VM00heZWZqwWG1YTRz5iYuaEMw+6nOdAhQsHHzYjF/px9H04A27yXjyX6otCPxBX+LLZ FG4Gy5SIeTRdmNsZ8kfQl1/oz+YIlfr9Eqwj3CNkcPPsXyWaCGlLFAaOgIXSIXusF9j8 M3ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dROhcJ7I; spf=pass (google.com: domain of kfitch42@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=kfitch42@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 w11-v6sor1308015otg.41.2018.03.28.03.22.52 for (Google Transport Security); Wed, 28 Mar 2018 03:22:52 -0700 (PDT) Received-SPF: pass (google.com: domain of kfitch42@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a9d:73d9:: with SMTP id m25-v6mr1891269otk.376.1522232572084; Wed, 28 Mar 2018 03:22:52 -0700 (PDT) In-Reply-To: <9d4a8ea3-9e7d-4851-8b28-5cd67779081a@isocpp.org> X-Original-Sender: kfitch42@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dROhcJ7I; spf=pass (google.com: domain of kfitch42@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=kfitch42@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:37514 Archived-At: --000000000000b9883505687663f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While a conforming implementation may jump through some hoops to minimize the impact of the floating point requirement, the biggest problem is the inclusion of ANY floating point. Once a floating point variable has been declared and manipulated, the compiler needs to include software floating point routines which can be quite large, especially by the standards of embedded systems. Also a resource constrained embedded system is exactly the place where you will likely need to manipulate max load factor to meet either memory or speed requirements. On Wed, Mar 28, 2018, 3:05 AM Alberto Barbati wrote: > Il giorno marted=C3=AC 27 marzo 2018 18:06:39 UTC+2, Kevin Fitch ha scrit= to: >> >> The current interface for dealing with load factor with in unordered >> containers is one of the few (only?) places in the C++ standard library >> where floating point is required even if you didn't "opt-in" to floating >> point. E.g. see >> http://en.cppreference.com/w/cpp/container/unordered_set/max_load_factor >> >> On many embedded systems hardware floating point is unavailable, and >> using software to emulate it is very expensive. Both in terms of code si= ze >> and runtime. >> >> > This is the kind of questions you get when cppreference is your only > source. cppreference is usually good, but having a look at the C++ standa= rd > wording may sometimes surprise you. Here is the description of the effect > of max_load_factor(z) > in the C++ standard (emphasis mine): "*May* change the container=E2=80=99= s > maximum load factor, using z *as a hint*." This means that a conforming > implementation on an embedded platform has at least two ways to avoid > floating point computation at runtime: > 1) it can just ignore all calls to max_load_factor(). Draconian, but > keeping a max_load_factor =3D=3D 1.0 (the default) does not require float= ing > point at all. > 2) it can use the value as a hint to compute an approximate integral rati= o > in max_load_factor() and store the ratio, then use the integral ratio in > all other places. All floating point computations would be confined in th= e > max_load_factor() call, which may even get inlined with no impact at > runtime. Even if the call is not inlined, the costs of the floating point > computations would be very limited, since the typical use-case of > max_load_factor() is to call it just once at initialization. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/kGHAX6um__c/= unsubscribe > . > To unsubscribe from this group and all its topics, 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/9d4a8ea3-9e7= d-4851-8b28-5cd67779081a%40isocpp.org > > . > --=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/CAN5YuFb%2BGdsijsjbrm6xx2ASpUNpubApEeVK3MQc1y%3D= NtV8JiQ%40mail.gmail.com. --000000000000b9883505687663f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While a conforming implementation may jump through s= ome hoops to minimize the impact of the floating point requirement, the big= gest problem is the inclusion of ANY floating point. Once a floating point = variable has been declared and manipulated, the compiler needs to include s= oftware floating point routines which can be quite large, especially by the= standards of embedded systems. Also a resource constrained embedded system= is exactly the place where you will likely need to manipulate max load fac= tor to meet either memory or speed requirements.=C2=A0

On Wed, Mar 28, 2018, 3:05 AM Alberto Barbat= i <albertobarbati@gmail.com<= /a>> wrote:

This is the kind o= f questions you get when cppreference is your only source. cppreference is = usually good, but having a look at the C++ standard wording may sometimes s= urprise you. Here is the description of the effect of max_load_factor(z) in the C++ standard (emphasis mine): "May change the containe= r=E2=80=99s maximum load factor, using z as a hint." This means= that a conforming implementation on an embedded platform has at least two = ways to avoid floating point computation at runtime:
1) it can just igno= re all calls to max_load_factor(). Draconian, but keeping a max_load_factor= =3D=3D 1.0 (the default) does not require floating point at all.
2) it = can use the value as a hint to compute an approximate integral ratio in max= _load_factor() and store the ratio, then use the integral ratio in all othe= r places. All floating point computations would be confined in the max_load= _factor() call, which may even get inlined with no impact at runtime. Even = if the call is not inlined, the costs of the floating point computations wo= uld be very limited, since the typical use-case of max_load_factor() is to = call it just once at initialization.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-pr= oposals/kGHAX6um__c/unsubscribe.
To unsubscribe from this group and all its topics, 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-propo= sals/9d4a8ea3-9e7d-4851-8b28-5cd67779081a%40isocpp.org.

--
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/CAN5YuFb%2BGd= sijsjbrm6xx2ASpUNpubApEeVK3MQc1y%3DNtV8JiQ%40mail.gmail.com.
--000000000000b9883505687663f3-- .