220 37522 <1356e140-2985-4fe7-b9ee-70e40738d1cf@isocpp.org> 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 06:40:15 -0700 (PDT) Lines: 260 Approved: news@gmane.org Message-ID: <1356e140-2985-4fe7-b9ee-70e40738d1cf@isocpp.org> 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/mixed; boundary="----=_Part_22614_1095880020.1522244415132" X-Trace: blaine.gmane.org 1522244295 18297 195.159.176.226 (28 Mar 2018 13:38:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 13:38:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCNZV4UAUMBRBQFW53KQKGQEORCELYA@isocpp.org Wed Mar 28 15:38:11 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1BHG-0004fk-57 for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 15:38:10 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id y43sf1648221uac.13 for ; Wed, 28 Mar 2018 06:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=0nHshDr4PO0g24V8OJne0gp4GFD2YdS24fQITN9nxGg=; b=2NaNTgNTUqwf0EhIdFXm0JmiresPm99t+8Lz7Cwo/wtZ1yen6FQInkIvpAs7u4TamC DwFD/XXppDQwA7DJPoCQhBoNLQFwikSnTtoE6HJnZlUKbVNxdZJ0CrdsLQ1m+UGxk7+4 iSI1RKMFqpW+CrGtOTvLwvXk9QTMO1iUr4+KmEA1IsfL4L7Gg9/Iake+1R2YyLrhKCmG LlcDZwz2kGZkuGZYuLppBhdkf4P5SnyA/avXIN+VSJIFDCeLvykZsS5w0NwociKs09Y3 H+UaYaq0fjabZNynljedLR6xOKj+AwmX+WExuHA78Z+qpKO3EGwg0iWTlmE/9tftgmOX PX7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=0nHshDr4PO0g24V8OJne0gp4GFD2YdS24fQITN9nxGg=; b=bZBiNdcZREsT4A6jEEOPlr7TQ0NFQ9V91Ueq0w0vUNUfZG20Dpvx4ANdU+ybcAW9WK 6V4CXg55wHkRjeWVkaMzOPMXl/Yr/aUQF58Tj40inggJIEqnQ3qV1XV9P/ioo08iWI/V oQ4Ae3chZ4/ye0AW+Jz4pgkU82jdm/YWsKrU66dcYsTgliaIERaO38OLArYy2v4YHmBT B0hQuUcdCNm0X4zRLd+mn25zx6clwfBWpOpkOQVK3WzDscVprEFO/GBjfEx0FEKG99B/ Al/2cQ7OjfaxWzH5QW6UH8MvBZSngiFCZJuRi42xtNdDEWqdoyxCTJNvtQPV/mhTXWeo 5JtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=0nHshDr4PO0g24V8OJne0gp4GFD2YdS24fQITN9nxGg=; b=O7uqR5yDjS8swwvFgrdLIZ2wj9eJXM4Fys8/8h1FFifWAqCK7BlbiD68lrWg9aHOWa 0suetyc+NGiJ81CUKjwhG/faYEAFG50f1TJESehWyy8HMZiA6LXOie5bfbWBnCXbrsRH DF2OM5veF8U3MCR1UKBEuxpYnCaNlvB0k160ZpQ8rzRw1avUhDEMRE6HAIz6/mvspU3I kXSmSaLZ6E/kRppYpmHeid6YAifxUbdFF+iophDSOdoO5d33rvwJZWJQybBsFVsSJWal g59rXErmN4Aw/FzD5ZCzfz/w9LcznbJ6k/ZWowrnTDzRAz1JtY8VKRmEYIXz31wpdk2d qnrA== X-Gm-Message-State: AElRT7EgPcheVjpu42zWLePnPfmH9y8RgOzOupvtzLYS95ADGLyhHpT6 llmqWJVJJvOGsaMM6QZ3lstP2w== X-Google-Smtp-Source: AG47ELt5KnXcy6pwJ2yipZHZ9HFuwzG9psewVh2V56r2P3WwDa+/iafQ1HzSUg50NBVt0qPxBmI0bQ== X-Received: by 10.176.26.139 with SMTP id j11mr8608187uai.103.1522244417366; Wed, 28 Mar 2018 06:40:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.160.67 with SMTP id j64ls2294676vke.21.gmail; Wed, 28 Mar 2018 06:40:16 -0700 (PDT) X-Received: by 10.31.32.148 with SMTP id g142mr1207097vkg.1.1522244415692; Wed, 28 Mar 2018 06:40:15 -0700 (PDT) In-Reply-To: X-Original-Sender: kfitch42@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:37522 Archived-At: ------=_Part_22614_1095880020.1522244415132 Content-Type: multipart/alternative; boundary="----=_Part_22615_576440381.1522244415132" ------=_Part_22615_576440381.1522244415132 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for replying to myself, but I wanted to clarify a few things. First,= =20 I think one of the greatest strengths of C++ is the philosophy of not=20 making you pay for features you don't want/need. While there are legitimate= =20 cases for arguments along the lines of "a conforming implementation=20 could..." those need to be cognizant of reality. In particular the number= =20 of conforming implementations is MUCH smaller than the number of=20 applications using those conforming implementations. Also, the kinds of=20 restrictions I am concerned with are more a function of the application=20 than the platform. Some users of a platform without floating point hardware= =20 (e.g. Arduino) might see software floating point as a huge advantage (in=20 terms of things like ease of development), while others using the same chip= =20 (e.g. the atmega 328p) might see software floating point as a nonstarter=20 due to things like code size and runtime. It should be the goal of the=20 standard to encourage implementations that can gracefully scale in multiple= =20 dimensions (required features, code size , memory usage...) to fit the=20 needs of any given application. Adding non-floating-point methods for=20 dealing with load factor would allow conforming implementations to be=20 written such that applications that don't want to floating point, don't=20 have to use floating point. On Wednesday, March 28, 2018 at 6:22:54 AM UTC-4, Kevin Fitch wrote: > > While a conforming implementation may jump through some hoops to minimize= =20 > the impact of the floating point requirement, the biggest problem is the= =20 > inclusion of ANY floating point. Once a floating point variable has been= =20 > declared and manipulated, the compiler needs to include software floating= =20 > point routines which can be quite large, especially by the standards of= =20 > embedded systems. Also a resource constrained embedded system is exactly= =20 > the place where you will likely need to manipulate max load factor to mee= t=20 > either memory or speed requirements.=20 > > 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 scri= tto: >>> >>> The current interface for dealing with load factor with in unordered=20 >>> containers is one of the few (only?) places in the C++ standard library= =20 >>> where floating point is required even if you didn't "opt-in" to floatin= g=20 >>> point. E.g. see=20 >>> http://en.cppreference.com/w/cpp/container/unordered_set/max_load_facto= r >>> >>> On many embedded systems hardware floating point is unavailable, and=20 >>> using software to emulate it is very expensive. Both in terms of code s= ize=20 >>> and runtime. >>> >>> >> This is the kind of questions you get when cppreference is your only=20 >> source. cppreference is usually good, but having a look at the C++ stand= ard=20 >> wording may sometimes surprise you. Here is the description of the effec= t=20 >> of max_load_factor(z) >> in the C++ standard (emphasis mine): "*May* change the container=E2=80= =99s=20 >> maximum load factor, using z *as a hint*." This means that a conforming= =20 >> implementation on an embedded platform has at least two ways to avoid=20 >> floating point computation at runtime: >> 1) it can just ignore all calls to max_load_factor(). Draconian, but=20 >> keeping a max_load_factor =3D=3D 1.0 (the default) does not require floa= ting=20 >> point at all. >> 2) it can use the value as a hint to compute an approximate integral=20 >> ratio in max_load_factor() and store the ratio, then use the integral ra= tio=20 >> in all other places. All floating point computations would be confined i= n=20 >> the max_load_factor() call, which may even get inlined with no impact at= =20 >> runtime. Even if the call is not inlined, the costs of the floating poin= t=20 >> computations would be very limited, since the typical use-case of=20 >> max_load_factor() is to call it just once at initialization.=20 >> >> --=20 >> You received this message because you are subscribed to a topic in the= =20 >> Google Groups "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this topic, visit=20 >> 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=20 >> 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=20 >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9d4a8ea3-9e= 7d-4851-8b28-5cd67779081a%40isocpp.org=20 >> >> . >> > --=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/1356e140-2985-4fe7-b9ee-70e40738d1cf%40isocpp.or= g. ------=_Part_22615_576440381.1522244415132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for replying to myself, but I wanted to clarify a fe= w things. First, I think one of the greatest strengths of C++ is the philos= ophy of not making you pay for features you don't want/need. While ther= e are legitimate cases for arguments along the lines of "a conforming = implementation could..." those need to be cognizant of reality. In par= ticular the number of conforming implementations is MUCH smaller than the n= umber of applications using those conforming implementations. Also, the kin= ds of restrictions I am concerned with are more a function of the applicati= on than the platform. Some users of a platform without floating point hardw= are (e.g. Arduino) might see software floating point as a huge advantage (i= n terms of things like ease of development), while others using the same ch= ip (e.g. the atmega 328p) might see software floating point as a nonstarter= due to things like code size and runtime. It should be the goal of the sta= ndard to encourage implementations that can gracefully scale in multiple di= mensions (required features, code size , memory usage...) to fit the needs = of any given application. Adding non-floating-point methods for dealing wit= h load factor would allow conforming implementations to be written such tha= t applications that don't want to floating point, don't have to use= floating point.

On Wednesday, March 28, 2018 at 6:22:54 AM UTC-4, K= evin Fitch wrote:
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 float= ing point routines which can be quite large, especially by the standards of= embedded systems. Also a resource constrained embedded system is exactly t= he place where you will likely need to manipulate max load factor to meet e= ither memory or speed requirements.=C2=A0

On Wed, Mar 28, 2018, 3:05 AM Alberto Barbati wrote:
<= /div>
Il giorno marted=C3=AC= 27 marzo 2018 18:06:39 UTC+2, Kevin Fitch ha scritto:
The current interface for dealing with = load factor with in unordered containers is one of the few (only?) places i= n the C++ standard library where floating point is required even if you did= n't "opt-in" to floating point. E.g. see http://en.cppreference.c= om/w/cpp/container/unordered_set/max_load_factor

On ma= ny embedded systems hardware floating point is unavailable, and using softw= are to emulate it is very expensive. Both in terms of code size and runtime= ..


This is the = kind of questions you get when cppreference is your only source. cppreferen= ce is usually good, but having a look at the C++ standard wording may somet= imes surprise you. Here is the description of the effect of max_load_factor= (z)
in the C++ standard (emphasis mine): "May change the co= ntainer=E2=80=99s maximum load factor, using z as a hint." This= means that a conforming implementation on an embedded platform has at leas= t two ways to avoid floating point computation at runtime:
1) it can jus= t ignore 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 al= l other places. All floating point computations would be confined in the ma= x_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 computati= ons 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 Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://grou= ps.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.o= rg.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/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/1356e140-2985-4fe7-b9ee-70e40738d1cf= %40isocpp.org.
------=_Part_22615_576440381.1522244415132-- ------=_Part_22614_1095880020.1522244415132-- .