Version imprimable
Citation:
ce ne serait pas marketing... ça se saurait
oui mais je pense qu'il y a du vrais sun c'est pas microsoft
de plus je le dis encore il faut voir ce de quoi est capable le java monkey engine ou le jeux tribal trouble
des évolutions sont prévu pour utilsé des processeur multi coeur comme celui de la PS3
et normalement il y aura une version de java sur PS3
En fait si j'ai bien compris Java est le langage utilisé pour faire des trucs interactifs sur les BlurayCitation:
Envoyé par super_navide
http://www.pcinpact.com/actu/news/35...ragon-lair.htm
http://en.wikipedia.org/wiki/BD-J
Premier principe, ne pas faire en hard ce qui ne peut pas y etre plus efficacement fait qu'en soft.Citation:
J'ai notions il y'a un cours sur ce site que j'ai lu et il y a les souvenir de facs
Avec quel gain? Un tel algo est limite par la bande passante de toute maniere.Citation:
Envoyé par super_navide
En quoi est-ce que ca concerne le processeur?Citation:
comme séparé la mémoire en deux espaces les classes et les instances
Qu'est-ce que ca signifie pour un S.E. d'etre objet? Qu'est-ce que ca apporterait?Citation:
de plus il y a aussi le system d'exploitation qui pourrait être objet et facilter le fonctionnement du GC
Qu'est-ce que le S.E. pourrait faire pour facilite le fonctionnement du GC?
Je ne vois pas en quoi? A part que Java force une certaine idee de l'OO.Citation:
java est un vrai langage objet moin que Smalltalk mais quand même bien plus qu'en C++
Le probleme sera le meme quel que soit le langage.Citation:
Ca semble peut-être évident mais calculer la complexité d'un algorithme est la vrais source de performence et n'est pas un reflexe chez tous les développeurs
Tu es sur que ce ne sera pas Fortress ;)Citation:
de plus si sun proclame que java sera la future plateforme pour les jeux videos ca n'est pas pour rien
à l'adresse suivante il y a un article sur les futures versions de java sur d'autre supportCitation:
En fait si j'ai bien compris Java est le langage utilisé pour faire des trucs interactifs sur les Bluray
http://www.pcinpact.com/actu/news/35...ragon-lair.htm
http://en.wikipedia.org/wiki/BD-J
http://weblogs.java.net/blog/invalid...forms_n_1.html
en hard c'est forcement plus rapide car il y a pas de decodage d'instructionCitation:
Premier principe, ne pas faire en hard ce qui ne peut pas y etre plus efficacement fait qu'en soft.
certain programme de traitement d'image implémenté sur des FPGA donnes des résultat meilleur que l'excution de celui ci sur un processeur
le revère de la medaille c'est que c'est plus complexe en mettre en place et plus difficile à maintenir
la règle est plutot ne pas faire en hard ce qui pourra surrement être amélioré ou ce qui doit évoluer ou doit être corrigé
et encore les carte graphique font bcp de chose en hard et sont souvent amélioré
Je n'ai pas tout suivi le debat (il y a beaucoup a lire :aie:), je risque de répéter ce qui a été dit avant.
Je travaille avec les 2 langages et les applis générées communiquent ensemble (grace a Corba).
J'en ai conclu que l'utilisation de tel ou tel langage dépend de l'application cible. Dans mon cas, on a un serveur multithreadé en Java qui commande et gere des serveurs de calcul en C++.
Java est mieux pour le multithreading, son API et son IDE (Eclipse) qui permet d'etre plus productif qu'en C++. Java a certains concepts pas tres simples a aprehender avec par exemple la gestion de la memoire avec garbage collector. Les evolutions du langages tendent a ressembler a du scotch pour palier les differences avec .Net.
C++ est plus performant. En contrepartie, il est compliqué a mettre en oeuvre (pointeurs, fuites de mémoires moins évidentes qu'en Java, ...) . L'IDE VS 2003 est plutot moyen en C++ (meilleur en C#). Les API sont aussi dispo (boost, STL, ...) mais sont plus dures a maitriser.
A deboguer, le C++ a ma preference (VS assure plus qu'Eclipse sauf en multithread ou Eclipse semble etre roi :king: ) et on accede a peu pres a tout assez facilement. Alors qu'en Java, on a l'impression que tout est caché.
Tu oublies de regarder le systeme dans son ensemble. Si tu prends de la place sur un processeur pour y mettre quelque chose, tu renonces a la possibilite d'y mettre autre chose.Citation:
Envoyé par super_navide
Et? D'une part, les caracteristiques des algos de traitement d'image sont passablement differentes des caracteristiques des algos de GC et je ne vois pas pourquoi le gain a mettre un des premiers sur un FPGA est transposable en quoi que ce soit aux seconds.Citation:
certain programme de traitement d'image implémenté sur des FPGA donnes des résultat meilleur que l'excution de celui ci sur un processeur
Deuxiemement, le passage du FPGA a l'integration dans un processeur ne me semble pas si simple que cela.
La conception d'un circuit est un compromis. J'aimerais bien avoir une idee de ce que tu esperes gagner en mettant un GC dans un processeur. Apres on pourra discutter de ce que tu veux enlever et donc de ce que tu perds la, et enfin de l'interface du GC avec l'OS et les processus utilisateurs -- deux choses qui ne me semblent pas tres simples a concevoir mais ca ne vaut pas la peine d'entrer la dedans si il n'y a en fait pas de gain a esperer.
Oui.Citation:
le revère de la medaille c'est que c'est plus complexe en mettre en place
Les temps de cycle sont plus long -- et plus couteux --, mais ce n'est pas particulierementCitation:
et plus difficile à maintenir
plus difficile.
C'est vrai aussi. Mais il faut d'abord savoir ce qu'on espere gagner. Partir sur le principe "en mettant dans le hard, c'est plus rapide", c'est oublier qu'une telle idee fut mainte fois prouvee fausse (il y a des instructions qui ne sont pas generees par les compilateurs parce qu'elles sont plus lentes que leurs equivalents par exemple).Citation:
la règle est plutot ne pas faire en hard ce qui pourra surrement être amélioré ou ce qui doit évoluer ou doit être corrigé
le seul truc que je trouve bien avec C++ et que personne ne dit c'est qu'une fois le programme compilé il n'a pas besoin d'une machine virtuel pour être executer donc c'est plus simple à deployé
codé en hard un algo est forcement plus rapide (je ne parle pas de micro instruction comme dans les processeurs ciscs je parle de gravure de transistor ).Citation:
C'est vrai aussi. Mais il faut d'abord savoir ce qu'on espere gagner. Partir sur le principe "en mettant dans le hard, c'est plus rapide", c'est oublier qu'une telle idee fut mainte fois prouvee fausse (il y a des instructions qui ne sont pas generees par les compilateurs parce qu'elles sont plus lentes que leurs equivalents par exemple).
le problème ensuite est de faire en sorte que le compilateur les utilises.
De plus de mettre en hard des algo dans un processeur à un cout très important
c'est pour ca que la PS3 utilise une autre statégie c'est de faire un jeux d'instructions très simple et de multiplier les coeurs.
c'est le rapport prix/performence qui est un frein pour
creer un processeur objet
Qu'est-ce qui a ton avis est le facteur limitant des GC? Qu'est-ce que tu esperes gagner dessus en mettant un GC dans le processeur?Citation:
Envoyé par super_navide
(Mes reponses: la bande passante, je ne vois rien d'important a gagner, la bande passante restera le probleme.)
Le premier probleme est de definir quelque chose d'utile. Pour un GC, si tu y arrives, meme si le compilo ne s'en sert pas ce n'est pas grave. Le code est ecrit une fois pour toute.Citation:
le problème ensuite est de faire en sorte que le compilateur les utilises.
T'as pas encore été confronté au DLL Hell. Ca reserve de mauvaises surprises quand on ne fait pas attention. :aie:Citation:
Envoyé par super_navide
Citation:
Envoyé par Jean-Marc.Bourguet
il y a les regions de memoire du gc old space young space etc..
ca correspond au caches du processeurs bcp d'objet jeune meurt jeune
a partir de la les performances sont augmenté si on a un gc qui tourne sur le processeur pour libéré la mémoire dans le cache (pb de bande passante )
actuelement tous ce fait dans le mémoire de plus haut niveau ce qui est un problème
et jar HELL tu connaisCitation:
Envoyé par Monorom
Sun est une société comme les autres, et toutes les sociétés sont pareilles. Elles veulent un plus gros gateau. Faut pas être naïf comme ça les enfants.
De la lecture intéressante sur un thème connexe: http://www.blinkenlights.com/classiccmp/javaorigin.html
que je sache, on ne met pas tous les jar dans un répertoire commun, généralement nommé system32.Citation:
Envoyé par super_navide
Ne peut on pas déjà commencé à exploiter ce genre de processeurs avec des langages de type Erlang qui tente d'implémenter un paradigme plus concurentielle?Citation:
Envoyé par Jean-Marc.Bourguet
Si j'ai bonne memoire, l'approche d'Erlang fonctionne bien dans certains cas "faciles", ou il y a une decoupe naturelle en thread/process. Le probleme a mon avis est dans les cas difficiles, ou si on decoupe on se retrouve avec la question de la synchronisation et du risque qu'au dela d'un nombre relativement petit de processeurs, on ne sache plus progresser.Citation:
Envoyé par Gnux
Comme les perfs en monothreads vont saturer/saturent deja -- on commence a voir des propositions un peu folle du genre pousser les coeurs en frequence au dela de ce qui est soutenable en continu mais en changeant regulierement de coeur de sorte qu'en moyenne on reste dans les specs; la latence sature depuis un moment et si augmenter la bande passante reste possible et permet de compenser un peu, ce n'est pas non plus une solution pour tout -- la seule source de progression a long terme c'est la parallelisation. Et faire une decoupe en (simplement) 10 process n'est pas simple du tout et pas toujours possible. Comment alors decouper un 100 process ou plus? On peut commencer a envisager des algo ou il faut plus de calcul mais mieux parallelisable donc on gagne en latence, mais meme cela ce n'est pas simple non plus. Il faudra de toute maniere de l'aide des langages pour la decoupe -- et simplement avoir une notion de process ne suffira pas.
c'est plus compliqué que ca ca dépend du type de problèmes a résoudreCitation:
Envoyé par Jean-Marc.Bourguet
pourquoi on créer des carte physique engine ou des carte graphique ??
on spécialise le processeur pour gagné de la vitesse
l'idéale serait un processeur regravable par logicielle mais bon la c'est pas demain la vaille peut-être avec les nanos technologie
de plus java permet de faire de la programmation en parallèle efficacement a cause de syntaxe de thread build-in
par exemple OpenMP est devenu un standard pour la parallelisation sur des processeurs a memoire partagé et il n'est disponible qu'en C++ et fortran
mais ou est Java ?
en plus comme dit precedemment, il faut sacrement reflechir au parallelisme de demain, et les processus/threads seront largement insuffisant.
1/ openMP n'est pas la solution dans ce cadre. C'est quelque chose de vraissemblablement tres utile dans son domaine mais qui est tres marque par celui-ci.Citation:
Envoyé par epsilon68
2/ Les processus et les threads seront ce qui sera utilise. Le probleme est de savoir comment le programmeur interragira avec eux.
Il faut que l'application s'y prete pour que specialiser permette de gagner suffisemment pour en valoir la peine. Quelque chose d'aussi parallele dans son principe que le calcul graphique s'y prete en effet tres bien.Citation:
Envoyé par super_navide
Les FPGA sont disponibles depuis longtemps. Il y a d'ailleurs des circuits qui combinent FPGA et processeurs.Citation:
l'idéale serait un processeur regravable par logicielle mais bon la c'est pas demain la vaille peut-être avec les nanos technologie
A ma connaissance Java ne resoud pas le conflit qu'il y a entre heritage et synchronisation (faire une recherche sur "inheritance synchronization anomaly" si vous ne savez pas de quoi je parle).Citation:
de plus java permet de faire de la programmation en parallèle efficacement a cause de syntaxe de thread build-in
le parralelisme peut se penser de plusieur façon
processeur vectoriel ou par thread
vectoriel j'entend faire N operation simple (addition / division / multiplication/affectation /comparaison) en même temps (exemple pour un multiplication de matrice c'est utile )
lequel de ces concept est le meilleur ? le seconds est implémenté dans les carte graphique