Eine Frage zu den Details von Speicherfunktionen in PCs: Die Zugriffsgeschwindigkeit bei DDR3- und DDR4-Speichern scheint sich ja in Richtung Latenz zu entwickeln, bei verbesserter Bandbreite. Ich habe mich die vergangenen Tage mit den Details zu beschäftigen gehabt und stolpere über eine Frage: Was macht den realen Speicherzugriff langsam? Die brutto ausrechenbaren Bandbreiten werden so gut wie nie erreicht. Im Gegenteil: Mehr als 60%-80% sind nicht zu erzielen. Bisher dachte ich, dass dieses durch u.a. den refresh verursacht wird. Ich lese aber in der WP, dass dies nur wenige Bruchteile von Prozenten zu sein scheinen, wenn die Rechnung dort stimmt: https://en.wikipedia.org/wiki/Memory_refresh Zu lesen ist dort, dass bei 64ms nur ein halbes Prozent aus macht, wenn die Rechnung stimmt. Das sollte man in der Praxis kaum merken. Woher kommt der Rest? Sind das die Bank- und Seiten-Umschaltungen? Oder die ungenutzten bursts? Davon ausgehend, daß selbst kleine Pakete für Bilder und sonstige Daten wie mp3 oder auch Messtechnikdaten im Bereich viele Kilobytes liegen, sollte der größte Teil eines solchen Auslesevorgangs mit voll gefüllten und genutzten bursts und auf derselben Seite stattfinden. Eine Bildzeile z.B. hat 2000 Punkte = 6000 Bytes, davon kann nur der letzte burst überwiegend leer sein, wenn es sinnvoll gefragt wird und abgespeichert wurde. D.h man sollte bei einem 32 Byte burst über hundert volle Paket bekommen. Macht wieder weniger als 1% Verlusts. Es müssten also Seitenwechsel sein. Oder? - Aber warum macht das so viel aus? Kann es sein, dass einfach das Betriebssystem zu viel "gleichzeitig" machen will und deshalb Anfragen von zuvielen Prozessen zu kleinkariert prozessiert, statt Speicherzugriffe zu bündeln? Lässt sich das irgendwie steuern?
:
Bearbeitet durch User
K. F. schrieb: > Was macht den realen Speicherzugriff langsam? > > Die brutto ausrechenbaren Bandbreiten werden so gut wie nie erreicht. Im > Gegenteil: Mehr als 60%-80% sind nicht zu erzielen. Bisher dachte ich, > dass dieses durch u.a. den refresh verursacht wird. Ich lese aber in der > WP, dass dies nur wenige Bruchteile von Prozenten zu sein scheinen, wenn > die Rechnung dort stimmt: Mein Speicher ist sauschnell und erreicht > 90% der theoretische Bandbreite. Hast du dir mal die Mühe gemacht, ein ordentliches Benchmarkprogram laufen zu lassen?
:
Bearbeitet durch User
Udo K. schrieb: > Hast du dir mal die Mühe gemacht, ein ordentliches > Benchmarkprogram laufen zu lassen? Und damit sind wir beim Punkt: Um den Durchsatz von RAMs voll auszukosten, benötigt man Software, die darauf optimiert ist. Benchmarks sind es. Normale Anwendungen nicht.
:
Bearbeitet durch User
K. F. schrieb: > Kann es sein, dass einfach das Betriebssystem zu viel "gleichzeitig" > machen will und deshalb Anfragen von zuvielen Prozessen zu kleinkariert > prozessiert, statt Speicherzugriffe zu bündeln? Eher nicht, die Kontextwechsel von PC-Betriebssystemen sind viele Größenordnungen langsamer als die einzelnen Speicherzugriffe. Auch dank Mehrkern-Prozessoren werden leistungshungrige Anwendungen (z.B. Spiele) sowieso eher selten unterbrochen. Das Hauptproblem ist einfach die Latenz, bis die Bits rauskommen. K. F. schrieb: > Lässt sich das irgendwie steuern? Wenn das so einfach ginge, würden die Hersteller es machen, das ist ja ein riesen Markt...
K. F. schrieb: > Die brutto ausrechenbaren Bandbreiten werden so gut wie nie erreicht. Im > Gegenteil: Mehr als 60%-80% sind nicht zu erzielen Die große Kunst ist es, die Speicherzugriffe so zu organisieren, das die Bandbreite auch ausgenutzt werden kann. In einer heutigen CPU gibt es viele verschiedene Einheiten die dann und wann was vom Speicher wollen. Der eine Hersteller kann das besser, der andere schlechter. Die maximal mögliche Bandbreite gilt außerdem nur für sequentiellen Zugriff mit möglichst großen Blöcken - ein Zugriffsmuster was in der Realität nicht unbedingt an der Tagesordnung ist.
Andreas M. schrieb: > Die maximal > mögliche Bandbreite gilt außerdem nur für sequentiellen Zugriff mit > möglichst großen Blöcken Eine Maschine mit vielen parallel laufenden und voneinander unabhängigen Prozessen/Threads kann dabei auch helfen. Wenn dabei genug Requests zusammen kommen, um die Lücken zu stopfen, die andere Threads bei den Zugriffen lassen. An die volle Bandbreite kommt man da nicht heran, aber es wird besser als beim Anwender-PC.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Eine Maschine mit vielen parallel laufenden und voneinander unabhängigen > Prozessen/Threads kann dabei auch helfen. Wie? Dort wird doch nur die Bandbreite aus Sicht der nutzenden Prozesse ausgenutzt, d.h. das, was der eine nicht verbraucht, kann der andere haben. Mir geht es aber darum, für einen einzigen Schreibe und Lese-Prozess die Bandbreiten bereitstellen zu können. Andreas M. schrieb: > Die große Kunst ist es, die Speicherzugriffe so zu organisieren, das die > Bandbreite auch ausgenutzt werden kann. Genau. Udo K. schrieb: > Mein Speicher ist sauschnell und erreicht > 90% der theoretische > Bandbreite. Wie hast du das gemessen? Doku erhältlich? Welcher Speicher? Welche Applikation? Was passiert mit den restlichen 10%? Wo versickern die?
K. F. schrieb: > Was passiert mit den restlichen 10%? Wo versickern die? Die werden für die Ausleitung der Daten an die NSA benötigt, das sollte doch klar sein.
Harald K. schrieb: > Die werden für die Ausleitung der Daten an die NSA benötigt, das sollte > doch klar sein. War klar, dass wieder so etwas kommt. Mal im Ernst: Hat jemand eine Quelle, anhand derer man einen solchen Speicherzugriff nachvollziehen kann? Könnte man das mit RAS/CAS timing nicht beispielhaft berechnen, wie und in welchen Fällem welche Verluste auftreten? Andere Idee: Kann eine unglückliche Cache-Nutzung die Bandbreite verschlechtern?
K. F. schrieb: > Hat jemand eine Quelle, anhand derer man einen solchen Speicherzugriff > nachvollziehen kann? Nimm dir einfach ein Datenblatt eines beliebigen RAMs Chip, da steht alles drin. Typischerweise werden die Daten auch in "Bursts" gelesen, d.h. es wird nie eine Speicherzelle, sondern meist 4-8 Zugriffe der selben Art direkt hintereinander, hängt vom RAM Typ ab. K. F. schrieb: > Andere Idee: Kann eine unglückliche Cache-Nutzung die Bandbreite > verschlechtern? Ich denke die Speicherzugriffsmuster in der Anwendung sind da kritischer. Wenn du z.B. viele kleine Häppchen an verschiedenen, weit auseinanderliegenden Adressen im Wechsel liest und schreibst, dann ist das ganz schlecht. Weil er ständig die Pages wechseln muss
K. F. schrieb: > Mir geht es aber darum, für einen einzigen Schreibe und > Lese-Prozess die Bandbreiten bereitstellen zu können. Dann gilt es nicht nur, sich mit dem Speicher zu beschäftigen, sondern auch mit den konkreten Prozessor. Wie man die Befehle passend arrangiert, und welche man dafür verwendet. Wie der Prefetch des Prozessors arbeitet, wie man ggf am Cache vorbei operiert, wenn der aufgrund zu grosser Datenmengen sowieso nur im Weg steht. Und was man den Performance Countern des Prozessors entnehmen kann. Alles in allem eine anspruchsvolle Aufgabe.
K. F. schrieb: > Mal im Ernst: > > Hat jemand eine Quelle, anhand derer man einen solchen Speicherzugriff > nachvollziehen kann? > > Könnte man das mit RAS/CAS timing nicht beispielhaft berechnen, wie und > in welchen Fällem welche Verluste auftreten? > > Andere Idee: Kann eine unglückliche Cache-Nutzung die Bandbreite > verschlechtern? Die Speicherbandbreite hängt vom Speichertakt ab, von der Breite des Speicherinterfaces und von der Anzahl der Speicherkanäle. Auf dem Laptop hier etwa 2400 MHz 8 Bytes 2 = 38400 MB/sec. Windows "winsat mem" als Admin gestartet liefert 35.2 MB/Sec, also 92% der theoretischen Bandbreite. Der Cache ist ist typischwerweise 8-way associative, du kannst also 8 Blöcke mit kollidierenden Addressen im Cache halten. Der L1 Cache ist dazu separat für Daten und Instruktionen. Wie man jetzt genau die Latenz ausrechnet, überlasse ich dem Dipl.-Ing. in deinem Namen.
(prx) A. K. schrieb: > Und damit sind wir beim Punkt: Um den Durchsatz von RAMs voll > auszukosten, benötigt man Software, die darauf optimiert ist. Benchmarks > sind es. Normale Anwendungen nicht. Eigentlich macht das die Hardware selbständig. Jedes Program, dass ein paar MB am Stück liest, hat 90% der maximalen Performance. Ich würde eher sagen, dass es verdammt schwer ist einen heutigen Cache Controller zu überlisten. Selbst wenn du die Bytes in kleinen Häpchen liest, ist die Performance ziemlich gut, solange die Daten nicht zufällig im Hauptspeicher verteilt sind. Normalerweise sind die Daten nach dem ersten Lesen oder beim Schreiben im L1/L2/L3 Cache, die DDRAM Geschwindigkeit und Latenz spielt daher nur bei sehr grossen Daten eine Rolle. Daher ist die Geschwindigkeit von DDRAM für die meisten Anwendungen unwichtig.
:
Bearbeitet durch User
Andreas M. schrieb: > Typischerweise werden die Daten auch in "Bursts" gelesen, > d.h. es wird nie eine Speicherzelle, sondern meist 4-8 Zugriffe der > selben Art direkt hintereinander Dazu kommt noch, dass nicht nur die Nutzdaten im RAM liegen, sondern auch noch das Anwendungsprogramm und das ganze BS. Wenn man sich auf einem aktuellen Windows so umschaut, sieht man das da in der Regel über 1000 und mehr Threads aktiv sind (ganz unabhängig von der eigentlichen Anwendung). Jeder diese Threads will gelegentlich mal Prozessorzeit zugeteilt bekommen. Das heißt Kontextwechsel und vorallem dessen Programmcode muss Befehl für Befehl aus dem RAM gelesen werden. Und mehrere Kerne, die nur über ein gemeinsames Speicherinterface angebunden sind, machen das Aufteilen der Speicherzugriffe auch nicht gerade besser. Dazwischen kommen dann auch noch Zugriffe wie auf die Festlatte oder die Netzwerkkarte, die ja auch ihre Datenblöcke im RAM zwischenlagern und dazu ggf. noch einen weiteren Software-RAM-Cache dazwischen haben. USB und so bekommen andauernd neue Daten die vom BS auch erstmal im RAM geparkt werden bis irgendeine Anwendung die haben will usw. Von der Grafikkarte, die ja vom BS auch immer wieder mal mit neuen Informationen (z.b. Mauszeiger ein Pixel nach rechts verschieben) gefüttert werden will, ganz zu schweigen. Ein "passender" Cache-Mistake und alle Kerne fangen an ihr Cache erstmal wieder aus dem RAM zu aktualisieren:-) Nochdazu, bei einer realen Anwendung ist es ja nicht damit getan, einfach nur Daten aus dem RAM zu lesen. Man braucht ja auch CPU-Befehle die die Daten lesen und man braucht auch noch Befehle, die die Daten verarbeiten und ggf. auch noch welche die die verarbeiten Daten wieder irgendwohin schaffen. Da kommt man dann zu irgendwelchen Benchmarks. Denn kann man einigermaßen so optimieren, dass dieser möglichst komplett im Cache abläuft und die gelesen Daten aus dem RAM quasi ohne Beachtung nach DevNull entsorgt werden. Sowas dann noch in einer Version die ohne größeres BS auskommt, wie z.B. DOS, wo keine andere Thread dazwischenfunken kann und große Teile der Hardware möglichst nicht genutzt werden, dann kommt man den theo. max vielleicht nahe.
Irgend W. schrieb: > Sowas dann noch in einer Version die ohne > größeres BS auskommt, wie z.B. DOS, wo keine andere Thread > dazwischenfunken kann und große Teile der Hardware möglichst nicht > genutzt werden, dann kommt man den theo. max vielleicht nahe. Das stimmt schon, was du schreibst. Aber wenn du mal Zahlen einsetzt, dann siehst du schnell, dass das alles nicht so schlimm ist. Es gibt nur wenige Programme, die die Geschwindigkeit des RAM ausreizten, da brauchst du grosse Datenbanken oder Film und Video Bearbeitung. Das typische Program liest und schreibt fast immer aus dem Cache. Um an die Grenzen des RAM zu kommen, musst du mindestens 30 MByte in einem Stück lesen oder schreiben. Alles drunter läuft aus dem Cache. Wenn du es nicht glaubst, schreibe ein simples Speicherkopierprogram. Du wirst sehen, dass der Speicher nicht langsamer als das RAM ist, sondern im Gegenteil viel schneller ist! Auf meiner Windows Kiste laufen gerade mal 25 Prozesse, die mehr RAM haben als in den Cache passt, und von denen braucht kein einziger mehr als 1% CPU.
Apropos Suche nach den letzten Prozenten: Wessen aktives Grafiksystem Teil des Prozessorkomplexes ist, der sollte den Bandbreitenbedarf seiner Bildschirme mitrechnen. Deren Refresh läuft dann aus dem normalen RAM.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Apropos Suche nach den letzten Prozenten: Wessen aktives Grafiksystem > Teil des Prozessorkomplexes ist, der sollte den Bandbreitenbedarf seiner > Bildschirme mitrechnen. Deren Refresh läuft dann aus dem normalen RAM. Ja, das ist auch ein wichtiger Aspekt. Ich habe hier im Wohnzimmer einen HTPC stehen. Früher war da mal ein Celeron 847 drinnen. Dieser hat ebenfalls eine integrierte GPU. Dekodieren von HD Streams über Satellit (ca 2,4MB/s) hat mit dem nur bei Dual-Channel RAM flüssig funktioniert. Wenn man nur einen RAM-Riegel bestückt hat, dann war die Bandbreite zu klein um die Hardwaredecoder, CPU und GPU parallel zu bedienen.
Udo K. schrieb: > Mein Speicher ist sauschnell und erreicht > 90% der theoretische > Bandbreite. Ich habe hier auf zwei Rechnern mal ein hand-gedengeltes 64bit Testprogramm in Assembler geschrieben. Bei 1GiB RAM über Quadword Zugriffe beim Lesen erreiche ich ca. 11.57GB/s bei theoretisch möglichen 12.8GB/s. Das sind ebenfalls 90.4%. (Device-1: ChannelA-DIMM0 type: DDR3 size: 4 GiB speed: 1600 MT/s)
Udo K. schrieb: > schreibe ein simples Speicherkopierprogram. "simples Speicherkopierprogramm", der Witz ist gut:-) Schaue dir mal alle die verschiedenen Funktionen in C/C++ an was da für eine Aufwand getrieben wird um eine paar Daten von A nach B zu kopieren. Da werden z.B. die SSE oder AVX Einheiten benutz um die Daten "zwischenzulagern" damit der RAM-Burst möglichst vollständig genutzt werden kann usw. Das ist erstmal nur die Daten von einem Speicherbereich in einen anderen Kopiert. Hier sind die Daten noch lange nicht irgendwie ver-/bearbeitet... - https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/multiarch/memcpy-ssse3.S Udo K. schrieb: > Kiste laufen gerade mal 25 Prozesse Viel interessanter als die Prozesse sind die Threads (kann man im Taskmanager im Tab Details einblenden). Die entscheiden darüber wieviele Aufgaben der Scheduler zu verteilen hat. Udo K. schrieb: > dass der Speicher nicht langsamer als das RAM ist Hä? RAM ist doch der Speicher?
Irgend W. schrieb: > "simples Speicherkopierprogramm", der Witz ist gut:-) Cache-Handhabung nicht vergessen. Vielleicht will man deren Inhalte nicht durch grössere Transfers plattwalzen, sondern darin Wichtigeres aufbewahren.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Cache-Handhabung nicht vergessen. Vielleicht will man deren Inhalte > nicht durch grössere Transfers plattwalzen, sondern darin Wichtigeres > aufbewahren. Kommt drauf an was man erreichen möchte. Um die Geschwindigkeit zu testen ist jedes Mittel recht (T0). Um lieb zu anderen zu sein wird es wohl eher auf (NTA) heraus laufen.
Norbert schrieb: > Um lieb zu anderen zu sein wird es wohl eher auf (NTA) heraus laufen. Für jene, denen das nichts sagt: https://www.felixcloutier.com/x86/prefetchh Ob da überhaupt etwas passiert, und wenn ja was, ist arg abhängig vom konkreten Prozessor, und auch nicht unbedingt erschöpfend dokumentiert. Man kann sich dann auch in die Arbeitsweise der automatischen Prefetches einlesen, die möglicherweise ähnliche Strategien verfolgen.
:
Bearbeitet durch User
K. F. schrieb: > Eine Frage zu den Details von Speicherfunktionen in PCs: Jeder der sich ernsthaft mit DRAM-Speicher beschäftigt, beispielsweise mal das umfängliche Datenblatt durchgelesen hat, kennt die Gründe dafür und das die Frage so unzureichend formuliert ist. https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/dram/ddr4/8gb_ddr4_sdram.pdf DDR RAM ist auf Blockzugriffe aka Bursts optimiert, die gehen rasend schnell, was vielleicht einen dummen Jungen langsam erscheint sind Zugriffe mit bei nicht sequentiellen Addresses. Die werden aber auch durch Caches abgefangen, zeigen aber das Problem des gemultiplexten Adressbusses, also das Addressierung über zwei Zugriffe (Row- und Column-bestandteil) erfolgen muss. Turnaround bei Umschaltung der Signalrichtung (read/write) sind auch nicht zu unterschätzen. > https://en.wikipedia.org/ Auch wenn die englische WP oft besser als die deutsche ist ist wie wikipedia kein Ersatz fürs Datenblatt oder (Hochschul-) Fachliteratur. Wenn man in Richtung PCB geht, tauchen weitere Probleme wie Laufzeitunterschiede und parasitäre Kapazitäten aus die zu einem Langsameren Taktschema zwingen.
Klar P. schrieb: > zeigen aber das Problem des gemultiplexten > Adressbusses, also das Addressierung über zwei Zugriffe (Row- und > Column-bestandteil) erfolgen muss. Wobei diese Trennung aber nicht nur Leitungen spart, sondern auch mit der internen Organisation der DRAMs zu tun hat. Für die Speicher-Matrizes braucht man zunächst eben nur den Teil der Adressbits zur Zeilenauswahl. Die Adressbits zu Spaltenauswahl haben etwas mehr Zeit.
Klar P. schrieb: > Turnaround bei Umschaltung der Signalrichtung (read/write) sind auch > nicht zu unterschätzen. Rambus hatte diesen Punkt adressiert, genutzt von den ersten Pentium 4 Prozessoren. Schneller wars jedoch nicht, und eckte zudem "politisch" an, weil sich die Firma in den Branche zum Paria machte.
:
Bearbeitet durch User
>> Turnaround bei Umschaltung der Signalrichtung (read/write) sind auch >> nicht zu unterschätzen. > > Rambus hatte diesen Punkt adressiert, genutzt von den ersten Pentium 4 > Prozessoren. Schneller wars jedoch nicht, und eckte zudem "politisch" > an, weil sich die Firma in den Branche zum Paria machte. Rambus kenne ich nicht so im detail, aber IMHO waren deren designs zu beginn (1990's) schon schneller als der "Standard" synchrone DRAM. Natürlich fehlt IP-(fabless) Firmen wie RAMBus die "normative Kraft des Faktischen" mit denen die grossen RAM-Hersteller alle "Neu-Einsteiger" "platt machen". rambus inc. hat ca. 600 Mitarbeiter, micron technologies dagegen 43000 .
(prx) A. K. schrieb: > Ob da überhaupt etwas passiert, und wenn ja was, Core i3 & Core i5 (ältere Modelle)
1 | ~/source/Assembler-64bit$ make memspeed && ./memspeed |
2 | gcc -c -Wall -Wextra -pedantic -fPIE -g -o mem_functions.o mem_functions.s |
3 | gcc -Wall -Wextra -pedantic -fPIE -g -o memspeed memspeed_test.o mem_functions.o |
4 | allocating 1 GiB… |
5 | done. ptr=0x7f7968afb000 |
6 | 0: 65136 µs/GiB -> 15.352 GiB/s 16.485 GB/s |
7 | 1: 56539 µs/GiB -> 17.687 GiB/s 18.991 GB/s |
8 | 2: 55494 µs/GiB -> 18.020 GiB/s 19.349 GB/s |
9 | 3: 55517 µs/GiB -> 18.013 GiB/s 19.341 GB/s |
10 | 4: 56474 µs/GiB -> 17.707 GiB/s 19.013 GB/s |
11 | 5: 56700 µs/GiB -> 17.637 GiB/s 18.937 GB/s |
12 | 6: 56963 µs/GiB -> 17.555 GiB/s 18.850 GB/s |
13 | 7: 56880 µs/GiB -> 17.581 GiB/s 18.877 GB/s |
14 | 8: 57200 µs/GiB -> 17.483 GiB/s 18.772 GB/s |
15 | 9: 57008 µs/GiB -> 17.541 GiB/s 18.835 GB/s |
16 | 10: 56886 µs/GiB -> 17.579 GiB/s 18.875 GB/s |
17 | 11: 56903 µs/GiB -> 17.574 GiB/s 18.870 GB/s |
18 | 12: 56789 µs/GiB -> 17.609 GiB/s 18.908 GB/s |
19 | 13: 56856 µs/GiB -> 17.588 GiB/s 18.885 GB/s |
20 | 14: 56854 µs/GiB -> 17.589 GiB/s 18.886 GB/s |
21 | 15: 56992 µs/GiB -> 17.546 GiB/s 18.840 GB/s |
22 | 16: 56913 µs/GiB -> 17.571 GiB/s 18.866 GB/s |
23 | ~/source/Assembler-64bit$ |
Die erste Spalte ist ein Multiplier für die vorauseilende Prefetch Adressierung. Also ohne alles: 16½ GB/s Beim ›sweet spot‹ fast 19½ GB/s
Klar P. schrieb: > mit denen die grossen RAM-Hersteller alle "Neu-Einsteiger" "platt machen". > rambus inc. hat ca. 600 Mitarbeiter, micron technologies dagegen 43000 . Man ist nicht automatisch eine David'sche Lichtgestalt, bloss weil man klein ist. Wer sämtliche Goliaths mit Klagen überzieht, sollte keine Küsse erwarten. https://en.wikipedia.org/wiki/Rambus#Lawsuits
:
Bearbeitet durch User
(prx) A. K. schrieb: > Rambus hatte diesen Punkt adressiert, genutzt von den ersten Pentium 4 > Prozessoren. Schneller wars jedoch nicht ... und viel Strom verbrauchte es. Rambus-Module waren die ersten, die mit Kühlkörpern ausgestattet wurden, und das war lange vor der "Casemodder"/"Gamer"-Seuche.
Irgend W. schrieb: > Udo K. schrieb: >> schreibe ein simples Speicherkopierprogram. > "simples Speicherkopierprogramm", der Witz ist gut:-) Schaue dir mal > alle die verschiedenen Funktionen in C/C++ an was da für eine Aufwand > getrieben wird um eine paar Daten von A nach B zu kopieren. Da werden > z.B. die SSE oder AVX Einheiten benutz um die Daten "zwischenzulagern" > damit der RAM-Burst möglichst vollständig genutzt werden kann usw. Das > ist erstmal nur die Daten von einem Speicherbereich in einen anderen > Kopiert. Hier sind die Daten noch lange nicht irgendwie > ver-/bearbeitet... memcpy - mehr brauchst du da nicht. Wie das funktioniert, musst du ja nicht wissen. Falls es dich interssiert - folgenden 10 Befehle sind alles was du auf einer modernen CPU brauchst.
1 | k_memcpy: |
2 | push rdi |
3 | push rsi |
4 | mov rax, rcx |
5 | mov rdi, rcx |
6 | mov rsi, rdx |
7 | mov rcx, r8 |
8 | rep movsb |
9 | pop rsi |
10 | pop rdi |
11 | ret |
> Udo K. schrieb: >> Kiste laufen gerade mal 25 Prozesse%. > Viel interessanter als die Prozesse sind die Threads (kann man im > Taskmanager im Tab Details einblenden). Die entscheiden darüber > wieviele Aufgaben der Scheduler zu verteilen hat. Wie geschrieben, ist die CPU Zeit praktisch <1%. > Udo K. schrieb: >> dass der Speicher nicht langsamer als das RAM ist > Hä? RAM ist doch der Speicher? Unter Speicher meinte ich den effektiven Speicher bestehend aus Cache und RAM. Dieser Speicher ist ein vielfaches schneller als der RAM.
Harald K. schrieb: > (prx) A. K. schrieb: >> Rambus hatte diesen Punkt adressiert, genutzt von den ersten Pentium 4 >> Prozessoren. > > und viel Strom verbrauchte es. Rambus-Module waren die ersten, die mit > Kühlkörpern ausgestattet wurden, Auch Geschwindigkeit hat ihren "Preis", dann muss man eben die Spannungspegel herabsetzen undparasitäre Capazitäten klein halten. Und die Integration (noch mehr schaltende Transistoren auf weniger Fläche) fordert als prinzipbedingter "Hot Spot" auch ihren Tribut. Wer schnell und klein sein will muß eben mehr schwitzen um nicht zu verglühen ...
DRAM-Kühlkörper kenne ich nur von Home-PCs. Nicht von Büro-PCs und Servern, auch keine unbeleuchteten
:
Bearbeitet durch User
Beitrag #7653739 wurde vom Autor gelöscht.
(prx) A. K. schrieb: > DRAM-Kühlkörper kenne ich nur von Home-PCs. Tja, Rambus war da ... äh, "besser": https://upload.wikimedia.org/wikipedia/commons/d/df/RAMBUS-Memory.jpg (Man beachte den "Achtung, heiß"-Aufkleber)
Harald K. schrieb: > (prx) A. K. schrieb: >> DRAM-Kühlkörper kenne ich nur von Home-PCs. > > Tja, Rambus war da ... äh, "besser": > > https://upload.wikimedia.org/wikipedia/commons/d/df/RAMBUS-Memory.jpg > > (Man beachte den "Achtung, heiß"-Aufkleber) Ach, der ist doch nur wegen der US-Schadensersatz-Verklage-Plage drauf, die wir Stella Liebeck zu verdanken haben.;-)
Klar P. schrieb: > das Problem des gemultiplexten > Adressbusses, also das Addressierung über zwei Zugriffe (Row- und > Column-bestandteil) erfolgen muss. Ich dacht, dass dieser Aspekt bei der Angabe der Bandbreite berücksichtigt sei, aber das scheint nicht der Fall szu sein. Oder doch? Ich dachte eigentlich dass ausgehend von der nutzerseitigen Taktfrequenz von z.B. 266 MHz die auf der RAM-Seite vervielfachte Frequenz ausreichen sollte, um die Adress-Zugriffe durchzuführen. Da der Anschluss für den Controller parallel zu den Daten ist, müsste man ohne Verzögerungen den Adressen-FIFO beschreiben können. Mit Command z.B. 2+2 = 4 Zugriffe für einen Burst. Die Daten könnten also seitens der RAM-Riegel ungehindert fließen. Abgesehen eben von Umschaltungen.
Hast Du Dir mal die Mühe gemacht, in ein Datenblatt eines aktuellen DDR(irgendwas)-DRAMs zu sehen?
K. F. schrieb: > (prx) A. K. schrieb: >> Eine Maschine mit vielen parallel laufenden und voneinander unabhängigen >> Prozessen/Threads kann dabei auch helfen. > > Wie? Wie bei HT beschrieben. Windows 95 war auch definitiv schneller (u.a. mehrere FPS bei Quake), wenn man die Auslagerungsdatei auf feste Werte (Min/Max/Gesamtgröße) eingestellt hatte. Einflussmöglichkeiten hat man auch, u.a. ausgewählte Rams, Ramposition auf dem Board, Pärchen, Alignments, Bioseinstellungen..bringt nicht viel, aber wenn man passende Messmethoden parat hat, könnte man Unterschiede finden. https://extreme.pcgameshardware.de/threads/ram-speicherverzoegerung.526832/
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.