Por que o tempo real pode ser menor que o tempo do usuário

31

Eu tenho um script para converter arquivos de vídeo e o executo no servidor com dados de teste e meço seu tempo time. Em resultado, vi:

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

Por que o tempo real é muito menor que o tempo do usuário? Isso tem alguma conexão com multithreading? Ou o que mais?

Edit: E eu acho que esse script estava rodando cerca de 2m48s

time kobylecki
fonte
re sua edição - que faz todo o sentido, uma vez que realo tempo é tempo de relógio de parede como explicado abaixo (ou seja, o que mediria se tivéssemos um stop-relógio)
Levon
Relacionados: stackoverflow.com/questions/15928334/...
try-catch-finally

Respostas:

42

A saída que você mostra é um pouco estranha, já que o tempo real geralmente seria maior que os outros dois.

  • Realhora é hora do relógio de parede. (o que poderíamos medir com um cronômetro)
  • User time é a quantidade de tempo gasto no modo de usuário dentro do processo
  • Sys é o tempo de CPU gasto no kernel dentro do processo.

Portanto, suponho que se o trabalho fosse realizado por vários processadores simultaneamente, o tempo da CPU seria maior que o tempo decorrido do relógio de parede.

Esse era um tipo de aplicativo simultâneo / multithread / paralelo?

Apenas como exemplo, é isso que recebo no meu sistema Linux quando emito o time find .comando. Como esperado, o realtempo decorrido é muito maior que os outros neste processo de usuário único / núcleo único.

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

A regra de ouro é:

  • real <usuário: o processo é vinculado à CPU e aproveita a execução paralela em vários núcleos / CPUs.
  • usuário real: O processo é vinculado à CPU e não tira vantagem da execução paralela.
  • usuário real: o processo é vinculado à E / S. A execução em múltiplos núcleos seria de pouca ou nenhuma vantagem.
Levon
fonte
Não sei se avconvé multiencadeado. Pode ser. avconvé a nova geração de ffmpeg. Eu estava convertendo 7 arquivos flv curtos (cerca de 20 segundos cada).
Kobylecki
tempo real normalmente seria maior do que os outros dois - mas eu perguntar sobre outra situação
Kobylecki
4
Esta explicação está correta. Parece que esse processo foi executado em 4 núcleos. Veja também minha explicação sobre hyperthreading para obter mais informações sobre como o tempo real / sys / usuário é calculado. Não se relaciona exatamente, mas os conceitos são os mesmos.
bahamat
O tempo real do @kobylecki é menor que os outros, porque parece que o avconv é executado em vários núcleos. Como eu não conheço esse software, nem como ele foi executado, não quero fazer uma reivindicação de 100%, mas é assim que parece com base nas informações disponíveis (três linhas de medições de tempo e conhecimento: - )
Levon
No findexemplo, o usrvalor é muito menor porque a maior parte do tempo foi gasta durante as interrupções, mesmo findque tivesse sido multithread, ele permaneceria baixo (desculpe se eu não domino o inglês).
Emmanuel
13

Apenas para ilustrar o que foi dito, com dois processos encadeados fazendo algum cálculo.

/*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 */

compilar

gcc a.c -lpthread

(Isso é apenas para ilustrar, na vida real eu deveria ter adicionado o sinalizador -D_REENTRANT) 

$ time ./a.out

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

(Os tempos estão em um Intel Atom com dois núcleos lentos :))

Emmanuel
fonte