Le topic de la programmation, string, chaînes, cuir et compagnie

[Tramb]

Une nouvelle commande git pour la prochaine version: http://git-man-page-generator.lokaltog.net/

[Tomaka17]

Une nouvelle commande git pour la prochaine version: http://git-man-page-generator.lokaltog.net/

J'ai absolument tout compris.

[Møgluglu]

Une nouvelle commande git pour la prochaine version: http://git-man-page-generator.lokaltog.net/

Excellent.

Je garde ça de côté pour les prochains qui essayent de me convertir à git.

[Tramb]

Arrête ça doit être un utilisateur Mercurial jaloux qui a écrit ce truc. Convertis-toi.
Tu sais le genre d'utilisateur Mercurial qui, pour avoir un patch utilisable, est obligé d'utiliser l'argument -g : http://selenic.com/hg/help/export

[shlagevuk]

Un cour du MIT sur l'optimisation du code, bon c'est en anglais et le professeur est indien ce qui n'aide pas niveau accent. Mais le cours est vraiment très intéressant, les choses sérieuses commencent à environ 30 minutes de la vidéo.

Pour résumer, par des optimisations assez simple, sur une multiplication de matrice, il multiplie les performances par 200000.

[Tomaka17]

Non mais après son code de départ est en Java, tu multiplies les perfs par 1000 rien qu'en changeant de langage

[Teocali]

Non mais après son code de départ est en Java, tu multiplies les perfs par 1000 rien qu'en changeant de langage

ouaip, t'economise allez, 10 secondes. mais comme il te faut 3 heures de plus pour faire la meme chose, je suis pas sur que ce soit rentable sur le long terme :contre-troll:

[Tomaka17]

C'est pas mal d'économiser 10 secondes sur une opération de 10.01 secondes.
Et puis l'autre avantage du C, c'est que je n'ai pas les yeux qui brûlent et l'envie de vomir quand je code :contre-contre-troll:

[shlagevuk]

Pour éviter les trolls:

En fait rien qu'en java, en optimisant tu peux augmenter les perfs par un facteur de 1117... Je vous conseil réellement de voir la vidéo!

[Teocali]

C'est pas mal d'économiser 10 secondes sur une opération de 10.01 secondes.

Certes. Comme disait l'autre c'est encore plus beau quand c'est inutile

Et puis l'autre avantage du C, c'est que je n'ai pas les yeux qui brûlent et l'envie de vomir quand je code :contre-contre-troll:

Non, ca ca arrive quand tu vois les messages d'erreur a l'execution... soit environ toutes les demi-heure pour un dev milieu de gamme :contre-contre-contre-troll:

(La regle c'est que Le premier qui est ban pour flood a perdu ?)

[rOut]

Pour éviter les trolls:

En fait rien qu'en java, en optimisant tu peux augmenter les perfs par un facteur de 1117... Je vous conseil réellement de voir la vidéo!

Ben forcément, comme il se tape par défaut le boxing / unboxing de chaque élément de la matrice, c'est pas très difficile de faire 1000x mieux.

---------- Post added at 01h00 ---------- Previous post was at 00h53 ----------

En fait c'est intéressant, mais seulement après, une fois qu'il est passé au C et qu'il a éliminé toute la partie objet et abstraction inutile (pour une multiplication de matrices quoi). A partir de la page 33: http://ocw.mit.edu/courses/electrica...2F10_lec01.pdf

Par contre pour arriver au gain de 300000x, c'est plus juste des optis simples, il sort l'artillerie lourde à coup de BLAS et de parallélisation.

[Tomaka17]

Je suis tombé là dessus ce matin : http://blog.codinghorror.com/the-inf...between-words/
Tu ne peux qu'imaginer la situation où ce seraient des humains qui exécuteraient une après l'autre les instructions machine.

[TiNitro]

En fait c'est intéressant, mais seulement après, une fois qu'il est passé au C et qu'il a éliminé toute la partie objet et abstraction inutile (pour une multiplication de matrices quoi).

Oui, je suis d'accord, on peut d'ailleurs critiquer la confusion entre approche objet et code inutile, il aurait pu templatiser pour pouvoir gérer différents types de résultats, il aurait pu conserver l'encapsulation en utilisant l'inlining etc... Mais ça ne change rien à son boulot, c'est très bien fait.

Ça me rappelle un spécialiste des compilateurs XL IBM qui avait montré que permuter deux boucles imbriquées (multiplication de matrices toujours je crois) permettait de rester dans le cache et accélérait de plusieurs ordres de grandeurs.(EDIT: c'était il y a 23 ans je crois...)

Sinon, utiliser de l'encapsulation pour une multiplication de matrice, rOut, ça m'a sauvé la vie le jours ou je me suis rendu compte que dans certains cas mes matrices étaient presque toujours creuses. Ça nous a permis de changer la représentation interne des matrices sans rien casser ailleurs et de gagner en consommation mémoire et en CPU de façon inespérée.

[kpouer]

Pour les optimisations au delà des trucs évidents genre pas de unboxing ou éviter les trucs objets inutiles, un truc qui marche dans tous les langages c'est tenir compte de la prédiction de branches:

http://stackoverflow.com/questions/1...unsorted-array

[Møgluglu]

En fait c'est intéressant, mais seulement après, une fois qu'il est passé au C et qu'il a éliminé toute la partie objet et abstraction inutile (pour une multiplication de matrices quoi). A partir de la page 33: [URL]http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall-2010/video-lectures/lecture-1-matrix-multiply-a-case-study/MIT6_172F10_lec01.pdf

Ce que je trouve dommage, c'est que les perfs sont présentées à l'envers. On s'en fout du speedup par rapport au code le plus débile qu'on puisse écrire (ça ne veut rien dire vu qu'il n'y a aucune limite à la débilité).
C'est le slowdown par rapport à l'optimal ou une borne sup qui nous intéresse. Pour le produit de matrice dense c'est facile, y'a qu'à compter les flops et comparer avec la fiche constructeur du CPU.

[Orhin]

RDJ (personnelle, ça doit exister depuis un bail) : du tri en O(n), le radix sort

[Tramb]

Trèèèèèès utilisé dans l'industrie du rendu pour trier des masses de trucs suivant z, par exemple.

[Møgluglu]

Il y a aussi une implémentation électro-mécanique, une machine pour trier les cartes perforées, quand on a trébuché et foutu tout le paquet de 10000 par terre. D'où l'utilité de bien numéroter ses lignes sur les premières colonnes en Fortran.



Ah, on me signale que ce n'est plus vraiment d'actualité...

[TiNitro]

Nan, mais dans mon 1er boulot les mecs n'arrêtaient pas de me parler de cartes... J'étais paumé jusqu'à ce que je comprenne que même s'ils avaient de beaux terminaux, pour eux une ligne de FORTRAN c'était une "carte".

Je ne vous raconte donc pas comment il a fallu gérer l'évolution vers l'objet, C++ toussa....

Cela dit, j'ai toujours un petit paquet de cartes FORTRAN sur le coin de mon bureau, et quand intellisense me fait remarquer que j'ai oublié un pont virgule ou une parenthèse fermante, je vois le bon côté de l'évolution.

[deathdigger]

C'est comme parler de clefs étrangères aux mecs de l'AS400.
Pour eux, c'est un fichier logique (ce qui peut être traduit un peu comme une vue pour nous)

[TiNitro]

Vouais un peu, c'est vrai. StrSql, c'est un truc de geek, quoi...

[Tomaka17]

Nouvelles propositions C++ :

Un objet pour remplacer __FILE__, __LINE__, etc. sans utiliser de macro : http://isocpp.org/files/papers/n3972.pdf
Enlever les trigraphs : http://isocpp.org/files/papers/n3981.html
Coroutines : http://isocpp.org/files/papers/n3985.pdf
Getters/setters : http://isocpp.org/files/papers/n3984.pdf
Réflection sur les fonctions membres : http://isocpp.org/files/papers/n3987.pdf

[dyblast]

Réflection Type traits sur les fonctions membres : http://isocpp.org/files/papers/n3987.pdf

[Tomaka17]

Il faudrait plutôt appeler ça "function traits" alors.

[rOut]

Ca m'a l'air assez pourri tout ça quand même.

[Tramb]

Ouep, mais j'ai confiance dans l'écosystème pour empêcher tout bloat de features non vraiment intéressantes.
Et surtout il faut laisser reposer C++11 histoire qu'il soit ubiquiteux.

[Tomaka17]

Je viens de jeter un coup d'oeil à la glibc.
Je ne savais même pas qu'il était possible de définir une fonction comme ça :

void
_ufc_doit_r(itr, __data, res)
     ufc_long itr, *res;
     struct crypt_data * __restrict __data;
{

---------- Post added at 18h17 ---------- Previous post was at 17h49 ----------

En fait le code source de la glibc, c'est une véritable plongée dans les bas fonds du langage C.

Apparemment à l'époque on pouvait définir une fonction à l'intérieur d'une autre fonction.
Je ne vois même pas comment ça peut encore compiler.

---------- Post added at 18h21 ---------- Previous post was at 18h17 ----------

Ah oui quand même.

ctx->total[1 - (BYTE_ORDER == LITTLE_ENDIAN)] += bytes;

[Tramb]

Reliquat d'une époque ou un ternaire était trop souvent compilé en branche, même évaluable à la compil'.

[rOut]

Je viens de jeter un coup d'oeil à la glibc.
Je ne savais même pas qu'il était possible de définir une fonction comme ça :

void
_ufc_doit_r(itr, __data, res)
     ufc_long itr, *res;
     struct crypt_data * __restrict __data;
{

---------- Post added at 18h17 ---------- Previous post was at 17h49 ----------

En fait le code source de la glibc, c'est une véritable plongée dans les bas fonds du langage C.

Apparemment à l'époque on pouvait définir une fonction à l'intérieur d'une autre fonction.
Je ne vois même pas comment ça peut encore compiler.

---------- Post added at 18h21 ---------- Previous post was at 18h17 ----------

Ah oui quand même.

ctx->total[1 - (BYTE_ORDER == LITTLE_ENDIAN)] += bytes;

Les fonctions imbriquées c'est une extension GNU, c'est des lambdas avant l'heure.

La déclaration des paramètres/variables en dehors du bloc de la fonction, c'était la syntaxe pre-ANSI C.

Le dernier truc, je ne vois pas vraiment le soucis, à part que c'est pas très lisible (et encore ça pourrait être bien pire).

[Tomaka17]

Bon, je craque.
J'essaye tout simplement de compiler crypt(3) sous windows, mais y a pas moyen. Je vais y passer des heures.

Et je n'arrive pas à trouver d'implémentation alternative qui soit à jour (c'est à dire qui gère aussi SHA, blowfish et MD5).