Le topic de la programmation: Et envoyez des sioux!

**William Vaurien** · 02/11/2017, 22h10

Alors je vous avais déjà raconté mon projet un peu déprimant en C, et certains de mes collègues en fin de carrière. Je vais vous parler de l'un d'eux

Donc tous les autres le chambraient pas mal, et c'est vrai que nous l'avons retrouvé plusieurs fois assoupi sur sa chaise.
Mon boss m'avait également parlé d'un sous projet au sein de notre gros logiciel avec lequel ce fameux collègue se bat depuis 2 ans parce qu'il n'arrive pas à boucler les 20% restant des fameux 80/20.
Je trouvais que mon chef était un peu rude avec lui, et j'avais un peu pitié.

Aujourd'hui j'ai eu une révélation: mon chef minimise son incapacité à travailler.

Pour ce projet on va devoir tout balancer et reprendre de 0 (du coup ça m'arrange au final

).
Le sous-projet consiste en 4 ou 5 fichiers sources, dont un principal, avec dedans une - grosse - poignée de méthodes

Comme le collègue en question n'arrive plus à avancer depuis plusieurs jours; il a eu une illumination: il a imprimé ce fichier pour "l'analyser à la maison" (nous avons des portables).

Voici le résultat, je vous laisse imaginer le nombre de lignes de code (c'est recto verso):

Il nous a au moins beaucoup fait rire !

**Patate** · 02/11/2017, 22h13

Ca représente un fichier le tas là ?!

**William Vaurien** · 02/11/2017, 22h15

oui un seul fichier

et la photo ne rend pas justice au tas. Il a l'air beaucoup plus épais en vrai !

**Orhin** · 02/11/2017, 22h20

Je...

**Patate** · 02/11/2017, 22h21

Je vois pas trop comment on peut en arriver là enfait... Beaucoup de réécriture de code ?

**William Vaurien** · 02/11/2017, 22h34

Programmation de logiciel de gestion en C avec les 'best practices' de 1982. Aucun refactoring, aucune factorisation de code, aucun framework.
Et beaucoup de code pour gérer la mémoire, les erreurs, les chaines de caractères...

Et dans le fichier il y a tout: appel à la base de données, le businness, le html à coup de printf violent avec du html de 1995 dedans (tags en majuscule, balise non standard depuis HTML 4) !
Du bonheur

- - - Mise à jour - - -

Et le reste du projet est quand même un peu du même ordre... même si là le code est devenu un monstre de if imbriqués à 12 niveaux impossible à redresser. C'est la quitescence

Le reste du code est quand même composé à 80% de code technique habituellement gérer par des frameworks et les fichiers de 10k sont légions. Et mon chef qui vient gueuler sur Java et les tests unitaires avec pour seul argument que son projet ne consomme quasiment pas de RAM et qu'il n'y pas besoins de tests (en même temps il ne font pas de refactoring, ils ne savent pas ce que c'est ! tout est figé et copié collé...)

**TiNitro** · 03/11/2017, 00h22

si vous saviez... dans ma boite.... si je devais imprimer le plus gros source. *soupir*

**Nattefrost** · 03/11/2017, 01h00

La définition de l'enfer sur terre.
J'ai connaissance d'un roguelike composé d'un fichier python de 425 000 lignes. Hélas on peut pas en profiter, c'est closed source. Le "dev" dit qu'il a du passer à vim parce que c'est le seul editeur qui parvient encore a l'ouvrir

. Le next step c'est quoi ? Ajouter du code avec sed ?

**Patate** · 03/11/2017, 06h19

Et ton taff c'est quoi ? Redresser le projet ? Ça mérite une réécriture ce genre de truc.

**Dross** · 03/11/2017, 06h35

La seule solution.

**William Vaurien** · 03/11/2017, 07h20

J'imagine qu'il y a bien pire; mais c'est la tentative ultime du dev qui sait plus trop comment faire qui nous a surtout faire rire (un peu jaune quand même). Genre il va s'installer au coin du feu avec son paquet de feuilles et va avoir l'illumination qui va le guider vers la release

**Mayalabielle** · 03/11/2017, 09h30

Envoyé par Nattefrost

La définition de l'enfer sur terre.
J'ai connaissance d'un roguelike composé d'un fichier python de 425 000 lignes. Hélas on peut pas en profiter, c'est closed source. Le "dev" dit qu'il a du passer à vim parce que c'est le seul editeur qui parvient encore a l'ouvrir

. Le next step c'est quoi ? Ajouter du code avec sed ?

Code:

echo >>

**Teocali** · 03/11/2017, 09h31

Y'a des projets comme ça. A ce qu'il parait, Dwarf fortress est du genre à te faire perdre 15 points de SAn chaque fois que ouvres le code...

**Nattefrost** · 03/11/2017, 09h51

Envoyé par Mayalabielle

Code:

echo >>

Bah non si tu dois modifier une fonction existante à la ligne 201657 (sisi c'est possible xD) '>>' c'est pas super utile

- - - Mise à jour - - -

Envoyé par Nattefrost

Bah non si tu dois modifier une fonction existante à la ligne 201657 (sisi c'est possible xD) '>>' c'est pas super utile

@Teocali c'est pas DF je crois que c'est Ultima ratio regum

**Mayalabielle** · 03/11/2017, 10h03

Envoyé par Nattefrost

Bah non si tu dois modifier une fonction existante à la ligne 201657 (sisi c'est possible xD) '>>' c'est pas super utile

Bah tu utilises head / tail pour couper le fichier et ensuite cat pour l'assembler à nouveau. What else ?

**Nattefrost** · 03/11/2017, 12h11

Envoyé par Mayalabielle

Bah tu utilises head / tail pour couper le fichier et ensuite cat pour l'assembler à nouveau. What else ?

Ouais, remarque c'est vrai que quand on a un fichier de 425k SLOC on n'est plus à ça près

**Lazyjoe** · 04/11/2017, 00h31

Imprimer du code.... L'épaisseur de la pile... 3km² de foret amazonienne y sont passés.

En fait j'ai de la chance finalement, plus jamais je ne viendrai me plaindre du code sur lequel je bosse.

**Lazyjoe** · 04/11/2017, 00h42

Envoyé par rOut

Après, perso j'avais pas du tout accroché aux cours d'assembleur en école d'ingé, donc j'avais pas mal séché, et je suis probablement un peu à la ramasse, mais en reversant des programmes, instructions par instruction j'ai fini par me familiariser un peu... Bon, probablement pas de quoi être capable d'écrire 3 lignes qui tiennent la route en assembleur ou pour le lire couramment, mais suffisamment pour ne plus en avoir peur.

Je suis un peu dans le même cas, de vagues souvenirs d'assembleur 68000 en licence (c'était bien

) et utilisation de quelques instrinsics mais incapable d'écrire du véritable assembleur.

J'utilise régulièrement l'Intel Advisor. C'est un outil de profiling qui permet entre autres d'afficher le code assembleur correspondant (approximativement, c'est pas parfait) à une ligne de code source donnée. Ca permet de facilement vérifier si le compilo a produit de l'assembleur à côte de la plaque ou pas ("mais où qu'elles sont donc mes instructions avx512 quand je compile pour le skylake ???").

**Dross** · 04/11/2017, 01h30

Envoyé par Lazyjoe

Imprimer du code....

J'avoue l'avoir déjà fait.

Pour ma thèse de master on m'a demandé 100 pages, j'ai demandé si ça comptait les annexes, ils ont répondu oui, j'ai demandé après si on pouvais mettre du code en annexe, ils ont répondu oui aussi. Et bien ils les on eu leurs 100 pages, 40 pages de code GUI en MFC C++.

**Patate** · 04/11/2017, 06h39

Envoyé par Dross

J'avoue l'avoir déjà fait.

Pour ma thèse de master on m'a demandé 100 pages, j'ai demandé si ça comptait les annexes, ils ont répondu oui, j'ai demandé après si on pouvais mettre du code en annexe, ils ont répondu oui aussi. Et bien ils les on eu leurs 100 pages, 40 pages de code GUI en MFC C++.

Taille de la police 24. Fainéant !

**Møgluglu** · 04/11/2017, 10h23

Envoyé par Lazyjoe

Imprimer du code.... L'épaisseur de la pile... 3km² de foret amazonienne y sont passés.

Mais arrêtez de vous foutre de la gueule de ce mec. Si ça se trouve, c'est la première fois qu'il imprime son code sur papier avec une page de code entière par feuille. Il faut l'encourager dans cette voie, c'est déjà un gros progrès par rapport à son armoire pleine de cartes perforées.

Envoyé par Lazyjoe

("mais où qu'elles sont donc mes instructions avx512 quand je compile pour le skylake ???").

Je confirme que c'est une feature :
https://software.intel.com/en-us/art...-2018#zmmusage

**Lazyjoe** · 04/11/2017, 14h39

Envoyé par Møgluglu

Je confirme que c'est une feature :
https://software.intel.com/en-us/art...-2018#zmmusage

Whaaaaaaaat !
Je vais tester ça avant que le proto qu'on nous a prêté reparte.

**Møgluglu** · 04/11/2017, 15h06

Je suis curieux de voir si tu arrives à obtenir un speedup en forçant AVX-512 ou si icc avait raison de rester en AVX2.

**Lazyjoe** · 04/11/2017, 18h43

Moi c'est ifort je rappelle. Bon déjà l'option semble y être aussi.

Fin bon le plus gros de mon boulot ce deux dernières années a été de réorganiser un gros code pour qu'il soit vector-friendly sur la partie calcul, mais ça se paie sur les accès mémoire. Pour l'instant, on a eu des résultats positifs que sur le knl en avx 512. Si ça ne marche pas aussi sur skylake, on peut jeter mon boulot.

**Foksadure** · 05/11/2017, 23h16

Envoyé par Lazyjoe

Imprimer du code...

On voit que vous n'avez pas connu la programmation sur mainframe BULL finissant, avec un code hérité, mi-généré, mi-monstre issu d'années d'abus et de pratiques personnelles variées.
Sans parler des limitations du système empêchant d'utiliser des noms de variables explicites ou de mettre des commentaires.
Et des éditeurs plein écran sur émulateur de terminal 80 colonnes, sans fonctions de recherche avancées.
A un moment, le papier et le crayon étaient la seule solution pour s'y retrouver.
On avait même différentes versions des programmes sur listing, au cas où.
Avec les affichage des variables sur la console pour débugguer.
Et les classeurs de specs remplissaient des armoires entières.
Il y a seulement 20 ans.

**Nilsou** · 06/11/2017, 14h52

Plop les canards.
Alors j'ai un petit soucis de programmation qui semble simple mais me tourmente depuis quelques jours.

Voila j'ai un thread principal et, dans ce cas précis un second thread qui se "réveille" de temps à autres par le thread principal.
Pour ce faire j'utilise les semaphore façon sem_wait et cie. C'est du C, posix et tout ça je précise.

Jusqu'ici pas de soucis.

Mon soucis vient quand je doit répondre (proprement) à la question : comment faire en sorte de communiquer à d'autres thread/instances que le thread est dans un état "eveillé" ou non?
Je m'explique.

Dans le thread principal je vais avoir un truc du genre :

Boucle ->

Blabla

Reveil_le_thread

Et dans le thread un truc du genre :

Boucle ->

Attends_le_reveil
blibli

Si on écrit ce qui se passe dans les sémaphores, en fait le semaphore à quasiment tout le temps la même valeur. Vu que le thread secondaire est très rapide, c'est le thread principal ici la limitation. Donc le sémaphore attends (valeur -1), se fait réveiller par le thread principal (valeur 0) et immédiatement se faire décrémenter par le thread secondaire. Résultat des courses, la valeur n'est à 0 que durant une infime fraction de temps processeur (et si le thread secondaire est sur un processeur distinct qui ne sert qu'a ça, on ne voit jamais le cas en réalité).
Il m'est donc difficile ici d'utiliser la valeur de sem_t pour savoir si j'ai éveillé le thread (si je suis dans blibli).

Une solution consiste alors à mettre un autre flag juste après "Attends_le_reveil" mais la je m'expose à un cas d'erreur, rare, mais possible (et c'est ce qui m'a fait détecter le soucis) puisque rien n'indique qu'un quelconque test sur une valeur dans blibli, même si c'est la toute première instruction, ou la toute dernière, n'arrivera pas pile de façon desynchrone (les tests pouvant tourner sur d'autres thread/processeurs) .

Exemple :

Boucle ->

Attends_le_reveil
Je_suis_reveillé=1
blibli

Si un test a lieu dans un autre thread entre Attends_le_reveil et Je_suis_reveillé, alors il ne peut ni se fier à Je_suis_reveillé, qui est faux (0) ni à la valeur du semaphore de attends_le_reveil, qui perd toute signification à cet instant.

Bref, je cherche une solution propre ... j'en ai pas trouvé pour le moment de vraiment convenable ...
SI quelqu'un connaît une astuce ... ce fut la cause d'un bug exotique dans un des gros programme de mon labo ...

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Autres questions qui n'a rien à voir. Quel est l'état de l'art pour optimiser en C/C++ (ou plus bas niveau) des tableau de strctures ?
Je m'explique, dans mes programmes j'ai bien souvent besoin de la notion objet vu les programmes que je manipule. Mais je me retrouve tout de même à traiter dans de longue boucle des sous éléments de ces objets/structures.

Typiquement :
for (i,i++)
{
mon_objet[i].bidule ++;
}

Problème, les structures "mon_objet" peuvent être lourde et donc mon_objet[1].bidule peut être fort loin dans la mémoire de mon_objet[2].bidule, ce qui m'interdit d'avoir aux optimisations, explicites ou implicites des instructions processeurs moderne pour la parallélisation des opérations dans les boucles. Pas sans passer par des recopie dans des tableaux intermediaire.

Ce qu'on me recommande souvent c'est de faire des tableau des sous ensembles, type bidule[i] directement.

Mais ce n'est pas pratique pour la lisibilité du code (c'est carrément affreux en fait). Est-ce qu'il n'y a pas moyens de faire en sorte, à la limite, idées comme ça, que d'un point de vue code ça reste sous le format objet mais que le compilo traite ça comme des alias et me ponde un joli tableau séparé ?
Je suis ouvert à toute autre solution évidemment me permettant d'avoir accès aux deux avantages ...

**Lazyjoe** · 06/11/2017, 16h12

Hum pas tout à fait clair ton histoire de threads... Les autres threads/instances vont exécuter le même code ?

Ce que je verrais : tout simplement mettre en place un mutex autour des accès à Je_suis_reveillé, et une condition pour attendre la création du thread depuis le principal.

En gros :

Thread principal :

Code:

pthread_mutex_lock(&mut_reveil);
Reveille_le_thread();
while (Je_suis_reveille == 0) pthread_cond_wait(&signal_reveil, &mut_reveil);
pthread_mutex_unlock(&mut_reveille);

Thread fils :

Code:

...
//je suis reveille !
pthread_mutex_lock(&mut_reveil);
Je_suis_reveille = 1;
pthread_cond_signal(&signal_reveil);
pthread_mutex_unlock(&mut_reveil);

Et dans un autre thread pour voir si le fils est reveillé :

Code:

pthread_mutex_lock(&mut_reveil);
if (Je_suis_reveille == 1)  printf("Nafl'ftaghn !");
pthread_mutex_unlock(&mut_reveil);

Ainsi, aucun conflit possible. Si le thread est actif ou inactif, on peut tester la variable, si il est en cours de reveil (ou d'endormissement, il faut gérer le passage 1 -> 0 dans le mutex évidemment) le thread demandant son état attendra la libération du mutex pour savoir ce qu'il en est.

**Møgluglu** · 06/11/2017, 16h51

Envoyé par Nilsou

Mais ce n'est pas pratique pour la lisibilité du code (c'est carrément affreux en fait). Est-ce qu'il n'y a pas moyens de faire en sorte, à la limite, idées comme ça, que d'un point de vue code ça reste sous le format objet mais que le compilo traite ça comme des alias et me ponde un joli tableau séparé ?
Je suis ouvert à toute autre solution évidemment me permettant d'avoir accès aux deux avantages ...

Ça peut se faire avec un peu de soupe de templates, du genre ça :
http://asc.ziti.uni-heidelberg.de/si...11ASX_CUDA.pdf

Pour ton problème de synchro, si j'ai bien compris tu veux synchroniser dans l'autre sens pour que ton thread principal attende que le thread secondaire ait commencé à traiter l'événement ? Il ne suffit pas d'un autre sémaphore ? (ou mutex dans la solution de Lazyjoe)

Dans tous les cas je ne vois pas l'intérêt de la variable non protégée Je_suis_reveille, à part tester les limites du modèle de consistance mémoire de la machine.

**rOut** · 06/11/2017, 17h34

Envoyé par Lazyjoe

Hum pas tout à fait clair ton histoire de threads... Les autres threads/instances vont exécuter le même code ?

Ce que je verrais : tout simplement mettre en place un mutex autour des accès à Je_suis_reveillé, et une condition pour attendre la création du thread depuis le principal.

En gros :

Thread principal :

Code:

pthread_mutex_lock(&mut_reveil);
Reveille_le_thread();
while (Je_suis_reveille == 0) pthread_cond_wait(&signal_reveil, &mut_reveil);
pthread_mutex_unlock(&mut_reveille);

Thread fils :

Code:

...
//je suis reveille !
pthread_mutex_lock(&mut_reveil);
Je_suis_reveille = 1;
pthread_cond_signal(&signal_reveil);
pthread_mutex_unlock(&mut_reveil);

Et dans un autre thread pour voir si le fils est reveillé :

Code:

pthread_mutex_lock(&mut_reveil);
if (Je_suis_reveille == 1)  printf("Nafl'ftaghn !");
pthread_mutex_unlock(&mut_reveil);

Ainsi, aucun conflit possible. Si le thread est actif ou inactif, on peut tester la variable, si il est en cours de reveil (ou d'endormissement, il faut gérer le passage 1 -> 0 dans le mutex évidemment) le thread demandant son état attendra la libération du mutex pour savoir ce qu'il en est.

Le plus safe c'est :

Code:

pthread_mutex_init(&mutex, NULL);
pthread_mutex_lock(&mutex);

// [...]

pthread_mutex_unlock(&mutex);
pthread_mutex_destroy(&mutex);

/privatejoke

**Nilsou** · 06/11/2017, 20h37

Envoyé par Lazyjoe

Ainsi, aucun conflit possible. Si le thread est actif ou inactif, on peut tester la variable, si il est en cours de reveil (ou d'endormissement, il faut gérer le passage 1 -> 0 dans le mutex évidemment) le thread demandant son état attendra la libération du mutex pour savoir ce qu'il en est.

Merci pour la solution, je voulais éviter de rajouter des semaphores/mutex, mais bon, ça marche aussi

- - - Mise à jour - - -

Envoyé par Møgluglu

Ça peut se faire avec un peu de soupe de templates, du genre ça :
http://asc.ziti.uni-heidelberg.de/si...11ASX_CUDA.pdf

Hoooooooooooooooooo, j'ai pas tout lu mais je croit que ceci peut résoudre mon problème avec succés. Je vais lire ça à tête reposé ce soir.
Merci

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages