lasher a écrit 2738 commentaires

Beurk. Et si j'ai un tableau à 5 dimensions? Dans un cas j'ai tab(i,j,k,l,m), qui fait correctement ce qu'il faut, dans l'autre, j'ai tab[i][j][k][l][m] qui fabrique tout plein de proxys juste pour pouvoir émuler la notation des tableaux classiques en C...

Je suis bien d'accord. :) Cela étant dit, je parlais de langages de plus haut niveau en général, pas uniquement de Java (Perl, Ruby, Python, etc. sont pour moi de bons candidats).

Je crois que tu as tort. :)

Les noyaux de calcul (par exemple une tuile pour faire une multiplication de matrice) ont généralement des bornes fixées à la compilation (en fonction de la taille des différents niveaux et tailles de cache, etc.). Cependant, on se retrouve avec des algorithmes généraux pour gérer des tailles arbitraires. Dans les codes de HPC que j'ai croisés jusqu'ici, les bibliothèques pour le calcul intensif sont bien entendu optimisées et spécialisées, mais les programmes traitent des entrées de taille arbitraire.

Non mais attends, c'est même pire que ça, en plus, si tu veux faire dans le multidimensionnel, C++ c'est nul, il faut passer par () et pas par [], parce que sinon ça passe pas. Quel fourbe ce Bjarne !

Concernant le modèle mémoire de C, il ne faut pas s'attendre à des miracles. Quand on voit le modèle suivi par C++...

Eeeeuh, tu es sûr de ton coup là ? Parce que tout ce que je vois, c'est une lvalue et une rvalue qui utilisent le même objet. Du coup, c'est un comportement indéfini, si je ne m'abuse (et le compilo peut faire ce qu'il veut, même décider d'aller commander un sandwich sur le net s'il veut).

Je suis plutôt d'accord (même si toutes tes réponses dans les commentaires de cette dépêche ont tendance à être un chouïa trop agressifs à mon gout...). Hors domaines extrêmement spécifiques comme l’embarqué [1], le calcul haute performance [2], et dans une certaine mesure les jeux vidéo [3], le reste du temps, je préfère des langages qui me garantissent plus de choses que ce que C et C++ offrent. J'adore le C, j'aime bien le C++, mais c'est parce que j'ai un coté bidouilleur (et que je bosse dans le HPC, donc C+assembleur c'est assez fréquent). Par contre bizarrement, quand j'ai du traitement de chaines a faire de façon un peu intelligente, ou bien d'autres petits traitements (sur potentiellement de gros volumes de données), je ne sais pas vous, mais je préfère quand même bien plus des langages de plus haut niveau ou en tout cas qui vont me permettre de réduire mon temps de développement (grâce a une bonne analyse statique, parce que le langage lui-même propose des constructions de haut-niveau tels que des tables de hachage, des tableaux dynamiques, etc.).

Le C et le C++ ne devraient être utilises selon moi que si la performance est un enjeu critique pour la majorité de l'application. Dans l’idéal bien sûr, on voudrait de la performance partout. En pratique, optimiser un bout de code pour une architecture particulière peut prendre des semaines, voire des mois. Et à, c'est en supposant qu'on est certain que l'algo utilise est le meilleur pour la tache donnée (et dans un contexte donnée).

[1] Je parle vraiment de matériel avec juste "une" tache bien spécifique a réaliser (avec des contraintes de puissance de calcul et d'espace mémoire drastiques), pas un machin qui peut se permettre d'avoir une JVM embarquée...
[2] Par calcul haute performance, je pense au traitement vidéo, a diverses simulations en physique et chimie, a l'utilisation de gros calculs mathématiques (par exemple de l’algèbre linéaire creuse ou dense), mais aussi au parcours de graphes en parallèles.
[3] Dans une certaine mesure parce qu'une bonne partie est réalisée a l'aide de langages de scripts customisés pour un moteur donné.

Cf. la réponse de brendel pour les problèmes de bornes.

Fortran ET C sont de relativement bas niveau. Les deux forcent le programmeur à faire attention à ce qu'ils font pour (presque) chaque ligne de code. Cependant, Fortran propose EN PLUS des construction spécifiques pour le calcul (addition de vecteurs, etc). J'aurais pu être plus explicite, il est vrai.

Si le compilo peut le faire de toute manière, bien sûr que ce serait cool. Cependant, ça va juste retarder le moment où tu vas devoir repenser ton algo pour gérer des entrées au problème 100 fois plus grandes...

En haute performance, on utilise pas la vérification automatique de dépassement de taille de tableau, car le seul moyen de le faire correctement, c'est de vérifier les bornes pour chaque accès (et ça coûte énormément en temps CPU). C'est un des cas où l'utilisation de Fortran, C ou C++ a plus d'intérêt que Java par exemple:

• C te force à tout penser, et puisque de toute manière on parle de calcul haute-perf, ça « va de soi » (et c'est bibi qui doit optimiser le tout ensuite...)
• Fortran propose tout un tas de constructions de relativement haut niveau concernant le calcul scientifique. Par exemple, si A et B sont des tableaux de même taille, je peux faire A=A+B et le compilateur va automatiquement générer le bon type de code: SSE pour x86/x86_64, Altivec pour PowerPC, etc.
• C++ n'est pas qu'un langage orienté objet. Comme le dirait S.Meyers (Efficient C++), il s'agit de plusieurs « langages » (ou dialectes) en un: C, C-avec-classes, templates, et STL. En HPC, on a tendance à utiliser C++ en tant que C + templates + surcharge des opérateurs (pour pouvoir reproduire ce que Fortran permet de faire nativement, et étendre le tout à de nouvelles structures données).

Oui, c'est ça le problème : un bon algo peut te faire gagner un facteur 1000, là où la micro-optimisation ben, un facteur 10 c'est déjà pas mal...

D'après mes vagues souvenirs d'analyse numérique, tout le principe de l'A.N. c'est de rendre un problème qui utilise le domaine continu en problème « discret » et linéarisé (à l'aide d'approximations). Et beaucoup, beaucoup de problèmes situés dans le continu sont des problèmes non linéaires (systèmes d'équa diff non-linéaires, résolution d'équations utilisant des attributs trigonométriques, intégrales elliptiques, calculer des gradients conjugués, etc.).

Pourtant ils proposent de définir numériquement des intégrales, utiliser des intégrales de Fresnel, avec sinus et cosinus dedans¹... Même si tu n'utilises pas leurs algos, tu as l'expression mathématique de ces derniers. C'est bien ce que tu voulais non ?

[1] Chapitre 6, "Special Functions", section 6.9

Je sais que Hugo Leclerc (ENS Cachan, labo de méca) bosse sur une sorte de DSL de haut-niveau pour mécaniciens. Tu peux peut-être le contacter pour voir s'il a des idées.

Sinon question bête : as-tu essayé de trouver « Numerical recipes in C » sur le net ? Y'a des versions légales qui sont téléchargeables (mais pas libres), avec maths+code naïf en prime (pas libres non plus).

Tiens, un lien ici :

http://apps.nrbook.com/c/index.html

Je te conseille de lire ou - encore mieux - d'assister à une representation de Dieu, de Woody Allen. Il a plein de truc à dire à ce sujet... :)

Pas d'accord. J'ai lu Neuromancien en français, puis en anglais (puis en anglais une deuxième fois). La traduction française est très en deçà de la VO (ce n'est pas le cas pour d'autres romans de Gibson, par exemple Lumière Virtuelle est, je trouve, correctement traduit).

Donc ma question est : « as-tu lu le livre en VO ou VF? » (pas que je veuille me la péter ni rien hein, mais, s'il y a plein de fois où l'adaptation est très fidèle, dans le cas précis de Neuromancien, ce n'est pas le cas).

C'est vrai, mais pour le coup c'est bien chiant. Parce qu'en Anglais, « consistency » et « coherency » ont deux sens bien distincts.

Il n'est pas payé à chaque fois que sa boite utilise son code. La différence est principalement à, à mon avis.

Oui, erreur de ma part. Il s'agit de Grapelli.

La créativité se fait aussi dans l'interprétation. Pour reprendre mon exemple avec Y.Menuhin : un compositeur a écrit un « Menuet pour Menuhin » (Erik Satie je crois bien). Il y a une raison à cela : tout artiste a une façon propre d'interpréter une œuvre (quelle qu'elle soit). Que tu considères que l'interprétation soit pourrie, soit. Que tu la trouves « mécanique » (pour faire le lien avec ta qualification de « technicien » faite précédemment), pourquoi pas. Mais il s'agit d'un avis purement subjectif, et par là-même, dénué de critères ... objectifs. :)

Pour résumer : dès lors que tu acceptes le fait que certains artistes (de génie) interprètent bel et bien une œuvre (musicale, théâtrale, cinématographique, etc.), tu ouvre la porte à toutes les fenêt^W^W^W^W au fait que le génie de l'un est le producteur de croûte de l'autre (pour reprendre l'exemple de V. Van Gogh). Et là où toi tu mets une limite, cette dernière peut être parfaitement différente pour quelqu'un d'autre.

C'est lumineux ! ©®™

Et dans la vraie vie, y'a plein de physiciens, numériciens, etc., qui veulent à fond de la double précision (souvent à raison), et puis un jour s'aperçoivent que ben, s'ils « omettaient » certains facteurs — genre une décimale, disons celle des dizaines de milliers, est fixe — du coup ils auraient besoin de moins de bits pour coder leurs nombres, et donc le risque d'imprécision baisserait mécaniquement, au point que la simple précision serait suffisant (histoire vécue).

La vraie vie, c'est aussi l'infographie, qui certes se fait le plus souvent via une carte spécialisée, mais parfois aussi sur des super-calculateurs (quand il s'agit de rendu mais pas en temps réel).

Hou la la, fatigué moi. :+)

Oooops. Quelque part pendant la saison 2 œuf corse.

Non.

Déjà, la première saison de Buffy fait 13 épisodes. Ensuite, dès le départ il y a un « fil rouge » (le Maître), qui présage une sorte de boss de fin de niveau, et qu'on va quelque part. Enfin, les personnages et l'histoire en règle générale était (est) bien moins stéréotypée, surtout comparée à ce qui existait à l'époque.

Enfin, pour ce qui est de Fringe, de ce que m'expliquait mon collègue, on n'a même pas cette grosse révélation en fin de saison 1 (ce qui pourrait inciter à continuer à regarder la série ensuite), mais quelque part pendant. Or, sans ça, cette série ressemble beaucoup à une resucée de X-Files plus ou moins mise au goût du jour, mais avec des personnages bien moins charismatiques (et là encore, X-Files avait un semblant de fil rouge malgré tout, à travers l'homme à la cigarette par exemple, ainsi que certains autres personnages récurrents).