> Die Operationen werden mittels »in-cache-processing« im Cache des Prozessors ausgeführt, der Hauptspeicher wird nur noch als Puffer für die Ein- und Ausgabe der Daten verwendet. Inwiefern unterscheidet sich dieses Vorgehen von den heutigen Datenbankengines? Meint man mit "Cache" die einzelnen Register der CPU?
Perfekt danke. War wohl etwas blind. 1 MB ist in der Tat nicht wirklich viel bei den Datenmengen, die heutzutage anfallen. Unter Linux gab es mal einen Treiber, um direkt in den Cache zu schreiben. Der lag dann in /dev/sram. Weiß jemand, was daraus geworden ist? Ein Modul namens "sram" gibt es hier nämlich nicht mehr.
"viel hilft viel" ist bei cpucache leider NICHT per definition gültig. denn für cache gelten andere regeln als für arbeitsspeicher. der arbeitsaufwand, cache zu verwalten, ist ungleich höher als beim systemram.
Nee, die Register benutzt du, um Parameter an die CPU-Operationen zu übergeben. Der Cache ist was ganz anderes. Prinzipiell hast du Register und Arbeitsspeicher. Da schneller Speicher sehr teuer ist, gibt es davon nur sehr wenig. Diesen nennt man auch Cache und i.d.R. ist dieser direkt im Prozessor integriert, damit der Zugriff besonders schnell ist.
BTW: Die Register sind noch schneller als der Cache und moderne Prozessoren mit SSE etwa haben sehr viele Register.
Besteht die Möglichkeit, dass man hohe Register, die sonst von niemandem genutzt werden (Linux-Calls bspw.), für sich reserviert und darin Daten persistent speichern kann oder werden die von einer Art Garbage Collection in Linux automatisch gelöscht, sobald das ASM-Programm beendet wird? Fragen über Fragen.
Ja, vom Prinzip her schon. Wie du garantieren willst, dass dir die keiner überschreibt ist aber eine andere Frage. Eine Garbage-Collection oder so gibt es dafür übrigens nicht, die Sachen werden einfach überschrieben. Letztendlich ist das nicht soo das Problem, schließlich räumt der Scheduler im Kernel sowieso die ganze Zeit die Register um, damit der nächste Prozess wieder in seinem Zustand ist.
Wie dem auch sei, Compiler (ob statisch oder just-in-time) versuchen eigentlich auch genau das zu erreichen. Nämlich dass deine Daten immer im schnellsten Speicher sind. Es gibt auch den Begriff Cache-Misses, d.h. wenn der Speicher im Cache nicht reicht und sachen ins RAM verschoben werden müssen.
Noch eine Anmerkung... Wenn kein Programm die hohen Register benutzt, du etwa keine SSE- oder MMX-Programme benutzt und keinen entsprechenden Kernel; prinzipiell sollten die dann in Ruhe gelassen werden...
Was MySQL fehlt ist eine build-in Such-Engine fur InnoDB. Solange dieser Mangel besteht bleibe ich bei PostgreSQL. MyISAM hat noch viel mehr Mangel wie fehlende Transactions schlechte Skallierung,... ist also keine Lösung.
> Die Operationen werden mittels »in-cache-processing« im Cache des Prozessors ausgeführt, der Hauptspeicher wird nur noch als Puffer für die Ein- und Ausgabe der Daten verwendet.
Inwiefern unterscheidet sich dieses Vorgehen von den heutigen Datenbankengines? Meint man mit "Cache" die einzelnen Register der CPU?
unter cpuMHz
BTW: Die Register sind noch schneller als der Cache und moderne Prozessoren mit SSE etwa haben sehr viele Register.
Bei "Hardened"-CPUs läuft aus Sicherheitsgründen vorher noch eine Vollbitverschlüsselung drüber.
Wie dem auch sei, Compiler (ob statisch oder just-in-time) versuchen eigentlich auch genau das zu erreichen. Nämlich dass deine Daten immer im schnellsten Speicher sind. Es gibt auch den Begriff Cache-Misses, d.h. wenn der Speicher im Cache nicht reicht und sachen ins RAM verschoben werden müssen.
genau