C++ Logo


Advanced search

Subject: Re: SG14 Aug 14 Zoom meeting
From: Michael Wong (fraggamuffin_at_[hidden])
Date: 2019-08-14 14:42:56

On Tue, Aug 13, 2019 at 8:19 PM Michael Wong <fraggamuffin_at_[hidden]> wrote:

> Topic: SG14 Low Latency Monthly
> Join URL: https://iso.zoom.us/j/406503386
> Time: 2:00 PM Eastern Time (US and Canada)
> Apr 17, 2019 2:00 PM
> May 8, 2019 2:00 PM
> Jun 12, 2019 2:00 PM
> Jul 10, 2019 2:00 PM
> Aug 14, 2019 2:00 PM
> Sep 11, 2019 2:00 PM
> Oct 9, 2019 2:00 PM
> Please download and import the following iCalendar (.ics) files to
> your
> calendar system.
> Monthly:
> https://iso.zoom.us/meeting/406503386/ics?icsToken=8d46c9bf03730dd553cc4f9306ceedfc45867014725c0aca989cb39d9602ae7c
> Join from PC, Mac, Linux, iOS or Android: https://iso.zoom.us/j/406503386
> Or iPhone one-tap :
> US: +16468769923,,406503386# or +16699006833,,406503386#
> Or Telephone:
> Dial(for higher quality, dial a number based on your current
> location):
> US: +1 646 876 9923 or +1 669 900 6833 or +1 408 638 0968 or 877
> 369 0926 (Toll Free) or 877 853 5247 (Toll Free)
> Meeting ID: 406 503 386
> International numbers available: https://zoom.us/u/abhaIjFKLZ
> Or Skype for Business (Lync):
> https://iso.zoom.us/skype/406503386
> Agenda:
> 1. Opening and introductions
> 1.1 Roll call of participants
 Ben Saks, Ben Craig, Hubert Tong, Javier Cabezas, John McFarlane, Marco
Foco, Matt Harrington, Matthew BUtler, Ronen Friedman, Staffan Tj. Michael

> 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
> Review Cologne results.
Flat map : P1727 in LEWG, deferred to LWG after C++20, some concerns about
unordered maps, Zach Laine driving, may need range component maturaity

Deterministic exception: EWG presented by Herb:
1. continuing on exception violation
2. memory exhaustion

EWG polls had some split results, Bjarne, Daveed, Chandler were strongly
against the out of memory aspects, and possibly implementation concerns

Affinity: high level affinity looks likely to move ahead
low level proposal topology discovery that is more lists like, instead tree

Niall papers on elsewhere/unreacheable memory:
P1026 next step go to SG1 for more confirmation before a SG is started

Linear Algebra Sg14 F2F;
both proposals were passed to LEWG, they try for integration

Plan CPPCON SG14 meeting
 Sept 18 Wednesday
Please get in touch about reserving a seat
Linear Algebra at CPPCON SG14
Please propose papers for next call Sept 11.as deadline.
Please submit draft to the reflector asap even before the Sept 11 meeting.
Patrice will be there.
SG14 members can enter for free but still need to register. others buy a
ticket, but the cost can be commuted
34 paid and 9 free

Belfast C++ meetng:
2 events: committee starts on Nov 4, Nov 11 is ACCU Ireland follow on
can hold an SG14 meeting for games developers and low latency in the UK

2.2 Paper reviews
> 2.2.1 Improving Debug Builds Inline With User Expectation: John MacFarlane
> p1832.html <https://lists.isocpp.org/sg14/att-0190/p1832.html>
 debug builds based on GCC -O0 -Og implementation
selecting which function to be inlined
generally disables inlining to enable stepping through
-Og enables the following optimization flags for function defined in
system headers -isystem
affects numeric work
need something intermediate between debug and release build

needed as a queue to debug for embedded systems
other impacting effects as well, when debugging interactively, real pain to
step over std:: begin and end for algorithm
tried to narrow the scope

yes have an issue: direction currently is compielr options and tweak
compiler behaviour
much more suited as an attribute
like explicit inlining
eigen library has this problem, undebuggable
if you want to step into your own code, but not some dependent library
code, so need fine grain control
good candidate for inlining not based on location of source code, but
whether it a dependency
bad thing is that attribute need to be used in conjunction with macros,
explicit inlining is a terible semantics
really need a hint for optimization, debuggability or some slider
macro to be used for my code that I want to debug

there is precedence for -isystem vs I, should be alternate interface that
is not based on location

on Msvc side there is no external I, they chose not to go that way due to
warnings, want to be able to give type conversion warnings in a template,
hard to get MSVC to take /Iexternal, but/Ob1 fo give good results
so I like the direction of turning more inlining
will find the blogpost

suspect msvc agree they have an issue. But in 2019 or 2017 one of the
change they introduced as a default is not step into, so they change the
step through experience to elide anything that was in angle bracket

modules dust is still setting, but they could help solve the problem, with
headers from one body of code is finding its place into a TU from another,
but still have to explictky say so that someone elses code is not to be

looks like there is some support external:I in Visual studio

like the pitch of the problem, the solution is general direction: to take
this beyond QOI
committee and if they want a more generic solution, then it will be more
load on compiler implementations
This problem is more chronic for numerics, where inlining and expression
templates with auto

No objections to moving onto SG15 tooling

Arthur also sent feedback.

> 2.2.2 Error Size Benchmarking by Ben Craig
> P1640R0: Error size benchmarking
> https://raw.githack.com/ben-craig/error_bench/master/error_size_benchmarking.html
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githack.com_ben-2Dcraig_error-5Fbench_master_error-5Fsize-5Fbenchmarking.html&d=DwMGaQ&c=r2dcLCtU9q6n0vrtnDw9vg&r=bHyceIQQHQvbfTSwvF3b5ym3XCQIh0_iFRNJbNk-FCc&m=_OFSroXnnYHKfBQqw8TVSac0et4fEQ80IMeaj-lWcD4&s=LGjT-TVB94ptHzUmdPNh4LJr1eMpKuAcmL7pQSWzxxA&e=>
  Didn't quite understand what the various scenarios mean.
            Didn't manage to try the EDG portable exception mechanism.
  Not sure only EH overhead is measured.
  noexcept is grossly underused
            - Because of Lakos rule
            - Because library shies away from conditional noexcept
     -> Maybe this is more of a library issue
  It was a mistake to require termination from noexcept functions
            that attempt to throw. Forces generation of EH tables.
  Also, because something like vector::operator[] isn't noexcept
            (due to Lakos rule), it's easy to get a situation where the
            compiler cannot prove that no exception is thrown.
   Analogy: Comparing the size of "int main() {}" to
                     int main() { std::cout << "Hello\n"; }"
                 will see a huge growth in size.
   We should compare the cost of the hot paths also.
   Ben Craig concludes that C++ EH doesn't serve all domains well.

  Ask for Patrice to restart his work
may be work with EDG, XLC, Sun compilers as well

 2.2.3 PTF/Colony?
No one to present.
had a mini discussion on the reflector, to support SIMD.
Matt Bently working on implementation to make use the simd scatter gather
instructions which only work on ARM for the core pieces on Colony. He
wishes to know if this was worthwhile. Niall was mildly positive, staffan
was mildly against. Matt will go off and experiement.

Is that to get better performance? Probably but it is not one of the detail
that WG21 cares about. There was concern about intrusive vs nonintrusive

> 2.2.4 Linear Algebra update from Aug 7

> Next call: Sept 4: 3-5 PM ET
> 2.2.5: Any serious study on cost of Exception vs cost of Error Codes
Done by Ben Craig's paper.

> 2.2.6 any other proposal for reviews?
> 2.3 Domain-specific discussions
> 2.3.1 Embedded domain discussions: Ben Craig, Wooter and Odin Holmes
> 2.3.3 Games Domain: John McFarlane, Guy Davidson and Paul Hampson
> 2.3.4 Finance Domain: Carl Cooke, Neal Horlock, Mateusz Pusz and Clay
> Trychta
> 2.3.5 Lnear Algenra: Bob Steagall, Mark Hoemman
> 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
> - *2019-11-04 to 09: Belfast, Northern Ireland;* Archer Yates
> -
> - 2020-02-10 to 15: Prague, Czech Republic
> - 2020-06-01 to 06: Bulgaria
> - 2020-11: (New York, tentative)
> - 2021-02-22 to 27: Kona, HI, USA
> 3. Any other business
> Reflector
> 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/2016/
> Code and proposal Staging area
> 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
> Sept 11
> 5.2 Future meeting
> Sept 11
> Oct 9: mailing deadline Monday Oct 7
> Nov 13: cancelled due to C++ Std meeting

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

Older Archives on Google Groups