From: SG14 [mailto:sg14-bounces_at_[hidden]] On Behalf Of Michael Wong via SG14
Sent: Wednesday, June 12, 2019 9:50 AM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>
Cc: Michael Wong <fraggamuffin_at_[hidden]>
Subject: [SG14] SG14 June 12 Zoom call


Michael Wong is inviting you to a scheduled Zoom meeting.

Topic: SG14 Low Latency Monthly
Join URL: https://iso.zoom.us/j/406503386
Time: Apr 17, 2019 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

Staffan Tjernstrom, Michael Wong, Ben Craig, Billy Baker,Brett, Charles Bay, David Stone, Jan Wilmans, John McFarlane, Matthew Butler, Rene Rivera(Partial), Ronen Friedman, Guy Davidson (Partial)

1.2 Adopt agenda

Adopted

1.3 Approve minutes from previous meeting, and approve publishing
 previously approved minutes to ISOCPP.org

Approved

1.4 Action items from previous meetings

2. Main issues (125 min)

2.1 General logistics

Review last call discussions.

2.2 Paper reviews
2.2.1 Embedded/freestanding vs hosted

Ben Craig:

The drafts of D1641R0.0 "Freestanding Library: Rewording the Status Quo"
and D1642R0.0 "Freestanding Library: Easy [utilities]". These papers can
also be reached at the following URLs:

https://raw.githack.com/ben-craig/freestanding_proposal/master/library/status_quo.html

https://raw.githack.com/ben-craig/freestanding_proposal/master/library/easy_utilities.html

These are follow-on papers from P0829 "Freestanding Proposal". I'm still
going in that direction, just with lots of little papers now, instead of
one big paper.

Summary of freestanding Kona evening session discussions
http://wiki.edg.com/bin/view/Wg21kona2019/SG14FreestandingImplementations

Outcome from Dec call:
In the SG14 session, he mentioned 2 that he prefers
* Freestanding is signal / interrupt safe
* Freestanding requires no special dispensation from the operating
environment above what freestanding C99 requires

But there are other possible directions
* Freestanding should be as small as possible
* Freestanding has all the same core language features as hosted

Nov Evening Session:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1376r0.html

Papers now have P Numbers

Trying to keep a small number of papers in flight at any point in time just in time LWG changes their editorial policy.

Discussion/Clarification that we’re removing the requirement for freestanding not to provide feature test macros for non-freestanding features.

Discussion of what to do in those cases where we want to not include the whole overload set. Std::abs() with the floating point overloads is a case in point. Certain of the swap() cases may also be troublesome. For these papers we think we’re ok, but the issue will very likely crop up in the later papers that start dealing with more string like things.

Calling the type operator new/delete is ok, but calling the global operator new/delete is not. Hence unique_ptr<> makes it in.

Both papers need champions for Cologne.

2.2.2 Concurrent Queue from David Stone

In response to P0260r3, an overview of the current art. Separate out concurrent vs non-concurrent is a viable strategy. Also papers by Guy Davidson (D????), P1470r0, and others.

Additional queues from Tony Van Eerd, and the Folly Team.

2.2.3 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=>
 Initial error neutral size cost is relative to the stripped_abort case.
Question about whether unreachable would be an even lower bound. No measurements as of yet.
Visual Studio has different implementation strategies between 32-bit and 64-bit compilations.
The light bars show the need imposed by the platform ABI to store unwind information on 64-bit. That restriction is not necessarily there on WinX32, or indeed on some embedded platforms.
The first time that you call a function (say a C function) that is not marked noexcept, with exceptions turned on, you pay the exception size penalty. This happens for Visual Studio in /EHc mode when calling abort().
As ever with microbenchmarks there was some necessary fighting the optimizer.
DG will be very interesting in these results.

2.2.4 Linear Algebra update from April 3rd
http://lists.isocpp.org/sg14/2019/04/0076.php

Michael gave a quick update on the current status. The idea of row and column vector is still a topic of discussion. There is a contrasting paper preferring a more eager evaluation technique from National Labs, avoiding expression templates.

Next call: July 10 2 PM EDT – will very likely be cancelled due to Cologne.

Backup date is August 14 2 PM EDT.

2.2.5: Any serious study on cost of Exception vs cost of Error Codes

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.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-07-15 to 20: Cologne, Germany; *Nicolai Josuttis
   - *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://groups.google.com/a/isocpp.org/forum/?fromgroups=#!forum/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

TBD

5.2 Future meeting
Apr 17: todays call
May 8
June 12: June 17 mailing deadline
July 10: likely cancelled due to Cologne Meeting July 15

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.