Le 21 janvier 2019 à 23:45:17 blackapplex a écrit :

Le 21 janvier 2019 à 23:33:15 godrik a écrit :

probablement un type variant maison

maison c++17 ( https://en.cppreference.com/w/cpp/utility/any , moi non plus je savais pas que ça existait avant de l'utiliser)

Ah, je n'avais pas vu qu'il avait foutu un type varaiatn dans C++ 17.

Du coup ça permet de faire certains trucs aussi salement qu'en Python. Après la mentalité C++ du "JE VEUX CONNAITRE LE TYPE A LA COMPILATION" te rattrape toujours

En meme temps, la presence de typing fort et toujours non ambigu est l'une des raison qui faiat que C++ a de meilleur perf que la plupart des languages de script.

Bah ouais je sais bien, faudrait un entre-deux, ou un compilateur qui devine un peu mieux ce qu'on veut faire

C'est pas vraiment un probleme de compilation. C'est un probleme de langage et de specification souvent. Les langages de scripts sont souvent specifie de facon qui permettent tout et n'importe quoi. Et c'est pour ca que les gens les aiment souvent. Mais ca rends le bousin completement impossible a optimiser par l'interpreteur ou le compilateur.

Souvent si tu supportes les type variants, ca veut dire que tout ce que tu manipules est des variants. Donc tous les access de variables se doivent commencer par verifier le type et ensuite acceder a la variable. Et ca tue completement les perfs de devoir faire ca. Dans certains cas tu dois pouvoir etre sur du type et contourner l'utilisation de variant. Mais c'est souvent plus difficile du point de vue du langage que les developpeurs ne le pensent.

Si je ne sias pas le type de retour d'une fonction, je suis obliger de verifier le type deretour avant de l'utiliser. Et en python, ce truc la est valide:

def greeting(name: str) -> int:
    return 'Hello ' + name

greeting ("erik")

Et c'est une horreur complete. Et ca c'est un cas simple par ce qu'au moins ca retourne toujours un string, meme si ca declare autre chose. Mais tu peux avoir des cas plus merdique que ca. Je te presente une infamie complete:

def bar(name: str) -> int:
    if name == "Erik":
        return 2.0
    return 14


print (bar ("Erik"))

print (bar ("erik"))

Le type de retour depend du parametre passe en entre. Ce truc ca tue toutes tentative d'optimization au niveau de la compilation/interpretation. Si n'importe quoi peut retourner n'importe quoi. Ca veut dire que je ne peux etre sur de rien. Et donc, l'outil doit toujours supposer le pire et verifier tout a chaque fois.

C'est pas mal en soit. Mais quand quelqu'un me dit que c'est possible de faire du Python rapide. Non, ce n'est pas possible. Le langage n'est pas specifie pour qu'il soit possible de rendre le langage rapide.

Il y a des merdiers comme ca en C aussi. Un classique est celui la:

void f(int* a, int *b, int *c) {
*b = *a+2;
*c = *a+2;
}

Tu pourrais croire que ce code ne va lire le contenu de a qu'une seule fois et que le compilateur va produire le meme assembleur que si le code etait:

void f(int* a, int *b, int *c) {
int res = *a+2;
*b = res;
*c = res;
}

Et si le compilateur ne le fait pas, les gens pensent que c'est que le compilateur est pourri. Mais en fait, le compilateur n'a pas le droit de faire cette optimisation parceque a et b pourrait overlapper.

Mais typiquement sur ton exemple du C ca va dans le sens de ce que je pense, le compilateur doit être suffisament malin pour se dire que PERSONNE overlap des zones mémoires, et au pire il prévoit une option supplémentaire pour les fous qui n'ont pas de sens de la logique

gcc --i_dont_care_about_logic

Et du coup ce qui est sale c'est de pas préciser le type là où il y en a besoin si je me rappelle bien.
Si je fais "any a = 2.16", c'est ok qu'il peut supposer que c'est un double (non?)
Si je fais "cout << any_cast<double>(a) << endl;", c'est propre ou pas? A la compil il connait le type, mais est-ce que le cast se fait sans ralentissement?

+lokilok ouais tu as raison, j'ai confondu avec autre chose (les unions sont suffisament bien foutus pour juste prendre la place mémoire la plus large, (même si ça reste sale))

Le 22 janvier 2019 à 19:07:05 blackapplex a écrit :
Mais typiquement sur ton exemple du C ca va dans le sens de ce que je pense, le compilateur doit être suffisament malin pour se dire que PERSONNE overlap des zones mémoires, et au pire il prévoit une option supplémentaire pour les fous qui n'ont pas de sens de la logique

gcc --i_dont_care_about_logic

Bah, il y a des tonnes de cas ou c'est le comportement voulu. Typiquement des que tu fais des unions, ou de la gestion memoires. Mais fondamentalement le langage defini que la, il peut y avoir de l'aliasing et donc le compilateur ne doti pas optimiser.
Ils ont fini par rajouter un keyword dans le langage (restrict) qui indique qu'un pointeur n'est jamais utiliser pour acceder un alias de quelquechose qui vient d'un autre pointeur.

Et du coup ce qui est sale c'est de pas préciser le type là où il y en a besoin si je me rappelle bien.
Si je fais "any a = 2.16", c'est ok qu'il peut supposer que c'est un double (non?)

Si tout s'inline bien correctement, il doit pouvoir faire ca. Mais si tu as un appel de fonction qui sort du scope du compilateur et qu'il y a potentiellement un pointeur qui peut remonter a cette variable, alors le compilateur ne peut plus rien supposer. En principe si la variable est sur la pile, il devrait pouvoir deviner.

Si je fais "cout << any_cast<double>(a) << endl;", c'est propre ou pas? A la compil il connait le type, mais est-ce que le cast se fait sans ralentissement?

any_cast envoie une exception. Ca veut dire que le code a un test. Apres est ce que le compilateur arrive a savoir a la compilation que le test est vrai et donc le retirer. Ca doit etre possible dans certains cas. Parcequ'un code qui fait:

int a = 1;
if (a>0) {
//dosomething
}

en pratique sait optimiser ca. Mais comme je disais au dessus si le code est:

int a = 1;
foo(&a);
if (a>0) {
//dosomething
}

avec foo une fonction qui n'est pas dans le scope a la compilation probablement pas. Si le pointeur est const, je ne sais pas si il arrive a faire ca. Parcequ'il y a des facons de faire sauter les const. Et donc pour que le code reste correcte, ce n'est pas sure qu'il ne faille pas le test. (La c'est un type primaire const, tu as une chance, mais si c'est un objet, la possibilite de l'utilisation de mutable probablement fait sauter l'optimisation.)

Encore une fois, ca depend completement de comment le langage est specifie et pas de comment les programmeurs comprennent (ou utilisent) les outils.

Ok je vois, en bref optimiser à l'opération assembleur près c'est UN TOUT PETIT PEU difficile si on a pas de connaissance préalable de ce qui est possible ou non pour le compilateur...

Osef ils ont qu'à faire des processeurs plus gros *va utiliser un binding python - java qui fait des appels via des commandes systèmes Perl à un script PHP*

J'ai oublié de préciser "*dans un émulateur"

Bah l'argument de "on va avoir un plus gros processeur, donc rien a foutre" a marche de 1980 a 2005. Donc ca a plutot bien marche comme argument globalement. Bon ca fait en gros 15 ans que l'argument ne marche plus...

En vrai, tu as des gains vachement plus important qu'une instruction assembleur en particulier. Par exemple, tu ne peux pas saturer la bande passante du systeme (proc-dram) sans utiliser d'instructions vectorielle. Souvent les langages interpretes ne peuvent faire que du scalaire parceque tout est alloue dynamiquement un par un. Donc tu jette un facteur 8 sur les instructions (theorique, 3 en pratique) et un facteur 2 sur la memoire (pratique).

Apres c'est pour ca que tu fais du numpy et du tensorflow. Pour faire efficacement le gros du boulot. Et faire le reste avec un langage plus simple a ecrire que du C

Ouaip. Et d'ailleurs j'ai une question sur le sujet je sais pas si tu vas savoir répondre.
En Tensorfow il y a un tf.while qui crée une boucle dans le graphe de calcul, ce qui n'existe à priori pas en Pytorch où tu ne construis pas de graphe de calcul et où ton réseau de neurone calcule tes appels sans connaitre les futurs instructions à executer (il calcule convolution(a) au moment où l'instruction Python s'exécute)
Dans Pytorch pour faire une boucle, tu dois donc passer par un for en python.
Théoriquement, sans même prendre en compte un besoin d'exécution parallèle, tu penses que l'itération dans une boucle python ajoute une latence par rapport à l'itération dans le tf.while_loop de Tensorflow?
En gros la question c'est est-ce que Python a en théorie un gros ralentissement sur ses boucles for relativement à une boucle C++ (suppression des variables du contexte local etc..?)

J'ai pas regarde des masses pour etre honete. Quand j'ai commence a me demande si je devrais regarder ces trucs la, je me suis rendu compte que je connaissais directement 20 numericiens, et 30 personnes de HPC qui avaient completement change leur recherche pour regarder uniquement ces trucs la a plein temps; sans compter les quelques potes a Google, NVIDIA, Baidu, et Facebook qui me disait qu'il y a en gros trois etages de chaques boites qui ne font que ca. Donc je me suis dit, ptet que ca sert a rien que j'aille la dedans...

Les gens qui ont pondu ces trucs la, ils savent ce qu'ils font dans l'ensemble, ca m'etonnerait qu'ils n'aient pas bencher le cout concret de repasser dans l'espace python pour faire ca. Apres tu as peut etre des cas degenere si tu regardes de tres petites convolution sur de tres petites image ou du fait, le retour dans l'espace Python pourrait devenir plus cher relativement. Mais j'imagine que ce n'est pas si gros que ca.

Ce qui m'etonne plus c'est la perte de pipelinage que tu as si tu n'as pas le graphe de calcul entier... Mais peut etre qu'ils se dise que ca sera fait au niveau de python (voir de C++) dans une vraie applis.

Ouais le contexte en prod est pas le même

Bonjour

Non, bonsoir.

Shananas

La forme ?

Mes comptes tombent comme des mouches.

Salutations

Le 29 janvier 2019 à 17:35:49 Ranma__Saotome a écrit :
Mes comptes tombent comme des mouches.

Vu que tu te fais ban et que tu change de pseudo à peu prêt tous les jours du coup, je vais finir par t'appeler "El Bannisso" ce sera plus simple

Bonsoir.

C'est pas la première fois que tu la sors celle-là.
El BannISSOU c'est mieux non ?

En tout cas rien n'a changé, je me fais toujours autant bannir qu'il y a cinq ans.
J'ai pas évolué, je sais pas s'il y a lieu de s'inquiéter.

Ouais je me disais bien que je l'avais déjà dit

Tu devrais quand même essayer d'être + relax et d'accepter que des gens ont pas forcément la même opinion que toi même s'ils ont tort

Je suis un peu le marché des prix des ordis portables (à perf "égales"), voir l'évolution, il y a quelques années je trouvais que ça stagnait, les critères principaux (taille du SSD, écran fullHD, processeur, gpu), pour des 15pouces, clavier rétroéclairé+pad numérique, 8Go RAM à 1k€
Aout 2017 : SSD 256Go, 1920*1080, quad core i7-7700HQ (2.8->3.8Ghz), gtx1050(2Go)
Février 2019 : SSD 256Go, 1920*1080, hexa core i7-8750H (2.2->4.10Ghz), gtx1050(4Go)
Le reste est pas équivalent évidemment c'est juste pour donner un ordre de grandeur pour ceux que ça intéresse. On voit qu'il y a aucune évolution folle sur 1an et demi, tout comme il y avait rien de fou les années qui ont précédé Aout 2017. Ce serait marrant de tracer des courbes sur les perfs voir le point de convergence. Je doute que pour 1k€ on aura un jour des SSD1To sur des ordis portables 4K octo-core 5Ghz et gtx1080 (et tout ça sans aucun bruit )
J'ai pas tout regardé mais c'est rare de voir des SSD256Go à moins de 1k, idem pour des GPU au dessus de GTX1050. Il y a parfois des offres qui font un tradeoff et qui baissent à 800€ pour des meilleures cartes graphiques mais en général c'est ponctuel.

Je me trompe peut-être, une vraie analyse serait cool, avec des stats de la data
Mais accessoirement sur les prix des cartes MicroSD je suis impressionné. T'as des cartes microscopiques à 128Go pour 50€ maintenant c'est assez impressionnant, ça fait relativiser les smartphones qui te chargent 200€ supplémentaires pour 60Go de plus.

Les laptops c'est trop cher pour ce que c'est.

(edit: Apple facture 110€ pour 128Go supplémentaire)
sachant https://www.darty.com/nav/achat/photo_camescope/carte_memoire/carte_micro/filtre__micro_sd_128_go__1280000344588.html
Ils sont forts.
Après j'imagine que c'est le surcoût du built-in, je sais pas s'il y a un port microsd sur les iphones. Et faut voir la durée de vie relative micro-Sd/iphone