Sytoka Modon a écrit 4538 commentaires

J'avais écrit 100% pour simplifier...

Effectivement, dans le classement de l'efficacité des machines, on ne retrouve pas IBM en premier mais NEC avec ses machines vectorielles puis SGI avec ses Altix.

Comme quoi, il faut toujours se méfier de la manière dont est réalisée un classement ou un comparatif.

A mon avis, ce n'est Windows qui ne tourne pas mais surtout les applications. MS ne peut pas mettre un Windows sur le marché si SQL Server, Exchange, Office... ne tournent pas bien, mais aussi les applications principales des éditeurs comme Adobe, Oracle...

Au niveau Linux et des *BSD, les OS tournent mais pas toujours les applications. Il suffit de prendre OpenOffice comme exemple...

MS ayant une stratégie purement commerciale, je la comprends un peu car je ne vois pas ce que lui apporte d'avoir un Windows multi-plateforme à part avoir plus de soucis. En plus, en temps qu'Ingénieur Sytème, je dois dire que la version 64 bits de XP me fait plus ch... qu'autre chose. Par ailleurs, avec l'extension PAE des processeurs x86, on n'a plus vraiment la limite des 4Go de RAM qui devenait bloquante en 32 bits (par exemple, mes serveurs Xen tournent très bien sous Debian 32 bits avec 6 Go de RAM).

Sinon, il faut être objectif, MS sais faire un OS multi-plateforme, il suffit de voir sa version embarqué de Windows. Ici le problème est différent de celui de la machine de bureau ou du petit serveur rack et il n'y a pas une architecture qui domine depuis des années. MS est donc obligé de s'adapter comme tout le monde à l'évolution rapide des architectures embarquées.

s/pourrait partie/pourrait tirer partie/

Par rappport à la dépêche que j'avais proposé (qui était pas si mal rédigé, snif snif...), le point que j'avais laissé de coté est la partie Itanium.

GCC était complètement largué sur Itanium par rapport au compilateur Intel car l'architecture EPIC oblige le compilateur à faire le boulot de l'optimisation des instructions. En effet, si on regarde l'architecture d'un Itanium par rapport à un x86, c'est beaucoup plus simple et du coup, Intel peut mettre bien plus de cache pour la même surface de silicium.

Cependant, on est en pratique obligé de travailler avec le compilateur Intel... J'espère que l'accélération dù à la version 4.2 va nous permettre de retravailler avec gcc.

Tu dis à peu près la même chose que moi. En effet, OpenMP est plus simple à mettre en oeuvre sur un Quad-Core, mais dans ce cas là, tu n'a pas 100 tâches mais au plus 4 (si tu te débrouilles bien car au dela, tu charge trop la machine et tu perds en global à cause des caches).

Maintenant, il n'y a pas beaucoup de machine SMP à 1000 coeurs (je connais les Altix de SGI par exemple). Ce sont souvent des clusters et donc les programmes sont réalisés avec MPI.

OpenMP est en effet bien plus simple à mettre en oeuvre et permet de gagner facilement du temps de calcul. Comme nous avons tous des machines SMP aujourd'hui, cette bibliothèque va être de plus en plus fondamentale sur le bureau.

Mais pour les gros calculs malheureusement, il faut plus se pencher sur ses algorithmes et prendre le temps de faire du MPI.

Pour les calculs titanesques (future machine pétaflop), il faut trouver une nouvelle manière de programmer. Ce n'est pas moi qui le dis, ce sont des spécialistes que j'ai rencontrer. Personnellement, je n'ai pas accès à des machines ayant plus de 32 coeurs... Je n'ai donc pas idée des réels problèmes qui se posent.

En effet, il n'y a quasiment aucun programme qui pourrait partie de 100% de la puissance d'une machine pétaflop aujourd'hui. Il n'y a donc pas encore de réel intérêt à construire une telle machine.

OpenMP permet de faire du calcul parallèle relativement facilement, c'est plutôt orienté pour les machines SMP comme par exemple les PC bi-processeurs dual-core. En effet, les quadri-coeur x86 ne sont pas encore au point pour le calcul intensif, notament à cause du goulet d'étrangement pour l'accès à la mémoire.

Sur plateforme Itanium, il y a de belles machines SMP, par exemple, les Altix de SGI qui permettent d'avoir en SMP plus de 4000 noeuds ! Heureusement, la gamme Altix permet de commencer plus modestement dans le SMP.

Pour finir, si on veut vraiment faire un programme parallèle sur les GROSSES machines, il vaut mieux se tourner vers la bibliothèque MPI. Très peu de programme OpenMP dépasse les 100 tâches sans perte de performance alors que MPI permet d'aller jusqu'a 1000 tâches. Au dela des 1000 tâches, de nos jours, très peu de programmes sont efficases et il y a un gros boulot d'ingénierie pour trouver des solutions.

En conclusion, pour le bureau et 99% des applications, OpenMP, c'est bon, mangé en ;-)

Je n'aime pas cette idée de compiler son gestionnaire de fenêtre pour le configurer. C'est ingérable pour les postes multi-utilisateurs... même si c'est bien pour l'embarqué.

Bien que le fait de ne pas avoir de cadre prédéfinit dans wmii me gêne, cela fait maintenant 15 jours que je suis dessus et il est parfois plus pratique que ion, notamment au niveau des fenêtres flotantes. J'aime bien aussi sa notion de pile de fenêtre. Comme quasiment toutes mes fenêtres sont des 'xterm', le fait de ne découper l'écran que verticalement ne me gène pas plus que cela.

En plus, la manière de configurer wmii est assez marrante. Cela change des autres getsionaires de fenêtre. J'étais pas fanatique au début mais je trouve cela assez efficase au final.

J'avoue que comme peck, je trouve que ton lien pointe vers un comparatif pas franchement explicite ;-)

Sinon, LibreSource, il peut prendre un trac en entrée pour en faire un LibreSource. Je pose la question à tout hasard pour mes trac mais aussi parce que les sites tournant sous trac pullulent sur le net aujourd'hui. C'est d'ailleurs une des raisons de mon choix vers trac, cela semble un petit outil pérenne et où j'ai pris mes marques très rapidement.

Personnellement, j'utilise en plus de vi l'éditeur nedit qui sais faire des sélections carré (Ctrl+Souris) et les déplacer. C'est très pratique.

Personnellement, j'utilise trac qui fait moins de choses me semble-t-il mais qui a l'air aussi plus léger. C'est juste du python au dessus d'apache. Par ailleurs, j'ai l'impression que trac est mieux intégré à subversion que LibreSource mais peut être que je me trompe.

Pour les petits projets que nous développons, il est clair qu'avoir un forum, de la messagerie instantanée... c'est bien mais pour les utilisateurs, cela commence à faire pas mal d'outil à maitriser.

Au moins avec trac, les utilisateurs utilisent une bonne partie de la plateforme.

Il est vrai que j'ai d'autres plateformes et que je ne souahite pas non plus que tout tourne autour de trac dans mon laboratoire de recherche...

Blague sexiste et un peu nunuche. Comment voulez-vous avoir des dames sur dlfp avec des commentaires pareils.

En plus, c'est pratique pour la conversation de la pause café du lendemain.

Mais c'est cela l'effet debian, même les trolls en tombent amoureux ;-)

J'avoue que c'est un des défauts des BSDistes, trop d'humour à toutes les lignes, ceal finit par me saturer et me donner une impression plutôt désagréable de secte.

Le 'camel book' n'était pas du tout comme cela, en tout cas l'édition 2. Au contraire, il y a dans ce livre de l'humour mais bien enrobé dans des phrases bien faites. Du coup, on ne voit pas toujours le second sens du premier coup. C'est beaucoup plus subtil je trouve.

Bref, pour moi, trop de BSD tue le BSD. Je ne sais pas lequel essayer en fin de compte. Surtout que j'ai été vachement deçu qu'OpenBSD ne tourne pas sous Xen.

Comment un système automatique décide pour un système multi-écran ?

Imaginons trois écrans, deux en xinerama pour une personne et l'autre pour une autre personne. Comment faire la configuration ? Etant l'utilisateur B, je refuse que l'utilisateur A puisse modifier la configuration générale.

Bref, des parametrage plus simple, ok, mais ne tombons pas dans le piège de Windows et d'Apple. Une machine UNIX se doit d'être multi-utilisateur dans son principe et l'utilisateur ne doit pas avoir par défaut les droits d'administration.

Si cette dérive est faite, les virus et autres cochonneries envahiront notre plateforme.

Je suis assez d'accord. Je ne comprends rien au python et je ne le trouve pas propre du tout avec ces __MACHIN__

Un truc super en perl c'est qu'une variable scalaire commence par un $. Cela, c'est vachement bien de séparer les variables des mots clefs.

Comme il a été dis, en perl6, ils ont éliminé pas mal de truc pas propre mais il est possible déjà de faire propre en perl5. Il suffit d'utiliser les bons modules.

Enfin, un gros avantages du perl, les programmes que j'ai fait il y a 10 ans en perl5_004 marche toujours tel quel !

Bref, il est de bon ton de critiquer perl de nos jours, surtout sur dlfp, notamment pour pousser vers python. Quand je vois dans une debian le nombre de version de python et les incompatibilités entre elles, personnellement, je n'ai pas envie d'en faire.

La radio n'est pas morte malgré tout ce qui a été prédis. C'est très pratique de ne pas avoir à faire sa programmation et d'écouter autre chose.

A une époque, erreur404 diffusais aussi de la vidéo. C'est pas extraordinaire comme film mais bon, Je vois que sur leur site, il dise que tv404, c'est de nouveau pour bientôt, mais sans date précise.

http://www.erreur404.org

Si quelqu'un a des informations plus fiables, je suis preneur.

PS : c'est aussi du P2P mais sans DRM chez erreur404.

Cela doit être la phrase fétiche

http://linuxfr.org/~Nyco/comments,139.html

Connaissez-vous l'intégralité du premier post de Nÿco sur dlfp ? C'était le 1 novembre 1999 :

J'arrête Linux demain !

Bravo Nÿco, n'arrête pas linuxfr.

Oui, pour troller !

Sauf que les dernières CRAY me font bien moins rêver. Les descendantes des CRAY sont les machines NEC mais elles sont hors de portées de la grande majorité d'entres nous.

Sinon, j'aime bien les Altix de SGI car ce sont des machines SMP très performantes et accessible financièrement.

Tout simplement merci.

Je ne fait plus de Fortran depuis quelques temps (5ans) mais les chercheurs autour de moi en ont l'air content.

Quel est l'intérêt d'augmenter la part du C sachant que le Fortran 95 est un langage de plus haut niveau, plus facilement parallélisable /a priori/ (il a été fait pour cela) et surtout que la notion de pointeur est limité au maximum afin de diminuer le risque de bogue.

Surtout que le Fortran 2000 amène la couche objet qui n'est pas dans le C ainsi qu'une interface normalisé pour faire des appels vers le C (un peu comme en Ada).

J'avoue que j'ai tenté un code-saturne.org comme pour Code_Aster mais le whois ne m'a rien répondu.

Pourquoi ne pas faire comme pour code_aster ? EDF ne souhaite pas rendre le développement plus communautaire ?

Pourquoi ne pas mettre Code_Saturne dans Code_Aster et ainsi marquer la convergence des deux.

Le numéro un mondial du calcul de structure, ANSYS (s'il est toujours numéro 1) a bien acheté un des gros codes d'élément finis : Fluent. Je pense qu'il a une stratégie d'intégration des deux à long terme.

D'ailleurs, je ne suis pas mécanicien des fluides mais qu'est ce qui distingue Code_Saturne de Fluent ?

Sauf que celui de BULL est unique dans le top 500. J'ai donc choisis dans la longue des machines de ne retenir que trois noms : un cluster car c'est la seule machine accessible aux petits budgets, la machine IBM car elle est très connu et IBM domine le marché des grosses machines, enfin la machine CRAY pour des raisons historiques. Cela fait toujours bien sur une plaquette de dire que son code tourne sur CRAY.