C++ Logo

SG14

Advanced search

Subject: Re: SG14 Sept 8 (Games) zoom call
From: Matt Bentley (mattreecebentley_at_[hidden])
Date: 2021-09-10 19:44:30


I think constexpr-everything will also make debugging more difficult, at
least in the short term until people realise we need an option to turn
it off on any given build.
Good to see that you've put this forward, I agree that ranges is likely
to make this more visible - which is why I'm not touching it with a
barge pole right now. Though doubtless it's intent is very positive.

On 11/09/2021 12:39 am, John McFarlane wrote:
> I raised this in P1832R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1832r0.html>
> and I'm still hopeful that there are implementer solutions to the
> problem. There should be no need to force users to step into
> someone else code while debugging their own - or incurring all the costs
> that this ability incurs. I'm hoping the considerable overhead of ranges
> will make this issue more prominent.
>
> On Fri, 10 Sept 2021 at 01:37, Matt Bentley via SG14
> <sg14_at_[hidden] <mailto:sg14_at_[hidden]>> wrote:
>
> Since I couldn't attend, a minor note for Patrice's doc, in the
> debug/release scenario:
>
> my take, garnered from watching the various twitter/reddit
> conversations
> that've cropped up around game dev in c++, is that the main problem is
> the standard and the compilers tend to ignore the fact that many of the
> 'high level' constructs do not optimize at all in debug mode. The
> concept repeated by many is that -O2 will solve things. But for games
> and any other field involving very large executables which require
> running in realtime debug mode, it doesn't.
> It is more of an attitudinal disfunction than an actual technical
> problem.
>
> Promoting std::fill over memset is one such example.
> Take using std::fill vs memset to zero memory under GCC8:
>
> Results in debug mode (-O0):
> =============================
>
> -----------------------------------------------------
> Benchmark              Time           CPU Iterations
> -----------------------------------------------------
> memory_filln       87209 ns      87139 ns       8029
> memory_fill        94593 ns      94533 ns       7411
> memory_memset       8441 ns       8434 ns      82833
>
>
>
> Results in -O3 (clang at -O2 is much the same):
> ================================================
>
> -----------------------------------------------------
> Benchmark              Time           CPU Iterations
> -----------------------------------------------------
> memory_filln        8437 ns       8437 ns      82799
> memory_fill         8437 ns       8437 ns      82756
> memory_memset       8436 ns       8436 ns      82754
>
>
> This is the same in clang. Clang optimizes to memset at -O2, GCC8 at
> -O3. That's a factor of ten difference in speed until you reach -O3.
> Granted memset is very limited in what values it can propagate.
>
> But the way that CPP is often communicated is that, no, you should use
> these high level constructs, not these terrible 'c-style' functions,
> and
> there will be zero cost - which is not true.
>
> I often see vector naively promoted as being 'a better array' in a
> similar way, which of course it's not, their usages are different.
>
> Ideally students of C++ coming into the industry should understand what
> creates performance - not coming from a viewpoint that high level is
> better, and then having to have those attitudes torn asunder by
> industry
> vets. The effort to promote C++ as a high level language with zero-cost
> abstractions does not gel with the games industry, or most of the
> industries focussed around performance. My reading on the general
> perception is that the direction which C++ is heading (high level
> abstractions attempting to cater to every scenario) does not match the
> expectations of the workforce.
>
>
> On 9/09/2021 7:57 am, Michael Wong via SG14 wrote:
> > Thanks to Rene for Chairing.
> >
> > On Tue, Sep 7, 2021 at 10:53 AM Michael Wong
> <fraggamuffin_at_[hidden] <mailto:fraggamuffin_at_[hidden]>
> > <mailto:fraggamuffin_at_[hidden] <mailto:fraggamuffin_at_[hidden]>>>
> wrote:
> >
> >     Topic: SG14 Low Latency Monthly
> >
> >     This meeting is focused on Games .
> >
> >     Hi,
> >
> >     Michael Wong is inviting you to a scheduled Zoom meeting.
> >
> >     Topic: SG14 monthly
> >     Time: 2nd Wednesdays 02:00 PM Eastern Time 1800 UTC (US and
> Canada)
> >          Every month on the Second Wed,
> >
> >
> >     Join from PC, Mac, Linux, iOS or Android:
> >
> https://iso.zoom.us/j/93151864365?pwd=aDhOcDNWd2NWdTJuT1loeXpKbTcydz09
> <https://iso.zoom.us/j/93151864365?pwd=aDhOcDNWd2NWdTJuT1loeXpKbTcydz09>
> >
>  <https://iso.zoom.us/j/93151864365?pwd=aDhOcDNWd2NWdTJuT1loeXpKbTcydz09 <https://iso.zoom.us/j/93151864365?pwd=aDhOcDNWd2NWdTJuT1loeXpKbTcydz09>>
> >          Password: 789626
> >
> >     Or iPhone one-tap :
> >          US: +12532158782,,93151864365# or +13017158592,,93151864365#
> >     Or Telephone:
> >          Dial(for higher quality, dial a number based on your current
> >     location):
> >              US: +1 253 215 8782 or +1 301 715 8592 or +1 312 626
> 6799 or +1
> >     346 248 7799 or +1 408 638 0968 or +1 646 876 9923 or +1 669
> 900 6833
> >       or 877 853 5247 (Toll Free)
> >          Meeting ID: 931 5186 4365
> >          Password: 789626
> >          International numbers available:
> > https://iso.zoom.us/u/abRrVivZoD
> <https://iso.zoom.us/u/abRrVivZoD> <https://iso.zoom.us/u/abRrVivZoD
> <https://iso.zoom.us/u/abRrVivZoD>>
> >
> >     Or Skype for Business (Lync):
> > https://iso.zoom.us/skype/93151864365
> <https://iso.zoom.us/skype/93151864365>
> >     <https://iso.zoom.us/skype/93151864365
> <https://iso.zoom.us/skype/93151864365>>
> >
> >     Agenda:
> >
> >     1. Opening and introduction
> >
> >     ISO Code of Conduct
> >     <
> >
> https://isotc.iso.org/livelink/livelink?func=ll&objId=20882226&objAction=Open&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dll%26objId%3D20158641%26objAction%3Dbrowse%26viewType%3D1
> <https://isotc.iso.org/livelink/livelink?func=ll&objId=20882226&objAction=Open&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dll%26objId%3D20158641%26objAction%3Dbrowse%26viewType%3D1>
> >
>  <https://isotc.iso.org/livelink/livelink?func=ll&objId=20882226&objAction=Open&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dll%26objId%3D20158641%26objAction%3Dbrowse%26viewType%3D1 <https://isotc.iso.org/livelink/livelink?func=ll&objId=20882226&objAction=Open&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dll%26objId%3D20158641%26objAction%3Dbrowse%26viewType%3D1>>
> >     >
> >
> >     ISO patent policy.
> >
> https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2
> <https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2>
> >
>  <https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2 <https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm?nodeid=6344764&vernum=-2>>
> >
> >     IEC Code of Conduct:
> >
> > https://www.iec.ch/basecamp/iec-code-conduct-technical-work
> <https://www.iec.ch/basecamp/iec-code-conduct-technical-work>
> >     <https://www.iec.ch/basecamp/iec-code-conduct-technical-work
> <https://www.iec.ch/basecamp/iec-code-conduct-technical-work>>
> >
> >     WG21 Code of Conduct:
> >
> >
> https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures
> <https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures>
> >
>  <https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures <https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures>>
> >
> >     1.1 Roll call of participants
> >
> >     1.2 Adopt agenda
> >
> >     1.3 Approve minutes from previous meeting, and approve publishing
> >       previously approved minutes to ISOCPP.org
> >
> >     1.4 Action items from previous meetings
> >
> >     2. Main issues (125 min)
> >
> >     2.1 General logistics
> >
> >     Future meeting plans
> >
> >          July 14, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> >          Aug 11, 2021 02:00 PM ET/1800 UTC: Games Cancelled
> >
> >          Sep 8 , 2021 02:00 PM ET/1800 UTC: Games
> >          Oct 13, 2021 02:00 PM ET/1800 UTC: Embedded
> >          Nov 10, 2021 02:00 PM ET/1800 UTC: DST change/cancelled
> >          Dec 8, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> >     2.2 Paper reviews
> >
> >     Discussion about Games topics:
> >
> >     P2388R1 - Minimum Contract Support: either Ignore or
> Check_and_abort
> >
>  <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r1.html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r1.html>>
> >
> >   P2388R1:
> > What is stopping static analyzers
> > want to allow programmers to declare good contract annotations in 23
> > so that in 26 tools can have annotations
> > min annotations
> > need from std:
> > portable notatoion
> > type system checking declared expre
> > guarantee that predicates can be rt evaluated if needed
> > ack disappearing side effects in declared expr
> > ack possibility of halting the program
> >
> > ignore mode
> > check and abort: noexcept by default
> > allow compiler to provide a way to install contract violation
> handler
> > but not require it: how about a compiler flag ?
> > possible to have pre/post-condition in hdr or cpp file: require from
> > first declaration; they are not part of type system
> > builtin unreachable is being standadized
> >
> > side effects in predicates as no way to be sure it is side effect
> free:
> > allowed but discouraged, may be evaluated, may be evaluated twice
> > ub if evaluation of one affects the other
> >
> > how does it interact with constexpr? constexpr fn with non-constexpr
> > predicate
> >
> > postconditions:
> > eval after destructors of local objects called
> > eval before destructors of function
> > referred objects values are those ...
> >
> > check value of parameter at the point it was passed, so need to
> make a
> > copy of the parameter in case parameter is changed during execution
> > if copy is made implicitly, then compiler can only optimize copy
> in some
> > cases by eliding
> > in ignore mode, you can avoid the copy
> >
> > precondition failure reported on caller side, rather then
> calleebut its
> > not always possible because we can not guarantee
> >
> > dropped from C++20 contracts
> > assertion levels
> > guaranteed non-evaluation of predicates (axiom)
> > continuation mode
> > interface
> >
> > Retained from C++20 contracts
> > contract annotations on first declaration
> > ODR identical annotations on overriding functions
> > access to private and protected members from predicates
> >
> > use case weher you want to widen and narroe the derived class
> contracts
> > and caller needs to be able to depend on the post condition being
> true
> > if you want to check you really need to check both the pre and post
> > conditions on the interface fn you call through so if you are
> calling
> > through a ptr to base , the caller is going to depend on the fact
> that
> > the post conditions and the pre and post conditions of the ptr
> you are
> > calling through are checked and the callee is going to depend on the
> > fact that the pre and post conditions it declares are going to be
> > checked. Crrectly checking the right things when they can be
> different
> > is complicated
> > So MVP approach is just require them to be the same for now and
> explore
> > what can be done later to be different
> >
> > Not addresign overriding fn issue, then this proposal will survive.
> >
> > Feedback on ignore mode, and const values
> > anything concern you on this approach?
> > in safety critical setting, might not be annotations we want them
> to be
> > not affecting too deeply the rest of the functions: can make it
> uniform
> > by referrng to a function input and output by value and are not
> const-able
> >
> > idiomatic constructor with operator plus trick would have to be
> rewritten?
> >
> >
> >
> >
> >
> >
> >
> >
> >     Patrice's WIP on Games issues.
> >
> > Making C++ better for Game Developers: some Request
> > based on survey from local Montreal game companies
> > general principles:
> > simplify C++
> > make it teachable due to high turn over
> > avoid negative perf impact
> > debugging matters
> >
> > how to split these 30 proposals?
> >
> > similar to freestanding, chop into many small pieces
> > but also good to have an omnibus paper before the split
> > do a few feature per meeting, or wait until January for the next
> Games focus
> > should address Arthur's feedback and generate V2
> > some are low latency and can be in Dec meeting
> > updates coming
> >
> >     Finance topics from July 14, 2021.
> >
> > https://lists.isocpp.org/sg14/2021/06/0636.php
> <https://lists.isocpp.org/sg14/2021/06/0636.php>
> >     <https://lists.isocpp.org/sg14/2021/06/0636.php
> <https://lists.isocpp.org/sg14/2021/06/0636.php>>
> >
> > https://lists.isocpp.org/sg14/2021/07/0642.php
> <https://lists.isocpp.org/sg14/2021/07/0642.php>
> >     <https://lists.isocpp.org/sg14/2021/07/0642.php
> <https://lists.isocpp.org/sg14/2021/07/0642.php>>
> >
> >     2.2.1 any other proposal for reviews?
> >
> >     Deterministic Exception for Embedded by James Renwick
> >
> https://www.pure.ed.ac.uk/ws/portalfiles/portal/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf
> <https://www.pure.ed.ac.uk/ws/portalfiles/portal/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf>
> >
>  <https://www.pure.ed.ac.uk/ws/portalfiles/portal/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf <https://www.pure.ed.ac.uk/ws/portalfiles/portal/78829292/low_cost_deterministic_C_exceptions_for_embedded_systems.pdf>>
> >
> >     Freestanding?
> >
> >     SG14/SG19 features/issues/defects:
> >
> >
> https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0
> <https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0>
> >
>  <https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0 <https://docs.google.com/spreadsheets/d/1JnUJBO72QVURttkKr7gn0_WjP--P0vAne8JBfzbRiy0/edit#gid=0>>
> >
> >     2.3 Domain-specific discussions
> >
> >     2.3.1 SIG chairs
> >
> >         - Embedded Programming chairs: Ben Craig, Wouter van
> Ooijen and Odin
> >         Holmes, John McFarlane
> >
> >         - Financial/Trading chairs: Staffan
> >     TjernstrÃÃâ€
> >     ÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ÃƒÆ’ƒâ€
> >
>  ÃƒÆ’¢â‚¬â„¢ÃƒÆ’‚¶m,
> >     Carl
> >     Cooke, Neal
> >     Horlock,
> >         Mateusz Pusz, Clay Trychta,
> >
> >
> > Richard Smith to take over paper
> >
> >         - Games chairs: Rene Riviera, Guy Davidson and Paul Hampson,
> >     Patrice Roy
> >
> >         - Linear Algebra chairs: Bob Steagall, Mark Hoemmen, Guy
> Davidson
> >
> >     2.4 Other Papers and proposals
> >
> >     2.5 Future F2F meetings:
> >
> >     2.6 future C++ Standard meetings:
> >
> https://isocpp.org/std/meetings-and-participation/upcoming-meetings
> <https://isocpp.org/std/meetings-and-participation/upcoming-meetings>
> >
>  <https://isocpp.org/std/meetings-and-participation/upcoming-meetings <https://isocpp.org/std/meetings-and-participation/upcoming-meetings>>
> >
> >     -
> >
> >     3. Any other business
> >     Reflector
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
> >     <https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>>
> >     As well as look through papers marked "SG14" in recent standards
> >     committee
> >     paper mailings:
> > http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/
> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/>
> >     <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/
> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/>>
> > http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/
> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/>
> >     <http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/
> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/>>
> >
> >     Code and proposal Staging area
> > https://github.com/WG21-SG14/SG14
> <https://github.com/WG21-SG14/SG14>
> <https://github.com/WG21-SG14/SG14 <https://github.com/WG21-SG14/SG14>>
> >     4. Review
> >
> >     4.1 Review and approve resolutions and issues [e.g., changes
> to SG's
> >     working draft]
> >
> >     4.2 Review action items (5 min)
> >
> >     5. Closing process
> >
> >     5.1 Establish next agenda
> >
> >     5.2 Future meeting
> >
> >          Oct 13, 2021 02:00 PM ET/1800 UTC: Embedded
> >
> >          Nov 10, 2021 02:00 PM ET/1800 UTC: DST change/cancelled
> >          Dec 8, 2021 02:00 PM ET/1800 UTC: Finance/Low Latency
> >
> >     Kind Rgds
> >
> >
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden] <mailto:SG14_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
> >
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden] <mailto:SG14_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
>


SG14 list run by sg14-owner@lists.isocpp.org

Older Archives on Google Groups