Si, mais ce n'est pas un multi-core, donc paralléliser dessus avec OpenMP ne sert à rien. Et comme je n'en aurai pas de si tôt, ma seule solution reste le cluster.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Si, mais ce n'est pas un multi-core, donc paralléliser dessus avec OpenMP ne sert à rien. Et comme je n'en aurai pas de si tôt, ma seule solution reste le cluster.
il n'y aura bientot que des multicores dans un futur tres proche...Envoyé par Miles
j'ai auusi bien envie du mac pro apple dual pro dual coregenial !
mais s'eloigne de plus en plus du sujet,
ce qui me parait etre finalement plus une histoire philosophique et pas rationnelle....
a+
Sauf que si les compilos qu'on a ne l'utilise pas, on s'en foutil n'y aura bientot que des multicores dans un futur tres proche...
j'ai auusi bien envie du mac pro apple dual pro dual core
le mac pro, il est nul, c'est un vieux relent de dual core à la sauce Pentium4
sacrilege comment peut-on dire ca HaarrrrggggSauf que si les compilos qu'on a ne l'utilise pas, on s'en fout
le mac pro, il est nul, c'est un vieux relent de dual core à la sauce Pentium4
Très, simple, il suffit de voir comment ils font ça, c'est absurde, tout comme avoir mis 2 P4 sur un seul die.
je ne pense pas que tu ai raison, je fais vraiment confiance a apple pour choisir la meilleure architecture pour ses machines....
t'as pas d'apple toi ... ca se voit ...
tu think pas different
Ouais, sauf que j'ai tout de même une certaine connaissance de la chose- à ton avis, c'est l'archi dual d'AMD avec ses X2 ou Intel avec ses Pentium D qui était la plus performante et logique ? -
alors bon, j'ai aussi lu beaucoup de chose la autour... et vu de nombreux tests ... c'est vrai je voulais m'acheter un dual pro AMD opteron, jusqu'a realiser que c'etait trop d'argent ....Ouais, sauf que j'ai tout de même une certaine connaissance de la chose
en fait ils disent que le controller memoire embarque de AMD necessite de la memoire separée et que finalement ca va etre leur goulot d'etranglement...
mais ca me dit que ca chipotte dur dur, un peu comme le COW en fait...
... les ingenieurs: tous pareils (j'en suis un)
a+
ps: on s'ecarte quand meme un peu trop du sujet non ?
Pas de bol, l'architecture d'AMD contournait justement le problème et c'est l'architecture d'Intel qui avait le goulot d'étranglement, parce que leur archi n'avait pas été pensée pour le parallélisme, contrairement à AMD - d'ailleurs, même combat pour la performance par watt, secteur où AMD a dominé jusqu'à ce qu'Intel se rende compte enfin que les marketeux n'avaient pas raison. -
Oui, on s'éloigne, mais bon...
Pour l'instant les AMD sont meilleurs mais ils disent que leurs fameux controllers memoire qui leur a donné l'avantage jusqu'à present deviendra leur goulot d'etranglement pour demain.
Honnetement, j'ai utilisé un bi-pro intel, c'est super vite, ca coute moins cher, tu peux tester tous les trucs d'openmp.... et je pense la difference entre AMD et Intel n'est pas si flagrant que ca en utilisation courante.
Tu reagis quand meme pareil que pour boost:
c'est mieux
c'est plus "propre"
ca utilise pas COW, ca fait gagner 1 seconde sur 1 millions de tests
Mais au final on est plus productif avec Qt en fait !
Non, Intel a repris l'avantage. Le contrôleur mémoire intégré n'est pas un facteur limitant, au contraire, ça a boosté les performances, sauf qu'Intel n'avait pas l'architecture adéquate pour ce genre de choses. Maintenant, ça peut changer puisque c'était à un moment sur la roadmap.
Ah oui, le facteur limitant des Pentium D, c'était justement que pour communiquer, il fallait sortir du processeur, comme pour accéder à la mémoire, et ça coinçait méchemment.
Non, ça n'a rien à voir. Boost et Qt ne jouent pas dans la même catégorie. L'un est une extension de la bibliothèque standard quand l'autre est une réimplémentation de la bibliothèque standard avec des bibliothèques de graphisme, XML, ... en plus. Ca n'a pas du tout la même utilité - va faire des graphes avec Qt par ex -
Boost et Qt joue dans la meme categorie sur certaine libs.
et c'est pour ca que j'ai ouvert cette discussion.
De nombreuses fois j'ai lu preferer boost pour le model metier parce que c'est mieux, plus standard etc. Si pour une fonctionnalité on a le choix entre boost et Qt, alors j'aimerais des arguments rationnels, et non pas "ca utilise le COW alors c'est nul" (j'exagere un peu). J'aimerais lire de l'experience la autour et lire "par experience j'ai remarqué un ralentissement dans ce cas de figure etc"
hummm .... va faire de l'opengl et un IHM avec boost.
comme je dis il y a des points communs, et il faut choisir entre.
Si boost resoud un probleme que ne s'est de toute facon pas faire Qt, il n'y a pas de debat, faut l'utiliser c'est tout. L'inverse est vrai.
Mais si les deux peuvent le faire ? il faudra faire un choix, que je prefererais pragmatique et pas trop trop philosophique.
ps: sinon ... pourquoi Intel est meilleur maintenant ?
au fait ... t'aurais pas Visual Studio 2005 ou mes yeux ne seraient plus fiables ? alors t'en as un compilo qui fait de l'openmpSauf que si les compilos qu'on a ne l'utilise pas, on s'en fout
moi j'attends gcc 4.2.... sur Mac
j'ai un mac book pro intel core duo
le mac c'est genial, unix en dessous (je suis aussi fan de linux), interface graphique a tomber par terre,
basé sur du materiel de qualité vraiment design.
Quand je compare avec mon laptop du travail, on dirait du materiel des années 80, c'est fou ....
C'est le seul systeme a allier aussi bien unix et une IHM conviviale et rapide,
linux n'est pas encore au niveau de l'IHM (impatient de voir kde4),
et windows ... comment dire ... ils auraient peut-etre du racheter beos
je rigole a peine, il n'a pas la puissance d'unix juste le dos (quand meme vraiment embetant, au boulot on pourrait utiliser des outils en ligne de commande qui font gagner du temps) et l'IHM est vieillote.
et voila comment completement louper le sujet ...
[QUOTE=epsilon68]Boost et Qt joue dans la meme categorie sur certaine libs.
et c'est pour ca que j'ai ouvert cette discussion.
De nombreuses fois j'ai lu preferer boost pour le model metier parce que c'est mieux, plus standard etc. Si pour une fonctionnalité on a le choix entre boost et Qt, alors j'aimerais des arguments rationnels, et non pas "ca utilise le COW alors c'est nul" (j'exagere un peu). J'aimerais lire de l'experience la autour et lire "par experience j'ai remarqué un ralentissement dans ce cas de figure etc"
ps: sinon ... pourquoi Intel est meilleur maintenant ?
Dans ces cas-là, je regarde si je peux avoir mon code en GPL ou pas. Si mon projet n'utilise pas d'IHM Qt, je garde Boost.
On est d'accord, j'ai donné un exemple, c'est tout
Boost si la licence est problématique et si on ne veut pas amener directement une grosse bibliothèque dans son code.
Parce qu'ils se sont décidé à faire comme AMD et à optimiser leur design au niveau puissance dissipée, et avec les C2D, c'est enfin le cas, alors qu'AMD fait ça depuis l'histoire du P-Rating pour rester dans la course marketing d'Intel. Ils ont bien fait de virer 1000 marketeux...
Au labo, on a une ou l'autre version de VS 2005, mais l'Express officielle ne Microsoft ne le propose pas.
L'argument de la beauté de l'interface, c'est d'un négligeable, tout le monde sait que le plus beau est la ligne de dcommande
humm hummL'argument de la beauté de l'interface, c'est d'un négligeable, tout le monde sait que le plus beau est la ligne de dcommande
Pour redevenir sérieux à ce sujet, je lis sur certaines mailing lists les déboires des gens avec cette interface graphique qui est en train de changer au niveau programmation. Ils se fracassent la tête contre les murs... Vive Apple...humm humm
C'est pour ca que j'ai choisi Qt
je ne suis pas assez fou pour me plonger dans une api specifique.
Je l'avais fais a l'epoque avec MFC mais c'est fini
J'ai juste regarde l'interface en C++ du mac, j'ai vite refermé, c'est meme pas la peine d'investir du temps dans quelque chose d'uniplateforme.
J'aime le mac, mais je veux que mon programme tourne sur Linux.
a+
... on dirait que ce debat est a peu pres fini, mais est-il resolu ?
heu ... oui je pense, Miles a trouvé la bonne reponse, c'est dependant du projet.
Je vais quand meme essayer d'utiliser boost a fond (c'etait pour le jeu de mot) sinon au maximum.... Je vous dirais les problemes..... ou les solutions
a+
J'ai fait une longue seance de recherche sur unicode, tout cela partant du filesystem de boost ....
pour gérer unicode, on peut utiliser iconv et ICU, la derniere etant tres tres complete, jusqu'au expressions regulieres...
J'ai ensuite lu des fichiers XML dans differents formats pour comparer les complexités, je n'ai pas reussi a installer icu sur mingw
Pour Miles, juste une parenthese pour dire que ICU utilise aussi le COW.
et que plus ca va plus je trouve ca tres elegant. On le voit quand on utilise Qt ca simplifie quand meme pas mal la lecture du code, du genre on retourne la collection au lieu de la passer en reference ou en pointer ....
donc pour dire que je finis par choisir Qt de bout en bout, en privilegiant les libs de Qt. J'ai vraiment fait un grand effort de chercher autour en pesant les avantages / inconvenients mais unicode est un gros morceau qui pese lourd.
a+
Tu as donc fait le choix de ne plus faire du C++, mais du C++/MOC, sous-ensemble du C++ (fonctionnalités avancées enlevées) avec du macro-code pour combler.donc pour dire que je finis par choisir Qt de bout en bout, en privilegiant les libs de Qt. J'ai vraiment fait un grand effort de chercher autour en pesant les avantages / inconvenients mais unicode est un gros morceau qui pese lourd.
L'avantage de boost, c'est que c'est du C++ moderne qui fait un usage intelligent de ses technologies, en particulier les templates et le RAII.
Avec Qt, ton code n'est pas exception-safe du tout, ce qui est pour moi un pré-requis dans la programmation C++. D'ailleurs je suis même pas sûr que Qt utilise les exceptions.
Effectivemment, le support Unicode dans boost serait pas mal, mais on se débrouille pas trop mal sans si on s'y connait un peu.
Ah oui et pour l'xml, y'a un parseur simpliste basé sur spirit je crois, et quelques trucs dans serialization, mais rien de plus.
Mais bon je vois difficilement comment on peut considérer l'xml comme faisant partie du coeur d'un framework donc utiliser une autre librairie comme libxml++ ne pose pas de problème.
Répondre avec citation
Partager