Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3007 connectés 

  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : Coeurs virtuels et parallélisme pour SoftMachines

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Précédente
Auteur Sujet :

[HFR] Actu : Coeurs virtuels et parallélisme pour SoftMachines

n°9307827
C_Wiz
Profil : Equipe HardWare.fr
Posté le 24-10-2014 à 12:10:02  profilanswer
0Votes positifs
 

Nos confrères d'EETimes nous font part de « l'émergence » d'une startup. Baptisée SoftMachines, cette société a été fondée en 2008 par deux anciens employés ...
Lire la suite ...

mood
Publicité
Posté le 24-10-2014 à 12:10:02  profilanswer
 

n°9307848
__ideal__
owned
Posté le 24-10-2014 à 12:34:01  profilanswer
1Votes positifs
 

^^ miam
 
Y a que chez vous qu'on peut se permettre de se réveiller un matin, lire un truc aussi poussé mais pourtant assez bien vulgariser pour se permettre de se dire "ok j'ai pas forcément tout compris au milieu mais au début et à la fin ça m'a fait rêver et j'ai compris pourquoi je me suis réveiller"
 
Bon sinon les programmes de traitements lourds en données ( rendering 3D, calcul scientifique ) savent parfaitement faire du parallélisme suffit de voir les supercalculateurs ou les render farms.
 
Puis pour le personnal computer de la famille ou le smartphone de tout un chacun qui auraient besoin de parallélisme pour alléger la charge, à part dans les jeux je vois pas trop...  
Faudra surement attendre que les programmeurs nous pondent une méthode pour créer un tread de rendu hautement parallélisable car je vois mal une solution magique qui s'appliquerait partout dans tous types de programmes avec un taux de performances élevées selon le nombre de coeurs/core...
 
Peut-être qu'en passant de la rastérisation basique d'aujourd'hui à du raytracing, cette méthode " magique " ajouterait encore à la facilité d'inclure du parallélisme dans la création d'univers 3D temps réel.
 
Bref merci en tout cas ça m'a fait rêver un peu. Corrigez moi si j'ai dis des conneries y a pas de soucis ^^ ça doit être le cas assurément.


Message édité par __ideal__ le 24-10-2014 à 12:38:23
n°9307903
iapx
euuuhhhh.....
Posté le 24-10-2014 à 13:18:16  profilanswer
0Votes positifs
 

Extraire du parallelisme de SPEC, ça tout le monde sait le faire... je pense que c'est du gros flan!

n°9307913
tolunoide
Posté le 24-10-2014 à 13:24:44  profilanswer
1Votes positifs
 

Euh, et ça marche en cluster ou c'est limité aux resources d'une seule machine physique?  
Est-ce que ça peut prendre en compte les "core GPU"? Là ce serait bingo pour AMD et ses APU!

n°9307924
leforgeron
Posté le 24-10-2014 à 13:33:07  profilanswer
0Votes positifs
 

Si leur truc c'est du soft, ça s'appelle un scheduler et normalement c'est dans le kernel. J'ai l'impression qu'alors leur marché, c'est les bidules avec un OS minimaliste (genre: y a des tâches, des mutex et c'est tout).
 
 
Si c'est du hard... j'attends de voir comment ils vont faire.

n°9307941
rootsayen
Jungle Cat
Posté le 24-10-2014 à 13:46:08  profilanswer
0Votes positifs
 

iapx a écrit :

Extraire du parallelisme de SPEC, ça tout le monde sait le faire... je pense que c'est du gros flan!


 
 
Vu les investisseurs ça doit être un peu plus que du flanc :o
 
Mais peut être juste une entreprise à brevets....


---------------
"Being solitary is being alone well; being alone luxuriously immersed in doings of your own choice, aware of the fullness of your own presence rather than the absence of others."
n°9307964
bugmstr
Posté le 24-10-2014 à 14:12:12  profilanswer
0Votes positifs
 

Euh ... Non la phrase d'origine est la bonne. Le compilateur a évidemment connaissance de l'intégralité du code.

n°9307986
TNZ
Ryzen 9 5950X powered ...
Posté le 24-10-2014 à 14:37:45  profilanswer
3Votes positifs
 

"J'ai tout bien tout lu freud" comme disait Coluche.
 
Cette startup n'est qu'une énième association de penseurs marketing avec option claquettes.
 
La question du parallélisme "bien fait" (ie avec le moins possible de ressources partagées et le moins possible de synchros) est au cœur de mes analyses depuis que je suis tout petit. L'utilisation du parallélisme se définit lors de l'analyse fonctionnelle (si on a de la chance) ou, plus généralement, lors de l'analyse technique du cycle en V. Donc, le "bon" parallélisme se trouve dans les neurones des concepteurs et pas dans des accessoires/plans sur la comète de prestidigitateurs marketing en mal de financement.  
 
Le seul point à valeur ajoutée potentiel se trouve dans la question de tolunoide savoir si leur concept est cluster-wide. J'ai bien mon idée sur le sujet. Je n'y crois pas trop dans la mesure où il faudrait que la mémoire des serveurs soit cluster-wide également. J'ai posé la question dans le cours Grid-Asm-RAC que j'ai suivi dernièrement et malheureusement, les OS cluster d'aujourd'hui ne savent pas partager la ressource mémoire sur un cluster. Je dis bien aujourd'hui, ce mécanisme existe depuis longtemps chez le concepteur des clusters : Digital. A ce jour, ce sont les seuls à proposer cette technologie. Malheureusement, leurs processeurs sont des Vax, des Alpha et depuis quelques années les Itanium2 (et encore je ne sais pas si les serveurs itanium sont 100% iso fonctionnel avec les plateformes Vax ou Alpha).
 
C'est bien joli tout ça, mais ça ne résout pas le problème des applications bien séquentielles qui ne peuvent pas tirer parti des architectures serveurs massivement multi-cœur. Dans cette catégorie, il suffit de regarder l'âge de ces applications. Une grosse majorité de celles-ci sont vieilles voire très vieilles. Du coup se pose la question, alourdissement du système pour des résultats pas forcément transcendantaux ou bien ré-analyse/ré-écriture de l'application avec une logique parallélisée ?  
 
Le conservatisme morbide est la plaie des datacenters (règles rigides, détournement fonctionnel de moniteurs de transfert, passage massif à la virtualisation pour contenir la mauvaise gestion des ressources système des applications, etc ...). Hors c'est ce conservatisme qui risque de donner une légitimité au "bricolage" présenté par cette "startup". Et ça, ça fait chier.


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
n°9308043
barbare128
pas de koi se rouler par terre
Posté le 24-10-2014 à 15:46:22  profilanswer
0Votes positifs
 

Cette startup n'est qu'une énième association de penseurs marketing avec option claquettes.>
 
Ouer, à 250 personnes, on est plus dans la start up. S'ils font de la pub pour leur deuxième tour de financement, c'est qu'on est pas loin du produit final.
 
Si ça permet d'exécuter des instructions à la volée sans recompiler, eh ben c'est une p*tin de bonne idée.
 
Genre faire travailler un core sur un registre et laisser passer que les instructions qui s'occupe de ce registre, et passer sur un second core les instructions qui le concerne. Bon en gros ce serrait ça ...
 
Mais c'est vraiment un sacré travail.
 
Chapeau.

Message cité 1 fois
Message édité par barbare128 le 24-10-2014 à 15:47:17
n°9308063
sasanpabon
Posté le 24-10-2014 à 16:01:51  profilanswer
0Votes positifs
 

Le problème c'est qu'en manque de plus d'information, il est difficile de se faire une idée sur l'efficacité globale du machin.
 
Le problème n'est pas tant de trouver les parties de code à paralléliser que savoir si c'est intéressant de paralléliser ces parties par rapport à l'overhead que ça engendre. (paralléliser une boucle de 10 itérations peut s'avérer mauvais, alors que paralléliser la même boucle avec 100 000 itérations peut faire gagner énormément de temps).
 
Le choix d'une machine virtuelle donne la possibilité d'utiliser un compilateur JIT qui permet d'analyser le code et d'améliorer son exécution au fur et à mesure. Ça permettrait d'adapter dynamiquement le degré de parallélisation en fonction de l'overhead engendré (sachant que le compilateur est partie prenante de cet overhead).  

mood
Publicité
Posté le 24-10-2014 à 16:01:51  profilanswer
 

n°9308065
TNZ
Ryzen 9 5950X powered ...
Posté le 24-10-2014 à 16:02:19  profilanswer
0Votes positifs
 

Citation :

Si ça permet d'exécuter des instructions à la volée sans recompiler, eh ben c'est une p*tin de bonne idée.


Euh, c'est pas ce que font les OS actuels avec les fichiers binaires (exécuter des instructions sans recompiler) ?

 

Et pis, c'est pas parce qu'il y a 250 gusses dans l'affaire que ce n'est plus du marketing claquette. D'ailleurs, dire qu'il y a autant de monde dans l'affaire est un élément pour rassurer les personnes qui n'y comprennent rien (souvent appelés poliment investisseurs).

 

Ce que tu décris avec les registres me laisse dubitatif (en un mot) fort de mes expériences d'assembleur et du fonctionnement des processeurs.
Je suis bien sceptique sur les résultats techniques qu'ils obtiendront ... en dehors des logiciels de benchmark.


Message édité par TNZ le 24-10-2014 à 16:08:20

---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
n°9308093
Seb lahall​eaupc
Preum's de la base oc :p
Posté le 24-10-2014 à 16:26:28  profilanswer
0Votes positifs
 

Si leur technologie fonctionne et qu'il arrive a la coupler avec les proc AMD sa pourrai permettre a ce dernier de revenir a la hauteur d'Intel.
@TNZ je doute que Samsung, GlobalFoundries et AMD fassent partis des "personnes qui n'y comprennent rien (souvent appelés poliment investisseurs)"

n°9308103
TNZ
Ryzen 9 5950X powered ...
Posté le 24-10-2014 à 16:40:10  profilanswer
0Votes positifs
 

Citation :

je doute que Samsung, GlobalFoundries et AMD fassent partis des "personnes qui n'y comprennent rien (souvent appelés poliment investisseurs)"


Dans le monde des startups, les investisseurs sont appelés Business Angels.
 
Leur intérêt est de mettre un petit peu dans BEAUCOUP de startups en espérant qu'il y en ai UNE qui fasse du pognon et de rentabiliser l'investissement sur l'ENSEMBLE des startups parrainées.
 
C'est le mécanisme de la loterie à l'état brut. Au lieu de cocher des cases sur une grille, tu fais des interviews des team leader de ces startups histoire de voir s'ils leur idée tient la route, s'ils ont un plan marketing à court terme et si leur tête te revient. Le système des startups est basé sur l'exploitation du jeunisme (Génération Y).


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
n°9308108
Lightness1​024
Posté le 24-10-2014 à 16:50:53  profilanswer
1Votes positifs
 

Ca ressemble fort a une implementation de ce que le Labri (laboratoire Bordeaux 1) a developpe dans son framework Marcel/PM2. (These de Samuel Thibault). les "bulles" ont ete renommes "virtual core" mais c'est pareil.

n°9308131
lapin
Posté le 24-10-2014 à 17:19:45  profilanswer
0Votes positifs
 

leforgeron a écrit :

Si leur truc c'est du soft, ça s'appelle un scheduler et normalement c'est dans le kernel. J'ai l'impression qu'alors leur marché, c'est les bidules avec un OS minimaliste (genre: y a des tâches, des mutex et c'est tout).
 
 
Si c'est du hard... j'attends de voir comment ils vont faire.


 
je vois plus un truc à la transmeta/crusoe et on sais se qu'il est advenu...

n°9308177
menfou
Posté le 24-10-2014 à 18:16:16  profilanswer
0Votes positifs
 

Ça existe depuis longtemps en effet, ca en fera un de plus qui partira à la poubelle dans quelques mois.
Ça permet d'optimiser les traitements qui sont mal codés, mais il n'y aura pas de gain avec du code bien optimisé.
 
Dans beaucoup de moteur de jeu 3D(Unity, Unreal, XNA), tout se passe dans un seul Thread pour être sure à 100% des synchronisations, avec ce concept ça permet de quasi doubler les performances, mais il est aussi possible de le faire en créant un Thread non secure qui fait uniquement de la lecture approximative.
 
Je travail sur un jeu de stratégie temps réel pour Mobile, j'étais limité à 500 unités intelligentes en mouvements sur un iPad Air.
Avec leur fonctionnalité le pourrait monter à 800-1000 unités.
Avec mon systeme de Thread approximatif, je peux monter à 5000 unités, et il n'y aura aucun gain avec leur procéder.
http://www.youtube.com/watch?v=QxIAYMwbOaQ
 


Message édité par menfou le 24-10-2014 à 18:17:18
n°9308194
bjone
Insert booze to continue
Posté le 24-10-2014 à 18:26:30  profilanswer
0Votes positifs
 

"Le manque de détails nous laisse pour l'instant circonspects sur la réalité de la solution utilisée."
Leur graphe il fait très nains collecteurs de slips.
 
http://reho.st/self/e6d59a54964e1a852a1b279384b4ef4c683a8c9f.jpg
 
1) Convert
2) ??????
3) Profit

n°9308200
blazkowicz
Posté le 24-10-2014 à 18:33:33  profilanswer
0Votes positifs
 

TNZ a écrit :


Le conservatisme morbide est la plaie des datacenters (règles rigides, détournement fonctionnel de moniteurs de transfert, passage massif à la virtualisation pour contenir la mauvaise gestion des ressources système des applications, etc ...). Hors c'est ce conservatisme qui risque de donner une légitimité au "bricolage" présenté par cette "startup". Et ça, ça fait chier.


 
Très juste, le conservatisme et la virtualisation. La virtualisation, cela se faisait du temps des mainframes IBM :D, ça existait avant que je sois né. Le CPU loué à la minute et utilisé à distance, encore plus vieux. Ah bé tiens : le jeu d'instruction virtuel, avec les AS/400! http://en.wikipedia.org/wiki/IBM_S [...] uction_set  (ce sont les binaires qui ont un jeu d'instruction virtuel, immuable, et le processeur a un jeu d'instruction réel, donc c'est plutôt l'inverse et puis c'est compilé en jeu d'instruction réel de toute façon)
 
Le prochain concept sera peut-être de copier la gestion des ressources des mainframes.
Je n'y connais rien, c'est trop compliqué et j'ai pas le triphasé et la clim, sans parler de la location du camion-benne pour ramener le matos :o


Message édité par blazkowicz le 24-10-2014 à 18:37:25
n°9308351
Maxwell166​4
Posté le 24-10-2014 à 21:16:26  profilanswer
0Votes positifs
 

C'est des threadlets!!! Comme les wavelets!!! Ca fonctionne avec la Fast Threadlets Transform surement!

n°9308414
ockiller
Posté le 24-10-2014 à 22:11:54  profilanswer
0Votes positifs
 

C'est assez nébuleux pour moi... Le vrai moteur d'un CPU c'est ses unités d'exécution, pour schématiser y a que ça qui fait le travail utile. Autour de ça il y a déjà une partie très complexe qui essaye de les alimenter au maximum en découpant les files d'instructions en chaines indépendantes. Sur un seul coeur avec un seul thread deux chaines d'instructions peuvent très bien s'exécuter en parallèle sur des unités d'exécution différentes (Out of Order...).
 
J'ai pas bien compris en quoi c'est différent/mieux ce qu'ils cherchent à faire...

n°9308643
Asthon
Posté le 25-10-2014 à 08:01:12  profilanswer
0Votes positifs
 

ockiller a écrit :

C'est assez nébuleux pour moi... Le vrai moteur d'un CPU c'est ses unités d'exécution, pour schématiser y a que ça qui fait le travail utile. Autour de ça il y a déjà une partie très complexe qui essaye de les alimenter au maximum en découpant les files d'instructions en chaines indépendantes. Sur un seul coeur avec un seul thread deux chaines d'instructions peuvent très bien s'exécuter en parallèle sur des unités d'exécution différentes (Out of Order...).
 
J'ai pas bien compris en quoi c'est différent/mieux ce qu'ils cherchent à faire...


 
Sans m'avancer dans l'architecture je penserais que les optimisations dont tu parles permettent de maximiser l'usage des unités d'exécutions d'un seul core...
 
En effet il me semble qu'un core "seul" contient déjà un peu de parallélisme en utilisant plusieurs unités ALU ou FPU pour effectuer une somme d'opérations sur un même nombre de cycles.
 
C'est à un niveau micro-ops, si je dis pas de conneries, donc il est possible que ça permette d'améliorer simplement des "grosses" instructions "découpées" dont on connait parfaitement le comportements (jeu d'instruction qui correspond au "langage" du CPU...)
 
Au final les front-ends actuels c'est une optimisation du CISC vers RISC, alors que la technologie présentée ici semble vouloir se mettre en "amont" et ré-ordonner les macro-instructions ce qui impliquerait d'avoir une bonne connaissance du comportement attendu non plus du jeu d'instruction mais du LOGICIEL en lui même... ce qui est une tout autre paire de manche vu la diversité ! (et ça expliquerait la nécessité d'un profiler temps réel similaires aux compilos JIT utilisées en Code managée)


Message édité par Asthon le 25-10-2014 à 08:03:22
n°9308691
Gigathlon
Quad-neurones natif
Posté le 25-10-2014 à 09:50:59  profilanswer
1Votes positifs
 

Je pige pas bien leur position... Intel a déjà commencé à aller vers un modèle similaire et TSX en est la première pierre. De mémoire, AMD avait annoncé quelque chose de similaire aussi.
 
Dans tous les cas, c'est bien une voie à explorer pour exploiter les APU, en revoyant intégralement les cores "CPU" pour les alléger de tout ce qui est redondant et sous-exploité (la FPU de Bulldozer, ça dit rien à personne?)
 
Bref...
 
On reprend tout le frontend, on vire les unités complexes type SSE/AVX/MMX, on remplace tout ça par un bloc "massivement parallèle" à la GCN (dont la fréquence n'est plus si éloignée de celle des CPU), tant qu'à faire, on réfléchit à un design asynchrone, et au final, on a probablement le CPU de la prochaine décennie...


Message édité par Gigathlon le 25-10-2014 à 10:13:34
n°9308733
lapin
Posté le 25-10-2014 à 11:07:12  profilanswer
1Votes positifs
 

TSX est bugger au dernière nouvelle désactivé via mise à jour BIOS/UEFI.

n°9308736
ockiller
Posté le 25-10-2014 à 11:09:47  profilanswer
0Votes positifs
 

Intel avait proposé une solution plus radicale avec ses Itanium, architecture VLIW, on met le paquet côté puissance de calcul avec une blinde d'unités vectorielles, et on laisse le compilateur gérer tout l'ordonnancement :D.

n°9308755
lapin
Posté le 25-10-2014 à 11:28:55  profilanswer
0Votes positifs
 

je croyais que s'était l'architecture EPIC en VLIW, ou il fallait tous dire au compilateur car y avait pas de prédiction de branchement.

n°9308765
dreambiker​82
Posté le 25-10-2014 à 11:35:45  profilanswer
0Votes positifs
 

Citation :

Je travail sur un jeu de stratégie temps réel pour Mobile, j'étais limité à 500 unités intelligentes en mouvements sur un iPad Air.
Avec leur fonctionnalité le pourrait monter à 800-1000 unités.
Avec mon systeme de Thread approximatif, je peux monter à 5000 unités, et il n'y aura aucun gain avec leur procéder.


Ca c'est fort, personne n'a de détails sur leur architecture, sur leur technologie ou sur leurs perfs estimées mais toi tu es capable de tirer des projections précises de performances. Je dis bravo ! ;)


Message édité par dreambiker82 le 25-10-2014 à 11:36:19
n°9308794
cocto81
Posté le 25-10-2014 à 12:10:26  profilanswer
0Votes positifs
 

AIX le fait déjà. Non ?
Pas étonnant qu'IBM ne soit pas sur le coup.

n°9308848
TNZ
Ryzen 9 5950X powered ...
Posté le 25-10-2014 à 13:18:14  profilanswer
0Votes positifs
 

A vrai dire, on sait pas trop. Les technos IBM en général sont peu documentées côté utilisateur. Ils ont la culture du secret.
A titre d'exemple, lors des interventions des techos IBM en salle machine, les gars refusent toute présence client quand ils manipulent les serveurs dans les baies. Est ce que c'est systématique ? Allez savoir !


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
n°9308990
Keser
Posté le 25-10-2014 à 15:44:25  profilanswer
0Votes positifs
 

Cette techno pourrait s'avérer utile pour AMD et certains fabriquant de puce ARM qui ont plus de facilité à multiplier le nombre de core qu'a augmenter les performances pour chaque core.
Car augmenter les perf / core comme la fait intel ces dernières années nécessite un budget énorme de R&D.
Si ces constructeurs peuvent utiliser une techno qui leur évite de dépenser des fortunes pour rester performant sur les applications monothreadé qui risque de disparaître dans les années à venir, c'est tout bénef pour eux.
 
Au vue de l'article et des commentaires j'ai l'impression que cette techno est l'opposé de l'hyperthreading, càd à la place d'émuler plusieurs threads pour un seul core, on va émuler un thread pour plusieurs core.
 
Donc au lieu d'avoir deux flux d'instruction qu'on va dispatcher sur deux threads pour remplir au mieux un pipeline et augmenter son débit, on va accéléré le traitement d'une instruction en affectant une étape de son traitement à un autre pipeline.
 
Je ne sais pas si c'est techniquement réalisable notamment à cause des temps de latence entre les core qui doit être bien plus élevé qu'entre les "sections" d'un pipeline.
Mais si cette technique permet à AMD de gagner ne serait ce que 30% sur l'IPC d'un de ses core en sacrifiant un autre core, ca pourrait quand même valoir le coût quand on voit le retard qu'ils ont à ce niveau. (et ca ne serait qu'une solution temporaire en attendant que les applications fortement multithreadé soit un standard)

Message cité 1 fois
Message édité par Keser le 25-10-2014 à 15:47:41
n°9309086
fkanker
Posté le 25-10-2014 à 18:12:40  profilanswer
0Votes positifs
 

Keser a écrit :

Au vue de l'article et des commentaires j'ai l'impression que cette techno est l'opposé de l'hyperthreading, càd à la place d'émuler plusieurs threads pour un seul core, on va émuler un thread pour plusieurs core.


Ca rappelle un peu le Reverse HT oui, sur lequel bossaient Intel et AMD. D'après DocTB de CanardPC (si mes souvenirs sont bons) AMD avait la techno câblée dans Bulldozer, mais désactivée. Vu l'architecture ça avait du sens.
 
On manque tellement d'infos pour conclure sur leur techno. Ils ont un prototype fonctionnel, qui déchire tout ce qui existe (forcément...), sur des benchmarks multithreadés ou monothreadés dont on peut extraire facilement de l'ILP. Et si ça marche réellement, leur techno est-elle applicable à bien plus haute fréquence, avec un pipeline bien plus long (dans le monde réel donc). Et comment croire qu'ils peuvent extraire magiquement de l'ILP d'un thread sur au moins 2 cores alors que tout le monde piétine, et le tout sans rien expliquer ou presque.
J'ai envie de leur laisser le bénéfice du doute, après tout quelques individus peuvent avoir une illumination. Ce sont soit des génies, soit des escrocs, pas de milieu.


Message édité par fkanker le 25-10-2014 à 18:23:00
n°9309096
rootsayen
Jungle Cat
Posté le 25-10-2014 à 18:24:39  profilanswer
0Votes positifs
 

Vu le CV des fondateurs, je dirais plutôt l'aboutissement de quelques choses plutôt qu'une illumination, si jamais leur truc est fonctionnel :D


---------------
"Being solitary is being alone well; being alone luxuriously immersed in doings of your own choice, aware of the fullness of your own presence rather than the absence of others."
n°9309334
hyksos_sow​o
Posté le 25-10-2014 à 23:31:50  profilanswer
0Votes positifs
 

Ce n'est pas bien difficile de distribuer un programme single thread sur plusieurs core... ce qui est difficile c'est de le faire de façon 100% fiable,  sans planter ou corrompre les données.... et la marge d'erreur est de 0... donc même si leur bidule est robuste a 99.999% du temps mais introduit un erreur dans 0.001% des cas, ça reste inutilisable et juste bon pour la poubelle.

n°9309353
Møgluglu
Posté le 25-10-2014 à 23:52:57  profilanswer
0Votes positifs
 

On a des infos un peu plus concrètes ici :
http://www.softmachines.com/wp-con [...] -11303.pdf
 
Comme toujours ils ont réinventé leur propre vocabulaire pour mieux se vendre. Mais ce qu'ils vendent est clairement une architecture Multicluster, comme proposé il y a 15 ans dans ce papier de recherche : http://www.eecg.toronto.edu/~pc/re [...] icro97.pdf
(Le fameux "Reverse HT" d'AMD, c'est cette idée là aussi.)
 
L'idée n'est donc pas révolutionnaire. Ce qui devrait l'être, c'est leur façon de former leurs "threadlets", c'est-à-dire comment ils choisissent quelles instructions vont sur un cluster ou sur un autre. Jusqu'ici, personne n'a réussi à faire ça bien, et on se retrouve toujours avec trop de communication entre les clusters pour que ce soit rentable. Ça fait que ce genre d'archi n'a jamais décolé...


Message édité par Møgluglu le 25-10-2014 à 23:54:05
n°9309372
TNZ
Ryzen 9 5950X powered ...
Posté le 26-10-2014 à 00:23:03  profilanswer
0Votes positifs
 

Attention aux lecteurs du thread : Ne pas confondre les clusters de core processeur avec les clusters de serveurs.
 
Même si cette techno apporte quelque chose dans le contexte des programmes séquentiels, cela reste la mauvaise approche pour faire du pseudo-neuf avec du vieux. La méthode d'analyse pour faire du parallélisme n'a rien à voir avec celle qui est à l'origine des vieux programmes séquentiels. De la part du programmeur, il faut avoir une autre façon de voir les choses, une autre culture qui n'est malheureusement plus enseignée aujourd'hui.


---------------
"Mieux vaut demander à un qui sait plutôt qu'à deux qui cherchent." ... "Le plus dur, c'est de faire simple.", TNZ
n°9309433
raptor68
Pouet !
Posté le 26-10-2014 à 02:33:11  profilanswer
3Votes positifs
 

et sinon on peux mieux payer les codeurs ou ,tout simplement, leurs demander de faire moins vite pour faire mieux (3 mois de plus pour un programme plus efficace à long termes, certes ça rapporte moins en mises à jour et en correctifs, mais ça rapporte plus de clients à la recherche de logiciels de qualité) ...

 

J'ai vu de mes yeux comment on forme les jeunes codeurs, soit à grand renfort de c, de java et parsemé d'assembleur (IUT, Epitech) soit avec des langages sur managé et sans notions de code low level (les formations afpa et consorts dont les programmes (datés de 2003) n'intègrent même pas la notion de thread alors le parallélisme et l'optimisation ...)

 

tout ça pour dire qu'avant de se poser la question de l'optimisation de l’exécution d'un soft, il vaudrait peut être mieux se préoccuper de mieux les coder


Message édité par raptor68 le 26-10-2014 à 02:35:58
n°9309637
barbare128
pas de koi se rouler par terre
Posté le 26-10-2014 à 10:25:18  profilanswer
1Votes positifs
 

Raptor68> Il faut juste voir la propension entre les bons codeurs et les mauvais codeurs ( attention pas d'amalgame avec un très bon sketch ).
 
Rien que le fait de le savoir, on sait tout de suite que c'est pas avant 30 ans qu'on aura franchit le cap du multithread ...

n°9309661
Gigathlon
Quad-neurones natif
Posté le 26-10-2014 à 10:42:56  profilanswer
0Votes positifs
 

dreambiker82 a écrit :


Ca c'est fort, personne n'a de détails sur leur architecture, sur leur technologie ou sur leurs perfs estimées mais toi tu es capable de tirer des projections précises de performances. Je dis bravo ! ;)


On peut estimer. Entre pas de synchro du tout (je vais piocher les données sans me préoccuper de leur mise à jour) et présence d'une synchro (j'attend le signal), peu importe le hard derrière, il y aura forcément un écart non-négligeable.
 
Après, on retrouve le même souci qu'avec la synchro verticale par contre, avec des "téléportations" dans le cas le plus performant (sur le papier), car on aura occasionnellement lu 3x la donnée 1 puis la donnée 4, en zappant les données 2 et 3.
 
Tout ça se résume en une séparation entre IHM, traitements et I/O : c'est toujours plus réactif quand l'IHM se contrefout du reste, mais pas forcément bien propre.
 

raptor68 a écrit :

J'ai vu de mes yeux comment on forme les jeunes codeurs, soit à grand renfort de c, de java et parsemé d'assembleur (IUT, Epitech) soit avec des langages sur managé et sans notions de code low level (les formations afpa et consorts dont les programmes (datés de 2003) n'intègrent même pas la notion de thread alors le parallélisme et l'optimisation ...)


Il y a aussi de quoi programmer "parallèle" dans C# (depuis VS 2010 voire 2008), c'est juste particulièrement mal foutu...
 
Au-delà des devs et de leurs formations, les outils eux-mêmes sont à considérer comme une des causes. On ne peut échapper au séquentiel, par ailleurs.


Message édité par Gigathlon le 26-10-2014 à 10:54:34
n°9309822
raptor68
Pouet !
Posté le 26-10-2014 à 13:57:24  profilanswer
0Votes positifs
 

oui, je sais qu'il y'a une classe thread dans le .Net mais c'est pas vraiment du code toujours très efficace et tu n'a pas vraiment possibilité de faire du vrai parallélisme (sous entendu efficace, les thread marchent bien, mais je ne suis pas sur qu'un usage lourds et massif de ces thread soit réellement efficace sans compter l'impossibilité d'aller piocher des données dans le thread principal comme tu le veux) sans avoir à passer par un wrapper C


Message édité par raptor68 le 26-10-2014 à 13:58:36
n°9309861
hyksos_sow​o
Posté le 26-10-2014 à 14:46:44  profilanswer
0Votes positifs
 

De quoi tu parle?? Y'a aucun problème à faire du multi thread 'lourd' et efficace en C#. C'est même foutrement plus facile que en C/C++. On peut exécuter des bout de code à la volé par n'importe quel thread grâce au dispatcher. Pis le nouveau system de Task que Microsoft ont ajouté a .Net 4.0 simplifie encore plus.
 
Bien sur il faut savoir coder, il ne suffit pas de simplement faire une boucle for et mettre quelques mot clé de compilation pour que le compilateur te chi du code multi threadé..

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : Coeurs virtuels et parallélisme pour SoftMachines

 

Sujets relatifs
[HFR] Actu : Baisse de prix des APU AMD FM2+ et FM2[HFR] Focus : Enermax Twister Storm et Pressure en test
[HFR] Actu : Pilotes GeForce 344.48 WHQL[HFR] Actu : 1 Go de DDR4 en 20nm chez Samsung
[HFR] Actu : Broadwell-E en retard, RDV en 2016[HFR] Actu : Skylake-S LGA 1151 en image
Plus de sujets relatifs à : [HFR] Actu : Coeurs virtuels et parallélisme pour SoftMachines


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR