grim7reaper a écrit 132 commentaires

Suffit de lire le man :

The time returned by gettimeofday(2) is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the system time). If you need a monotonically increasing clock, see clock_gettime(2).

Mouais, vaut quand même mieux éviter RDTSC sur du multicore si on veut un truc fiable.

This use of RDTSC for timing suffers from these fundamental issues:

• Discontinuous values. Using RDTSC directly assumes that the thread is always running on the same processor. Multiprocessor and dual-core systems do not guarantee synchronization of their cycle counters between cores. This is exacerbated when combined with modern power management technologies that idle and restore various cores at different times, which results in the cores typically being out of synchronization. For an application, this generally results in glitches or in potential crashes as the thread jumps between the processors and gets timing values that result in large deltas, negative deltas, or halted timing.
• Availability of dedicated hardware. RDTSC locks the timing information that the application requests to the processor's cycle counter. For many years this was the best way to get high-precision timing information, but newer motherboards are now including dedicated timing devices which provide high-resolution timing information without the drawbacks of RDTSC.
• Variability of the CPU's frequency. The assumption is often made that the frequency of the CPU is fixed for the life of the program. However, with modern power management technologies, this is an incorrect assumption. While initially limited to laptop computers and other mobile devices, technology that changes the frequency of the CPU is in use in many high-end desktop PCs; disabling its function to maintain a consistent frequency is generally not acceptable to users.

Source.

De même, le coup du gettimeofday je ne suis pas sûr qu’il soit très multicore proof (à vérifier).
Je partirais plus sur un coup de clock_gettime(CLOCKMONOTONIC_RAW)_

Et encore…

If the CPUs in an SMP system have different clock sources then there is no way to maintain a correlation between the timer registers since each CPU will run at a slightly different frequency. If that is the case then clock_getcpuclockid(0) will return ENOENT to signify this condition. The two clocks will then only be useful if it can be ensured that a process stays on a certain CPU.

The processors in an SMP system do not start all at exactly the same time and therefore the timer registers are typically running at an offset. Some architectures include code that attempts to limit these offsets on bootup. However, the code cannot guarantee to accurately tune the offsets. Glibc contains no provisions to deal with these offsets (unlike the Linux Kernel). Typically these offsets are small and therefore the effects may be negligible in most cases.

Source: page de man de clock_gettime

Au final, faudrait peut-être partir sur HPET pour avoir un timing cohérent (à vérifier).

À part ça, je plussoie les deux commentaires précédents.

Pour gcc:

-pedantic -Wall -Wextra -Wformat=2 -Winit-self -Wcast-qual -Wcast-align -Wconversion -Wwrite-strings -Wstrict-prototypes -Wfloat-equal -Wshadow -Wredundant-decls -Wundef -Wbad-function-cast -Wold-style-definition -Wdouble-promotion -Wmissing-declarations -Wmissing-include-dirs -Wswitch-default -Wlogical-op -Wnested-externs -Wunreachable-code -Wpadded

Pour g++ (un peu moins fourni, je code moins souvent en C++):

-pedantic -Wall -Wextra -Wcast-qual -Wcast-align -Wconversion -Wsign-conversion -Wshadow -Wredundant-decls -Wundef -Wold-style-cast -Wdouble-promotion -Wfloat-equal -Woverloaded-virtual -Wmissing-include-dirs -Wswitch-default -Wlogical-op -Wno-long-long -Wunreachable-code -Wpadded

Je tiens à signaler que Wpadded produit pas mal de bruit, donc je ne l'active pas toujours (c’est souvent juste pour info, je l’active de temps en temps).

Bon faudrait que je mette mes flags à jour. Avec les dernières versions de gcc, il y en a probablement des nouveaux qui sont intéressants.

Pour clang, c’est bien plus simple (même options pour le C et le C++):

-Weverything -fcatch-undefined-behavior -ftrapv

Parce que dès qu'on joue un petit peu avec des theads, les traces ont un impacte dans l’ordonnancement.

Le debuggeur aussi.

Je plussoie.
C’est d’ailleurs pour cette raison que des gens s’amusent à tripoter GDB pour donner ça, ce qui permet d’avoir des trucs un minimum reproductibles quand on debug du multithread.

Si, il y a bien un rapport.

Dans ton exemple oui, c’est bidon et crade car ça change sans aucune raison ni logique.
Il y a des cas où c’est justifié, et du coup c’est bien pratique :
Genre tu veux lire 2 entiers dans un fichier, et bien je ne trouve pas ça choquant de faire :

with open('INI2.dataset', encoding='utf-8') as dataset:
    a, b = dataset.readline().rstrip().split(' ')
    a, b = int(a), int(b)

Et pourtant, a et b sont des chaînes de caractères puis deviennent des entiers.
Est-ce que le monde va s’effondrer pour autant ? Est-ce que le code est illisible et devient très sale ?
Il me semble que non.
(Oui, je sais que je pourrais passer par une liste en intention ici, mais c’est histoire de faire un exemple)

Après, c’est sûr qu’une inférence de type efficace (à la Haskell par exemple), ça offre beaucoup plus de garantie et de sécurité.

Ça te choque car tu vois les variables en Python comme des variables en C.
Or, ça ne fonctionne pas pareil.
Après, on est d’accord, nommer une variable a c’est choquant car c’est très mauvais nommage.

Sinon l’argument de « ça permet de faire des choses crades », bof.
Le C est typé statiquement, pourtant je te fais des choses crades à la pelle si l’envie me prend.

Il y a 2 ans, j’avais vu passer une discussion sur un livre dans lequel de grands développeurs (dont Guido van Rossum (Python), Bjarne Stroustrup (C++) ou encore James Gosling (Java)) disaient ne jamais utiliser de débogueur.

Après, d’un point de vue personnel, j’utilise assez rarement le débogueur mais ça varie beaucoup selon le langage (et du programme sur lequel je bosse). J’ai plus tendance à sortir le débogueur en Java qu’en C par exemple.

De manière générale, mon cerveau + crayon/papier reste mon débogueur le plus efficace à ce jour.
Après, les print, le débogueur interactif, Valgrind, les outils d’analyses statiques & cie je les sors au cas par cas, selon la situation et le problème.

Édit : ha, je viens de retrouver le lien vers la discussion.