C' est quoi ce langage ?

[Jack]

Tu me confirmes que j'ai bien compris (j'ai un peu de mal): une appli "pas classique" c'est une appli qui utilise du parallélisme, "au niveau" du processeur ?

Tout dépend de ce qu'on appelle du parallèlisme. Je pensais plutôt au parallélisme hardware. On ne doit pas programmer des machines regroupant des grappes de processeurs comme une simple PC, même multicoeurs.
-----

[pm42]

Je précise ma question : en regardant les gros serveur mainframe IBM ( les system z par exemple) je vois qu'il y a plusieurs "type" de processeurs. Je me demandais si du coup ça changeait quelque chose pour le développeur "de base" ou si c'est une optimisation complètement transparente.
(note : ça n'a peut-être rien à voir avec l'architecture, j'y connais pas grand chose en processeur)

Non ca ne change rien pour le développeur de base.

[pm42]

Tout dépend de ce qu'on appelle du parallèlisme. Je pensais plutôt au parallélisme hardware. On ne doit pas programmer des machines regroupant des grappes de processeurs comme une simple PC, même multicoeurs.

Oui mais souvent, les langages et Api cachent une grande partie du hardware au niveau processeur et on se concentre sur le modèle de parallélisme induit par la communication entre les unités de calcul.

[invite0bbe92c0]

Tu me confirmes que j'ai bien compris (j'ai un peu de mal): une appli "pas classique" c'est une appli qui utilise du parallélisme, "au niveau" du processeur ?

Non, c'est devenu une feature standard; plus précisément, le non-parallélisme est un cas particulier d'exécution un programme "normal" c'est à dire conçu pour une exécution parallèle (du moins quand cela s'applique : ce n'est pas toujours le cas, très loin de là).

[invite0bbe92c0]

Tout dépend de ce qu'on appelle du parallèlisme. Je pensais plutôt au parallélisme hardware. On ne doit pas programmer des machines regroupant des grappes de processeurs comme une simple PC, même multicoeurs.

Je ne suis pas trop d'accord avec ça : en général on part d'une conception parallèle (bien sur,je ne parle pas des cas extrème de "massivement parallèle"; d'ailleurs c'est un domaine que je ne connais pas; la simple gestion des structure de synchronisation dans ces cas est tout à fait spécifique), et le cas "non parallèle" est une juste un cas particulier entrainant une application de règles d'affinités restrictives.

[jiherve]

Bonsoir,
Il n'existe pas ou peu de langage capable de gerer le // , je ne parle pas du // caché dans le processeur élémentaire(qui se gérait à la mano dans les premiers DSP) mais du // entre processeurs .
J'ai bien pratiqué OCCAM (nous n’étions que quelques centaines/milliers? sur la planète) il y a un quart de siècle et comme je l'ai déjà écrit(avec l'age on radote) ce langage et ces processeurs(Transputer) sont arrivés trop tôt et on été tués par les pisseurs de lignes de l’époque(et les financiers) qui ne comprenaient rien au //, là le massivement // était courant et à moindre cout,des machines ayant plusieurs centaines de processeurs furent commercialisées à la fin des 80's .

On ne doit pas programmer des machines regroupant des grappes de processeurs comme une simple PC, même multicoeurs.

oui et non , OCCAM permettait de développer sur un seul coeur (// par time sharing)et ensuite de diffuser sur plusieurs (//vrai) ce n’était qu'une question de configuration à la compilation.https://fr.wikipedia.org/wiki/Occam_%28langage%29; Mais évidement il fallait penser // des le début.
Le problème du massivement // c'est la certification au sens DO178, il n'y a pas ou peu d'outils capable d'analyser une machine massivement //.

JR

[pm42]

Il n'existe pas ou peu de langage capable de gerer le // , je ne parle pas du // caché dans le processeur élémentaire(qui se gérait à la mano dans les premiers DSP) mais du // entre processeurs .

Et pourtant, un certain nombre de calculs lourds ou d'architecture servant des millions d'utiisateurs simultanés sont aujourd'hui faites en parallélisme massif. Des choses comme les acteurs ou map/reduce entre autres permettent de traiter un certain nombre de problèmes.
La techno a pas mal évolué depuis OCCAM et tout le monde n'a pas besoin d'une certification DO178 pour du soft destiné à l'aviation.

[invite2800a7c8]

il n'y a pas ou peu d'outils capable d'analyser une machine massivement //.

Salut

parceque à un Moment donné il faut passer synchrone.

A mha, je pense qu'il vaut mieux avoir des processeurs multiples sur le même chip. ce qu'on fait d'ailleurs. Mais encore, s'il faut plus de 250 clock puls pour exécuter une instruction machine ( comme certaines instructions sur les XXX86 ) je ne vois pas trop ce que l'on va gagner.

Toujours amha, je pense que la solution RISC n'est pas stupide. Motorola avait sorti le POWER PC un processeur RISC, un seul clock pulse par instruction machine, on pouvait simuler les XXX86 et c'était toujours plus rapide que les XXX86 eux même.
Si mes Souvenirs sont juste, APPLE avait monté ça dans des Note book je crois?? ça leurs permettait d'exécuter des programmes codés XXX86.


Cordialement


Ludwig

[pm42]

parceque à un Moment donné il faut passer synchrone.

Rien à voir. Déjà, je ne suis pas sur que vous parliez de la même chose et certains modèles de parallélisme sont très proches en programmation des modèles non paralléle. Par ex, tout ce qui se fait en programmation fonctionnelle avec des données immuables...

A mha, je pense qu'il vaut mieux avoir des processeurs multiples sur le même chip. ce qu'on fait d'ailleurs.

Sauf que ce modèle ne monte pas en charge comme celui à multiples processeurs et qu'il a ses propres limites en terme de synchronisation...

Mais encore, s'il faut plus de 250 clock puls pour exécuter une instruction machine ( comme certaines instructions sur les XXX86 ) je ne vois pas trop ce que l'on va gagner.

C'est normal que vous ne voyiez pas : il n'y a absolument aucun rapport entre le nombre de "clocks" pour exécuter une instruction sur 1 processeur et le parallélisme massif.

Toujours amha, je pense que la solution RISC n'est pas stupide.

RISC ou CISC n'ont également aucun rapport avec le parallélisme. Le même code en parallélisme multi-processeur peut d'ailleurs très bien s'exécuter sur une configuration hétérogène composée de machines RISC et CISC sans aucune contrainte.

Motorola avait sorti le POWER PC un processeur RISC, un seul clock pulse par instruction machine, on pouvait simuler les XXX86 et c'était toujours plus rapide que les XXX86 eux même.
Si mes Souvenirs sont juste, APPLE avait monté ça dans des Note book je crois?? ça leurs permettait d'exécuter des programmes codés XXX86.

Oui et avant Sun avait fait le Sparc qui existe toujours. Et IBM continue les PowerPC. Bons processeurs mais le gain en performance mono-coeur par rapport aux x86 n'est pas si impressionnant que ça (x2 en gros).
Au demeurant, Intel a incorporé les bonnes idées du Risc dans sa ligne x86 mais à un niveau en dessous des instructions classiques. Il a ainsi fait d'important gains en performances sans perdre la compatibilité.
Alors qu'à un époque, le sous-investissement d'IBM dans les PowerPc faisait qu'ils étaient à la traine en perfs pures et en versions basse consommation : Apple notamment est donc passé sur x86.

Cela m'embête de le dire mais encore une fois, vous parlez de choses désormais anciennes, de débat qui n'ont plus lieu et sans lien avec les sujets abordés, en mélangeant un peu tout.
En info, il faut se mettre à jour régulièrement au lieu de s'accrocher aux années 80.

[Forthman]

Bonsoir,

Je me permet de déterrer ce post car j'ai vu que Ludwig se faisait traiter de "Forth Man"

Alors moi je dis stop !
ça fait plus de 25 ans que je me traîne ce pseudo, alors un peu de respect !

[invite2800a7c8]

Bonsoir,

Je me permet de déterrer ce post car j'ai vu que Ludwig se faisait traiter de "Forth Man"

Alors moi je dis stop !
ça fait plus de 25 ans que je me traîne ce pseudo, alors un peu de respect !

Salut,
J'y peu rien si certains utilisent le dénigrement de la personne en lieu et place d'une argumentation sans parti pris.

Cordialement

Ludwig

[Jack]

Bon, je pense qu'il n'y a plus rien à ajouter. Je ferme.