为什么实时可以低于用户时间

我有一个转换视频文件的脚本，我在服务器上根据测试数据运行它，并通过来测量其时间time。结果，我看到了：

real    2m48.326s
user    6m57.498s
sys     0m3.120s

为什么实时时间比用户时间低得多？这和多线程有关系吗？或者还有什么？

编辑：我认为该脚本正在运行大约2m48s

time

— Kobylecki
source

重新编辑-完全有道理，因为real时间是以下所述的挂钟时间（即，如果有秒表，我们将进行的测量）

— Levon 2012年

相关：stackoverflow.com/questions/15928334/...

— 的try-catch-终于

Answers:

您显示的输出有些奇怪，因为实时通常会大于其他两个。

Real时间是挂钟时间。（我们可以用秒表测量）
User 时间是流程中用户模式花费的时间
Sys 是进程中在内核中花费的CPU时间。

因此，我想如果工作是同时由多个处理器完成的，则CPU时间将比经过的挂钟时间更长。

这是并发/多线程/并行类型的应用程序吗？

仅作为示例，这就是我发出time find .命令时在Linux系统上得到的。不出所料，real在这个单用户/单核过程中，经过的时间比其他时间长得多。

real    0m5.231s
user    0m0.072s
sys     0m0.088s

经验法则是：

真实<用户：进程受CPU限制，并利用了在多个内核/ CPU上并行执行的优势。
真正的≈用户：该进程受CPU限制，不利用并行执行。
实>用户：进程受I / O约束。在多个内核上执行几乎没有优势。

— 列文
source

我不知道是否avconv是多线程的。希望如此。avconv是的新一代ffmpeg。我正在转换7个简短的flv文件（每个文件约20秒）。

— kobylecki 2012年

实际时间通常会比其他两个大 -但我问其他情况

— kobylecki

这个解释是正确的。该过程似乎在4个内核上运行。另请参阅我对超线程的解释，以获取更多有关如何计算真实/ sys /用户时间的信息。它并不完全相关，但是概念是相同的。

— bahamat 2012年

@kobylecki的实时时间比其他时间少，因为avconv看起来运行在多个内核上。由于我既不知道该软件，也不知道它是如何运行的，因此我不想提出100％的主张，但这是基于可用信息（三行时间测量和知识：）得出的结果。）

— 勒冯·2012年

在该find示例中，该usr值要低得多，因为大多数时间都花在了中断期间，即使find是多线程的，它也会保持较低的状态（很抱歉，如果我不掌握英语时态）。

— 伊曼纽尔

只是为了说明所说的内容，两个线程的进程进行了一些计算。

/*a.c/*
    #include <pthread.h>
    static void  * dosomething () {
        unsigned long a,b=1;
        for (a=1000000000; a>0; a--) b*=3;
        return NULL;
    }
    main () {
        pthread_t one, two;
        pthread_create(&one,NULL, dosomething, NULL);
        pthread_create(&two,NULL, dosomething, NULL);
        pthread_join (one, NULL);
        pthread_join (two, NULL);
    }
/* end of a.c */

编译

gcc a.c -lpthread

（这只是为了说明，在现实生活中，我应该添加-D_REENTRANT标志）

$ time ./a.out

real    0m7.415s
user    0m13.105s
sys     0m0.032s

（时间在具有两个慢速内核的Intel Atom上：）

— 伊曼纽尔
source