Date: Wed, 14 Aug 2019 15:42:56 -0400
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
Wong
> 1.2 Adopt agenda
>
Approve
> 1.3 Approve minutes from previous meeting, and approve publishing
> previously approved minutes to ISOCPP.org
>
Approve.
> 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
like
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
inlined
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
"#include<iostream>
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
interface.
>
> 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
>
>
>
> 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
Wong
> 1.2 Adopt agenda
>
Approve
> 1.3 Approve minutes from previous meeting, and approve publishing
> previously approved minutes to ISOCPP.org
>
Approve.
> 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
like
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
inlined
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
"#include<iostream>
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
interface.
>
> 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
>
>
>
Received on 2019-08-14 14:45:11