Time-consuming methods and pits for running code blocks in C++11

# PS: To reproduce, please indicate the source. I have the copyright.

# PS: This is just my own understanding, if with yours

# Principles conflict, please understand, do not spray

Introduction to chrono:

Source: http://www.cplusplus.com/reference/chrono/?kw=chrono

The elements in this header deal with time. This is done mainly by means of three concepts:
Durations
They measure time spans, like: one minute, two hours, or ten milliseconds.
In this library, they are represented with objects of the duration class template, that couples a count representation and a period precision (e.g., ten milliseconds has ten as count representation and milliseconds as period precision).
Time points
A reference to a specific point in time, like one's birthday, today's dawn, or when the next train passes.
In this library, objects of the time_point class template express this by using a duration relative to an epoch (which is a fixed point in time common to all time_point objects using the same clock).
Clocks
A framework that relates a time point to real physical time.
The library provides at least three clocks that provide means to express the current time as a time_point: system_clock, steady_clock and high_resolution_clock.

To me:

Three timing modes and one time conversion mode are ok, corresponding to each other:

Timing method:
std::chrono::high_resolution_clock //high_resolution_clock is the clock with the shortest tick period. It may be a synonym for system_clock or steady_clock.
std::chrono::system_clock //Specifically, system_clock is a system-wide realtime clock.
std::chrono::steady_clock //steady_clock is specifically designed to calculate time intervals.
//Time conversion mode:
std::chrono::duration_cast
/*
Converts the value of dtn into some other duration type, taking into account differences in their periods.

The function does not use implicit conversions. Instead, all count values are internally converted into the widest representation (the common_type for the internal count types) and then casted to the destination type, all conversions being done explicitly with static_cast.
*/

Pits in chrono law (differences in ms, us and ns levels exist for different clocks)

// Under windows, std::chrono::system_clock may not be timed accurately. Note that here is """"""""""""may""
// In windows, high_resolution_clock time is the most accurate. If you need the highest accuracy, use this clock.
/ / summary:
// 1 If it is second-level time evaluation, std::chrono::system_clock does not matter. If it is ms, us, ns-level time evaluation (here I do algorithm evaluation), then std::chrono::system_clock may have a larger problem, which can be solved by high_resolution_clock.
// 2 If the timing is applied to multiple threads, you need to add up the timing of all threads, which is your real time-consuming.
// At the same time, I guess the reason for this problem is that the time slices used by different clock types (corresponding to different types of clock cycles) are different. Of course, some cpu-related knowledge friends should know that the most accurate timing is: time slice = cpu clock cycle (this is unreasonable, understand part of the line)

chrono timing method

//Code point 1
std::chrono::time_point<std::chrono::high_resolution_clock> p0 = std::chrono::high_resolution_clock::now();
// ... Several codes
//Code point two
std::chrono::time_point<std::chrono::high_resolution_clock> p1 = std::chrono::high_resolution_clock::now();

//Calculating and printing time-consuming, the use is not standard, 1000 in this paper is converted to milliseconds.
cout << "stitch high_resolution_clock time:" << (float)std::chrono::duration_cast<std::chrono::microseconds>(p1 - p0).count() / 1000 << "ms" << endl;

# PS: Please respect the originality, do not spray if you don't like it.

# PS: To reproduce, please specify the source. I have the right to reserve it.

If you have any questions, please leave a message. I will reply as soon as I see it.

Keywords: Windows

Added by morbidchick on Wed, 15 May 2019 08:12:09 +0300