C++ Logo

sg14

Advanced search

Re: [SG14] Initial attempt at Latency Preserving Library "Core" Guidelines

From: Tjernstrom, Staffan <Staffan.Tjernstrom_at_[hidden]>
Date: Tue, 26 Feb 2019 19:41:38 +0000
Thanks Arthur, exactly the kind of "what was I thinking" critique I was hoping for :) ... I'll see what I can whip up in response.

From: Arthur O'Dwyer [mailto:arthur.j.odwyer_at_[hidden]]
Sent: Tuesday, 26 February, 2019 14:38
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>; Tjernstrom, Staffan <Staffan.Tjernstrom_at_[hidden]>
Subject: Re: [SG14] Initial attempt at Latency Preserving Library "Core" Guidelines

The "good" example for LP2 says span<string> when it means span<char>.
Both examples for LP2 misuse seeding: obviously constructing random_device is not going to be "latency-preserving," and then on top of that mt19937 gen(r()) does not uniformly initialize the generator. See "The Twitter App Mystery<http://www.pcg-random.org/posts/cpp-seeding-surprises.html>" for the problem and P0205 "Allow Seeding Random Number Engines with random_device"<https://github.com/jensmaurer/papers/issues/325> for the solution.

LP3's example is not very good, because surely real code (even if not latency-sensitive) would just document this precondition, maybe even use C++2a contracts to document it, but never even check it, let alone throw if the check fails. (And if we do bother to check and the check fails, we'd probably just abort(), in the absence of any motivation to do otherwise.)

LP4 is slightly misleading when it equates TriviallyCopyable with StorableInRegisters. Trivial copyability is currently necessary, but not sufficient, for getting passed and returned in registers. For example, std::array<int, 1000> is trivially copyable on every implementation I'm aware of, but it will not be passed or returned in registers on any ABI I'm aware of. I would prefer to see the pro-TriviallyCopyable position motivated by something other than ABI concerns, and then a separate guideline that gives motivation and strategies for reducing the overall size of your data types.

I wish the examples for LP4 didn't use `rand()`. How about using something like complex<int>::operator+ as a motivating example?

LP5 looks incomplete, and/or maybe the final page wasn't meant to be blank?

HTH,
Arthur


On Tue, Feb 26, 2019 at 10:57 AM Tjernstrom, Staffan <Staffan.Tjernstrom_at_[hidden]<mailto:Staffan.Tjernstrom_at_[hidden]>> wrote:
I had a bit of time to spare, and decided to attempt to re-write Niall's D1027 into something a bit more Core Guideline-like (as we discussed a few months ago). Apologies that I haven't been able to author it into the SG14 github, but we don't have authenticated access here at work. If this seems promising I'll work out a way of getting it up there.

Comments / flames very much invited.

Kind Rgds
Staffan Tj.


________________________________

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.
_______________________________________________
SG14 mailing list
SG14_at_lists.isocpp.org<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14

________________________________

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.

Received on 2019-02-26 13:43:04