ce qui est vraiment moche, c'est l'impossibilité de concaténer des messages ... même Outlook express sait faire ça... enfin, heureusement il y a pan, thunderbird comme lecteur de news reste du domaine du gadget occasionnel.
Tout dépend si tu as signé le NDA de Macromedia...
Macromedia ne donne les spécifications qu'à la condition de s'engager de ne pas développer de lecteur, mais les personnes ne signant pas le NDA sont libres d'analyser les différents générateurs libres existant et d'utiliser les infos ainsi récoltées pour recréer un lecteur.
Les nouveaux amendements changent le rôle du collège de médiateurs qui étaient normalement chargés de corriger les déviances des drm et préserver les droits à la copie privée en une instance de répression du piratage?
Les nouveaux amendements changent le rôle du collège de médiateurs qui étaient normalement chargés de corriger les déviances des drm et préserver les droits à la copie privée en une instance de répression du piratage?
Celà m'étonnerait, Intel est le roi de l'optimisation compilateur.
Par contre il faut noter qu'avec le P4, le code optimisé pour les autres processeurs tourne plus mal que sur P3, Pentium M ou Athlon XP/64 ...
En compilant les applications de manière optimale pour le P4, ce dernier reste plus lent que la concurrence (mais regagne à peu près en perfs que que l'hyperthreading peut récupérer)... En fait du code optimisé p4 ne gagne rien avec l'hyperthreading (car tout le cpu est utilisé), alors que le code optimisé PIII, PM, AMD, peut gagner avec l'hyperthreading vu que le processeur est moins bien alimenté en instructions.
Partagé le cache de niveau 2 est simplement un moyen d'aller plus vite que d'attendre la ram.
La communication intercache ne passe pas par la ram, donc c'est pas un argument.
Et cela évite aussi d'avoir besoin d'un cache write "though" qui à chaque écriture devrait mettre à jour la ram au cas ou l'autre cpu veuille y accéder.
Encore une fois, il y a déjà un protocole de communication intercache avec contrôle d'intégrité (même sur les intels), donc pas un argument non-plus.
Tu peux imaginer des tas de truc pour lisser l'execution
Si, si, je peux parfaitement m'imaginer, ça a été mon boulot pendant quelques années.
Par contre, ce qui m'échappe, c'est l'intéret d'une cache de second niveau partagée dans de telles conditions, et j'ai beau regarder, j'en vois pas. Une cache séparée évite bien des problèmes tout en évitant de devoir faire mumuse avec des techniques qui n'ont pas leur place dans le contexte d'une mémoire cache L2.
De plus, sur les amd64, il y a le protocole moesi qui permet une communication intercache directe entre les divers processeurs d'un même système, qu'ils soient en dual core, en multi proc ou en multi dual core.
et la concurrence à 4Ghz enterrerait le P4 à 5Ghz...
tu espères démontrer quoi?
La meilleure unité de mesure serait encore la consommation électrique: quel processeur fait le plus par watt, et encore une fois c'est pas le P4 qui gagnerait.
Le design du P4 est malheureusement trop éloigné des réalités physiques pour qu'on puisse dire qu'il est bon. Et puis, il me semble qu'intel promettait les 10Ghz lorsque le P4 est apparu... plutôt raté.
Au final, le coup du netburst ressemble plus à un coup de pocker manqué qu'à une architecture correctement ficelée.
La "puissance par cycle" n'a aucune importance, ce qui compte c'est les performances réelles.
les performances réelles, la conso électrique et la chaleur émise... et étonnemment, un manque d'efficacité par cycle semble tout de même mener à un manque d'efficacité electrique et à un manque d'efficacité thermique.
Chaque cycle a un coût.
Sans les problèmes de conso statique du 90nm, les P4 tourneraient à 5 Ghz.
Monter à 5ghz en P4, ça a autant de sens que de pousser un moteur de voiture à 15000 tours/minute en 3è vitesse. En plus, à 5ghz, l'électricité commence à avoir de sérieux problèmes de propagation (sur le temps d'un cycle, la lumière ne parcours que 6cm, l'électricité est beaucoup plus lente dans un processeur en surchauffe, les transistores ont eux-mêmes leurs latences, ce qui rend la propagation du signal dans le processeur beaucoup plus difficile dans une fenêtre de temps aussi réduite)
Pour l'hyperthreading sur le P4, le constat est simple: sur les applications optimisées P4, le gain est quasi nul, pour les applications otpimisées pour le PIII le gain peut monter effectivement dans les cas les mieux adaptés à 30%, mais c'est loin d'être une généralité, et au final ça ne rivalise pas avec la puissance par cycle d'un PIII, d'un Dothan ou d'un AMD64.
ben, je suis certain qu'un brouilleur, ça ferait fureur sur la cache L2 d'un processeur, l'étape suivante c'est de rajouter des sièges baquets et un frigo...
Sans rire, je sais pas ce que tu entend par "brouilleur", mais tout chipotage à ce niveau ne ferait que faire plonger les perfs du processeur... et ne dis pas que la carte à puce en a un, la carte à puce n'a ni la finalité ni la puissance d'un microprocesseur généraliste.
AMD lit dans le cache L2 de l'autre processeur depuis l'athlon MP. C'était plus rapide d'aller lire dans le cache que dans la rame.
ah, ça c'est sûr que lire dans la cache plutôt que dans la ram, c'est un gain (même si ça passe par le bus), mais notre ami boubou faisait le reproche suivant aux dual cores "Quand le cache sera partagé entre les cores, on en reparlera" ...
Hors, une vrai cache partagée (donc un bloc unique de mémoire cache accessible de manière uniforme par deux cores), ça n'existe pas dans le monde x86, c'est compliqué, et surtout ça pose des problèmes de sécurité (l'hyperthreading l'a démontré sans qu'on ait besoin d'aller jouer avec deux vrais cores).
Dans les amd64, les caches communiquent via le crossbar qui se situe entre les caches, les trois cannaux hypertransport et les deux cannaux de contrôleur ram.
En aucun cas ce ne sont des caches partagées, elles communiquent, mais ce sont bien deux blocs distincts qui ne peuvent être accédés par le processeur en face au même titre que par leur processeur.
C'est un truc d'AMD ou d'un constructeur en particulier ?
Je crois que c'est du pur amd, une solution indispensable pour garder une compatibilité parfaite pour les systèmes x86.
bref, l'extase de l'ingé, tu peux faire plein d'erreurs, tu passes plein d'heures à profiler.... .... Et l'humanité perd un temps fou.... mais nous qu'est-ce qu'on s'éclate !!!
Yesss... au fait, tu bosses sur quelle architecture?
Oui, c'est ce que j'ai dit, c'est un argument marketing, du multi-processeur plus facile à mettre en oeuvre.
Je dirais que c'est surtout un argument technique. L'intéret n'est pas juste de mettre un bel autocollant "dual core" sur son boîtier, mais de mettre un maximum de processeurs dans un minimum de place, et si possible en évitant un maximum les complications.
Tu confonds la gestion de la communication entre les processeurs et avec le chipset (contrôleur mémoire inclus), et l'intégration de cette gestion dans le processeur.
Je pense que c'est toi qui confond...
L'intégration du contrôleur de mémoire dans le processeur permet d'avoir autant de fois la bande passante proc<->mémoire que de socket occupé. Dans le cas de l'AMD64, l'hypertransport est utilisé pour communiquer avec le chipset et les autres processeurs, mais chaque processeur peut dialoguer directement avec sa propre ram sans passer par le bus, d'où un gain énorme d'efficacité dans les communications (on est à presque 95% de la bande passante théorique de 6,4Gb/sec alors qu'en passant par un contrôleur externe éventuellement partagé, on tombe sous les 70%)
Dans le cas d'une machines bi-Xeon ou bi-athlon xp, les deux processeur passent par le même northbridge pour atteindre la ram, ce qui rajoute des problèmes de collisions et de partage.
Il y a eu du cache partagé sur les machines SMP depuis très longtemps.
Dans quel film tu as vu ça?
Comment veux-tu avoir de la cache vraiment partagée et accédée sans intermédiaire entre deux processeurs physiquement distincts?
Sur du smp classique (xeon/athlon mp) avec deux processeurs physiquement séparés, les caches ne peuvent communiquer qu'en passant par le bus, ce qui correspond presque avec la méthode d'interconnexion utilisée pour l'amd64 x2 sauf que l'amd64 x2 a l'interconnexion directement en sortie du processeur au lieu de faire un détour par le bus.
Les futurs multi-core d'Intel et d'AMD prévoient d'intégrer du cache partagé.
C'est fort possible, il ne faut jamais dire jamais, mais le problème de sécurité du P4 HT a soulevé pas mal de questions au sujet de la cache partagée, et sans réponses valable à ce sujet, il serait risqué de la part de l'un ou de l'autre de lancer un processeur multi-core à cache partagée.
C'est vrai que question gestion, le Numa n'est pas des plus aisé (enfin bon, on te demande généralement pas non-plus de migrer les processus à la main)...
Dans le cas l'amd64, on travaille en mode hybride SUMO (sufficiently uniform memory organization), ce qui permet si l'on est avec un OS stupide (comme windows), de travailler comme si on était en bête SMP (avec tout de même un système d'interconnexion très performant comparativement à ce qu'on a chez Intel), et si l'on est avec un os plus évolué, de travailler avec un kernel optimisé capable de gérer les affinités entre les processus et les processeurs.
Avantage du SUMO ?
- La migration de processus peut se faire de manière transparente (alors que dans une config NUMA standard, la migration nécessite plus de préparation pour envoyer un processus sur un autre processeur)
- les échanges entre processus situés sur des processus différents se font aussi de manière transparente, le partage de mémoire peut se faire exactement comme pour du smp.
Donc oui, le Numa, c'est pas évident, mais dans le cas de l'amd64, c'est tout de même beaucoup plus intéressant.
Sinon, je vois pas ce que le pauvre hyperthreading vient faire là dedans...
Je viens de prendre le temps de lire le rapport de Colin Percival, en fait, grâce aux attaques de timing, il est carrément possible de deviner des données de la cache avec un taux d'erreur de 25% à 400k/s sur un P4 2,8ghz... Encore un bon argument pour ne pas avoir de partage de cache dans les dual-cores.
D'après ce que j'ai lu, il semble que le problème soit surtout que les réactions d'un pseudo proc permettent de mesurer dans certains cas le comportement de l'autre pseudo-proc et du même coup de déterminer la vitesse d'exécution d'opérations crypto, ce qui permet de faire des attaques basées sur les mesures des temps d'exécution pour faire un profile du cryptage.
Au boulot on a des serveurs de crypto à ultra basse latence, et sur ces machines, l'hyperthreading est impérativement désactivé sinon le temps de réaction du serveur devient trop instable, ce qui mène à des timeouts dans les transactions.
Le dual core est un argument marketing (très joli, il est vrai) mais en aucun cas une véritable innovation technique.
Euh, là c'est idiot ce que tu dis. Le dual core a un réel avantage car il permet de mettre deux vrais processeurs dans un, ce qui permet d'avoir un coût infrastructure par processeur bien plus bas pour les workstations et pour les serveurs. Aucune comparaison possible avec des astuces de dernier espoir comme l'hyperthreading.
C'est particulièrement intéressant dans le cas où tu bosses avec des serveurs compactes de type blade où il devient très simple d'avoir un quadri-proc sans augmenter la taille des machines.
Je ne sais pas si tu as déjà vu beaucoup de systèmes 8 processeurs mono-core, mais crois moi sur parole que du dual core sur une carte mère 4 sockets est une solution bien plus élégante.
Pour l'affaire du contrôleur de ram intégré, c'est vrai qu'il y a débat car celà réduit les possibilités de changer le type de ram.
Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.
Quand le cache sera partagé entre les cores, on en reparlera
Une cache unifiée entre les deux cores nécessiterait soit de mettre un contrôle transactionnel multiclient sur l'allocation, la désallocation et l'accès à la cache, soit de limiter les accès à un seul processeur à la fois. Dans le premier cas, ça coûterait plus cher, dans le second, ça réduirait sérieusement les performances.
La solution de la cache séparée assortie d'une interconnexion directement à la sortie de la cache est en revanche une solution très efficace, et c'est ce qui est utilisé chez amd.
Pour le reste, je te recommande vivement de lire des tests et benchmarks plutôt que de donner dans les croyances populaires.
La grosse bouse en question propose un hyperthreadnig fort agréable en pratique.
Ben si je disais que l'hyperthreading dans pas mal de cas c'est une grosse bouse aussi :P
Plus sérieusement, le P4 est un processeur qu'Intel a jeté sur le marché beaucoup trop tôt, sans laisser le temps aux ingés de le finaliser (le développement initial du P4 n'a duré que trois ans au lieu des 5 initialement prévus, ce qui en fait un grand prématuré). Dans les défauts de base du P4, on retrouve d'ailleurs un gros problème de fluidité entre les unités de décodage et les unités d'exécution, du coup, ces dernières n'étaient pas correctement alimentées en instructions.
L'hyperthreading est venu pour masquer ce problème en créant un système de pseudos-processeurs se partageant les unités d'exécution afin de réduire l'inoccupation chronique de celles-ci. Malheureusement, il est fréquent qu'un pseudo-processeur doive exécuter du code mais ne trouve pas d'unité d'exécution libre pour le traiter, ce qui rajoute des micro latences aléatoires dans l'exécution et rend l'hyperthreading particulièrement préjudiciable aux applications temps-réel.
D'un point de vue "processeur juste assez bon pour des trucs à haute latences ou pour le consommateur de base qui marche au marketting", le P4+HyperThreading est bon, pour le reste, c'est un processeur de merde qui a besoin de presque un ghz et pas mal de jus de plus que la concurrence pour faire la même chose.
D'un point de vue architecturale, le P4 est mal torché, c'est tout.
[^] # Re: UbuntuMac
Posté par ragoutoutou . En réponse à la dépêche Nouveautés dans le monde Ubuntu. Évalué à -2.
[^] # Re: UbuntuMac
Posté par ragoutoutou . En réponse à la dépêche Nouveautés dans le monde Ubuntu. Évalué à 2.
Tu fais des licenses pour les softs que tu distribues pas toi? LOL
[^] # Re: Est-ce que l'IMAP et Usenet se sont améliorés?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Thunderbird 1.5. Évalué à 2.
[^] # Re: Est-ce que l'IMAP et Usenet se sont améliorés?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Thunderbird 1.5. Évalué à 3.
[^] # Re: Problème légal?
Posté par ragoutoutou . En réponse à la dépêche Gnash, le lecteur Flash libre. Évalué à 5.
Macromedia ne donne les spécifications qu'à la condition de s'engager de ne pas développer de lecteur, mais les personnes ne signant pas le NDA sont libres d'analyser les différents générateurs libres existant et d'utiliser les infos ainsi récoltées pour recréer un lecteur.
# Si j'ai bien compris...
Posté par ragoutoutou . En réponse à la dépêche DADVSI - Les minutes du débat à l'Assemblée. Évalué à -1.
# Si j'ai bien compris...
Posté par ragoutoutou . En réponse à la dépêche DADVSI - Les minutes du débat à l'Assemblée. Évalué à 3.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
Tout n'est pas mauvais chez intel, loin de là. Le P4 est une bouse, mais le Yonah est vraiment un processeur exceptionnel si on en croit les benchs.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
Par contre il faut noter qu'avec le P4, le code optimisé pour les autres processeurs tourne plus mal que sur P3, Pentium M ou Athlon XP/64 ...
En compilant les applications de manière optimale pour le P4, ce dernier reste plus lent que la concurrence (mais regagne à peu près en perfs que que l'hyperthreading peut récupérer)... En fait du code optimisé p4 ne gagne rien avec l'hyperthreading (car tout le cpu est utilisé), alors que le code optimisé PIII, PM, AMD, peut gagner avec l'hyperthreading vu que le processeur est moins bien alimenté en instructions.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
20 étages nécessitent déjà une super bonne prédiction de branchements, 40 étages, j'ose même pas imaginer la gamelle à chaque prédiction ratée...
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
La communication intercache ne passe pas par la ram, donc c'est pas un argument.
Encore une fois, il y a déjà un protocole de communication intercache avec contrôle d'intégrité (même sur les intels), donc pas un argument non-plus.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 3.
Si, si, je peux parfaitement m'imaginer, ça a été mon boulot pendant quelques années.
Par contre, ce qui m'échappe, c'est l'intéret d'une cache de second niveau partagée dans de telles conditions, et j'ai beau regarder, j'en vois pas. Une cache séparée évite bien des problèmes tout en évitant de devoir faire mumuse avec des techniques qui n'ont pas leur place dans le contexte d'une mémoire cache L2.
De plus, sur les amd64, il y a le protocole moesi qui permet une communication intercache directe entre les divers processeurs d'un même système, qu'ils soient en dual core, en multi proc ou en multi dual core.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 3.
et la concurrence à 4Ghz enterrerait le P4 à 5Ghz...
tu espères démontrer quoi?
La meilleure unité de mesure serait encore la consommation électrique: quel processeur fait le plus par watt, et encore une fois c'est pas le P4 qui gagnerait.
Le design du P4 est malheureusement trop éloigné des réalités physiques pour qu'on puisse dire qu'il est bon. Et puis, il me semble qu'intel promettait les 10Ghz lorsque le P4 est apparu... plutôt raté.
Au final, le coup du netburst ressemble plus à un coup de pocker manqué qu'à une architecture correctement ficelée.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
les performances réelles, la conso électrique et la chaleur émise... et étonnemment, un manque d'efficacité par cycle semble tout de même mener à un manque d'efficacité electrique et à un manque d'efficacité thermique.
Chaque cycle a un coût.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
Monter à 5ghz en P4, ça a autant de sens que de pousser un moteur de voiture à 15000 tours/minute en 3è vitesse. En plus, à 5ghz, l'électricité commence à avoir de sérieux problèmes de propagation (sur le temps d'un cycle, la lumière ne parcours que 6cm, l'électricité est beaucoup plus lente dans un processeur en surchauffe, les transistores ont eux-mêmes leurs latences, ce qui rend la propagation du signal dans le processeur beaucoup plus difficile dans une fenêtre de temps aussi réduite)
Pour l'hyperthreading sur le P4, le constat est simple: sur les applications optimisées P4, le gain est quasi nul, pour les applications otpimisées pour le PIII le gain peut monter effectivement dans les cas les mieux adaptés à 30%, mais c'est loin d'être une généralité, et au final ça ne rivalise pas avec la puissance par cycle d'un PIII, d'un Dothan ou d'un AMD64.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 2.
Sans rire, je sais pas ce que tu entend par "brouilleur", mais tout chipotage à ce niveau ne ferait que faire plonger les perfs du processeur... et ne dis pas que la carte à puce en a un, la carte à puce n'a ni la finalité ni la puissance d'un microprocesseur généraliste.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 3.
Hors, une vrai cache partagée (donc un bloc unique de mémoire cache accessible de manière uniforme par deux cores), ça n'existe pas dans le monde x86, c'est compliqué, et surtout ça pose des problèmes de sécurité (l'hyperthreading l'a démontré sans qu'on ait besoin d'aller jouer avec deux vrais cores).
Dans les amd64, les caches communiquent via le crossbar qui se situe entre les caches, les trois cannaux hypertransport et les deux cannaux de contrôleur ram.
En aucun cas ce ne sont des caches partagées, elles communiquent, mais ce sont bien deux blocs distincts qui ne peuvent être accédés par le processeur en face au même titre que par leur processeur.
[^] # Re: confusion...... disgression & précision sur le NUMA
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 3.
Je crois que c'est du pur amd, une solution indispensable pour garder une compatibilité parfaite pour les systèmes x86.
Yesss... au fait, tu bosses sur quelle architecture?
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 5.
Je dirais que c'est surtout un argument technique. L'intéret n'est pas juste de mettre un bel autocollant "dual core" sur son boîtier, mais de mettre un maximum de processeurs dans un minimum de place, et si possible en évitant un maximum les complications.
Je pense que c'est toi qui confond...
L'intégration du contrôleur de mémoire dans le processeur permet d'avoir autant de fois la bande passante proc<->mémoire que de socket occupé. Dans le cas de l'AMD64, l'hypertransport est utilisé pour communiquer avec le chipset et les autres processeurs, mais chaque processeur peut dialoguer directement avec sa propre ram sans passer par le bus, d'où un gain énorme d'efficacité dans les communications (on est à presque 95% de la bande passante théorique de 6,4Gb/sec alors qu'en passant par un contrôleur externe éventuellement partagé, on tombe sous les 70%)
Dans le cas d'une machines bi-Xeon ou bi-athlon xp, les deux processeur passent par le même northbridge pour atteindre la ram, ce qui rajoute des problèmes de collisions et de partage.
Dans quel film tu as vu ça?
Comment veux-tu avoir de la cache vraiment partagée et accédée sans intermédiaire entre deux processeurs physiquement distincts?
Sur du smp classique (xeon/athlon mp) avec deux processeurs physiquement séparés, les caches ne peuvent communiquer qu'en passant par le bus, ce qui correspond presque avec la méthode d'interconnexion utilisée pour l'amd64 x2 sauf que l'amd64 x2 a l'interconnexion directement en sortie du processeur au lieu de faire un détour par le bus.
C'est fort possible, il ne faut jamais dire jamais, mais le problème de sécurité du P4 HT a soulevé pas mal de questions au sujet de la cache partagée, et sans réponses valable à ce sujet, il serait risqué de la part de l'un ou de l'autre de lancer un processeur multi-core à cache partagée.
[^] # Re: confusion...... disgression & précision sur le NUMA
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 5.
Dans le cas l'amd64, on travaille en mode hybride SUMO (sufficiently uniform memory organization), ce qui permet si l'on est avec un OS stupide (comme windows), de travailler comme si on était en bête SMP (avec tout de même un système d'interconnexion très performant comparativement à ce qu'on a chez Intel), et si l'on est avec un os plus évolué, de travailler avec un kernel optimisé capable de gérer les affinités entre les processus et les processeurs.
Avantage du SUMO ?
- La migration de processus peut se faire de manière transparente (alors que dans une config NUMA standard, la migration nécessite plus de préparation pour envoyer un processus sur un autre processeur)
- les échanges entre processus situés sur des processus différents se font aussi de manière transparente, le partage de mémoire peut se faire exactement comme pour du smp.
Donc oui, le Numa, c'est pas évident, mais dans le cas de l'amd64, c'est tout de même beaucoup plus intéressant.
Sinon, je vois pas ce que le pauvre hyperthreading vient faire là dedans...
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 4.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 1.
D'après ce que j'ai lu, il semble que le problème soit surtout que les réactions d'un pseudo proc permettent de mesurer dans certains cas le comportement de l'autre pseudo-proc et du même coup de déterminer la vitesse d'exécution d'opérations crypto, ce qui permet de faire des attaques basées sur les mesures des temps d'exécution pour faire un profile du cryptage.
Au boulot on a des serveurs de crypto à ultra basse latence, et sur ces machines, l'hyperthreading est impérativement désactivé sinon le temps de réaction du serveur devient trop instable, ce qui mène à des timeouts dans les transactions.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 8.
Euh, là c'est idiot ce que tu dis. Le dual core a un réel avantage car il permet de mettre deux vrais processeurs dans un, ce qui permet d'avoir un coût infrastructure par processeur bien plus bas pour les workstations et pour les serveurs. Aucune comparaison possible avec des astuces de dernier espoir comme l'hyperthreading.
C'est particulièrement intéressant dans le cas où tu bosses avec des serveurs compactes de type blade où il devient très simple d'avoir un quadri-proc sans augmenter la taille des machines.
Je ne sais pas si tu as déjà vu beaucoup de systèmes 8 processeurs mono-core, mais crois moi sur parole que du dual core sur une carte mère 4 sockets est une solution bien plus élégante.
Pour l'affaire du contrôleur de ram intégré, c'est vrai qu'il y a débat car celà réduit les possibilités de changer le type de ram.
Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.
Une cache unifiée entre les deux cores nécessiterait soit de mettre un contrôle transactionnel multiclient sur l'allocation, la désallocation et l'accès à la cache, soit de limiter les accès à un seul processeur à la fois. Dans le premier cas, ça coûterait plus cher, dans le second, ça réduirait sérieusement les performances.
La solution de la cache séparée assortie d'une interconnexion directement à la sortie de la cache est en revanche une solution très efficace, et c'est ce qui est utilisé chez amd.
Pour le reste, je te recommande vivement de lire des tests et benchmarks plutôt que de donner dans les croyances populaires.
[^] # Re: confusion...
Posté par ragoutoutou . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 7.
Ben si je disais que l'hyperthreading dans pas mal de cas c'est une grosse bouse aussi :P
Plus sérieusement, le P4 est un processeur qu'Intel a jeté sur le marché beaucoup trop tôt, sans laisser le temps aux ingés de le finaliser (le développement initial du P4 n'a duré que trois ans au lieu des 5 initialement prévus, ce qui en fait un grand prématuré). Dans les défauts de base du P4, on retrouve d'ailleurs un gros problème de fluidité entre les unités de décodage et les unités d'exécution, du coup, ces dernières n'étaient pas correctement alimentées en instructions.
L'hyperthreading est venu pour masquer ce problème en créant un système de pseudos-processeurs se partageant les unités d'exécution afin de réduire l'inoccupation chronique de celles-ci. Malheureusement, il est fréquent qu'un pseudo-processeur doive exécuter du code mais ne trouve pas d'unité d'exécution libre pour le traiter, ce qui rajoute des micro latences aléatoires dans l'exécution et rend l'hyperthreading particulièrement préjudiciable aux applications temps-réel.
D'un point de vue "processeur juste assez bon pour des trucs à haute latences ou pour le consommateur de base qui marche au marketting", le P4+HyperThreading est bon, pour le reste, c'est un processeur de merde qui a besoin de presque un ghz et pas mal de jus de plus que la concurrence pour faire la même chose.
D'un point de vue architecturale, le P4 est mal torché, c'est tout.