J'habite à Nantes de puis quelques années, et bien que j'y sois passé de temps à autre (au LUG Nantais, chez B17), et que j'y ai à chaque fois passé un agréable moment, avec des gens très très sympa, j'ai jamais accroché, en fait.
J'ai longtemps cherché pourquoi, et quelqu'un un jour m'a donné ce qui me semble être la réponse.
J'ai passé deux ans à Angers, et le Lug de là bas me manque beaucoup plus. Ce qu'il y a à Angers et qu'il n'y pas à nantes :
- Le fait de se rejoindre autour d'une bière chaque mois, ce qui est vraiment sympa.
- Et surtout, surtout : le fait que les personnalités, les expériences sont très diverses. On a de tout à Angers, des vieux de la vieilles, qui ont connu les début de l'informatique à la fin des années 60 (et là je restais bouche ouverte à écouter religieusement l'ancien), on a des entrepreuneurs, des étudiants, etc...
Linux-Nantes est peu être un peu trop marqué par la cohabitation avec les extrêmes gauchistes du B17, la tonalité est moins "ouverte", et j'ai l'impression que le fait de bosser dans une boite non "libre-compliant" est quelques part mal vu.
Donc évidemment, y a moins de monde, et on s'y sent pas tant à l'aise que ça, alors que les membres de l'assoc sont vraiment chaleureux.
'fin, c'est qu'une impression...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Quand j'ai "subi" VC++ 6, mes collègues m'ont expliqué que le seul moyen de faire des fonctions en C++, c'était le pointeur.
De même, quand j'ai voulu passer un paramètre sans le &, le compilateur m'a gueulé dessus, et on m'a expliqué pourquoi c'était pas possible.
Bon après, il parait que VC++ 6, c'est pas le meilleur.
Je ne connais pas C++ car pour moi, et c'est, je suis d'accord, un avis très très tranché, un langage dont la spec fait 500 pages c'est ------> poubelle.
Je pense pour ma part qu'une spec de langage, ça doit pas dépasser 80 pages, exemples compris. Un bon langage est minimaliste, pas bloated. Sinon on met des années à le maîtriser, on se complique inutilement, et à part faire plaisir aux quelqu'un comme toi, qui maîtrisent (très bien) la chose, on ennuie tout le monde.
Faut pas s'étonner que Java se soit imposé.
Cela dit, j'avoue que j'ai un peu regardé les templates pour piquer les rares fonctionnalités de c++ qui n'existent pas dans Lisaac, afin qu'on les y mettent. C'est en debug, ça va arriver bientôt.
Je me suis documenté sur les foncteurs en C++ (http://h-deb.clg.qc.ca/Sujets/Divers--cplusplus/CPP--Foncteu(...) : je ne sais pas si cette doc te parait valable )
Désolé, mais c'est un workaround tordu pour implémenter le type block bien connu des langages comme smalltalk/ruby/lisaac/io/...
Le type bloc est une fonction à évaluation retardé, elle peut recevoir un ou plusieurs paramètre et en renvoyer plusieurs (bien que ça dépende du langage)
Parce que franchement, utiliser les opérateurs pour redéfinir () et utiliser le constructeur comme foncteur, c'est tordu de chez tordu.
N'avaient qu'à implémenter le type block et ça aurait été réglé.
Le problème, c'est que c'est dur à compiler du block, et c'est très très dur d'avoir des perfs avec. Ils ont alors préféré faire un truc hyper compliqué, mais qui refile le sale boulot au programmeur.
Parce que tu sais ce que sont les templates en définitive ?
De l'analyse de flot codé à la main par le programmeur !
Comme le compilateur est beaucoup trop gros pour faire de l'analyse de flot lui-même et détecter les chemins de code à optimiser (évidemment, il y a 500 pages de specs à implémenter), en effectuant de l'évaluation partielle de code sur le code statique, on demande au programmeur de baliser l'analyse de flot parce que le compilateur ne sait pas le faire !
Je revient au type block : l'itérateur devient inutile, puisque tu fait ton foreach naturellement, et que le coût est exactement le même.
Ton idée de généraliser l'intersection est très intéressante : je la mettrai bien dans object.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Au passage vu que le kernel maîtrise la mmu, même si la mémoire physique est fragmenté, il peut la faire apparaître contiguë en virtuel (au appi).
Oui, mais elle est fragmenté en page de 4 ko, ce qui n'est pas très grave, vu que ta ligne de cache fait 64 octets.
Pour bien faire, il faudrait un gros malloc au début, et un gestionnaire mémoire interne au logiciel...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Et si on développait des moteurs à muscle animal, développé par génie génétique ?
Un humain, voire un animal, c'est chiant ça a une psychologie tout ça.
Tandis qu'un muscle couplé à un système digestif et respiratoire, c'est, ce me semble, le système le plus rentable au monde.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ah. Et dans les langage que tu cites, une fonction qui fait n'importe quoi, ca ne plante pas, et le compilateur verifie ? Pour toutes les valeurs de n'importe quoi, meme les grandes ?
En Smalltalk/Ruby/IO ça devrait planter à l'exécution.
En Lisaac, le compilateur te gueulera dessus à la compilation, et refusera de compiler.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est quoi l'objectif final de toute ces bidouilles, avoir de la généricité tout en gardant une vérification de type ?
Imagine, tu est dans l'objet Collection<E>
Tu veux faire une méthode d'intersection qui te permet de prendre une collection<F> en argument
et de rendre une autre Collection<E> qui soit l'intersection de E et F selon une fonction de comparaison
f(E,F) -> boolean |-> E == F; que tu vas lui donner en paramètre.
Par exemple, je sais pas, un exemple débile : F est un type date, E est un type String dont le contenu contient toujours un numéro d'année.
Tu veux la liste des string qui contiennent le numéro d'année (par exemple "2008") qui soit le même que la collection de date que tu lui donne en argument.
ça te permet de faire
Collection<E> list1,result;
Collection<F> list2;
result = list1.intersection(& F autreliste, * pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix);
Evidemment, sans type Block comme en Smalltalk/Ruby/IO/Lisaac, t'es obligé de passer par un pointeur de fonction, mais voilà la puissance est là :
Quand tu écris la fonction d'intersection, tu connais pas E, tu connais pas F, et ça marche dans tout les cas (pas en C++ parce que si ta fonction fait n'importe quoi... ça plante, et le compilateur vérifie pas)
loufoque nous donnera surement une bidouille pour contourner ça proprement !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est la philosophie du C++ qui me dérange. Et là, d'accord, ce n'est que mon avis.
Je suis pour des langages minimalistes. des langages définis avec une ou maximum deux dizaines de primitives, une dizaine de mots clé, admettons une vingtaine.
Si le langage est bien conçu et les primitives bien choisies, tu peux aller très loin.
Les langages à la smalltalk/ruby/io/lisaac ont ma préférence car ils sont minimalistes en étant bien plus puissant. Toutes les structures de contrôles sont définies en lib, et énormément de choses le sont avec des primitives de base.
En c++, tu pleures avec ton pauvre for et ton while.
Quand au template, c'est un problème de compilation : les templates servent à précompiler toutes les données statiques disponible à la compil. Un bon compilateur à analyse de flot sait le faire, sans imposer au programmeur de concevoir les templates.
En mettant en dur ta regexp dans une chaine, et la chaine à matcher, le compilateur est capable, par analyse de flot, de calculer la réponse.
Si la chaine cible n'est pas là, il compilera l'automate.
Pas besoin de template qui palie aux faiblesse d'un compilateur, sur lequel tous les énormes efforts sont portés à implémenter une norme pléthorique, plutot que de faire un compilateur puissant, mais simple.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Euuh, Le langage D propose quasiment tout ce que propose C++, Templates compris, avec une définition plus courte et une syntaxe beaucoup plus propre.
Eiffel.. euh non, mauvais exemple.
Aller, je vais quand même pas passer outre la défense de ma chapelle : Lisaac, permet de faire bien plus de choses qu'en C++, avec une définition beaucoup plus courtes, et même sans nécessiter de templates, le compilateur fait tout tout seul avec l'analyse de flot*, et ce avec sensiblement les mêmes perfs : http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)
Le génie, c'est de tout mettre tout ces concepts avec quelques primitives de base, et de produire un compilateur capable de tout faire, rapidement, avec celle-ci.
* Bientôt poussé à fond, ie. sur les collections statiques
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Aller je suis gentil, il n'y a *que* les 400 premières pages qui servent à définir le langage.
Le C++ est pire que l'administration française, c'est une accumulation de couche les unes sur les autres. A ce stade, ça devient de la sédimentation !
Alors, à la décharge des divers implémenteurs, je les comprends, je compatie à leur douleur, même.
Bon après tout, si de gens aiment des langages pas beau, mal conçu, avec des concepts certes très intéressant, mais qui constitue une véritable usine à gaz qui rend le code impossible à débugguer... Grand bien leur fasse.
Pour ma part, et moinssez moi, faites vous plaisir, je pense qu'il faut que ce langage disparaisse, et vite.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
D'après ce que j'ai compris, il retrouve les données de départ par analyse de flot (du pauvre, parce que SSA, c'est assez limité), et si elles sont pas trop loin, il les alignent.
Je suppose qu'il aligne toutes les données, de toutes façons.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Comme précisé dans cette news somptueuse, l'autovectorisation est en standard dans Gcc 4.3. On l'attendait avec impatience.
Qu'est-ce que c'est exactement :
Pour pas mal de type de boucle (celle-ci : http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vect(...) ) Gcc va être capable de produire du code MMMX, SSE, ou altivec sur powerPC. Voire, d'après ce que j'ai compris, du SPU du cell.
Ceux qui veulent lire des vidéos HD sur leur linux installé sur la PS3 vont être content (parce que pour avoir passé une après midi à essayer de le faire marcher, faire accéder au codec le spu du cell, c'est mission impossible).
Effectivement, si tu veux veux multiplier 3 matrices et un vecteur, passe ton chemin, vu le bordel que c'est de charger des matrices dans la pile et de les multiplier à coup de glMultMatrixf, c'est forcément lent. Mais si on arrive à bidouiller pour profiter des opérations de très (trop) haut niveau de la carte dispo en openGl, alors oui il y a des choses à faire.
De plus, avec les glShadingLanguage on a un outil plus flexible :
Oui voilà tiens merci, c'est ce que j'avais intuitivement dans la tête en initiant ce fil (enfin je pense) :
Je t'ai souvent lu expliquer que même avec les meilleurs libs, on ne peut pas exploiter plus de quelques milliers de processus.
En 1995, j'imagine qu'il était largement faisable d'exploiter toute la puissance de la première au top 100, aujourd'hui çe devient plus des fermes de calculs, incapable de gérer des programmes difficilement parallelisable qui atteignent une complexité trop grande.
C'est pour ça que le top 100, qui m'excitait quand j'étais gosse, ne m'inspire maintenant qu'un très vague intérêt.
Je crois qu'il va falloir qu'on attende les ordinateurs quantiques pour revoir des choses intéressantes.
Et là, la recherche sur la preuve de programme montrera toute son utilité.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ce qui est particulièrement intéressant c'est de voir la part de marché de Cray Research diminuer en 1993 et aujourd'hui (41 % contre 2,8 % en 2007).
Derrière tout cela, il y a un évènement technologique : la victoire du microprocesseur.
Pendant longtemp, la force des cray était d'assembler massivement des circuit intégrés contenant quelques portes, mais très rapides. Le Cray 1 était de cette race là, avec des IC de type ECL avec 2 portes NAND qui contenait quelques portes (moins de 10), alors qu'à l'époque on commençait à avoir des microprocesseurs complet... qui tournait 100 fois moins vite.
Il faut savoir que le premier ordinateur à utiliser des circuits intégré, était l'ordinateur de bord des missions apollo qui était lui aussi constitué de puces contenant 4 portes NAND.
Le Cray1 était un gigantesque empilage de circuits intégré (248832) qui formait une espèce de Pentium II, très orienté calcul vectoriel.
Le microprocesseur n'était pas vraiment considéré comme quelques chose de sérieux par les vieux de la vieille et Saymour Cray, qui n'a accepté d'utiliser des circuit intégré à la place des transistors qu'en 1976 avec le Cray 1 (il a conçu pas mal de CDC avant). Auparavant il faisait tout en transistor....
Jean-Louis Gassée racontait qu'un peu avant sa mort, Seymour Cray lui avait dit "ça va, j'ai compris, je vais arrêter de faire des machines avec des circuits intégré, je vais me mettre aux microprocesseurs"
Autant concevoir des super ordinateur avant 1990 m'aurait fait triper, autant maintenant, ça consiste principalement à empiler des intel core quad, des cell ou autres choses, et s'arracher la tête à gérer la communication entre les noeuds de sorte à optimiser le flux au maximum. C'est surement intéressant pour certains.
Je me demande, s'il ne serait pas possible de faire tourner une machine à 50 Ghz, en utilisant non plus des processeurs du marché, mais des puces dessinées pour l'occasion, avec des technologies capable de supporter de telles fréquences, sachant qu'évidemment, on mettrait beaucoup moins de transistors dessus
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
les américains ne vont pas se laisser faire et disposent d'une technologie d'armement qui a au moins 2 générations d'avance sur nous.
Euhh, ça dépend pour quoi :
- Les missiles français sont bien meilleurs que les américains.
- Les radars français embarqué dans les chasseurs sont bien meilleurs que leur homologues américains :Des militaires sud-africains, équipés de mirage 2000, + le dernier radar français, ont fait un exercice avec leur homologue américains (F-16 + radar américains). Les américains se sont fait eclatés, principalement, car les radars français faisaient une accroche radar (ie l'avion en rouge dans le viseur dans Top Gun) à 80 km, et les américains 30...
- Le char Leclerc est le seul char capable de tirer avec une grande précision en plein vitesse (90 km.h-1)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
On consomme environ 3.10^10 baril dans le monde, chaque année. Un baril coute environ 100$. Ce qui fait environ 3.10^12 dollar pour le payer, sachant que l'immense majorité du pétrole est (encore) payé en dollar.
Alors effectivement, personne ne veut plus de dollar, mais pour le moment, l'équivalent en $ de 10 % du PIB américain se promène pour payer la facture énergétique.
Donc, on veut plus de dollar, mais il en faut quand même. Le problème est évidemment différents pour les pays pétroliers...
Tiens au fait, on pourrait gagner de l'argent en spéculant contre le dollar à long terme, comment on fait ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
En ce qui me concerne, je ne considère pas ce genre d'analyse comme anti-américaine. Il s'agit plus pour moi de caractériser un fait, et le plus intéressant, de remarquer que ce genre de structure s'est déjà vu dans l'histoire humaine.
A part ça, je suis d'accord sur l'importance de l'industrie et l'innovation américaine.
Mon propos était plutôt d'attirer l'attention sur un phénomène dont on parle peu dans les médias, mais qui pourrait bien avoir pas mal de conséquences.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pour moi, le soundtracker, c'est le studio du pauvre, il ne devrait pas falloir un noyau temps-réel ou des trucs externes.
Surtout que FT2, ça tournait super bien sur mon 486 sx33 en 1994.
Donc, je pense pas que ça soit très dur à faire aujourd'hui
C'est vrai qu'il n'y a pas grand chose sous Linux, soit des logiciels pas fini de commencer, ou des super logiciels imbitable comme Ardour.
J'avais assisté à une conférence sur le libre à Nantes en 2004, et le directeur région ouest de Microsoft était présent. Il avait expliqué que le mouvement allait vers l'ouverture chez microsoft.
La raison en était, d'après lui, que les systèmes d'informations étant de plus en plus ouverts et interconnectés, il était nécessaire qu'il y ait inter-opérabilité, d'où l'ouverture des formats.
Microsoft ne peut plus trop se permettre un business modèle qui enfermes les utilisateurs dans des formats qui empêche la collaboration avec des acteurs dont on ne maîtrise pas l'orientation technologique.
Sans compter, bien sûr, la concurrence..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
1) Perdu, en 2001 ces 2 OS n'avaient pas de firewall active par defaut
Normal, yen a pas besoin ! 2) Ton Mac/Ubuntu de 2001 ne le faisait pas
Ubuntu oui, Mac, je demande à voir.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
GCC fonctionne un peu comme LLVM : il a un code intermédiaire dans lequel est traduit le code venant du front-end (Gcc, Gcj, Ada, G++, etc ...), ce code est ensuite traduit dans l'assembler cible, après avoir été optimisé.
Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
Je suppose que c'est un problème de gestion du 64 bits dans l'assembleur cible (ie. LLVM), dans laquelle la gestion du "plus que 32" doit être un problème, à cause de la "sérialisation" de ce genre de nombre sur deux valeurs de 32 bits.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
1. Sous Linux ou Mac OS X, je n'ai pas à activer de Firewall. Et je parie que c'est le cas pour un mac os et un linux de 2001.
2. Mon mac ou mon ubuntu me propose de mettre à jour, je ne suis pas censé le savoir.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Nantes est un cas peut être un peu particulier
Posté par Ontologia (site web personnel) . En réponse au journal Vers la fin des LUGs ?. Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Nantes est un cas peut être un peu particulier
Posté par Ontologia (site web personnel) . En réponse au journal Vers la fin des LUGs ?. Évalué à 4.
J'ai longtemps cherché pourquoi, et quelqu'un un jour m'a donné ce qui me semble être la réponse.
J'ai passé deux ans à Angers, et le Lug de là bas me manque beaucoup plus. Ce qu'il y a à Angers et qu'il n'y pas à nantes :
- Le fait de se rejoindre autour d'une bière chaque mois, ce qui est vraiment sympa.
- Et surtout, surtout : le fait que les personnalités, les expériences sont très diverses. On a de tout à Angers, des vieux de la vieilles, qui ont connu les début de l'informatique à la fin des années 60 (et là je restais bouche ouverte à écouter religieusement l'ancien), on a des entrepreuneurs, des étudiants, etc...
Linux-Nantes est peu être un peu trop marqué par la cohabitation avec les extrêmes gauchistes du B17, la tonalité est moins "ouverte", et j'ai l'impression que le fait de bosser dans une boite non "libre-compliant" est quelques part mal vu.
Donc évidemment, y a moins de monde, et on s'y sent pas tant à l'aise que ça, alors que les membres de l'assoc sont vraiment chaleureux.
'fin, c'est qu'une impression...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C++ : RAII et programmation générique
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 2.
De même, quand j'ai voulu passer un paramètre sans le &, le compilateur m'a gueulé dessus, et on m'a expliqué pourquoi c'était pas possible.
Bon après, il parait que VC++ 6, c'est pas le meilleur.
Je ne connais pas C++ car pour moi, et c'est, je suis d'accord, un avis très très tranché, un langage dont la spec fait 500 pages c'est ------> poubelle.
Je pense pour ma part qu'une spec de langage, ça doit pas dépasser 80 pages, exemples compris. Un bon langage est minimaliste, pas bloated. Sinon on met des années à le maîtriser, on se complique inutilement, et à part faire plaisir aux quelqu'un comme toi, qui maîtrisent (très bien) la chose, on ennuie tout le monde.
Faut pas s'étonner que Java se soit imposé.
Cela dit, j'avoue que j'ai un peu regardé les templates pour piquer les rares fonctionnalités de c++ qui n'existent pas dans Lisaac, afin qu'on les y mettent. C'est en debug, ça va arriver bientôt.
Je me suis documenté sur les foncteurs en C++ (http://h-deb.clg.qc.ca/Sujets/Divers--cplusplus/CPP--Foncteu(...) : je ne sais pas si cette doc te parait valable )
Désolé, mais c'est un workaround tordu pour implémenter le type block bien connu des langages comme smalltalk/ruby/lisaac/io/...
Le type bloc est une fonction à évaluation retardé, elle peut recevoir un ou plusieurs paramètre et en renvoyer plusieurs (bien que ça dépende du langage)
Parce que franchement, utiliser les opérateurs pour redéfinir () et utiliser le constructeur comme foncteur, c'est tordu de chez tordu.
N'avaient qu'à implémenter le type block et ça aurait été réglé.
Le problème, c'est que c'est dur à compiler du block, et c'est très très dur d'avoir des perfs avec. Ils ont alors préféré faire un truc hyper compliqué, mais qui refile le sale boulot au programmeur.
Parce que tu sais ce que sont les templates en définitive ?
De l'analyse de flot codé à la main par le programmeur !
Comme le compilateur est beaucoup trop gros pour faire de l'analyse de flot lui-même et détecter les chemins de code à optimiser (évidemment, il y a 500 pages de specs à implémenter), en effectuant de l'évaluation partielle de code sur le code statique, on demande au programmeur de baliser l'analyse de flot parce que le compilateur ne sait pas le faire !
Je revient au type block : l'itérateur devient inutile, puisque tu fait ton foreach naturellement, et que le coût est exactement le même.
Ton idée de généraliser l'intersection est très intéressante : je la mettrai bien dans object.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C++ : RAII et programmation générique
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Consommation
Posté par Ontologia (site web personnel) . En réponse au journal Firefox et consommation de mémoire. Évalué à 2.
Oui, mais elle est fragmenté en page de 4 ko, ce qui n'est pas très grave, vu que ta ligne de cache fait 64 octets.
Pour bien faire, il faudrait un gros malloc au début, et un gestionnaire mémoire interne au logiciel...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Nos dirigeants ont une vision! \o/
Posté par Ontologia (site web personnel) . En réponse au journal 38 Téraflops pour Renault F1...et Linux !. Évalué à 3.
Un humain, voire un animal, c'est chiant ça a une psychologie tout ça.
Tandis qu'un muscle couplé à un système digestif et respiratoire, c'est, ce me semble, le système le plus rentable au monde.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C++ : RAII et programmation générique
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 3.
En Smalltalk/Ruby/IO ça devrait planter à l'exécution.
En Lisaac, le compilateur te gueulera dessus à la compilation, et refusera de compiler.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C++ : RAII et programmation générique
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à -1.
Imagine, tu est dans l'objet Collection<E>
Tu veux faire une méthode d'intersection qui te permet de prendre une collection<F> en argument
et de rendre une autre Collection<E> qui soit l'intersection de E et F selon une fonction de comparaison
f(E,F) -> boolean |-> E == F; que tu vas lui donner en paramètre.
Par exemple, je sais pas, un exemple débile : F est un type date, E est un type String dont le contenu contient toujours un numéro d'année.
Tu veux la liste des string qui contiennent le numéro d'année (par exemple "2008") qui soit le même que la collection de date que tu lui donne en argument.
ça te permet de faire
Collection<E> list1,result;
Collection<F> list2;
result = list1.intersection(& F autreliste, * pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix);
Evidemment, sans type Block comme en Smalltalk/Ruby/IO/Lisaac, t'es obligé de passer par un pointeur de fonction, mais voilà la puissance est là :
Quand tu écris la fonction d'intersection, tu connais pas E, tu connais pas F, et ça marche dans tout les cas (pas en C++ parce que si ta fonction fait n'importe quoi... ça plante, et le compilateur vérifie pas)
loufoque nous donnera surement une bidouille pour contourner ça proprement !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: gcc lave plus blanc ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 4.
Je suis pour des langages minimalistes. des langages définis avec une ou maximum deux dizaines de primitives, une dizaine de mots clé, admettons une vingtaine.
Si le langage est bien conçu et les primitives bien choisies, tu peux aller très loin.
Les langages à la smalltalk/ruby/io/lisaac ont ma préférence car ils sont minimalistes en étant bien plus puissant. Toutes les structures de contrôles sont définies en lib, et énormément de choses le sont avec des primitives de base.
En c++, tu pleures avec ton pauvre for et ton while.
Quand au template, c'est un problème de compilation : les templates servent à précompiler toutes les données statiques disponible à la compil. Un bon compilateur à analyse de flot sait le faire, sans imposer au programmeur de concevoir les templates.
En mettant en dur ta regexp dans une chaine, et la chaine à matcher, le compilateur est capable, par analyse de flot, de calculer la réponse.
Si la chaine cible n'est pas là, il compilera l'automate.
Pas besoin de template qui palie aux faiblesse d'un compilateur, sur lequel tous les énormes efforts sont portés à implémenter une norme pléthorique, plutot que de faire un compilateur puissant, mais simple.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: gcc lave plus blanc ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 6.
Eiffel.. euh non, mauvais exemple.
Aller, je vais quand même pas passer outre la défense de ma chapelle : Lisaac, permet de faire bien plus de choses qu'en C++, avec une définition beaucoup plus courtes, et même sans nécessiter de templates, le compilateur fait tout tout seul avec l'analyse de flot*, et ce avec sensiblement les mêmes perfs : http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)
Le génie, c'est de tout mettre tout ces concepts avec quelques primitives de base, et de produire un compilateur capable de tout faire, rapidement, avec celle-ci.
* Bientôt poussé à fond, ie. sur les collections statiques
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: gcc lave plus blanc ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 9.
Vous êtes prêt à avaler la définition du standard du C++ ? Ses 1205 pages ? Le pdf de 8 Mo, quasiment sans images ?
C'est ici : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n246(...)
Aller je suis gentil, il n'y a *que* les 400 premières pages qui servent à définir le langage.
Le C++ est pire que l'administration française, c'est une accumulation de couche les unes sur les autres. A ce stade, ça devient de la sédimentation !
Alors, à la décharge des divers implémenteurs, je les comprends, je compatie à leur douleur, même.
Bon après tout, si de gens aiment des langages pas beau, mal conçu, avec des concepts certes très intéressant, mais qui constitue une véritable usine à gaz qui rend le code impossible à débugguer... Grand bien leur fasse.
Pour ma part, et moinssez moi, faites vous plaisir, je pense qu'il faut que ce langage disparaisse, et vite.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Auto vectorisation
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 6.
Je suppose qu'il aligne toutes les données, de toutes façons.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Auto vectorisation
Posté par Ontologia (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 10.
Qu'est-ce que c'est exactement :
Pour pas mal de type de boucle (celle-ci : http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vect(...) ) Gcc va être capable de produire du code MMMX, SSE, ou altivec sur powerPC. Voire, d'après ce que j'ai compris, du SPU du cell.
Ceux qui veulent lire des vidéos HD sur leur linux installé sur la PS3 vont être content (parce que pour avoir passé une après midi à essayer de le faire marcher, faire accéder au codec le spu du cell, c'est mission impossible).
D'après cette note http://gcc.gnu.org/wiki/AutovectBranchOptimizations , la vectorisation est automatique. Gcc détecte ce qui est optimisable dans le code.
Ca veut dire, que ça risque d'être très intéressant de recompiler pas mal de logiciels gourmand en calcul avec cette nouvelle version de gcc.
La 4.2 gérai un peu de vectorisation, mais de manière très limitée et à condition qu'on active le switch correspondant.
Il va y avoir des benchs à refaire...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: compléments
Posté par Ontologia (site web personnel) . En réponse au journal Raytracing temps réel. Évalué à 3.
Le problème est que ça n'est intéressant que pour des calculs massifs sur de grosses quantités de données, quand l'algo est "utilisable"
Par exemple, on explique comment faire Y = Y + a.X où Y et X sont des vecteurs à n dimension (n très grand) et a un scalaire.
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutori(...)
Plus d'infos ici :
http://www.gpgpu.org/developer/index.shtml#conference-tutori(...)
Effectivement, si tu veux veux multiplier 3 matrices et un vecteur, passe ton chemin, vu le bordel que c'est de charger des matrices dans la pile et de les multiplier à coup de glMultMatrixf, c'est forcément lent. Mais si on arrive à bidouiller pour profiter des opérations de très (trop) haut niveau de la carte dispo en openGl, alors oui il y a des choses à faire.
De plus, avec les glShadingLanguage on a un outil plus flexible :
http://www.ozone3d.net/tutorials/mandelbrot_set.php
Donc à voir et ça ne fait que commencer
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: compléments
Posté par Ontologia (site web personnel) . En réponse au journal Raytracing temps réel. Évalué à 3.
Avec les nouveaux framework du genre NVidia Cuda, tu peux facilement délester le processeur de calculs simple comme addition et multiplications.
D'ailleurs, en bidouillant opengl, tu peux déjà le faire, mais c'est un peu tordu.
Je vais essayer de creuser le concept, je vous en reparlerai.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cray
Posté par Ontologia (site web personnel) . En réponse au journal Top500 : La rétrospective des 15 ans.. Évalué à 3.
Je t'ai souvent lu expliquer que même avec les meilleurs libs, on ne peut pas exploiter plus de quelques milliers de processus.
En 1995, j'imagine qu'il était largement faisable d'exploiter toute la puissance de la première au top 100, aujourd'hui çe devient plus des fermes de calculs, incapable de gérer des programmes difficilement parallelisable qui atteignent une complexité trop grande.
C'est pour ça que le top 100, qui m'excitait quand j'étais gosse, ne m'inspire maintenant qu'un très vague intérêt.
Je crois qu'il va falloir qu'on attende les ordinateurs quantiques pour revoir des choses intéressantes.
Et là, la recherche sur la preuve de programme montrera toute son utilité.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Cray
Posté par Ontologia (site web personnel) . En réponse au journal Top500 : La rétrospective des 15 ans.. Évalué à 10.
Derrière tout cela, il y a un évènement technologique : la victoire du microprocesseur.
Pendant longtemp, la force des cray était d'assembler massivement des circuit intégrés contenant quelques portes, mais très rapides. Le Cray 1 était de cette race là, avec des IC de type ECL avec 2 portes NAND qui contenait quelques portes (moins de 10), alors qu'à l'époque on commençait à avoir des microprocesseurs complet... qui tournait 100 fois moins vite.
Il faut savoir que le premier ordinateur à utiliser des circuits intégré, était l'ordinateur de bord des missions apollo qui était lui aussi constitué de puces contenant 4 portes NAND.
Le Cray1 était un gigantesque empilage de circuits intégré (248832) qui formait une espèce de Pentium II, très orienté calcul vectoriel.
Le microprocesseur n'était pas vraiment considéré comme quelques chose de sérieux par les vieux de la vieille et Saymour Cray, qui n'a accepté d'utiliser des circuit intégré à la place des transistors qu'en 1976 avec le Cray 1 (il a conçu pas mal de CDC avant). Auparavant il faisait tout en transistor....
Jean-Louis Gassée racontait qu'un peu avant sa mort, Seymour Cray lui avait dit "ça va, j'ai compris, je vais arrêter de faire des machines avec des circuits intégré, je vais me mettre aux microprocesseurs"
Autant concevoir des super ordinateur avant 1990 m'aurait fait triper, autant maintenant, ça consiste principalement à empiler des intel core quad, des cell ou autres choses, et s'arracher la tête à gérer la communication entre les noeuds de sorte à optimiser le flux au maximum. C'est surement intéressant pour certains.
Je me demande, s'il ne serait pas possible de faire tourner une machine à 50 Ghz, en utilisant non plus des processeurs du marché, mais des puces dessinées pour l'occasion, avec des technologies capable de supporter de telles fréquences, sachant qu'évidemment, on mettrait beaucoup moins de transistors dessus
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: L'impérialisme, stade suprême du capitalisme, cf Lénine ;) Suite
Posté par Ontologia (site web personnel) . En réponse au journal Le dollar et l'empire. Évalué à 4.
Euhh, ça dépend pour quoi :
- Les missiles français sont bien meilleurs que les américains.
- Les radars français embarqué dans les chasseurs sont bien meilleurs que leur homologues américains :Des militaires sud-africains, équipés de mirage 2000, + le dernier radar français, ont fait un exercice avec leur homologue américains (F-16 + radar américains). Les américains se sont fait eclatés, principalement, car les radars français faisaient une accroche radar (ie l'avion en rouge dans le viseur dans Top Gun) à 80 km, et les américains 30...
- Le char Leclerc est le seul char capable de tirer avec une grande précision en plein vitesse (90 km.h-1)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Il manque juste le principal dasn l'article d'Agoravox.
Posté par Ontologia (site web personnel) . En réponse au journal Le dollar et l'empire. Évalué à 2.
http://fr.wikipedia.org/wiki/Tonne_d%27%C3%A9quivalent_p%C3%(...)
http://www.industrie.gouv.fr/energie/statisti/se_petmc.htm
http://generationsfutures.chez-alice.fr/petrole/consommation(...) et http://www.terredebrut.org/article-1862415.html
On consomme environ 3.10^10 baril dans le monde, chaque année. Un baril coute environ 100$. Ce qui fait environ 3.10^12 dollar pour le payer, sachant que l'immense majorité du pétrole est (encore) payé en dollar.
Pour info, le PIB américain est d'environ 1.10^13 $
(http://www.finances.gouv.fr/fonds_documentaire/Prevision/dpa(...)
Alors effectivement, personne ne veut plus de dollar, mais pour le moment, l'équivalent en $ de 10 % du PIB américain se promène pour payer la facture énergétique.
Donc, on veut plus de dollar, mais il en faut quand même. Le problème est évidemment différents pour les pays pétroliers...
Tiens au fait, on pourrait gagner de l'argent en spéculant contre le dollar à long terme, comment on fait ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Analyser n'est pas juger
Posté par Ontologia (site web personnel) . En réponse au journal Le dollar et l'empire. Évalué à 4.
A part ça, je suis d'accord sur l'importance de l'industrie et l'innovation américaine.
Mon propos était plutôt d'attirer l'attention sur un phénomène dont on parle peu dans les médias, mais qui pourrait bien avoir pas mal de conséquences.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Soundtracker
Posté par Ontologia (site web personnel) . En réponse au journal Renoise. Évalué à 2.
Surtout que FT2, ça tournait super bien sur mon 486 sx33 en 1994.
Donc, je pense pas que ça soit très dur à faire aujourd'hui
C'est vrai qu'il n'y a pas grand chose sous Linux, soit des logiciels pas fini de commencer, ou des super logiciels imbitable comme Ardour.
Au pire, en cherchant bien ici : http://linux-sound.org/
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Verre à moitié plein ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Les spécifications des formats Microsoft Office enfin publiées. Évalué à 5.
La raison en était, d'après lui, que les systèmes d'informations étant de plus en plus ouverts et interconnectés, il était nécessaire qu'il y ait inter-opérabilité, d'où l'ouverture des formats.
Microsoft ne peut plus trop se permettre un business modèle qui enfermes les utilisateurs dans des formats qui empêche la collaboration avec des acteurs dont on ne maîtrise pas l'orientation technologique.
Sans compter, bien sûr, la concurrence..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Article plus technique et plus intéressant par ici
Posté par Ontologia (site web personnel) . En réponse au journal Mes impressions des Microsoft TechDays 2008. Évalué à 2.
Normal, yen a pas besoin !
2) Ton Mac/Ubuntu de 2001 ne le faisait pas
Ubuntu oui, Mac, je demande à voir.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: questions
Posté par Ontologia (site web personnel) . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 4.
GCC fonctionne un peu comme LLVM : il a un code intermédiaire dans lequel est traduit le code venant du front-end (Gcc, Gcj, Ada, G++, etc ...), ce code est ensuite traduit dans l'assembler cible, après avoir été optimisé.
Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
Je suppose que c'est un problème de gestion du 64 bits dans l'assembleur cible (ie. LLVM), dans laquelle la gestion du "plus que 32" doit être un problème, à cause de la "sérialisation" de ce genre de nombre sur deux valeurs de 32 bits.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Article plus technique et plus intéressant par ici
Posté par Ontologia (site web personnel) . En réponse au journal Mes impressions des Microsoft TechDays 2008. Évalué à 2.
2. Mon mac ou mon ubuntu me propose de mettre à jour, je ne suis pas censé le savoir.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker