[LINUX] J'ai oublié d'évaluer les performances à cause de l'habitude de sauter "J'ai essayé de viser le Fizz Buzz le plus rapide"

introduction

J'ai oublié d'évaluer les performances dans l'article que j'ai écrit plus tôt, "j'ai essayé de viser le FizzBuzz le plus rapide". Es-tu stupide? Pour cette raison, nous avons évalué les performances du programme manquant.

Méthode d'évaluation

Le programme FizzBuzz créé la dernière fois

$ time -p ./fizzbuzz >/dev/null
real 0.00
user 0.00
sys 0.00
$ 

Cela n'est pas utile car le temps d'exécution du programme est trop court pour être mesuré avec la commande time. Avec un peu d'ingéniosité

 $ time -p (for i in `seq 1 10000`; do ./fizzbuzz; done) >/dev/null
real 6.76
user 4.55
sys 4.41

Une méthode d'exécution multiple et de division du temps d'exécution par le nombre d'exécutions peut être envisagée, mais cette méthode n'est pas adoptée car la répétition par le shell semble être plus coûteuse que le temps d'exécution du programme. Cette fois, j'ai décidé de créer un programme court qui exécute à plusieurs reprises le même programme et l'utilise.

repeat.c

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <stdbool.h>
#include <unistd.h>
#include <errno.h>
#include <spawn.h>
#include <sys/wait.h>

int main(int argc, char* argv[])
{
    int opt;
    int n = 1;
    bool f = false;
    int fd = -1;
    opterr = 0;
    while ((opt = getopt(argc, argv, "hfn:")) != -1) {
        switch (opt) {
        case 'h':
        default:
            fprintf(stderr, "Usage: repeat [options]... command\n");
            exit(EXIT_FAILURE);
            break;
        case 'f':
            f = true;
            break;
        case 'n':
            n = atoi(optarg);
            break;
        }
    }
    if (f) {
        fd = open("/proc/sys/vm/drop_caches", O_WRONLY);
    }
    for (int i = 1; i <= n; i++) {
        if (f && fd >= 0) {
            while (write(fd, "1", 1) == -1 && errno == EINTR) {
                ;
            }
        }
        pid_t pid;
        posix_spawn(&pid, argv[optind], NULL, NULL, &argv[optind], NULL);
        int status;
        wait(&status);
        if (status) {
            fprintf(stderr, "pid %d: %d\n", pid, status);
            exit(status);
        }
    }
    if (f && fd >= 0) {
        close(fd);
    }
}

cette

$ gcc -Wall -Wextra -O2 repeat.c -o repeat

Compilez comme

python

$ time -p ./repeat -n 10000 ./fizzbuzz >/dev/null
real 1.84
user 1.44
sys 0.48
$ 

Utilisé comme. L'option de ligne de commande \ -n value's spécifie le nombre de fois que le programme est exécuté de manière répétée, et le nombre produit par la commande time est divisé par le nombre d'exécutions pour obtenir le temps d'exécution par exécution. Une fois que le programme est lu à partir du disque, son contenu est enregistré dans le cache de page, et il n'ira pas lire le disque pendant une exécution répétée. Puisque nous voulons également évaluer la charge de lecture du programme à partir du disque, nous avons fourni une fonction pour exécuter le programme à partir de l'état où le cache de page est effacé en spécifiant l'option de ligne de commande \ -f '. Le cache de page est effacé en écrivant 1 dans / proc / sys / vm / drop_caches, et les privilèges d'administrateur sont requis, il est donc nécessaire d'utiliser sudo ensemble.

$ sudo time -p ./repeat -n 10000 -f ./fizzbuzz >/dev/null
real 85.90
user 3.26
sys 78.85
$ 

Comme dans l'exemple précédent, le nombre de sortie est divisé par le nombre de répétitions pour obtenir le temps d'exécution incluant le temps de chargement du programme.

Résultat de la mesure

Pas d'effacement du cache (* La valeur numérique est le temps (secondes) exécuté 10 000 fois)

Il y a une compensation de trésorerie (* comme ci-dessus)

Taille du fichier d'exécution (* l'unité est en octets)

Évaluation

• Le résultat était que la version assembleur était la plus rapide avec et sans effacement du cache (pour le moment, je suis soulagé).
• Sous la condition sans effacer le cache, le disque est en lecture seule pour la première fois, donc la taille du fichier d'exécution n'a presque aucun effet sur le temps d'exécution (devrait). La différence qui se produit semble être due aux deux points suivants
• Temps nécessaire pour démarrer un programme écrit en C (version de lien statique en langage C, version de lien dynamique en langage C)
• Temps requis pour le lien dynamique (version de lien dynamique en langage C)
• Dans la condition sans cache clear, user + sys ≒ real tient, mais dans la condition avec cache clear, il y a une différence entre les valeurs de user + sys et real, et la différence semble être le temps nécessaire pour attendre la lecture du disque. Par conséquent, sous la condition d'effacement du cache, on considère que plus la taille du fichier d'exécution est grande, plus l'influence sur le nombre réel est grande.

en conclusion

La fin.