Reprise du message précédent :

 
 
Ah bon donc le L3 n'est plus utilisé des lors qu'on a spécifié la taille selon toi
Ca fait cher payé le truc inutile alors...  

C'est pour ça que le nouveau P4EE n'aura pas de cache L3, mais un trés gros L2.

mais enfin, arrêtez de divaguer, un L3 est toujours utilisé, windows n'a rien à voir là-dedant.
 
il faudrait penser à lire un article ou deux sur ce qu'est le cache et comment ça fonctionne, parce que là....
 
 
Le nouveau P4EE, s'il a un gros cache L2 au lieu d'un L3, c'est juste que le L2 est + rapide que le L3, c'est tout

j'ai jamais dit que le L3 est désactivé. le hardware continue à l'utiliser mais windows se limite à l'utilisation du cache L2 qu'on lui spécifie il n'enverra donc pas suffisament d'instruction pour dépasser la taille du cache. de plus dois-je vous rappellez que tout le monde n'a pas de L3. donc si windwos envoi trop de données ou d'instructions pour le L2 le CPU est surchargé et le surplus d'instruction est stocké dans des caches plus lent (chipset, ram,...)
si la taille n'est pas spécifié windows ne vérifie pas si le cache L2 est saturé ou pas d'où l'utilité du L3. si la taille du L2 est spécifié windwos utilisera intelligement le L2 donc le L3 sera inutile pour lui mais continura à être utiliser par le cpu pour stocker d'autre chose (bios pci, prefetch) donc sont utilisation sera également meilleure.
pour ceux qui n'ont pas de L3 les performances seront légèrement meilleures que si windows sature systématiquement le L2.
 
PS: linux fait une distinction entre les P4 pour la gestion du L2 par exemple, pas windows.  
-linux : celeron P4<P4A=P4B=P4C=P4EE(mais il tient compte du L3)<P4E
-windows : celeron P4=P4A=P4B=P4C=P4EE(ne tient pas compte du L3)=P4E
c'est pour cela que le P4EE et son cache L3 est parfois avantagé ou d'autre fois à égalité avec les P4C : sa dépend de la saturation ou non du L2 par l'application utilisée.
 
Ex: -une application aura besoin de 100ko de L2. elle ne sature pas le L2 du P4C ni celui du P4EE. leur performance dans cette application seront égales.
-une application utilise jusqu'à 600Ko de L2. le P4C est dépasser il doit stocké dans des caches lents le P4EE utilise son L3. le P4EE est plus performant.
-une application utilise jusqu'à 600ko de L2 mais windows connait la taille du L2. windows limite l'utilisation de L2 par l'application. Pourtant le p4EE sera plus performant. le L2 contient aussi les bios des périphériqes PCI AGP ou des résultats d'instruction... si windows réserve le L2 toutes ces informations passe dans le L3 du P4EE mais recte dans L2 du P4C ou passe en RAM. ce qui fait que le système est globalement plus performant avec le P4EE qui garde tout son L2 disponible et les informations du système dans un cache rapide.  
ce qui fait au final que les P4EE sont optimisés pour les calculs intensifs et répétitifs puisqu'il ne pénalise jamais le reste du système lors de ces calculs qui saturent systématiquement le L2.
 
PS bis: augmenter le cache L2 revient à ajouté du L3 mais le L2 étant plus rapide on gagne en performance. le problème restant le même si L2 est saturé mais à 1Mo de L2 rare sont les applications qui peuvent le saturer.
 
j'espère que c'est plus clair maintenant

 
STOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOP !
 
Le cache CPU n'est pas une mémoire utilisée comme une RAM. Que nenni. C'est un système d'accélération d'accès mémoire basé sur plusieurs paradigmes :
-proba spatiale : si une donnée X est demandée, y a de grandes chances qu'on demande la donnée X+1 après.  
-Proba temporelle : me souvient plus de celle la, désolé  
 
En clair : ce n'est qu'un espace de stockage totalement invisible à l'utilisateur, destiné à accélérer les accès mémoire de facon significative. Après, il y a les caches inclusifs, exclusifs, write-through, write-back... bref.
 
De plus, le cache L2 est totalement transparent au multitache. Comme il travaille en collaboration étroite avec le CPU, ce dernier  ne faisant que des accès mémoire, multitache ou pas, une application n'a JAMAIS besoin d'une certaine quantité de Cache ( L1, L2 ou L3). Non. C'est juste utilisé dynamiquement, de facon totalement transparente, et, pour être bien clair, aucun programme ne touche au cache CPU directement comme une mémoire. C'est même impossible.
 
L'OS est aussi inclus dans ces programme ( un OS n'est qu'un programme à la base ).
 
Parti de la, dire que une application a besoin de 100Ko de L2 est complètement débile. L'application, elle a besoin de tant de RAM. Le cache CPU, elle peut tourner sans, quoiqu'il arrive. Vu que pour elle, il n'existe pas et elle fait référence à la mémoire de facon constante.
 
Donc, le post de Chabinoxu est, jusqu'a preuve du contraire, de la science-fiction totale et dfinitve. Surtout, ne croyez pas qu'une application a besoin de x Ko de cache CPU : c'est complètement faux.
 
Pour info personelle, comment ca marche le cache CPU, simplement :
 
-Le CPU demande une info à la mémoire, disons l'info X.
-l'info est aps dans le cache, on fait l'accès
-comme l'info est petite, on peut en rapatrier une tripotée en même temps. Alors on le fait et on le met dans le cache CPU. Alors, dans le cache, il y a l'info X, X+1, X+2, X+3...x+8 (mettons).
-Le CPU va recevoir l'info X dans un temps long ( normal, on a fait un accès mémoire, c'est très couteux, disons... 1 000 cycles CPU (j'exagère).
-Le CPU bosse et demande l'info X+1 ( probabilité spatiale).
-On regarde dans le cache et... POF ! elle y est l'info ! on la rapatrie directement au CPU sans rien demander à la mémoire. Cout : 3 cycles.
-Le CPU continue...
 
Bref, la mémoire cache, en simplifié, c'est ca.

Une autre chose :
 
Mettons que windows "gère" le cache de facon "intelligente". Comme un OS n'est qu'un programme son algorithme de gestion "intelligente" devra s'executer dans le CPU. Et donc fera fatalement des accès mémoire ( rien que pour récupérer le code de gestion du cache), code qui se retrouvera fatalement dans le cache du CPU ( logique, y a eu un accès).
 
L'existence même de cette fonctionnalité est une optimisation MONSTRUEUSE du cache effectivement
 
Tout le cache est géré en hard par la bécane. Point. ce que dit le monsieur au dessus est de la science-fiction

On touche pas au cache mais on peut optimiser la vitesse d'un prog sur un proc en organisant correctement les données (style paquets de x ko, aligement sur bits pairs, etc ...) (cf manuel de l'optimisation intel)
 
a mon avis ce que dit chabinoux c'est ca. windows gere peut etre des paquets de taille différente en fct de la taille de cache qu'on lui donne. (j'en ai aucune idée, je propose, c tout ), d'ou de legers gains possibles.

nous sommes d'accord.
je rectifie si une application nécessite 100ko d'instruction desinée au CPU (c'est qu'ils fallait comprendre je sais bien que le L2 n'est pas une petite ram)

 
Lors du chargement en mémoire oui Mais cela n'est qu'un algorithme de chargement de données, pas un algorithme de gestion du cache !

 
bein oui mais ce seul chargement compte pour toute la suite

+1
 
y'a que le SSE qui permet de faire des prefetchs explicites.
 
tout ce que peut servir cette valeur dans la BDR c'est définir le sweet spot de la taille de certains tampons internes à l'os pour avoir un rendement optimal.  
 
au mieux théorique tu gagnes des pouillèmes de %.  
 
vu qu'un cache plus gros ne posera pas de problèmes de rendement avec des tampons "petits". ie si tu fais un traitement dans un tampon de 2Ko, c'est pas ça qui fera que le cache L3 de 1Mo sera utilisé ou pas.
 
dans la pratique personne n'a jamais mesuré de variation de performances (via cette valeur de la BDR).
 
ensuite une chose parfaitement claire, l'OS n'ajuste rien qui appartiens à l'appli par rapport aux caches L1/L2/L3.
 
tout ce que tu faire comme j'ai dit, c'est faire des traitements par chunks de 2K/4K/8K, et si ça doit être spécifié ou ajusté, c'est au niveau OS/APPLI/BIBLIOTHEQUE (codec par exemple).

c'est exacement ce qu'il fallait comprendre. le cache L2 stock des infos, des résultat, d'algorithme et autres. mais si windows sait comment ne pas sur exploiter les capacité de cache du proc ça marche bcp mieux. et ce n'est pas de la science-fiction, mr tetedeiench.

c'est de la science-fiction, l'OS ne peut pas ajuster la taille des tampons des process.
 
cette clé dans la BDR est de la branlette dans la mesure que ça peut n'avoir une incidence que sur le kernel lui-même au mieux.

et puis merde on se bat alors qu'on dit tous la même chose. j'ai jamais dit que le PC décuplait par dix sa puissance. le gain est infime mais sur de grosses applications de calcul intensif le gaine sera notable mais dans les jeux que dalle ou pas grand chose et l'utilisation de tous les jours (net bureautique...) alors là encore moins.
tout ça c'est pour dire que le cache L3 n'apporte presque rien et que définir la taille du L2 apporte une meilleure gestion pas une transfiguration du PC. et je le répète parce que j'en suis sûr (je le fait en cour en ce moment) toutes applications fonctionnant sous windows (ou un autre OS) utilise les tampons définis par l'OS.  
application->OS->hardware->OS->application. je n'ai pas dis non plus que le controle du L2 est fait par l'OS mais c'est OS qui optimise ses données en fonction de la taille du cache L2 spécifié. bref le cache L3 n'est utile qu'exceptionnellement et windows peut optimiser sa gestion du cache pas en prendre le controle totale nous somme bien d'accord.
petite métaphore:
tu ne conduira pas un ferrari comme une coccinelle. chacune à ses possibilités, à toi de les utiliser au mieux.  
A méditer!!!!

rappel : le kernel à tout interet à être optimiser pour le matos utilisé.

bon oki on est d'accord, sauf pour préciser:
 
cette clé dans la BDR aura au mieux une incidence uniquement sur le noyau. hors le noyau, y bouffe 1/2% du temps CPU.
cette clé n'a pas d'incidence au niveau appli. stout.

heu........
 
quand je dis tampon c'est un terme générique.
 
par exemple, les "tampons" utilisés par un codec vidéo pour son IDCT en SSE, elle est absolument pas controllée par l'OS (au niveau de sa taille).

je crois que tu confonds avec les tampons d'entrée/sortie.
 

Je pense aussi qu'il nous fait un sacré mic mac, et qu'il se rends pas compte que windows y peut pas gd yauq, au cache CPU

ni linux, spareil.  
d'un point de vue kernel, la seule chose que tu peux faire au cache, c'est configurer ce qui est cacheable ou pas, ajuster la taille des tampons des routines internes pour que ça reste dans le cache.
 
spareil au niveau appli, mais personne le fait, déjà on prends des tampons style 2K qui tiennent dans le cache de donnée L1, et on se prends pas trop le choux après... le L2/L3 c'est du cado bonux au bon vouloir du fabricant. mais l'intêret de prendre en compte sa taille au niveau du code....

waouw, quel topic !!    
 

Alors en fait on me propose une CM "MSI Pro 266TD Master" (9105) BI-CPU avec 2 PIII-S 1,4 Ghz et 512 Mo ECC-R de DDR PC 2100 (2x256 corsair).
 
Le vendeur me lache ca pour 250 euro et me dit que les CM PIII acceptant de la DDR sont assez rare et que ca vaut le coup. C'est vrai ou pas ?

je ne savais même pas que les carte-mères DDR pour P-III existaient

BAh justement, j'ai regarder sur le site de MSI pour voir les spec de cette carte que j'ai pu voir de mes yeux. Mais a part sur le site de MSI on trouve très peut d'info sur le net a propos de cette carte. J'en avait deja recherché il y a longtemps mais c'est de pire en pire....

c'est marrant chez moi il est déjà reglé sur 200 alors que je n'ai touché à rien

c'est rare, et pas forcément utile pour un P3.
ceci dit si y'en a deux... (mais je connais po les restrictions en SMP de P3, si le bus est partagé ou il y a deux bus)
 
si il y a deux bus, la DDR mets une baffe à la sdr, si y'en a qu'un le bus se sature facilement, et la ddr est peu utilisée.
 
le prob, c'est que l'offre qu'on te fait peut être interressante si tu fais du rendu 3DS à mort ou autre truc tirant profit du SMP.
 
pour ce qui en tire pas profit, les jeux, ce sera plus certainement plus performant avec un athlon xp.
 
par contre ça pourrait être interressant d'o/c les PIII pour du rendu 3DS/Maya, avec le rendement du PIII en fréquence, avec les deux cpus o/c à 1.6, tu dois pouvoir arriver à un P4 3.6 dans certaines situations....

mais qu'est ce que tu te prends la tête avec des vieux machins qui coûtent la peau du cul????  

bah c'est le top du P3, ça doit bien se comparer à un bi-MP 1800+ ou 2000+, mais qd même c'est cher

Apparement sur cette CM le chipset VIA (VT8653 et VT8233) on un double bus V-Link ou un truc comme ca. Je ne sais pas si ca correspond a ce que tu dis.
 
Par contre pour la mémoire c'est marqué : "Supports only x8 technology" ca veut dire quoi au juste ?

c'est peut-être 8 bits par module

tetedeiench et bjone j'essayrais même pas de les contredire un jour sur un truc qu'ils ont l'air de connaître.
Te sortiraient des mots dont t'arriverais même pas à les prononcer

les P3, c'est comme les P4, ils ont un bus partagé

Je connais cette mobos, pour l'instant je la trouve un peu limite niveau perf, faut voir ce qu'elle donne avec 4x256 de ram pour avoir le max de bande passante memoire, et aussi un autre P3-s  

 
pluzun

le coup du X8 c le nombre de chip par face non ?
 
ben non puisque sur certaines vieilles cm ct x34 max
 
et en ce moment c bcp plus

Mustang ---> Bah c'est pour ça que je pose la question, je ne voudrais pas me faire avoir en achetant une DDR qui ne passe pas.

c valable que pour la SDR te fait pas de soucis

enfin toutes les mobo recentes marchent avec toutes les ram
 
et meme les mobo un peu vieille
 
 
 
flagelez moi si je me trompe

 
Sauf certaines anciennes ( du temps du chipset BX et LX ) avec certaines SDRam...
 
Une sombre histoire de couches.

je voulais pas le sorir le BX , LX et ZX (j'ai une ZX)
 
si ma memoire est bonne, ZX cai max x32