Même si j'ai pas eu le temps de regarder ou de jouer avec, y'a pas un ligne de python dans Presto AFAIK.
Après ce qu'il faut bien comprendre, c'est que si tu veux un truc efficace tu dois construire un truc adhoc parfaitement adapté à un besoin précis. On ne peut pas comparer des choux et des carottes.
Quand tu parle de python, tu parles bien de python sans cython/pythran and co?
Oui.
Tu as beaucoup moins de hotspot précis et isolés que dans un contexte HPC.
Une fois que tu as le design et les algo corrects pour résoudre ton problème, il reste que tout ton code va grosso modo boucler de quelques centaines de millions à quelques milliers de milliards de fois. Dans ces traitements tu as beaucoup de code métier qui fait pas forcément grand de méchant chose mais qui coûte. Pas du tout adapté à une approche cython/pythran si python n'est pas capable de fait le job.
Après tu as quelques fois des vrais bon vieux Hotspot où tu peux te faire plaisir. Mais en général ca sert à rien de les optimiser avec toute la lourdeur que ca implique si tu rames sur le reste.
Bref c'est pour ca que Java/Scala sont pas mal utilisés dans ce domaine. C'est un compromis acceptable entre facilité et rapidité de déploiement/écriture et les perfs atteignables. Après dès que t'es sur une boucle qui demande du SIMD, tu prends une énorme tatane et tu fais un binding natif si c'est vraiment un job clé et qui va te coûter du pognon. Mais d'une manière générale on cherche pas l'efficacité mais simplement que ca tourne de manière acceptable. Contrairement au HPC, ca bouge beaucoup trop vite pour avoir le temps de peaufiner.
Je m'excuse si je passe à côté de quelque chose et je peux avoir tord mais ici j'arrive pas à voir ce que je manque: j'ai toujours cette vision de la compression de maillage 3d basé sur un octree et un ordre de morton où python me tue les performances par rapport au C++ (simd etc...)
Heu je crois qu'on dit la même chose:
C/C++ peuvent être très rapide et fortement tordu quand tu as une petite base de code à optimiser fortement.
Python ça permet d'écrire des trucs crado mais lent rapidement. Ca permet aussi d'optimiser des petits bouts de code précis quand tu as des hotspots.
Java c'est un compromis qui est relativement rapide tant que t'as pas de SIMD (pas d'auto-vectorisation du tout) au pire tu peux optimiser comme tu le ferais avec Python.
Ca veut pas dire qu'il faut jeter python, il a parfaitement ses usages. Surtout que très souvent les batchs de prod récurrents sont minoritaires. Mais tu semblais dire que ca ne change pas grand chose quand t'es IO bound, alors que d'expérience en big data grosso faut compter 3 à 10x plus lent qu'un truc écris proprement en Java. Franchement de l'IO bound au sens strict du terme, pas souvenir d'en avoir vu des masses. En général tes batchs suivent difficilement un flux disque ou réseau bien compressé comme il faut.
[^] # Re: Et MPI ?
Posté par ckyl . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 3.
Même si j'ai pas eu le temps de regarder ou de jouer avec, y'a pas un ligne de python dans Presto AFAIK.
Après ce qu'il faut bien comprendre, c'est que si tu veux un truc efficace tu dois construire un truc adhoc parfaitement adapté à un besoin précis. On ne peut pas comparer des choux et des carottes.
Oui.
Tu as beaucoup moins de hotspot précis et isolés que dans un contexte HPC.
Une fois que tu as le design et les algo corrects pour résoudre ton problème, il reste que tout ton code va grosso modo boucler de quelques centaines de millions à quelques milliers de milliards de fois. Dans ces traitements tu as beaucoup de code métier qui fait pas forcément grand de méchant chose mais qui coûte. Pas du tout adapté à une approche cython/pythran si python n'est pas capable de fait le job.
Après tu as quelques fois des vrais bon vieux Hotspot où tu peux te faire plaisir. Mais en général ca sert à rien de les optimiser avec toute la lourdeur que ca implique si tu rames sur le reste.
Bref c'est pour ca que Java/Scala sont pas mal utilisés dans ce domaine. C'est un compromis acceptable entre facilité et rapidité de déploiement/écriture et les perfs atteignables. Après dès que t'es sur une boucle qui demande du SIMD, tu prends une énorme tatane et tu fais un binding natif si c'est vraiment un job clé et qui va te coûter du pognon. Mais d'une manière générale on cherche pas l'efficacité mais simplement que ca tourne de manière acceptable. Contrairement au HPC, ca bouge beaucoup trop vite pour avoir le temps de peaufiner.
Heu je crois qu'on dit la même chose:
Ca veut pas dire qu'il faut jeter python, il a parfaitement ses usages. Surtout que très souvent les batchs de prod récurrents sont minoritaires. Mais tu semblais dire que ca ne change pas grand chose quand t'es IO bound, alors que d'expérience en big data grosso faut compter 3 à 10x plus lent qu'un truc écris proprement en Java. Franchement de l'IO bound au sens strict du terme, pas souvenir d'en avoir vu des masses. En général tes batchs suivent difficilement un flux disque ou réseau bien compressé comme il faut.