voir ce film en streaming ca sert à rien, vu que dans ce cas il faudrait qu'il y ait du suspense ou un scénario un peu profond pour tenir les 2h35. Je suis allé le voir pour les effets spéciaux, et j'en ai pris plein les mirettes à regarder tous les détails et tout le soin qu'ils y ont mis. C'est le genre de film où justement le cinéma a un interet, plutot qu'etre tranquillement chez soi avec sa boisson préférée à moins de 5€ dans la main : un ecran de plusieurs metres et une installation audio au poil ca permet d'apprécier tout ca.
Si les effets speciaux ca t'interesse pas (et je respecte tout à fait), ne regarde pas ce film (et surtout pas en streaming), il n'a que peu d'interet. Par contre si les prouesses techniques t'interessent, alors fait honneur aux quelques dizaines (voir centaines) d'artistes et d'ingés (on les oublie souvent, mais y en a une tripotée qui se prennent la tete pour rendre ca possible) qui ont bossés dessus et ont fait quelque chose d'un niveau que je n'avais que rarement vu avant (et pourtant des films à effets speciaux, j'en ai vu !).
Personnellement, j'y allais pour voir une démoreel gigantesque, et j'y ai eu droit (les moments sans action étant assez ininteressants). J'en suis ressorti ravi !
concernant le temps de latence, sous reserve de mémoire suffisante on peut faire des streams asynchrones (copie(s) host<->GPU en parallèle de calculs), ca fait que la latence host/GPU est à peu près inexistante pour tout calcul valant le coup d'etre fait sur GPU (qui prennent un minimum de temps donc, pas 3 additions max à faire par stream).
En tout cas très interessant votre boulot de recherche ! y a de la doc (papiers, ...) dispo et lisible par quelqu'un ayant des connaissances limitées en compil et trucs dans le genre ?
à perfs égales, un moteur de lancer de rayons temps réel c'est 10 fois moins embêtant à coder sur GPU que sur CPU (et je parle d'expérience). Il suffit de voir les forums pro parlant de lancer de rayon temps réel [1], le nombre de gens qui se sont fait un petit raytracer avec CUDA qui tourne à 30 fps pour une scène simple est très important comparés à ceux qui l'ont fait sur CPU, et ce ne sont pas forcément des gourous du domaine (moi le premier). On parle bien d'implementations à *performances égales* ici, pas de dire qu'on a codé son algo sur une plate-forme, parce que dans le genre "comparaison qui veut rien dire", c'est difficile de faire mieux....Donc encore une fois, pour un certain nombre (et même un nombre certain) de problèmes, arriver à des performances données est bien plus simple sur GPU que sur CPU. Et pour d'autres, ca sera l'enfer, je suis tout aussi conscient de ça.
alors, dans l'ordre, et sous reserve de corrections par des gens plus qualifiés que moi* :
1/oui, on peut faire n'importe quel type de calcul. Avec CUDA par exemple (openCL j'ai regardé de très très loin, mais de ce que j'ai vu ca devrait etre pareil), tout le côté pipeline graphique est caché, meme si tu peux interagir un peu avec openGL côté CPU (j'ai pas trop regardé ca). Tu vas programmer ce que Le langage ressemble très fortement au C, avec quelques mots clés en plus pour dire ce qui est sur GPU ou sur CPU, et gerer la hierarchie mémoire (que tu gères de manière explicite). Niveau prog effective, c'est comme du C : tu peux boucler, appeler des fonctions, ... . Alors par contre à la réflexion je sais pas si ca gere les pointeurs de fonctions - je n'en ai pas eu besoin -, comme tout est inliné dans le noyau (équivalent du main() d'un prog C). Et après, tu appelles ton noyau depuis un prog (C ou C++) presque comme une fonction normale, tu précises juste comment tu répartis chaque tache sur le GPU (je te laisse te référer au guide de programmation de CUDA - très bien fait, trouvable dans le SDK - pour plus de détails).
2/ Tout peut être calculé, mais d'un autre côté, seuls une partie des problèmes peut être traités efficacement par le GPU. Typiquement, les GPUs ne sont pas du tout adaptés aux algos purement séquentiels avec une seule donnée à traiter à travers de nombreuses étapes. Le mieux, c'est quand tu veux N résultats (N grand) d'une même fonction (ne bossant pas forcément sur les mêmes données, heureusement ^^). Dans ce cas, ton noyau contiendra le code d'une tâche. tu peux aussi faire des opérations où tu ne veux qu'un seul résultat, pour des fonctions de type "rédux". Si les données de base sont très grosses, le gain est vraiment notable aussi. Bon après des fois des algos qui apparemment ne s'y pretaient pas peuvent être adaptés, c'est au cas par cas.
3/Si j'ai bien compris, le Larrabee se programmera comme un GPU, avec du vectoriel en plus. Après, peut-etre qu'ils proposeront plusieurs niveaux : un niveau "facile", ca sera du openCL (threading et SIMD géré automatiquement), et un niveau "bas niveau", où tu te feras ton threading toi-meme et exploitera le SIMD toi-même. N'étant pas devin et ne bossant pas sur le Larrabbee, j'attend de voir ^^. Dans tous les cas, ca sera par du parallélisme massif qu'on en tirera le mieux (plus y a de taches, plus on peut cacher la latence des accès mémoires)
4/ben la CUDA zone donne un bon apercu...je l'utilise pour du rendu par lancer de rayons, mais des gens l'utilisent en dynamique des fluides, en electrodynamique, en rayonnement, ... en gros, dès que c'est intensif et qu'on veut plein de résultats d'un même calcul de base.
les algos qui en tirent le plus parti
*parce qu'il y en a toujours, loi 1 de l'humanité ^^
"Après pour les autres utilisations je ne pense pas que l'impact sur le marché soit vraiment important, ce sont les gamers qui achètent les grosses carte graphiques."
déjà les labos en achètent (et pas que dans les équipes de synthèse d'images, mais aussi certains labos de physique), parce que s'ils peuvent faire leurs calculs dessus, ils sont preneurs :) après, si vraiment ça marche bien, les industries concernées vont certainement s'y mettre aussi, il suffit de voir la gamme Tesla de nVidia (4 GPU avec 4Go de RAM par GPU, pas de sortie video) pour voir qu'ils sont près à cela et l'espèrent fortement...
Ça fait plusieurs années que Tim Sweeny dit que le GPU est mort, et à SIGGRAPH cette année (où j'étais), ça n'a pas semblé être très relayé. Au contraire, le nombre de papiers s'appuyant sur le GPGPU semblait encore avoir augmenté (si c'est possible).
Après, qu'utiliser de manière efficace le GPU soit non trivial, certes (et je peux en parler, je l'utilise, et je trouve ça non trivial). Mais utiliser le SSE (et plus généralement les instructions vectorielles) de manière efficace peut être tout aussi casse-tête, et demande des adaptations majeures des algorithmes (au moins pour ceux que je connais, liés à la synthèse d'images). Utiliser les SPUs (vectoriels et avec gestion de la mémoire code/données explicite) de la PS3 au maximum de leurs perfs est tout aussi difficile (aussi testé). Et rien qu'utiliser un CPU efficacement (donc s'arranger pour ne pas exploser le cache, minimiser le nombre de défauts de pages, etc) demande là aussi des adaptations non négligeables sur les algos, et pas mal de réflexion (au moins pour moi). Bref, toute utilisation orientée performances nécessite une bonne connaissance du matériel et une adaptation des algos plus ou moins importante, il n'y a rien de nouveau ni de spécifique aux GPUs là dedans. Concernant la flexibilité des GPU et leur bonne capacité à traiter des problèmes liés au calcul scientifique, il suffit d'aller sur la CUDA zone [1] pour voir que ce n'est pas que de la 3D temps réel, loin de là.
Donc au final, il y a toujours les mêmes problèmes qu'avant : quelle est la techno la plus adaptée à mon problème ? Sans essayer ou sans forte expérience sur chacune des technos disponibles, il me semble très difficile de le dire... Mais jeter à la poubelle une techno parce qu'on ne peut pas en tirer le maximum en codant avec ses pieds, je trouve ça un peu hâtif. De plus, la somme de travaux faits sur la programmation générique des GPUs est quand même bien moindre que celle faite sur l'utilisation des CPUs. Ça ne fait que quelques années que ca existe, et je trouve que les résultats sont plus que prometteurs quand on sait depuis combien de temps on utilise les CPUs actuels et qu'on compare les résultats pour des problèmes où les GPUs sont adaptés. Et les outils commencent à arriver eux aussi (debugger notamment, cf [2]). Donc voyons ce que ça va donner, je doute qu'on ait assez de recul actuellement pour juger.
je trouve que c'est une très bonne initiative de proposer ce genre de projets à des personnes d'IUT, mais un petit peu plus de détails seraient les bienvenus ;)
"Mais comme toute école d'ingénieur, il s'agit avant tout d'acquérir le diplôme que l'on peut ensuite montrer aux recruteurs"
c'est marrant, quand je suis arrivé à mon école d'ingé (publique), j'y suis allé pour acquérir des connaissances en info et en maths, et j'en suis ressorti avec bien plus que ca (vive l'abstraction !), mais en tout cas le diplôme n'etait pas la priorité, vu que dès le départ je savais que je voulais faire de la recherche. Pourquoi ne pas être allé à la fac ? la différence de moyen. et je doute que mes copains venant de prepa ne venaient que pour le diplome, meme s'ils ont fait leur choix en se basant sur le classement des écoles et les classements aux concours de ceux qui avaient été acceptés les années d'avant.
Après, j'ai tendance à avoir un a-priori négatif sur les ecoles privées, mais c'est peut-etre parce que j'ai un apercu partial : des gens de milieu-bas de classement de l'IUT dans lequel j'étais ont été acceptés volontiers par l'école d'ingé d'à coté. Mais peut-etre ne sont elles pas toutes dans ce cas.
"Mais comme toute école d'ingénieur, il s'agit avant tout d'acquérir le diplôme que l'on peut ensuite montrer aux recruteurs"
c'est marrant, quand je suis arrivé à mon école d'ingé (publique), j'y suis allé pour acquérir des connaissances en info et en maths, et j'en suis ressorti avec bien plus que ca (vive l'abstraction !), mais en tout cas le diplôme n'etait pas la priorité, vu que dès le départ je savais que je voulais faire de la recherche. Pourquoi ne pas être allé à la fac ? la différence de moyen. et je doute que mes copains venant de prepa ne venaient que pour le diplome, meme s'ils ont fait leur choix en se basant sur le classement des écoles et les classements aux concours de ceux qui avaient été acceptés les années d'avant.
Après, j'ai tendance à avoir un a-priori négatif sur les ecoles privées, mais c'est peut-etre parce que j'ai un apercu partial : des gens de milieu-bas de classement de l'IUT dans lequel j'étais ont été acceptés volontiers par l'école d'ingé d'à coté. Mais peut-etre ne sont elles pas toutes dans ce cas.
étant utilisateur de ion3 et celui-ci ayant quelques problemes au moins sur ma config, le concept de CLFSWM m'interesse beaucoup, vu qu'il semble bien plus general que ion3 (l'arbre de cadres me plait beaucoup !), et qu'il semble facile de refaire ion3 au moins partiellement comme un cas particulier de CLFSWM...bref, il est clairement dans ma liste "TO-TEST" :)
mais pour le tester, il faut l'installer, et ne voulant pas le faire à la main, j'ai cherché un paquet debian...mais je n'en ai trouvé aucun, meme pas pour une version plus ancienne...il n'y a donc que l'installation à la main comme possibilité ? ou j'ai mal cherché ?
pour l'instant, tout ce que la programmabilité croissante des GPU a apporté, c'est une autre ressource à utiliser en meme temps que le CPU, ou à coté, pour des problèmes qui s'y pretent bien (et ils sont loin de tous bien s'y preter). Quand j'ai un probleme à regler, j'ai 2 approches possibles, je me dis pas que je vais utiliser que le CPU ou que le GPU, mais je vais essayer d'utiliser les 2 au mieux, en essayant de prendre en compte les problemes de localisation des données tout ca.
et vivement que les cartes physiques programmables arrivent, ca fera un troisieme type d'unité de calcul efficace pour une autre classe de problemes, ca sera bien en conjonction avec ce qu'on a deja !
pourquoi vous ne leur demandez pas de compiler directement en ASM ? nous c'est ce qu'on nous a demandé en 2A pour le projet de compil, et ca permet de voir d'autres problematiques en plus de celles données ici, sauf le mangling certes mais bon, c'est pas le plus important je pense.
g++ le fait, pourquoi codeworker ne le ferait pas ? au pire il faut regarder comment les createurs de g++ ont fait, libre powa ! \o/ Tout ca pour dire qu'avec le temps et la motivation, c'est faisable, et que donc je ne vois pas pourquoi ils n'en seraient pas capables...
et doxygen a t'il reellement besoin d'un parser exact ?
Personnellement je n'aime pas java, donc je risque pas de tomber dans leur marketing. j'ai appris la prog sur le tas, l'objet sur le tas (comme beaucoup de monde, il n'y a rien d'extra à ca) et ca m'a permis de me faire une idée sans intervention exterieure sur l'apport de cette approche...certes la POO ca fait pas encore le café, mais en tout cas pour les critères cités ca aide bien, enfin en tout cas pour moi ;-)
et au milieu il y a les ingés qui veulent devenir chercheurs, qui savent à peu près à quoi s'en tenir des 2 cotés :-)
Cela dit, j'ai rencontré des ingés qui pensent effectivement que la recherche ca sert à rien...mais par contre coté chercheur, bien que n'en ayant pas rencontrés beaucoup (la plupart étant mes profs), je n'ai pas vu le coté "les ingés c'est des nuls". Cela dit je ne doute pas que certains pensent comme cela. Mais bon, faudrait pas non plus prendre l'arbre pour la foret quoi...enfin, j'espere que les gens visés ne sont bien que l'arbre qui planque la foret, sinon c'est grave ^^
ben tu prends le code asm généré pour ca par exemple, ou les instructions proc executées... :)
les approches recursives et imperatives sont turing-complet, donc tout ce que tu peux ecrire dans l'un est ecrivable dans l'autre.
ouais mais après, comme tu le dis, c'est toujours la meme chose quelque soit le langage, à plus ou moins haut niveau. Mais bon, un developpeur c'est aussi faineant, et reinventer la roue c'est moyen niveau faineantise :-)
Donc il faut voir ce qui va être fait, et surtout garder un oeil dessus, pour eviter ce genre d'écueils ;)
certes, pour les IDE on y travaille, mais c'est un boulot enorme. J'ai fait un plugin pour KDevelop avec auto-completion intelligente etc, mais ca représente des mois de boulot (en tout cas quand on est accessoirement etudiant). Donc c'est bien de dire "oh y a rien je regarde pas, il vous manque ca ca et ca", mais c'est bien aussi de mettre la main à la patte. C'est là qu'interviennent les communautés non ? ;-)
certes, mais definir la semantique de chaque bloc tu ne peux pas. resultat, à la fin tu te demandes ce que vas faire chaque fonction...c'est un probleme plus general cela dit, et qui font que Lisaac, avec les mots clés, permet d'avoir ce genre de constructions complexes. un exemple bete qui fera que tu auras des problemes avec C# :
1 : mon_arbre.foreach_while {...} do {...} finally {...};
2 : mon_arbre.foreach_while {...} do {...} at_beginning {...};
bon ce sont des exemples un peu à la con, mais ca montre bien le probleme.
De plus, et là il y a une difference enorme, c'est que tu ne peux pas "manipuler" ton bloc. Comment fais-tu des structures du genre
bloc.f1 {//code}.f {....} etc ?
typiquement, le if ... elseif ...elseif est codé comme cela en lisaac, elseif etant une mthode codée dans BLOCK. Tu ne peux pas appeler de membres sur ta fonction lambda, donc les structures "à plusieurs étages" ne sont pas faisables. BLOCK est bien plus general que les declarations lambda.
je suis d'accord avec toi, sauf que ca ca s'applique aussi à la transition imperatif/Objet (ou Cobol/Java ca marche aussi)...pourtant le pas a été fait, c'est donc bien que ca fournissait un atout. Tout le problème c'est que pour voir les avantages que ca apporte il faut accepter d'y consacrer un peu de temps...(par exemple le passage à J2EE, qui dans le genre pas facile à prendre en main est pas mal, meme si ca amene ensuite pas mal de confort pour certains types d'applis)
je ne connais pas C#, mais rien que de voir que y a 15 manieres d'exprimer la meme chose prévues par la grammaire en elle-meme je me dis que niveau redondance c'est pas mal...ou alors y a de fines nuances sur le comportement...
Et si on veut avoir des conditions (comme pour le foreach_while ou autre), qu'on veut 3 blocs en parametres, etc, on fait comment ? moi c'est résumé, il n'y a qu'une seule maniere, elle est claire et non ambigue.
Dans ton exemple,
mon_arbre.Foreach(i =>
{
//mon code
});
le i, tu le declares avant ? meme question pour le elem de ton 1er extrait de code que j'ai remis dans ce commentaire...Non parce que ne connaissant pas C# ca me laisse confus...
OUi, obligé de faire une fonction pour ca, c'est vachement lisible dis moi ! on voit vachement le coté prediqué de la chose...à la relecture je doute que tout le monde comprenne ce que ca fait, comparé à un :
mon_arbre.for_all { i : ITEM;
//code
};
il y en a une que je comprend tout de suite (parce que la notation ressemble à ce qu'on trouve dans beaucoup de langage), l'autre non (on me donne à froid ton code je ne sais pas ce que ca fait).
Les 2 approches sont valables, mais une est definitivement limitée à un domaine, plus ou moins vaste certes, mais limité, contrairement à l'autre.
[^] # Re: sinon
Posté par tarlack . En réponse au journal Transformers 3 : la face cachée de la lune. Évalué à 1.
voir ce film en streaming ca sert à rien, vu que dans ce cas il faudrait qu'il y ait du suspense ou un scénario un peu profond pour tenir les 2h35. Je suis allé le voir pour les effets spéciaux, et j'en ai pris plein les mirettes à regarder tous les détails et tout le soin qu'ils y ont mis. C'est le genre de film où justement le cinéma a un interet, plutot qu'etre tranquillement chez soi avec sa boisson préférée à moins de 5€ dans la main : un ecran de plusieurs metres et une installation audio au poil ca permet d'apprécier tout ca.
Si les effets speciaux ca t'interesse pas (et je respecte tout à fait), ne regarde pas ce film (et surtout pas en streaming), il n'a que peu d'interet. Par contre si les prouesses techniques t'interessent, alors fait honneur aux quelques dizaines (voir centaines) d'artistes et d'ingés (on les oublie souvent, mais y en a une tripotée qui se prennent la tete pour rendre ca possible) qui ont bossés dessus et ont fait quelque chose d'un niveau que je n'avais que rarement vu avant (et pourtant des films à effets speciaux, j'en ai vu !).
Personnellement, j'y allais pour voir une démoreel gigantesque, et j'y ai eu droit (les moments sans action étant assez ininteressants). J'en suis ressorti ravi !
[^] # Re: Un peu précipité, non ?
Posté par tarlack . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 1.
En tout cas très interessant votre boulot de recherche ! y a de la doc (papiers, ...) dispo et lisible par quelqu'un ayant des connaissances limitées en compil et trucs dans le genre ?
[^] # Re: Un peu précipité, non ?
Posté par tarlack . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 3.
[1] http://ompf.org/forum/
[^] # Re: Un peu précipité, non ?
Posté par tarlack . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 10.
1/oui, on peut faire n'importe quel type de calcul. Avec CUDA par exemple (openCL j'ai regardé de très très loin, mais de ce que j'ai vu ca devrait etre pareil), tout le côté pipeline graphique est caché, meme si tu peux interagir un peu avec openGL côté CPU (j'ai pas trop regardé ca). Tu vas programmer ce que Le langage ressemble très fortement au C, avec quelques mots clés en plus pour dire ce qui est sur GPU ou sur CPU, et gerer la hierarchie mémoire (que tu gères de manière explicite). Niveau prog effective, c'est comme du C : tu peux boucler, appeler des fonctions, ... . Alors par contre à la réflexion je sais pas si ca gere les pointeurs de fonctions - je n'en ai pas eu besoin -, comme tout est inliné dans le noyau (équivalent du main() d'un prog C). Et après, tu appelles ton noyau depuis un prog (C ou C++) presque comme une fonction normale, tu précises juste comment tu répartis chaque tache sur le GPU (je te laisse te référer au guide de programmation de CUDA - très bien fait, trouvable dans le SDK - pour plus de détails).
2/ Tout peut être calculé, mais d'un autre côté, seuls une partie des problèmes peut être traités efficacement par le GPU. Typiquement, les GPUs ne sont pas du tout adaptés aux algos purement séquentiels avec une seule donnée à traiter à travers de nombreuses étapes. Le mieux, c'est quand tu veux N résultats (N grand) d'une même fonction (ne bossant pas forcément sur les mêmes données, heureusement ^^). Dans ce cas, ton noyau contiendra le code d'une tâche. tu peux aussi faire des opérations où tu ne veux qu'un seul résultat, pour des fonctions de type "rédux". Si les données de base sont très grosses, le gain est vraiment notable aussi. Bon après des fois des algos qui apparemment ne s'y pretaient pas peuvent être adaptés, c'est au cas par cas.
3/Si j'ai bien compris, le Larrabee se programmera comme un GPU, avec du vectoriel en plus. Après, peut-etre qu'ils proposeront plusieurs niveaux : un niveau "facile", ca sera du openCL (threading et SIMD géré automatiquement), et un niveau "bas niveau", où tu te feras ton threading toi-meme et exploitera le SIMD toi-même. N'étant pas devin et ne bossant pas sur le Larrabbee, j'attend de voir ^^. Dans tous les cas, ca sera par du parallélisme massif qu'on en tirera le mieux (plus y a de taches, plus on peut cacher la latence des accès mémoires)
4/ben la CUDA zone donne un bon apercu...je l'utilise pour du rendu par lancer de rayons, mais des gens l'utilisent en dynamique des fluides, en electrodynamique, en rayonnement, ... en gros, dès que c'est intensif et qu'on veut plein de résultats d'un même calcul de base.
les algos qui en tirent le plus parti
*parce qu'il y en a toujours, loi 1 de l'humanité ^^
[^] # Re: Fallais y penser !!!
Posté par tarlack . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 3.
déjà les labos en achètent (et pas que dans les équipes de synthèse d'images, mais aussi certains labos de physique), parce que s'ils peuvent faire leurs calculs dessus, ils sont preneurs :) après, si vraiment ça marche bien, les industries concernées vont certainement s'y mettre aussi, il suffit de voir la gamme Tesla de nVidia (4 GPU avec 4Go de RAM par GPU, pas de sortie video) pour voir qu'ils sont près à cela et l'espèrent fortement...
# Un peu précipité, non ?
Posté par tarlack . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 10.
Après, qu'utiliser de manière efficace le GPU soit non trivial, certes (et je peux en parler, je l'utilise, et je trouve ça non trivial). Mais utiliser le SSE (et plus généralement les instructions vectorielles) de manière efficace peut être tout aussi casse-tête, et demande des adaptations majeures des algorithmes (au moins pour ceux que je connais, liés à la synthèse d'images). Utiliser les SPUs (vectoriels et avec gestion de la mémoire code/données explicite) de la PS3 au maximum de leurs perfs est tout aussi difficile (aussi testé). Et rien qu'utiliser un CPU efficacement (donc s'arranger pour ne pas exploser le cache, minimiser le nombre de défauts de pages, etc) demande là aussi des adaptations non négligeables sur les algos, et pas mal de réflexion (au moins pour moi). Bref, toute utilisation orientée performances nécessite une bonne connaissance du matériel et une adaptation des algos plus ou moins importante, il n'y a rien de nouveau ni de spécifique aux GPUs là dedans. Concernant la flexibilité des GPU et leur bonne capacité à traiter des problèmes liés au calcul scientifique, il suffit d'aller sur la CUDA zone [1] pour voir que ce n'est pas que de la 3D temps réel, loin de là.
Donc au final, il y a toujours les mêmes problèmes qu'avant : quelle est la techno la plus adaptée à mon problème ? Sans essayer ou sans forte expérience sur chacune des technos disponibles, il me semble très difficile de le dire... Mais jeter à la poubelle une techno parce qu'on ne peut pas en tirer le maximum en codant avec ses pieds, je trouve ça un peu hâtif. De plus, la somme de travaux faits sur la programmation générique des GPUs est quand même bien moindre que celle faite sur l'utilisation des CPUs. Ça ne fait que quelques années que ca existe, et je trouve que les résultats sont plus que prometteurs quand on sait depuis combien de temps on utilise les CPUs actuels et qu'on compare les résultats pour des problèmes où les GPUs sont adaptés. Et les outils commencent à arriver eux aussi (debugger notamment, cf [2]). Donc voyons ce que ça va donner, je doute qu'on ait assez de recul actuellement pour juger.
[1] http://www.nvidia.com/object/cuda_home.html# (je sais, c'est du flash....)
[2] http://developer.nvidia.com/object/nexus.html (je sais, c'est que pour windows, je suis le premier que ca embête croyez le bien, mais bon, les outils arrivent !)
[^] # Re: ?
Posté par tarlack . En réponse à la dépêche Conférence sur l'échange de fichiers en 3D (VORTEX). Évalué à 2.
je trouve que c'est une très bonne initiative de proposer ce genre de projets à des personnes d'IUT, mais un petit peu plus de détails seraient les bienvenus ;)
[^] # Re: Publi-Dépêche
Posté par tarlack . En réponse à la dépêche WinGineer : concours d'algorithmique, avec bourse d'étude d'ingénieur. Évalué à 0.
[^] # Re: Publi-Dépêche
Posté par tarlack . En réponse à la dépêche WinGineer : concours d'algorithmique, avec bourse d'étude d'ingénieur. Évalué à -1.
c'est marrant, quand je suis arrivé à mon école d'ingé (publique), j'y suis allé pour acquérir des connaissances en info et en maths, et j'en suis ressorti avec bien plus que ca (vive l'abstraction !), mais en tout cas le diplôme n'etait pas la priorité, vu que dès le départ je savais que je voulais faire de la recherche. Pourquoi ne pas être allé à la fac ? la différence de moyen. et je doute que mes copains venant de prepa ne venaient que pour le diplome, meme s'ils ont fait leur choix en se basant sur le classement des écoles et les classements aux concours de ceux qui avaient été acceptés les années d'avant.
Après, j'ai tendance à avoir un a-priori négatif sur les ecoles privées, mais c'est peut-etre parce que j'ai un apercu partial : des gens de milieu-bas de classement de l'IUT dans lequel j'étais ont été acceptés volontiers par l'école d'ingé d'à coté. Mais peut-etre ne sont elles pas toutes dans ce cas.
[^] # Re: Publi-Dépêche
Posté par tarlack . En réponse à la dépêche WinGineer : concours d'algorithmique, avec bourse d'étude d'ingénieur. Évalué à 2.
c'est marrant, quand je suis arrivé à mon école d'ingé (publique), j'y suis allé pour acquérir des connaissances en info et en maths, et j'en suis ressorti avec bien plus que ca (vive l'abstraction !), mais en tout cas le diplôme n'etait pas la priorité, vu que dès le départ je savais que je voulais faire de la recherche. Pourquoi ne pas être allé à la fac ? la différence de moyen. et je doute que mes copains venant de prepa ne venaient que pour le diplome, meme s'ils ont fait leur choix en se basant sur le classement des écoles et les classements aux concours de ceux qui avaient été acceptés les années d'avant.
Après, j'ai tendance à avoir un a-priori négatif sur les ecoles privées, mais c'est peut-etre parce que j'ai un apercu partial : des gens de milieu-bas de classement de l'IUT dans lequel j'étais ont été acceptés volontiers par l'école d'ingé d'à coté. Mais peut-etre ne sont elles pas toutes dans ce cas.
[^] # Re: paquet debian ?
Posté par tarlack . En réponse à la dépêche Sortie de CLFSWM 0809.. Évalué à 2.
cela ne me regarde peut-etre pas, mais pourquoi tu devrais faire un paquet non-officiel ? pourquoi pas un officiel ?
[^] # Re: paquet debian ?
Posté par tarlack . En réponse à la dépêche Sortie de CLFSWM 0809.. Évalué à 3.
....
ah mince on est vendredi :D
# paquet debian ?
Posté par tarlack . En réponse à la dépêche Sortie de CLFSWM 0809.. Évalué à 2.
étant utilisateur de ion3 et celui-ci ayant quelques problemes au moins sur ma config, le concept de CLFSWM m'interesse beaucoup, vu qu'il semble bien plus general que ion3 (l'arbre de cadres me plait beaucoup !), et qu'il semble facile de refaire ion3 au moins partiellement comme un cas particulier de CLFSWM...bref, il est clairement dans ma liste "TO-TEST" :)
mais pour le tester, il faut l'installer, et ne voulant pas le faire à la main, j'ai cherché un paquet debian...mais je n'en ai trouvé aucun, meme pas pour une version plus ancienne...il n'y a donc que l'installation à la main comme possibilité ? ou j'ai mal cherché ?
[^] # Re: Et si rien ne disparaissait ?
Posté par tarlack . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 2.
et vivement que les cartes physiques programmables arrivent, ca fera un troisieme type d'unité de calcul efficace pour une autre classe de problemes, ca sera bien en conjonction avec ce qu'on a deja !
[^] # Re: ...
Posté par tarlack . En réponse à la dépêche CodeWorker 4.4. Évalué à 2.
[^] # Re: Parser du C++
Posté par tarlack . En réponse à la dépêche CodeWorker 4.4. Évalué à 5.
et doxygen a t'il reellement besoin d'un parser exact ?
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Cela dit, j'ai rencontré des ingés qui pensent effectivement que la recherche ca sert à rien...mais par contre coté chercheur, bien que n'en ayant pas rencontrés beaucoup (la plupart étant mes profs), je n'ai pas vu le coté "les ingés c'est des nuls". Cela dit je ne doute pas que certains pensent comme cela. Mais bon, faudrait pas non plus prendre l'arbre pour la foret quoi...enfin, j'espere que les gens visés ne sont bien que l'arbre qui planque la foret, sinon c'est grave ^^
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
les approches recursives et imperatives sont turing-complet, donc tout ce que tu peux ecrire dans l'un est ecrivable dans l'autre.
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Donc il faut voir ce qui va être fait, et surtout garder un oeil dessus, pour eviter ce genre d'écueils ;)
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
1 : mon_arbre.foreach_while {...} do {...} finally {...};
2 : mon_arbre.foreach_while {...} do {...} at_beginning {...};
bon ce sont des exemples un peu à la con, mais ca montre bien le probleme.
De plus, et là il y a une difference enorme, c'est que tu ne peux pas "manipuler" ton bloc. Comment fais-tu des structures du genre
bloc.f1 {//code}.f {....} etc ?
typiquement, le if ... elseif ...elseif est codé comme cela en lisaac, elseif etant une mthode codée dans BLOCK. Tu ne peux pas appeler de membres sur ta fonction lambda, donc les structures "à plusieurs étages" ne sont pas faisables. BLOCK est bien plus general que les declarations lambda.
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
donc si je resume, on avait une syntaxe du genre :
C#
maliste.foreach_while(elem => elem.Foo() , elem => elem.truc == 0);
et
Lisaac
mon_arbre.for_all { i : ITEM;
//code
};
je ne connais pas C#, mais rien que de voir que y a 15 manieres d'exprimer la meme chose prévues par la grammaire en elle-meme je me dis que niveau redondance c'est pas mal...ou alors y a de fines nuances sur le comportement...
Et si on veut avoir des conditions (comme pour le foreach_while ou autre), qu'on veut 3 blocs en parametres, etc, on fait comment ? moi c'est résumé, il n'y a qu'une seule maniere, elle est claire et non ambigue.
Dans ton exemple,
mon_arbre.Foreach(i =>
{
//mon code
});
le i, tu le declares avant ? meme question pour le elem de ton 1er extrait de code que j'ai remis dans ce commentaire...Non parce que ne connaissant pas C# ca me laisse confus...
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
il y en a une que je comprend tout de suite (parce que la notation ressemble à ce qu'on trouve dans beaucoup de langage), l'autre non (on me donne à froid ton code je ne sais pas ce que ca fait).
Les 2 approches sont valables, mais une est definitivement limitée à un domaine, plus ou moins vaste certes, mais limité, contrairement à l'autre.