La programmation s'en retrouve assez peu affectée finalement.
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
La programmation s'en retrouve assez peu affectée finalement.
On peut imaginer avoir des kernels spécifiques sur les cores GPU, et donc avoir des API/Services spécifiques. Du coup, une programmation différente pour les applications utilisant ces cores.Envoyé par deadalnix
On peut aussi imaginer que le kernel soit assez sophistiqué pour déléguer automatiquement une tache spécifique a un core spécialisé. Auquel cas, ca ne changerait effectivement pas trop la manière de programmer.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je suis également d'accord avec Paul Toth. Que je salue bien bas pour ses ouvrages qui m'ont été utiles.
Plus les machines évoluent, plus on programme lourd avec des "binaires" lourd.
Depuis la fin des années 90 les machines ont fait une montée en puissance phénoménale et le constat est toujours pareil. J'ai ici un Dual Core 2ghz et parfois j'ai l'impression de me retrouver devant un 386.
J'entends souvent le discour, à propos de Java, que c'est pas grave si c'est lourd car on a la puissance machine. En gros on gaspille !!!
Bref, de manière générale, l'utilisation des ordinateurs n'est pas plus fluide aujourd'hui qu'il y a 10 ans. L'utilisation est la même : principalement du Web, du texte et des jeux.
Il n'y a vraiment que pour la création multimédia que ça a évolué, mais là ça se fait toujours avec des règles classiques et des outils de développent, même s'ils ont évolués, qui sont très proches de ce qu'il y avait il y a 10 ans.
Java et .Net ne remplaceront jamais un véritable exécutable qui cause directement à l'Os et à la machine. C'est pourtant ce que veulent nous faire croire certains développeurs Java.
Une application Java ou .NEt, est certes moins rapide qu'une application en assembleur ou C.
Mais vu la complexité des applications modernes, on est prêt à sacrifier de la performance au profit de la stabilité et de la rapidité de développement. D'ou l'utilisation massive de bibliothèques, frameworks et machines virtuelles (meme en C/C++) depuis ces 10 dernières années.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je plussoie. On ne peut pas penser aujourd'hui une refonte de tout ce qui existe dans les logiciels en les orientant multithreading, d'une parce que chaque logiciel a une tâche bien précise, d'autre parce que pour avoir un peu étudié sur le sujet si on est pas bac+15 uniquement sur ça on rendra rien de vraiment efficace, différent et surtout, stable. (j'éxagère pour bac+15On peut aussi imaginer que le kernel soit assez sophistiqué pour déléguer automatiquement une tache spécifique a un core spécialisé. Auquel cas, ca ne changerait effectivement pas trop la manière de programmer.)
La vraie beauté de la chose serait en effet un OS qui serait capable de repérer, pré-exécution, quelles ressources sont critiques, quels threads sont concurentiels, lesquels sont dispachables sur un coeur de manière à pouvoir tourner tout seul dans son coin sans attendre pour rien et sans interférer sur le reste... et l'équipe qui sera foutue de mettre ça au point, ben je la salue d'avance (quelque chose me dit qu'un mec comme Sheldon serait intéressé)
Ou alors, ai-je mal compris et qu'il faudrait juste, au lieu de laisser un coeur s'occuper tour à tour de toutes les applications en cours, de partager les applicatiions en cours dans tous les coeurs... mais peut-être m'égare-je
L'approche OS Multi-Core ne va pas aussi loin que cela, pour l'instantLa vraie beauté de la chose serait en effet un OS qui serait capable de repérer, pré-exécution, quelles ressources sont critiques, quels threads sont concurentiels, lesquels sont dispachables sur un coeur de manière à pouvoir tourner tout seul dans son coin sans attendre pour rien et sans interférer sur le reste... et l'équipe qui sera foutue de mettre ça au point, ben je la salue d'avance (quelque chose me dit qu'un mec comme Sheldon serait intéressé
Ou alors, ai-je mal compris et qu'il faudrait juste, au lieu de laisser un coeur s'occuper tour à tour de toutes les applications en cours, de partager les appli en cours dans tous les coeurs... mais peut-être m'égare-je
Dans les OS actuels, il n'y a qu'un seul "kernel" qui est chargé de gérer les accès concurrents aux ressources, et chargé d'attribuer des quantums de temps CPU aux threads. Ces tâches étant privilégiés et prioritaires, le kernel est amené à "bloquer" l'execution des threads "applicatifs" pour faire son boulot.
En gros, on pourrait dire que le kernel est un service "mono tache" qui doit être utilisé par plusieurs applications. Il y a donc une sorte de "file d'attente" qui se créé. Chaque application qui a besoin du kernel (= donc toutes) doit attendre son tour.
L'approche OS Multi-Core consiste a avoir plusieurs kernels : un par CPU. Chaque kernel gère un CPU, un espace mémoire, un ensemble de ressources, ... Un kernel s'occupe donc de moins d'applications, et donc pénalise moins d'application lorsqu'il doit faire son boulot.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je ne pense pas que ce soit la priorité à l'heure actuelle. Les problèmes d'accès concurrents aux différentes ressources sont plus pénalisants que les OS monolithiques.
L'avantage de programmer en Java sous une machine virtuelle est très claire ici...
Ils peuvent changer ce qu'ils veulent niveau OS, ça sera le boulot de Sun d'adapter sa machine virtuelle pour qu'elle puisse tirer partie des nouvelles fonctionnalité des OS et "mapper" les concepts de multi-threading avec ce qui existera plus tard...
C'est la stabilité des applications dont parle pseudocode (entre autre, si j'ai bien compris).
Yoshi
PS : tous les propos tenus dans le message ci-dessus sont à préfixer avec "A mon humble avis", "Je pense que". Il serait inutilement fastidieux de le rappeler à chaque phrase.
L'aspect monolithique - en opposition a micro-kernel - n'est pas remis en cause (même si les tests ont été faits sur des micro-kernel)
Le problème d'accès aux ressources vient surtout du fait qu'on n'a qu'un seul OS, et que cet OS doit se débrouiller pour à la fois piloter la ressource (driver) et gérer les accès concurrents.
L'approche multi-core implique un niveau "hyperviseur" afin que chaque kernel puisse accéder aux ressources. En ce sens, la gestion des accès concurrents se fait a deux niveaux:
- l'hyperviseur qui virtualise la ressource physique en autant de ressources virtuelles qu'il y a de kernels
- le kernel, qui gère les accès concurrents à sa ressource (virtuelle)
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Ce genre de déclaration n'est pas surprennante, Microsoft travaille sur des projets comme Helios ou Singularity depuis des années.
Ces prototypes d'OS sont fait pour fonctionner sur des architectures distribuées et/ou hétérogènes donc ils sont bien adaptés aux environnements multi-coeur, multi-CPU, CPU+GPU....
Après la vraie question est : est-ce qu'un OS de ce type a des performances nettement meilleures qu'un OS "lamda" équipé d'openCL et d'une gestion multi-thread correcte ?
Car d'après les quelques statistiques qu'on trouve, c'est loin d'être le cas.
Je pencherai plutôt pour une jolie déclaration commerciale à la Apple dans le genre "on va révolutionner le monde promis ! suivez-nous"
It's not a bug, it's a feature
je pense que même sous Java il y a un moment ou tu vas te demander comment modifier ton superbe modèle théoriquement génial en quelque chose quoi soit moins théorique mais pragmatiquement plus performant...et c'est justement là que d'avoir de multiples couches va te compliquer la vie.
le fait que Java soit une VM ne change pas les choses, de nos jours on bosse avec des frameworks aussi bien en Java, en .Net qu'en Win32 ou Linux. L'avantage théorique de la VM est d'être multiplateforme...mais je connais peu d'application qui le soit réellement.
J'aimerais connaitre tes références en terme de performances... Pour ce qui est des performances actuelles des langages (sous debian) tu as des exemples ici.
ce tableau n'a pas beaucoup de rapport avec mon propos. Peu importe les performances du langage utilisé, il arrive dans tous les langages qu'un traitement prenne trop de temps pour que ce soit acceptable. Et alors on cherche à faire des optimisations qui vont en général à l'encontre de la "pureté" du code.
je programme habituellement sous Delphi, la VCL apporte une couche d'abstraction très intéressante au dessus de l'API Win32...sauf qu'il arrive que les performances de la VCL soient insuffisantes pour un traitement en temps réel. Il faut alors descendre plus bas dans l'API Win32 ou passer sur d'autres API (GDI+, DirectX...), voir passer une portion du code directement en assembleur pour atteindre un niveau suffisant.
Je faisais donc remarquer que plus il y a de couches d'abstractions, plus il est difficile de trouver comment optimiser le résultat final.
La dernière optimisation du genre que j'ai faite n'a d'ailleurs pas été au niveau GDI mais au niveau gestion mémoire car j'avais énormément d'objets détruits et recréés dans un laps de temps très court....ça prenait 80% du temps du traitement. En changeant les méthodes d'allocation mémoire j'ai donc grandement optimisé mon traitement. Si je n'avais pas pu intervenir sur la durée de vie de mes objets, ce sont les objets que j'aurais dû supprimer !
La plupart des langages bases sur un VM ont un mécanisme qui permet d'exécuter du code en dehors de la VM (= code natif) justement pour ce genre de raison.
Mais je ne vois pas trop le rapport avec les OS multi-core
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Oui, dernièrement quelqu'un me ventait les mérites de Java on expliquant combien JOGL était performantLa plupart des langages bases sur un VM ont un mécanisme qui permet d'exécuter du code en dehors le VM (= code natif) justement pour ce genre de raison.
Mais je ne vois pas trop le rapport avec les OS multi-core
non pas grand chose avec l'OS multi-core
Mais mon boss vient de me demander s'il était possible dans nos pages web d'avoir des zones numérique avec un séparateur de millier à la saisie ...peut-être qu'avec un nouveau OS on pourra appliquer un style CSS qui le fait
Les langages à VM ont un super avantage sur ce type d'OS, c'est de pouvoir tourner sur des architectures hétérogènes.
Je ne parle pas de faire quelque chose de plus performant, je parle de la transition entre les OS actuels, et les éventuels futur OS.
Je dis juste qu'il suffit d'adapter la JVM pour que toutes les applications qui tournent sous cette JVM continuent de fonctionner.
Je parlais pas des performances de Java actuelles.
Je ne parle que des applications java, ou parties d'applications java...
Le fait de souligner que lorsqu'on utilise autre chose que java pose un problème, ça confirme plutôt ce que je dis non ?
Yoshi
PS : tous les propos tenus dans le message ci-dessus sont à préfixer avec "A mon humble avis", "Je pense que". Il serait inutilement fastidieux de le rappeler à chaque phrase.
Je ne suis pas convaincu par l'idée selon laquelle l'impératif serait le paradigme le plus naturel.
Même le fonctionnel me paraît aussi naturel (déterminer l'action à effectuer selon l'action et le contexte courant plutôt que de les lister séquentiellement).
As-tu déjà essayé Erlang ?Dès qu'on attaque de la programmation concurrente, ouïe ouïe!
Soit on ne crée des threads ou autres que pour certains calculs dont on est certain que ça ne va pas interférer avec le prog principal, soit on essaye de tout mélanger en même temps et il faut y aller à coups de sémaphores, synchronized, etc. Tester dans tous les sens, se dire qu'avec les conditions de courses on peut avoir zapper un truc.
Par contre, si il y a moyen de trouver une nouvelle façon de penser les choses, là ça peut-être fantastique.Il y a plusieurs langages vraiment orientés vers des concepts différents, mais aucun (à ma connaissance) ne semble s'être vraiment imposé comme LA solution.
ok, je n'avais pas compris le sens de ton intervention.
c'est pas faux, mais je pense que la recompilation des sources est une meilleure approche ... déformation GPL sans douteC'est aussi pour cela que je préfère le langage Pascal au C/C++ car la compilation est non seulement plus rapide, mais également plus certaine (pas de configure, make, make install...juste un compilateur qui fait tout d'un coup en une seule passe avec des dépendances explicites)
Un expert de Microsoft qui déclare :
"on ne devrait plus avoir à patienter devant son ordinateur"
Cette nouvelle serait plus à sa place dans la catégorie HUMOUR (jaune)
Ce qui s'énonce clairement se conçoit bien ( Le hautbois)
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