【问题标题】:C++ chrono::duration_cast always outputs "0 seconds"C++ chrono::duration_cast 始终输出“0 秒”
【发布时间】:2016-04-28 11:52:58
【问题描述】:

这是我在这里的第一个问题,我也是 C++ 的新手,但我会尽我所能,尽可能具体。请告诉我是否含糊不清:

我正在尝试使用 chrono 和 duration_cast 测量排序方法(合并排序)对给定整数数组进行排序所需的时间。这是有问题的代码sn-p:

    auto t1 = std::chrono::high_resolution_clock::now();
    mergesort(sortingArray, temp, 0, num - 1);
    auto t2 = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double, std::milli> fp_ms = t2 - t1;
    std::cout << fp_ms.count() << " seconds\n";

而且我得到的输出总是“0 秒”,无论我制作的数组有多大,它都需要排序。即使它对一百万个整数进行排序并且有明显的执行时间,它仍然给我相同的输出。

我基本上遵循这里给出的示例:http://en.cppreference.com/w/cpp/chrono/duration/duration_cast

我使用的是合并排序函数,而不是 f()。如何让它正确测量我的排序方法?

编辑:我在 Windows 10 中使用 minGW 通过 Powershell 进行编译。命令如下所示:

g++ -std=c++11 .\Merge.cpp

【问题讨论】:

  • mergesort 是你自己的函数吗?你确定它实际上是在对数组进行排序吗?
  • 是的,mergesort 是我自己的函数。我已经打印了排序后的数组以确保它有效。
  • 您能否尝试切换打印纳秒,以确保它不会四舍五入为 0。还详细说明哪些编译器/平台可能有助于您追踪任何错误。
  • 好的,我现在切换到纳秒,它给了我相同的输出,所以那里没有进展。我在 Windows 10 中使用 minGW 通过 Powershell 进行编译。命令如下所示:g++ -std=c++11 .\Merge.cpp
  • 尝试切换到steady_clock

标签: c++ g++ mingw chrono


【解决方案1】:

TL;DR:看起来std::chrono 实现 (libstdc++) 在 Windows 上的性能很差,您不会得到比秒更好的东西。

加长版:

libstdc++ typedefs std::chrono::high_resolution_clockstd::chrono::system_clock。根据implementation,对std::chrono::system_clock::now() 的调用将导致对以下之一的调用,具体取决于平台:

  • syscall(SYS_clock_gettime, CLOCK_REALTIME, ...),这是一个Linux系统调用
  • clock_gettime(CLOCK_REALTIME, ...),这是 Windows 不支持的 POSIX 系统调用
  • gettimeofday(...),这是 Windows 不支持的 POSIX 函数
  • std::time() 作为后备

因此,std::time() 在 Windows 内部被调用。未指定std::time()的编码;但是,大多数系统都遵循POSIX specification

time() 函数应返回自 Epoch 以来以 为单位的时间值。

微软自己做the same:

返回自 1970 年 1 月 1 日午夜以来经过的 时间,如果出现错误,则返回 -1。

我认为可以肯定地说,使用 MingW 的 std::chrono 不会获得更高的分辨率。

至于你的问题,你有两种选择:

  1. 如果您的程序仅在 Windows 上运行,您可以使用 QueryPerformanceCounter 构建自己的时间测量
  2. 如果您想保持便携,请使用Boost.Chrono。它使用native Windows APIs,应该提供更好的分辨率。

【讨论】:

猜你喜欢
  • 1970-01-01
  • 2015-02-24
  • 1970-01-01
  • 2018-01-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-12-15
  • 1970-01-01
相关资源
最近更新 更多