lasher a écrit 2731 commentaires

Sauf que faire du multi-processus ça veut dire installer tout un tas de mécanismes pour pouvoir passer les données à son processus voisin, alors qu'avec le multithreading les données sont partagées. Et surtout, la consommation mémoire est moindre pour une application multi-threadée comparée à son équivalent multi-processus.

OK. Si on parlait multithreading sur systèmes multi-cœurs/multi-processeurs ? Ah ben zut, python fait pas. :-/

Ben je suis assez d'accord en fait. Une des premières sources de bugs dans les programmes c'est quand même les problèmes de gestion mémoire. D'ailleurs ce n'est pas pour rien que Boost en C++ permet d'avoir des pointeurs « magiques » (avec comptage de références). Alors certes, ça implique une certaine perte de perfs, mais qu'est-ce qu'on y gagne en temps de débogage !

Hem. Je suis plutôt d'accord avec toi sur le fait que Java n'est pas si mauvais en termes de perfs, mais il y a quelques limites quand mêmes ... Parce que bon, tes histoires d'algos d'analyse numérique, s'il s'agit d'algèbre linéaire dense par exemple, sauf à avoir des classes qui en réalité passent par du C en sous-main, malheureusement Java est derrière le langage C. Il y a d'autres domaines où au contraire Java rivalise sans rougir avec C++ bien sûr.

Mais quand même globalement, en termes de consommation mémoire et de rapidité, quand la latence réseau n'est pas le facteur limitant, Java reste globalement moins rapide que C (après parfois il s'agit d'un « à peine moins rapide » et du coup, autant se simplifier la vie et rester sur Java, bien sûr).

« Je me demande si il existe un successeur à NFS qui est capable de faire de la réplication mais en privilégiant au maximum la machine local qui lit et écrit les données (GFS ?). »

Je ne sais pas si la machine locale est privilégiée, mais Lustre n'est pas censé être un successeur de NFS dans le cadre du calcul haute performance ?

Mais (neuneu != dev)
Certes, mais sysadmin != dev. De la même façon qu'on ne demandera pas à un admin de faire plus que scripter pour l'admin justement (je me vois mal demander à un sysadmin de développer une application critique temps réel pour faire décoller une fusée), je me vois mal demander à un dév de faire de l'admin. Oh, il finira peut-être par faire marcher l'appli, mais ce sera certainement au mépris des règles d'admin et/ou de sécurité élémentaires, vu que c'est pas son boulot, et qu'il ne sait pas forcément quelles contraintes il doit respecter.

Dans ton post, on peut d'ailleurs substituer « dev » par « admin » et « programme » par « config ». Ce qui commencerait comme ça : « On en connaît tous des configs mal faites. Elles sont mal faites lorsque l'admin est un neuneu. [...] »

Les bibliothèques oui je sais, tout comme les pamphlets de Céline ou autres... Et il faut montrer patte blanche pour y accéder (ie « être du métier » : journaliste, traducteur, universitaire, etc). Maintenant étant donné que l'incitation à la haine raciale est interdite en France, j'aimerais bien savoir comme un truc comme Mein Kampf pourrait être en vente libre ici ... Si c'est possible, il doit bien y avoir une raison officielle non ?

Hum, en France le livre est aussi interdit à la vente.

Admettons plein de trucs. Admettons que le disque était quasi-neuf. Admettons qu'on sait quel OS se trouvait sur le disque avant de le récupérer, et même quel FS et avec quelles versions. Admettons que du coup, grâce à notre expert local en dév linux/ext3 (par exemple), on sache où sont passés des pans importants du système sur le disque (quels secteurs, etc.), et donc qu'au final, on sait plus ou moins où trouver les fichiers de "/home". Bon, même comme ça, ton linux, sur un disque dur de 100 Go, il fait peut-être 10 à 20 Go (en étant optimiste).

Même en sachant que /home n'occupait que (disons) 40% du reste (soit 40% de 80Go, soit 32 Go), il reste encore à trouver notre aiguille dans la meule de bits que représentent ces 32 Go. Si je cherche une information précise, ça risque de prendre un temps sacrément long à retrouver. On parlait de crypto un peu plus haut, et quelqu'un disait que les problèmes de crypto étaient plus difficiles à résoudre. Du point de vue mathématique très certainement, mais du point de vue « combien de temps me faudra-t-il pour récupérer l'information, et celle-ci sera-t-elle toujours pertinente au moment où je l'aurais trouvée ? », je ne pense pas qu'on soit si éloigné des bonnes méthodes cryptographiques en termes de résultat : imaginons que je récupères mes bits 1 à 1, histoire d'avoir mes 87% de chances de récupérer mon image disque, combien de temps cela aura-t-il pris ? Passons ensuite des codes de correction d'erreur, des algos permettant de récupérer des infos, tout ça ... Là encore, combien de temps ? (Sans parler des risques d'erreur lors de la récupération des données, bien sûr)

Et une dernière chose : sur le disque des chinois du FBI ou de la marine, ils chiffrent pas les données ? :-)

En même temps, tu as déjà vu le warning affiché par gcc si tu utilises gets() ?

C'est vrai, mais par exemple, un compilateur comme icc qui génère du code SSE assez facilement (ie du moment que le code est assez régulier pour le justifier, sans if ou while imbriqués) refusera systématiquement de générer ledit code SSE si on lui dit qu'on veut coller exactement à la norme IEEE 754 (ou son équivalent double précision). Il doit bien y avoir certaines hypothèses de commutativité donc (je passe sur le côté "sur x86 je stocke les nombres sur 80 bits en interne avant de les refoutre sur 64/32 bits") quand on demande au compilo d'optimiser.

je pense que ceux qui utilisent les OS alternatifs, il y en a une majorité qui font du multiboot et donc qui ne peuvent pas scratcher tout le disk, donc nous sommes en contradiction.

J'avais l'impression que de plus en plus de gens passaient par la virtualisation pour tester de nouveaux OS... En tout cas c'est ce que je fais.

C'est drôle, après avoir eu droit à tout un tas d'installations plus ou moins graphiques, j'ai trouvé que celle qui me convenait le mieux était celle d'OpenBSD. Une fois qu'on a compris le système de « slices », il y a très peu de questions, et l'installation est réglée en 15 minutes pour le système de base. Ça change de machins genre CentOS, Ubuntu ou autres, où il faut absolument passer par 36 écrans (certes, la plupart du temps il suffit de cliquer sur next, mais c'est long).

tant qu'on y est : « packet » => « paquet »

Euh, les Blue Gene/L et autres calculateurs d'IBM tournent quand même en grande majorité sous Linux ...

En 2005-2007, c'était de l'ordre de 30-36 k€ bruts / an pour un ingé fraîchement sorti de l'école.

certains codes assez malins sont organisés par exemple pour intercaler des additions de nombres positifs et négatifs pour éviter les dépassements, et il suffit d'un bête échange d'opération qui semble anodin pour faire un overflow

Juste une petite remarque : sur un processeur tel que le x86 ou le PowerPC, intercaler ce genre d'opération ne garantit absolument rien quant à l'ordre des opérations, vu que le système out-of-order va choisir dans quel ordre émettre les instructions (en fonction de la place restante dans la station de réservation). Ce qui pourrait presque rendre « caduque » certaines transformations du compilateur d'ailleurs. Tout dépend du coup de la chaîne de dépendances qui existe entre les registres (i.e. plus j'ai des registres dont le contenu sert à mettre à jour d'autres registres, moins l'exécution dans le désordre aura d'effet ... mais du coup plus on sera potentiellement limité dans le parallélisme d'instruction).

Mmmmh, ça sent la propagande crypto-communiste d'un prof de fac ça ... O:-) Bon bon. Sinon, je corrobore ce que dit Cédric.

... Et proposent aussi des menus sans porc pour permettre aux enfants de juifs et musulmans de pouvoir manger à la cantine le midi.

Dans la constitution US, y'a juste marqué que tout homme a le droit de défendre sa famille, pas qu'il peut acheter une bombe thermo-nucléaire.

« Ils se trompent de cible ? ils visent trop large ? ils s'en branlent. »
Forcément, puisqu'ils ont récupéré les magasines des toutous et des madames dessous.

La norme du C dit qu'il y a promotion d'entier vers flottant si au moins l'un des opérandes en présence est lui-même un flottant. Comme en plus il n'y a pas de garantie sur l'ordre des opérations (sauf si on met des parenthèses), ça s'applique à toute l'expression.

Entierement d'accord sur ton second point cela dit.

Et moi pas. :-)
Je me sers de langages de script pour prototyper pas mal de trucs. Pas forcément une grosse appli monstrueuse, mais le temps que je gagne à développer ces trucs (et parfois à faire de mes petits scripts des modules qui re-servent à mes collègues) fait gagner un temps fou en dév. Après, il y a aussi des fois où je fais un rapide prototype en Perl, et ensuite je code le truc pour de bon en C (parce que par exemple, j'aurai besoin d'avoir une bibliothèque qu'on puisse directement appeler).

Malgré tout, des langages comme Ruby ou Python, qui ont tout un tas de très bons mécanismes intégrés au langage, sont tout à fait viables pour faire des applis « sérieuses ». [1] Faut-il être plus vigilant du fait que ce sont des langages à typage dynamique (par exemple) ? Pas sûr, après tout, Python fait dans le typage fort, et renvoie des exceptions et tout ce qui va avec comme les autres langages de haut-niveau.

Après quelques mois de dév Java, j'ai eu au contraire l'impression inverse : le langage est tellement rigide qu'il force à faire des contorsions pas possible là où parfois il existerait des raccourcis tellement pratiques. Mais c'est le prix à payer pour un typage fort et statique, je suppose, et aussi au fait que je devenais aigri à devoir faire du Struts/Hibernate/JBoss/JSP/JSP/JSP. Surtout JSP en fait.

Quand je suis retourné à faire du Perl par la suite, tout un tas de choses compliquées en Java me semblaient quand même vachement plus simples à accomplir avec Perl.


[1] Perl aussi selon moi, mais j'avoue avoir beaucoup de mal avec la façon dont Perl gère la programmation orientée objet, du coup je ne programme que de bêtes modules pas OO.

Il ne s'agit pas forcément de cas si particuliers que ça. Par exemple, les compilateurs sont très bons pour optimiser du code avec des accès réguliers à la mémoire (et le matériel aide aussi quand il peut). Si on doit y rajouter les indirections dues aux objets (accès aux méthodes et membres des classes), tout un tas de if, etc., on peut perdre le compilateur. Même si le branchement est prédit non pris au bout d'un moment, il y a un certain nombre limité de branches qu'il peut conserver en mémoire.

De plus dans le cas de code scientifique par exemple, typiquement un solveur itératif, il n'est pas rare d'avoir des accès de type

for (i=1; i<m ; ++i) {
____for (j = 1; j < n; ++j) {
________v1[i][j] += a + (v1[i][j-1] *v1[i][j+1]) + b + v1[i-1][j] * v1[i+1][j] + ...;
}

Bien entendu il s'agit d'un code factice, mais l'idée est là. On a même des cas où plusieurs vecteurs se mélangent. Dans ce cas précis j'ai pris un tableau 2D, donc le terme de « vecteur » n'est certes pas le meilleur, mais c'était pour illustrer mon propos.

Concernant mon post précédent, je faisais 2 remarques, orthogonales l'une de l'autre :
1/ Un langage n'est pas obligé d'imposer une seule façon de traiter les structures de données, pour tout un tas de raisons (et je prenais C++ en exemple, qui propose les deux mécanismes, à cause de certains problèmes de perf); de plus même si le langage n'impose qu'une seule façon (« Java »), il n'est pas dit que ce soit la seule bonne façon de faire, et la façon de gérer cela par d'autres langages n'est pas nécessairement moins mauvaise : tout dépend des objectifs qu'on se fixe.

2/ Concernant Ruby spécifiquement, renvoyer nil (ou undef en Perl) n'est pas nécessairement une mauvaise chose, et je parlais du fait que parfois j'ai une sortie « imparfaite » de mes scripts Perl, mais « suffisamment bonne » pour que je puisse quand même me servir de ces résultats, ne serait-ce que partiellement (je me sers beaucoup de Perl pour analyser la sortie de fichiers au format CSV ou pas très loin du CSV dumpés par mes programmes, et adapter les données à mes besoins). Par exemple, à cause d'une erreur de ma part, le script peut avoir raté une ligne (je n'avais pas prévu un certain type de format de ligne, et du coup mon script ne sait pas le gérer), mais le calcul en lui-même n'est pas forcément faux pour le reste des autres lignes du fichier que je veux traiter. Dans ce cas je préfère un warning qui me dit que je divise par 0, que j'essaie de faire des trucs avec une variable non-définie, etc, mais que le programme continue de tourner pour pouvoir quand même espérer détecter une tendance par exemple, plutôt qu'avoir un programme qui s'arrête parce que euh, ben, « Y'a une exception, là, et je sais pas quoi en faire, donc je stoppe tout. ».

Tout ce que je voulais dire, c'est que si (par exemple hein) en C++ on a décidé de proposer les deux méthodes, ce n'est pas pour rien. Il y a des fois où la performance *est* importante, et les exceptions se mettent en travers. Et au final, la réflexion concernait le fait qu'il n'y a pas de solution unique, et que le « tout exception » n'est pas forcément quelque chose de voulu ou de souhaitable. Tout dépend l'état d'esprit dans lequel on programme.

[à propos des exceptions] Certes, ca va ralentir un peu les perfs.
Non. Si tu fais un accès dans une boucle, ce n'est pas « un peu ». Alors c'est sûr, si tu comptes parcourir tout le tableau/la liste/le vecteur/etc, il vaudrait mieux utiliser un itérateur, mais parfois, on ne peut pas (la variable d'induction sert pour indexer d'autres structures, etc).

Qu'on soit bien d'accord je suis à fond pour l'utilisation de langages de haut-niveau, avec tous les mécanismes modernes qu'ils peuvent procurer, et ce le plus souvent possible. Mais il y a des fois où ils se mettent en travers de la performance, car trop présents implicitement. Dans ces cas-là, j'aimerais pouvoir « désactiver » certaines fonctionnalités (par exemple en utilisant v[i] à la place de v.at(i) en C++ :-) ) qui font que mon programme ne va pas assez vite (après avoir fait du profiling, vérifié que je ne faisais pas de la micro-optimisation pour rien, etc, bien entendu). Avant de passer à du « pur C » ou encore pire, de l'assembleur, j'aimerais bien que le langage, ou plutôt l'environnement, me laisse désactiver certains mécanismes qui me semblent superflus dans une région de code bien précise.

La façon de faire de Ruby pour l'accès aux tableaux est très semblable (identique ?) à ce que fait Perl. Quand je code en Perl, je suis conscient de ça, et c'est pour ça que j'ai les warnings à fond tout le temps, parce que l'implicite, c'est bien, mais je préfère avoir l'interpréteur qui continue de faire tourner mon code, mais qui m'avertit quand j'ai des valeurs indéfinies qui sont quand même utilisées. Ça ne bloque pas mon programme pour autant (même si souvent ça le rend "faux", ie le warning n'était pas prévu), mais parfois l'erreur que j'ai introduite n'est pas grave, au sens où le résultat que je recherche est quand même là. Bon évidemment, je finis toujours par tomber sur un cas où ça va sérieusement m'empêcher d'avancer dans mon boulot, et je dois bien arriver à faire taire ce #@! d'interpréteur qui m'avertit que je gruike un peu trop ... et donc changer mon code. :)

Concernant les NullPointerException, la différence, c'est que même en C où un programme pourrait tout à fait continuer longtemps avant de planter tout en donnant un résultat erroné, avec un pointeur NULL, ton programme plante, et c'est tout (et en ce qui me concerne, je ne fais que du C ou presque, et si j'ai un segfault, au moins je sais qu'il y a une erreur, et j'ai un point de départ pour la trouver). On aura donc du mal à la capturer. :-)