warum immer eine verdopplung?

[=Floi=]

Hallo
ich finde diese verdopplung nicht schlecht aber teilweise nimmt es schon abstrakte formen an
zB cache der prozessoren
lange nichts (p2 hatte schon 512kb extern) und nun ein extremes wachstum auf 4!!!mb
beim p4 kam das wachstum ja auch erst zum ende der baureihe

oder das wachstum des vrams der grafikkarten bald haben wir 1gb und da frage ich mich ob nicht auch 768mb vram auch reichen würden
gleiches dann bei 1,5gb oder bei 3gb da hier dann der unterschied von 2 auf 4 gb schon eklatant wird
auch reichen heute of 256mb gerade nicht mehr aus aber 384mb würden diese lücke erfolgreich schliessen

ich würde mich eben auch mit weniger zufiedengeben und ihr?
wie ist eure persönliche meinung dazu?


MFG
Floi

[Trap]

Ein Cache dessen Größe nicht 2^n ist, ist schwieriger zu bauen und könnte im Endeffekt teurer sein als einfach verdoppeln oder er ist langsamer als einer mit der nächstkleineren 2^n-Größe.

Bei Haupt-/Grafikspeicher bin ich mir nicht ganz sicher ob es technische Gründe hat.

[Gast]

Bei der CPU mit dem cache gibt es datenpfade und speicherzellen dessen breite zu einander passen müssen; und da immer mit 2er potenzen gearbeitet wird (register, befehle, daten, addressen), werden auch meistens keine datenpfade gebaut welche nicht 2^n breit sind.
Man könnte nun sicherlich auf die idee kommen spericherchips/zellen zu bauen welche einen passend breiten datenpfad haben, aber eine kapazität welche keine 2er potenz ist; speicher muß aber addressiert werden, und da kommt man wieder auf die breite der addressleitungen zurück, welche wieder 2er potenzen sind - es macht also wenig sinn komische speichergrößen herzustellen oder verbauen zu wollen.
Die speicherverbindung ist bei grafikchips nunmal 256bit breit (oder 128bit, oder 64bit, usw); speicherchips sind 32bit breit und meistens 16MB oder 32MB groß. Somit ergibt sich z.b. bei einer 256MB karte mit 256bit speicherbandbreite eine ausstattung mit 8 speicherchips mit jeweils 32bit breite und einer kapazität von 32MB - du siehst also warum man auf keine irrwitzigen speichergrößen wie 384MB kommen kann - weil niemand speicherchips mit z.b. 48MB kapazität herstellt.

[ShadowXX]

Bei der CPU mit dem cache gibt es datenpfade und speicherzellen dessen breite zu einander passen müssen; und da immer mit 2er potenzen gearbeitet wird (register, befehle, daten, addressen), werden auch meistens keine datenpfade gebaut welche nicht 2^n breit sind.
Man könnte nun sicherlich auf die idee kommen spericherchips/zellen zu bauen welche einen passend breiten datenpfad haben, aber eine kapazität welche keine 2er potenz ist; speicher muß aber addressiert werden, und da kommt man wieder auf die breite der addressleitungen zurück, welche wieder 2er potenzen sind - es macht also wenig sinn komische speichergrößen herzustellen oder verbauen zu wollen.
Die speicherverbindung ist bei grafikchips nunmal 256bit breit (oder 128bit, oder 64bit, usw); speicherchips sind 32bit breit und meistens 16MB oder 32MB groß. Somit ergibt sich z.b. bei einer 256MB karte mit 256bit speicherbandbreite eine ausstattung mit 8 speicherchips mit jeweils 32bit breite und einer kapazität von 32MB - du siehst also warum man auf keine irrwitzigen speichergrößen wie 384MB kommen kann - weil niemand speicherchips mit z.b. 48MB kapazität herstellt.
AFAIK sollten aber mal Volari-Karten mit solchen krummen Speicherbelegungen rauskommen....da war allerdings dann auch die Anzahl der Adressleitungen "krum".
Das Licht der Welt haben diese allerdings AFAIK nie erblickt.

[Stone2001]

Ein Cache dessen Größe nicht 2^n ist, ist schwieriger zu bauen und könnte im Endeffekt teurer sein als einfach verdoppeln oder er ist langsamer als einer mit der nächstkleineren 2^n-Größe.

Ich wage es mal zu behaupten, dass sich der Mehraufwand einen Cache zu bauen, der nicht eine Größe von 2^n hat, vernachlässigbar ist.
Es gibt genügend Prozessoren, die einen Cache haben, dessen Größe kein Vielfaches von 2^n ist. Das neuste Beispiel ist der Itanium 2 mit Montecito-Core. In der Endausbaustufe hat er 24 MB L3-Cache.
Da ist Caches heute eh von einem Computer generiert werden, glaube ich auch kaum, dass er schwieriger zu bauen ist.

Ich würde sagen, dass Marketinggründe dahinter stecken. Für einen, der im Computerbereich 2er Potenzen gewohnt ist, hört sich halt 384 KiB Cache schon etwas komisch an.

(Man könnte jetzt natürlich auch gemein sein und sagen, dass die Simulationswerkzeuge der Entwickler keine Caches simulieren können, die nicht ein vielfaches von 2^n sind ;) )

[=Floi=]

bin gespannt ob der G80 wirlich mit einem 384bit breitem speicherinterface und 768mb varam kommt
das würde genau meine theorie bestätigen :D;D

[Gast]

Ich wage es mal zu behaupten, dass sich der Mehraufwand einen Cache zu bauen, der nicht eine Größe von 2^n hat, vernachlässigbar ist.
Es gibt genügend Prozessoren, die einen Cache haben, dessen Größe kein Vielfaches von 2^n ist. Das neuste Beispiel ist der Itanium 2 mit Montecito-Core. In der Endausbaustufe hat er 24 MB L3-Cache.Ich hab's an anderer Stelle schon mal geschrieben, als du nach er Addressierung eines solchen Caches gefragt hattest:
Diese Caches haben alle gemeinsam, dass die Anzahl der Sätze eine Zweierpotenz ist und somit die Addressierung ebenfalls wieder auf eine Zweierpotenz hinausläuft. Lediglich die Anzahl an Ways ist vollkommen ungerade bzw. nicht eine Zweierpotenz.
Die Addressierung (Auswahl des Satzes) ist aber weiterhin sehr einfach. Wenn man dann mit den entsprechenden Bits den Satz ausgewählt hat, muss man dort eben nur noch alle Ways durchprüfen, indem man alle Tags der zu diesem Satz gehörenden Cachelines prüft. Diese Zahl kann wie gesagt 7, 53 oder 36 sein. Entscheidend ist nur, dass genügend Tag-Prüfer in der Hardware vorhanden sind, damit auch alle Ways in einem Takt auf Hit/Miss geprüft werden können.

Die einzige (mir bekannte) Ausnahme von obigem sind imho die Power4/5 Prozessoren mit ihren L2 Caches. Diese sind in drei unabhängige Stücke ("Slices" im IBM-Jargon) aufgeteilt, die mittels Modulo3-Arithmetik auf Teile der physikalischen Addresse ausgewählt werden. Innerhalb dieser Slices wird aber wiederum genau wie oben addressiert. Die Kennzahlen des L2 des Power5 sind ja bekannt:
1,875 MiB L2 Cache in drei Slices => jeder Slice hat eine Größe von 0,625 MiB. Die Linegröße sind 128 Byte => 0,625 MiB / 128 Byte = 655360 Bytes / 128 Byte = 5120 Cachelines pro Slice. Diese sind als 10-fach assotiativer Cache organisiert, was also genau 10 Ways mit je 512 Sets entspricht. Wie du siehst, ist die Anzahl der Sets wiederum eine Zweierpotenz und damit wieder leicht zu addressieren.

Beim Power5 ist also nur die Aufteilung auf die drei Slices des Caches schwierig. Innerhalb dieser ist dann wieder alles beim alten.

(Man könnte jetzt natürlich auch gemein sein und sagen, dass die Simulationswerkzeuge der Entwickler keine Caches simulieren können, die nicht ein vielfaches von 2^n sind ;) )Dann sind die Werkzeuge nichts wert. Es gibt doch einige Prozessoren, die Cachegrößen haben, die nicht Zweierpotenzen sind: EV7, Power4/5, Sparc64 V, Ultrasparc T1, Itanium2 uvm.
(Zugegebenermaßen alle aus dem Server-Umfeld und nicht aus dem Mainstream)

[StefanV]

Die speicherverbindung ist bei grafikchips nunmal 256bit breit (oder 128bit, oder 64bit, usw); speicherchips sind 32bit breit und meistens 16MB oder 32MB groß. Somit ergibt sich z.b. bei einer 256MB karte mit 256bit speicherbandbreite eine ausstattung mit 8 speicherchips mit jeweils 32bit breite und einer kapazität von 32MB - du siehst also warum man auf keine irrwitzigen speichergrößen wie 384MB kommen kann - weil niemand speicherchips mit z.b. 48MB kapazität herstellt.
Naja, MBDRAM gabs mal, von MoSys, das war etwas krumm.

Tseng ET6000 verwendete es...