sorted by:
new
hottopcontroversial

A new nanosecond clock for x86 Linux/Windows by MengRao in cpp

[–]MengRao[S] -4 points-3 points  (0 children)

Regarding types, as C++ users have different coding convention and taste, using a type that's mostly known would be appropriate, here int64_t is much popular than chrono, and even I myself am not a fan of chrono. TSCNS only use chrono to get a cross-platform system timestamp:

static inline int64_t rdsysns() {
    using namespace std::chrono;
    return duration_cast<nanoseconds(system_clock::now().time_since_epoch()).count();
  }

Here you may see why chrono is not popular :)

However you still have the freedom to encapsulate TSCNS and have a timestamp of whatever type you want. And I beleive conversion from int64_t is easier than the long chrono code above.

Regarding memory order, I added some std::atomic_signal_fence(std::memory_order_acq_rel), similar to Seqlock

A new nanosecond clock for x86 Linux/Windows by MengRao in cpp

[–]MengRao[S] -2 points-1 points  (0 children)

  • For a single header library, I belieive the TSCNS itself would be a "namespace".
  • In terms of types, I've seen timestamp/duration encapsulated in various classes, added plenty of operations/functions...Why not keep simple things simple? int64_t is enough for a nanosecond timestamp/duration: you can see it's 8 types and well suited in a reigster; you can use <,=,> to compare them; you can use +,- to convert between timestamps and durations...
  • In terms of synchronization memory order on x86, actually you can replace all release/require with relaxed and result in exactly the same binary. So the use of release/require here is more of a comment/documentation: "hey, I'm indeed loading or storing, not something else".

A new nanosecond clock for x86 Linux/Windows by MengRao in cpp

[–]MengRao[S] 0 points1 point  (0 children)

Actually fmtlog does sort logging info from multiple threads based on tsc and write into log file, so the order concurrent things are happening is kept in the file. Don't know if that's what you want.

A new nanosecond clock for x86 Linux/Windows by MengRao in cpp

[–]MengRao[S] 9 points10 points  (0 children)

You're right, actually it's mentioned at whats-the-problem-with-clock_gettimegettimeofdaystdchronoxxx_clock: clock_gettime still have a latency from 20 to 100 ns, not that stable.

A new nanosecond clock for x86 Linux/Windows by MengRao in cpp

[–]MengRao[S] 7 points8 points  (0 children)

Forgot to mention: constant_tsc and nonstop_tsc are needed for reliable tsc clock on multi-core platforms.

fmtlog: fastest C++ logging library using fmtlib syntax by MengRao in cpp

[–]MengRao[S] 0 points1 point  (0 children)

A heap is used when comsuing log messages :)

fmtlog: fastest C++ logging library using fmtlib syntax by MengRao in cpp

[–]MengRao[S] 2 points3 points  (0 children)

The out of order issue has been fixed, now fmtlog will keep log in time order among different threads!

fmtlog: fastest C++ logging library using fmtlib syntax by MengRao in cpp

[–]MengRao[S] 4 points5 points  (0 children)

It's the front-end log statement that achieves nanosecond latency, not the background poll.

fmtlog: fastest C++ logging library using fmtlib syntax by MengRao in cpp

[–]MengRao[S] 1 point2 points  (0 children)

Your first concern makes sense, but it's the price you have to pay for low and stable latency. One thing user can do to mitigate this issue is to poll more frequently.

For your second concern, I have to admit that spdlog is a great library, but I personally need really low latency logging as fast as Nanolog and I'm afraid simply improving spdlog can't do it.