Ce que la remarque veut dire, c'est qu'en green threads, même avec 100 processeurs libres, tout tournera quand même sur un seul proc en temps partagé.
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
Ce que la remarque veut dire, c'est qu'en green threads, même avec 100 processeurs libres, tout tournera quand même sur un seul proc en temps partagé.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Yes. C'est sur. A l'inverse, en threads native, même avec 100 processeurs libres, rien ne garantit que tout tournera simultanement.Envoyé par Médinoc
Les green thread sont quand meme bien pratique quand on a besoin de determinisme sur le scheduling. Par contre en terme de perf, c'est pas terrible car on empile deux couche de time-slicing (VM et OS).
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
c'est un aspect qui dépend totalement de l'implémentation de la JVM sur un OS particulier : pas de généralités à en déduire…
seul point à retenir :
si une application Java dépend du multithreading d'une manière particulière, il faudra surveiller cet aspect particulier lors du déploiement sur un autre OS et une autre JVM.
Bah pareil pour .Net !!
Une appli .Net qui tourne sur un win98/monopro va peut-etre pas se comporter parreil sur un vista/quadcore...
(enfin j'espere... sinon ils vendront pas bcp de multicore)
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
ne vous faites pas plus bête que vous l'êtes :
cela sous-entend évidemment : "sur le même hardware ou comparable"
sinon on va partir dans tous les sens…
sauf que l'on parle beaucoup de l'abc des threads, alors que ma question originale concerne les techniques de communications avancées entre threads, éventuellement de process différents et éventuellement sur des hôtes différents…
Tsssss je te laisse deviner et faire une recherche sur les forums ou j'interviens souvent.
Bon je ne veux pas troller et faire du HS
et l'on me répond en parlant des primitives de bases de synchronisation de thread d'un seul process…
la synchronisation est une forme de communication mais pas la seule…
J'aurais plutôt dit : Langage managé : 1 / Langage natif : 0Sur .NET le support bi-pro sera meilleur car .NET utilise au plus pres les appels systemes.
Donc .NET 1 Java 0
Je m'explique !
Si je ne me trompe pas, la JVM de Sun n'utilise plus de "green thread". D'ailleurs elle n'en a jamais utilisée sous Windows mais seulement sous certains anciens systèmes Unix/Linux...
En effet, sous ces systèmes les threads natifs pouvaient être implémenté par des processus lourds, qui étaient donc nettement plus couteux à créer !
En environnement mono-processeur, les "green-threads" étaient donc mieux adapté, alors que c'était l'inverse en environnement multiprocesseur...
Les JVMs intégraient donc les deux implémentations (green thread et native thread), et il était possible de passer de l'un à l'autre via un simple paramètre de la JVM (-green ou -native).
Bref la JVM s'adapte au système hôte...
a++
Je ne suis pas d'accord
Comment fait un Thread sous Java pour veritablement demarrer ?
La JVM s'il est n'utilise pas les API natives par exemple sous Windows elle ne peut pas tourner !
Si tu declares un Thread dans ton applet Java et qu'un moment il n'appelle pas les API win32 CreateThread ou _beginthread comment le processus parallele est-il reellement cree ?
Si tu m'expliques comment chapeau !
Apparemment on ne parle pas de la meme chose : un "thread" chez moi c'est un processus parallele en bon francais et seuls l'OS + CPU peuvent permettre cette fonctionnalit.En effet, sous ces systèmes les threads natifs pouvaient être implémenté par des processus lourds, qui étaient donc nettement plus couteux à créer !
Le CPU notamment grace aux mechanismes du multitache et protection de zones memoires.
.NET et Java n'ont pas acces au CPU donc le multitache avec ces technologies c'est veritablement a apprecier
Donc il ya contradiction alors ? C'est bien ce que je dis la JVM appelle les fonctionnalites en natif et c'est pas JVM 1 natif 0 je m'excuse
Oui. Hotspot n'utilise plus que les Thread natives. Pour autant il y a pas mal d'options de lancement a hotspot concernant la gestion des threads
Oui. C'est meme sa raison d'etreBref la JVM s'adapte au système hôte...
Ok, je change ma phrase:
Une appli .Net qui tourne sur un win98/quadcore va peut-etre pas se comporter parreil sur un vista/quadcore...
(enfin j'espere... sinon ils vendront pas bcp de vista)
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
eh oui vu juste !
Qui nous dit que .NET et Java soient reellement optimises pour les Dual COre machin d'Intel et hyperthreading et compagnie ?
faux en natif tu pourras toujours arriver a optimiser ce qui n'est pas possible avec JVM ou .NET
Heu ! J'ai bien dit justement que sous Windows les threads natives ont toujours été utilisé !
Les "green-threads" correspondent simplement à une simulation des threads par la JVM : il y a un seul processus qui exécute plusieurs tâches en passant de l'une à l'autre (grosso modo la JVM fait le boulot que devrait faire l'OS).
Je ne vois pas ce qu'il y a de révolutionnaire là dedans ! On a du mal se comprendre...
a++
Ils ne le sont pas. Et ils ne le seront pas. Seul l'OS peut "optimiser" l'utilisation d'un hardware. Tout ce qui est au-dessus de l'OS ne voit que des "artefacts" fabriqués par l'OS (processeurs, prorités, ...)eh oui vu juste !
Qui nous dit que .NET et Java soient reellement optimises pour les Dual COre machin d'Intel et hyperthreading et compagnie ?
Exemple typique: avec un processeur hyperthreadé, Windows "montre" deux processeurs "physiques".
En programmation, un thread est plutot vu comme un "pointeur d'execution". Une sorte de curseur qui execute les lignes de codes les unes apres les autres. Lorsqu'on "lance" un programme, le processus créé un thread (le main-thread) qui commence a executer le code de la fonction main() {...} (ou equivalent).
Apres cela, le code lui meme peut contenir une commande qui va créer un autre thread (donc un second pointeur). Ce second pointeur va lui aussi se mettre a executer du code, parallelement au main-thread.
Dans le cas des thread native, les deux curseurs sont effectivement des thread de l'OS. Dans le cas des green thread, les deux curseurs sont gérés par la JVM.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Merci pseudocode pour avoir répondu à ces questions. J'espère que d'autres prendront aussi le temps pour discuter sur ces critères.
de fait…
dès que le noyau de l'OS évolue tout ce qui dépend du scheduling des tâches et des threads peut se voir affecté…
alors d'autant plus quand l'OS est totalement réécrit…
Je confirme... d'autant plus qu'en ce moment j'ai 1 bug sur le feu:
- une appli qui fonctionne correctement sur une JVM v5 sur un PC hyperthread.
- La meme appli qui ne fonctionne plus pareil sur une JVM v6 sur le meme PC hyperthread.
- La meme appli qui refonctionne correctement sur la meme JVM v6 sur le meme PC, avec l'hyperthread désactivé dans le BIOS
Bon, faut dire que la partie incriminée est du portage de code fait par des céplusplussiens en JAVA+JNI . C'est deja bien que ca marche.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
déjà vu ce type de situation avec un pdflib utilisé en DLL, serveur Windows, Coldfusion, …Je confirme... d'autant plus qu'en ce moment j'ai 1 bug sur le feu:
- une appli qui fonctionne correctement sur une JVM v5 sur un PC hyperthread.
- La meme appli qui ne fonctionne plus pareil sur une JVM v6 sur le meme PC hyperthread.
- La meme appli qui refonctionne correctement sur la meme JVM v6 sur le meme PC, avec l'hyperthread désactivé dans le BIOS
Bon, faut dire que la partie incriminée est du portage de code fait par des céplusplussiens en JAVA+JNI . C'est deja bien que ca marche.
le bug disparaissait quand on passait à la version EXE… (ou quand on désactivait l'hyperthreading…)
ce sont les tests de montée en charge avec JMeter qui avaient levé le lièvre…
la première réaction du développeur Coldfusion avait été de penser que l'on avait exagéré la charge dans JMeter… il a quand même poussé un gros ouf quand on a trouvé le coupable … et la solution… car les premiers logs pointaient dans sa direction (évidemment : c'était lui le "client" de la librairie en cause…)
Mille excuses alors j'ai mal compris
Oui c'est ce que je disais en fait
sinon tout le monde demeure étrangement silencieux sur ma remarque concernant Direct3d
Oui c'est ce que je disais en fait
sinon tout le monde demeure étrangement silencieux sur ma remarque concernant Direct3dPour .Net/Direct3D, le post que tu indiques se termine comme ca:
Donc ca m'a l'air de venir du code de l'appli et pas trop des wrappers du framework.eh bien je suis allé dans les options "déboguer >> exceptions" et j'ai décoché loaderlock. C'est pas super propre mais pour l'instant en attendant de "nettoyer" mon code ça m'évite des crises de nerfs
Pour java/Direct3D, comme le dit le tuto :
La raison d'etre de Java est la portabilité... et donc OpenGL est préféré a ClosedDIRECTXCette API est disponible uniquement sur la plateforme Windows. Comme cela est contraire aux principes de Java (portabilité), il y a très peu de moyen d'accéder à cette API en Java.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager