Sytoka Modon a écrit 4565 commentaires

Attention, le génie civil coûte une fortune ! Tranchée pour les câbles, foreuse, étude du sous sol. Je n'ai pas les tarifs mais je ne serais pas étonné que 50% du prix soit invisible ;-)

Les éoliennes sont de plus en plus puissantes et hautes -> fondations plus importantes.

Avec le temps, les fondations peuvent s'être fissurée, avoir vieillis… Pas facile de savoir si l'acier est toujours bon dedans. C'est ainsi qu'il est très rare dans les remontées mécanique de ré-utiliser les anciens socles d'il y a 30 ans. Cependant, je pense que les blocs de béton actuels sont bien plus robuste et conçus pour une durée de vie bien plus longue.

cest surement moins pire que nos villes

L'éolien en mer a un rendement quasi double, il est évident qu'il faille mettre les hélices au large dès que cela est possible techniquement. En plus, avec des éoliennes flottantes, il n'y a au fond que les câbles d'ancrage et un gros bloc de béton. Facile à déplacer si jamais il le faut ! Quand aux éoliennes sur les crêtes, ce sont rarement des terres cultivables…

Au sujet des fondations, je n'ai pas de chiffre sous la main mais cela me semble négligeable pas rapport aux barrages, voire à toutes les routes que l'on construit (et les ponts) !

Les surgénérateurs comme superphénix sont basés sur une mauvaise idée : le refroidissement au sodium liquide. Le CEA essaye de nous faire croire que la technologie est maîtrisé. C'est une folie de faire un circuit de transfert de chaleur avec du sodium, beaucoup trop dangereux. On a l'impression que le CEA n'a rien retenu des accidents graves…

Il y a une technologie très prometteuse qui résoudrait notre problème électrique pour au moins un millénaire, le temps de mettre au point la fusion, c'est le réacteur au sel fondus. C'est pas un gouffre financier hypothétique comme ITER ou SuperPhénix, les risques sont /a priori/ bien plus limités et les problèmes techniques qui restent à résoudre (passage à un vrai réacteur fonctionnel) bien plus à notre portée qu'ITER par exemple (dont on ne sais toujours pas comment on va récupérer les calories !). Mais le projet est porté par des chercheur du CNRS et ce n'est pas du tout un projet assumée par les pontes du CEA qui ont tous été formé à l'école Phénix ! A noter que le sel fondus n'a pas /a priori/ d'intérêt militaire…

http://fr.wikipedia.org/wiki/R%C3%A9acteur_nucl%C3%A9aire_%C3%A0_sels_fondus

On voit que le béton se dégrade au final assez rapidement sans rien faire ;-) C'est un peu la différence avec le nucléaire, les durée et la dangerosité n'est pas du tout la même. Un bloc de béton sous terre est il réellement dangereux ?

Et il faut voir la quantité de bentonite injecté dans les montagnes pour chaque barrage…

Il me semble que le build de Debian tourne déjà (en partie) sur un cluster Amazon…

Dans le même ordre d'idée, sur un fichier HDF5 (ou NetCDF4), est-il capable de lire un morceau d'un tableau sans tout charger en mêmoire ? C'est un peu le défaut des modules classique qui ne fonctionne pas avec de gros volumes de données.

Autre question, Pandas gère t'il le format VTK ?

s/c'est les gros packages/ce sont les gros paquets/

F90 rajoute les modules donc c'est à partir de là que tu as du mangling. Si tu ne fais pas de module, tu fait du F77 caché dans l'appellation F90 mais c'est pas du Fortran moderne… C'est avec cette notion de Module que sont généré automatiquement les .mod, équivalents des .h du C qui permettent une vérification forte du typage dès la compilation.

Avec F2003, il y a l'héritage simple mais on sais tous que c'est facile a émuler puisque qu'en gros, un cast suffit (c'est ce que fait GTK). C'est pour cela que je considère (come d'autre) que la bascule importante a eu lieu avec F90.

En calcul numérique, cela peut être bien plus simple de faire du Fortran. En C, tu te fais chier avec les valeurs, les pointeurs et les références… En Fortran, tout passe par adresse. Il y a tout plein de code matlab que tu fais facilement en Fortran par exemple. De très nombreux thésards n'ont aucun notion de programmation en démarrant…

Évidement, il n'y a aucun intérêt à faire du Fortran pour un clickodrome ou un serveur web. A chacun son domaine. Moi j'aime bien aussi la philosophie Erlang ou tout est immutable et passe par copie ;-)

Le support du Fortran par GCC est très loin d'être nul, c'est pas parce que c'est pas dans LVVM que GCC ne fait rien ! Le support des Co-Array est en cours (Fortran 2008 de tête), les Co-Array sont des tableaux qui fonctionne de manière transparent sur un cluster. C'est faisable avec MPI et/ou OpenMP (sur un noeud) mais ici, l'API est simplifié. La bascule vers des codes parallèle est importante et ne doit pas être que l'affaire des spécialiste. Fortran cherche sa voie très calcul numérique. A chacun ses choix.

C et Fortran ont une ABI compatible (il suffit de mettre les underscores au bon moment, au bon endroit

C'est complètement faux !

Tu parles du Fortran 77, une très ancienne version qui a plus de 35 ans… Depuis le Fortran 90, le Fortran moderne, il y a la notion de Module donc d'espace de nom et chaque compilateur gère le mangling comme il veut. Cela va même plus loin car l'ordre des champs dans un type est laissé au choix du compilateur par défaut (ce qui n'est pas le cas en C) pour des questions de performances et d'alignement…

Fortran est aujourd'hui un langage objet (héritage simple). C'est un langage qui a énormément évoluer (c'est pour cela qu'il n'est pas encore mort), bien plus que le C.

Merci de ne pas reprendre bêtement la phrasologie "nazis de l'interface". Le nazisme, c'est cela :

http://fr.wikipedia.org/wiki/Nazisme

On dis souvent les plus grosses vacheries à ses collègues de bureau mais bon, c'est souvent du second degré ;-)

D'après Wikipédia http://en.wikipedia.org/wiki/Name_mangling

En C++, le "name mangling" n'est pas standardisé. Ils donnent des bonnes raisons même si en pratique, c'est très chiant. Dès qu'on a deux compilateurs, il faut tout se retaper, toutes les lib !

C'est un truc qu'on est régulièrement confronté en Fortran avec gfortran et ifort. Il faut tout se taper en double (et on recommence tout à chaque fois que gfortran change son format, c'est à dire trop souvent). Je pense que c'est moins le cas entre g++ et icc (de mon coté, on n'utilise quasiment jamais icc). Mais cela risque de le devenir si LLVM se généralise de plus en plus et que le C++ de celui-ci soit incompatible avec celui de g++.

Bref, c'est vrai qu'avec le C, une bibliothèque est une bibliothèque qui marche pour tout (même si elle n'est pas forcément optimum).

Peut être une partie du problème viens que GNOME cherche à suivre MacOSX ou Android. Or ces OS ne suivent pas la tradition UNIX (X-Window) du copier coller par bouton du milieu, follow mouse, menu local…

Apple se fout de la compatibilité ascendante et coupe régulièrement les vieux trucs. Ce ne doit pas être évident de faire (en C) un toolkit généraliste qui fonctionne bien dans tous les paradigmes de UI ?

Ensuite, GTK viens de Gimp et non de GNOME… Ensuite, au dela du problème de licence de Qt, il y avait aussi le problème du langage. Qt utilise une surcouche de C++ et il n'était pas envisageable de tout basé sur ce C++. Il faut voir que le binding de bibliothèque C++ depuis d'autre langage n'est pas aussi évident que de partir du C.

Ceci dis, Fortran évite au maximum les pointeurs et a ajouté pas mal de possibilités via les ALLOCATABLE. Dans de très nombreux cas, cela suffit et pour la performance, c'est 100 fois mieux car les pointeurs sont en général une horreur lorsqu'on veut optimiser un code.

Les pointers du Fortran ne sont pas des pointers au sens du C. Tu n'as jamais accès à l'adresse mémoire. On ne les déférence jamais. Ca évite pas mal de chose… mais du coup, pour changer la réfèrence vers laquelle il pointe, on n'utilise pas l'affection = mais l'opération =>

Bref, ce sont plutôt des alias que des pointers…

Sur les Xeon haut de gamme par exemple, il y a plus de bus d'accès à la mémoire. C'est ce qui permet à SGI par exemple de faire des machines avec 4096 coeurs qui restent performant.

Si on veut concurrencer le x86_64 sur les calculateurs, il faut avoir une bonne unité de calcul flottant en double précision ainsi qu'une interconnexion efficace (par infiniBand ou équivalent). J'ai rien lu concernant la double précision dans la dépêche or c'est souvent le composant qui coûte cher et qui fait une partie de la différence entre les CPU intel haut et bas de gamme (en plus de capacité IO plus importante aussi).

Je suis d'accord, l'Itanium s'est planté car trop cher et ils n'ont jamais sortis de 'PC' de bureau avec. Il en a été de même quelques années avant avec l'Alpha qui a eu des PC compatible mais pas longtemps et pas à un prix concurrentiel. Pas facile de faire un tarif face à la très très grande série qu'est le x86 !

On le voit avec ARM qui y arrive lentement, non pas en jouant sur les PC, mais via les téléphones puis les tablettes ou la problématique est la consommation et ou les calculs en double précision ne sont pas important.

Enfin, ce n'est pas il y a quelques mois, cela fait maintenant des années ! Et ce genre de chose s'accompagne d'une grosse campagne de communication…

parce que là, je reste sur ma faim… On est alléché, on lit jusqu'au bout mais non, on n'a pas de le connaître ;-(

Tout le monde sais que Windows NT a été écrit en grande partie par des anciens de chez Digital… Un bon résumé de ce qui s'est passé :

http://windowsitpro.com/windows-client/windows-nt-and-vms-rest-story