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]>> 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>
> 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>
>
> Or Skype for Business (Lync):
> 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>
> >
>
> 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>
>
> IEC Code of Conduct:
>
> 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>
>
> 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>
>
> 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/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>
>
> 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>
>
> 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>
>
> -
>
> 3. Any other business
> Reflector
> 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/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>
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>