les compétences requises sont lourdes, surtout pour la dernière page !
Je n'ai pas l'impression que les compétences requises soient si lourdes que cela....
Une bonne formation "suffit" (voire un bon apprentissage sur le tas), un peu comme dans le monde du logiciel pur et dur.
Par contre, là où la diff' avec le monde logiciel intervient : c'est bien de s'amuser avec des FPGAs et autre joujous du genre, mais c'est matériel, et cela coûte de faire une carte pour tester, de tester, d'avoir le matériel necessaire aux mesures, .... Difficile de ne pas centraliser au moins cette partie....
Je n'ai pas l'impression que les compétences requises soient si lourdes que cela....
Pour un simple ALU, d'accord. Mais pour un alpha ou un G5, amuse toi ! va faire un pipeline prédisant et optimisant des instructions pas encore arrivées ...
Si tu fais un processeur from scratch, sans te soucier de l'historique d'une archi particuliere, tu n'as pas besoin de faire ce genre de chose, car le compilo te fera deja le meilleur arrangement pour ta machine. En meme temps, si tu ne fais que de l'open-source, c'est une fonctionnalite pas forcement utile et qui prend beaucoup de ressource pour un gain minimal compare a ce que peut faire un compilo.
Donc autant mettre les ressources dans des fonctionnalites plus utile : cache, simd, smt, ...
Plein de processeurs modernes utilisent l'out of order, pour la simple et bonne raison que ca permet d'augmenter l'IPC.
Ton compilo aura beau etre tres tres bon (du style bien meilleur que gcc sur certains points, ce qui est quand meme plutot dur a faire) un cache miss arrivera un jour ou l'autre, et quand il arrivera un si ta pas d'unite de reordenancement tu te chopera une grosse penalite (les temps d'access a la ram sont tres lents), qui pourra etre diminuée si t'en a une. Quand tu vois l'hyperthreading du pIV qui pousse l'idée a l'extreme en pouvant changer carrement de thread dans ce cas (et dans d'autres), ce qui permet (avec l'utilisation simultane de plus d'unite d'execution) d'augmenter les perf de dizaines de pourcents dans certains cas, tu te dis que c'est pas négligeable . Bref, ya tout plein d'alea dynamiques qui font qu'une unité de reordenancement dynamique est une bonne idée. Pis je ne vois pas en quoi c'est pas utile si tu fais de l'open source. C'est tout aussi utile que si tu fais du proprio.
Concernant la complexité d'un proc, elle est grande, et le niveau de competence requis en la matiere est au moins aussi elevé que pour developper une grosse appli, mais ce n'est pas du tout insurmontable.
En cas de cache miss, si ton processeur fait des acces memoires asynchrones, tu ne prends pas la penalite. Tu prends la penalite au moment ou tu tentes d'acceder au resultat de ton acces memoire (Dependance read after write). Tu vas avoir du mal a compense cette penalite, car si ton compilo a bien fait les choses, toutes les operations suivantes decoulent de cette lecture (Actuellement avec une representation sous forme d'automate du processeur et avec une bonne description de son fonctionnement, tu peux obtenir de bon resultat avec gcc).
Donc je ne vois pas ou l'out-of-order va pouvoir faire quelque chose, a part continuer a charger les unite de reservation avec des calculs qui ne pourront de toute facon pas s'executer. C'est d'ailleur pour ca qu'Intel a mis en place l'hyperthreading sur PIV, c'est pour compenser les bulles du pipeline qui deviennent de plus en plus importante avec l'augmentation de la frequence et que le simple out-of-order ne peut compenser.
Effectivement, il y a de l'alea dynamique, mais le compenser n'est necessaire que si le code que tu utilises ne prend pas ou peu en compte la structure du processeurs. Le cas qui se presente pour toutes les familles de processeurs ayant une compatibilite binaire, ou forcement l'out of order est utile.
Je penses que si on a les sources et que l'on peut decrire suffisemment precisement l'automate qui represente le processeur, le code produit n'utilisera pas ou peu les capacites out of order de la machine cible.
Pour un simple ALU, d'accord. Mais pour un alpha ou un G5, amuse toi ! va faire un pipeline prédisant et optimisant des instructions pas encore arrivées ...
Je suis tout à fait d'accord : mais est-ce que l'objectif de l'open hardware est d'atteindre, dans un premier temps, les perfs' d'un G5 ou autre Alpha?
Déjà avoir à dispo' l'équivalent d'un 80386 serait pas mal, du moins pour démarrer.... Ce serait un grand pas. On aurait le logiciel (noyau Linux ou autre), et le matériel!
On peut suivre l'évolution du noyau linux : au début pas grand chose dedans, puis aujourd'hui plétore. Avant de faire un système de fichiers avec journalisation, le premier enjeu était d'avoir un système de fichiers tout court.
Les compétences requises pour accéder à un système de fichiers du type EXT2/EXT3 étaient élevées, et comparables à ce que nécessite en matière de compétences autre chose que le pipeline qu'on apprend en cours.
Possible aussi que le fait que ce projet ne donne pas l'impression d'avancer des masses (du moins au niveau du retour qu'on peut en avoir par la page www) leur ai fait croire qu'il soit mort....
Quand on regarde la page web, les infos les plus récentes font référence à 2001 (d'ailleurs la MAJ au bas de la page mentionne 05-2001).
Possible que le projet avance derrière, mais à moins d'être impliqué dedans, difficile de se faire une idée.
# Re: open Hardware
Posté par vincent LECOQ (site web personnel) . Évalué à 1.
Cela dit un tel chip, ce serait pur bonheur !
[^] # Re: open Hardware
Posté par Sylvain Briole (site web personnel) . Évalué à 1.
Je n'ai pas l'impression que les compétences requises soient si lourdes que cela....
Une bonne formation "suffit" (voire un bon apprentissage sur le tas), un peu comme dans le monde du logiciel pur et dur.
Par contre, là où la diff' avec le monde logiciel intervient : c'est bien de s'amuser avec des FPGAs et autre joujous du genre, mais c'est matériel, et cela coûte de faire une carte pour tester, de tester, d'avoir le matériel necessaire aux mesures, .... Difficile de ne pas centraliser au moins cette partie....
[^] # Re: open Hardware
Posté par vincent LECOQ (site web personnel) . Évalué à 1.
Pour un simple ALU, d'accord. Mais pour un alpha ou un G5, amuse toi ! va faire un pipeline prédisant et optimisant des instructions pas encore arrivées ...
[^] # Re: open Hardware
Posté par cedric . Évalué à 1.
Donc autant mettre les ressources dans des fonctionnalites plus utile : cache, simd, smt, ...
[^] # Re: open Hardware
Posté par xilun . Évalué à 1.
Ton compilo aura beau etre tres tres bon (du style bien meilleur que gcc sur certains points, ce qui est quand meme plutot dur a faire) un cache miss arrivera un jour ou l'autre, et quand il arrivera un si ta pas d'unite de reordenancement tu te chopera une grosse penalite (les temps d'access a la ram sont tres lents), qui pourra etre diminuée si t'en a une. Quand tu vois l'hyperthreading du pIV qui pousse l'idée a l'extreme en pouvant changer carrement de thread dans ce cas (et dans d'autres), ce qui permet (avec l'utilisation simultane de plus d'unite d'execution) d'augmenter les perf de dizaines de pourcents dans certains cas, tu te dis que c'est pas négligeable . Bref, ya tout plein d'alea dynamiques qui font qu'une unité de reordenancement dynamique est une bonne idée. Pis je ne vois pas en quoi c'est pas utile si tu fais de l'open source. C'est tout aussi utile que si tu fais du proprio.
Concernant la complexité d'un proc, elle est grande, et le niveau de competence requis en la matiere est au moins aussi elevé que pour developper une grosse appli, mais ce n'est pas du tout insurmontable.
[^] # Re: open Hardware
Posté par cedric . Évalué à 1.
Donc je ne vois pas ou l'out-of-order va pouvoir faire quelque chose, a part continuer a charger les unite de reservation avec des calculs qui ne pourront de toute facon pas s'executer. C'est d'ailleur pour ca qu'Intel a mis en place l'hyperthreading sur PIV, c'est pour compenser les bulles du pipeline qui deviennent de plus en plus importante avec l'augmentation de la frequence et que le simple out-of-order ne peut compenser.
Effectivement, il y a de l'alea dynamique, mais le compenser n'est necessaire que si le code que tu utilises ne prend pas ou peu en compte la structure du processeurs. Le cas qui se presente pour toutes les familles de processeurs ayant une compatibilite binaire, ou forcement l'out of order est utile.
Je penses que si on a les sources et que l'on peut decrire suffisemment precisement l'automate qui represente le processeur, le code produit n'utilisera pas ou peu les capacites out of order de la machine cible.
[^] # Re: open Hardware
Posté par Sylvain Briole (site web personnel) . Évalué à 1.
Je suis tout à fait d'accord : mais est-ce que l'objectif de l'open hardware est d'atteindre, dans un premier temps, les perfs' d'un G5 ou autre Alpha?
Déjà avoir à dispo' l'équivalent d'un 80386 serait pas mal, du moins pour démarrer.... Ce serait un grand pas. On aurait le logiciel (noyau Linux ou autre), et le matériel!
On peut suivre l'évolution du noyau linux : au début pas grand chose dedans, puis aujourd'hui plétore. Avant de faire un système de fichiers avec journalisation, le premier enjeu était d'avoir un système de fichiers tout court.
Les compétences requises pour accéder à un système de fichiers du type EXT2/EXT3 étaient élevées, et comparables à ce que nécessite en matière de compétences autre chose que le pipeline qu'on apprend en cours.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: open Hardware
Posté par Sylvain Briole (site web personnel) . Évalué à 1.
Possible aussi que le fait que ce projet ne donne pas l'impression d'avancer des masses (du moins au niveau du retour qu'on peut en avoir par la page www) leur ai fait croire qu'il soit mort....
Quand on regarde la page web, les infos les plus récentes font référence à 2001 (d'ailleurs la MAJ au bas de la page mentionne 05-2001).
Possible que le projet avance derrière, mais à moins d'être impliqué dedans, difficile de se faire une idée.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.