MichiLH schrieb:
Das gebetsmühlenartige Wiederholen von drei Fachtermini tilgt nicht die fehlende technologische Plausibilität deiner Argumentation. Des Weiteren, selbst bei ignorieren der Technologie, stützt die Empirie deine Thesen ebenfalls
nicht, denn Flashspeicher müsste - wie bereits erläutert - eine
signifikant höhere Wachstumsgeschwindigkeit (bei der Bandbreite) im Vergleich zu DRAM aufweisen und dies langfristig. Jenes hatte Flashspeicher aber noch nie.
Schon eine einfache Regressionsanalyse auf den Wachstumsraten der Speichertechnologien zeigt den Mangel an Evidenz deiner These auf, denn die Steigung (bei der Bandbreite) von Flashspeicher müsste eben - wie gesagt - deutlich höher sein als bei DRAM und dies langfristig um in Zukunft zu einer sinnvollen Substitution zu werden.
...und selbst wenn man bisherige Entwicklungsgeschwindigkeiten
und die Technologiehürden
ignoriert, ist da immer noch das Preis-/Leistungsverhältnis. DRAM mit hoher Bandbreite und sehr niedrigen Latenzen lässt sich günstiger produzieren. Sofern nicht gänzlich neue Fertigungswege beschritten werden - da dieser Umstand an der Fertigung selbst liegt - wird sich auch dies zukünftig nicht signifikant zu Gunsten von Flashspeicher ändern.
Nichtsdestoweniger, selbst wenn ich
all diese Einwände (und die der Anderen)
außen vor lasse, kann ich deine Argumentation nicht nachvollziehen. Man kann TLB (ich meine da mal im Tanenbaum was von gelesen zu haben), sofern das wirklich zum Flaschenhals wird, doch relativ einfach (wenn man denn will) mit einem größeren Assoziativspeicher versehen, sodass der Buffer einfach mehr virtual -> physical Adressen parat hält.
Unabhängig davon reserviert sich performancekritische Software, z.B. AI Experimente (bastel ich selbst), zu Beginn der Kalkulation große physische Adressbereiche und arbeitet dann die ganze Zeit damit...also sehr low-level.
Natürlich zieht der Aufbau von neuen Adressen für die TLB viel Ressourcen, aber wo limitiert denn da herkömmliche Software heutzutage tatsächlich?
Beim Paging wüsste ich jetzt im Übrigen nicht, warum das durch SSDs so viel komfortabler/besser werden sollten?!
Das man Scheduling besser lösen kann...normalerweise kann man alles besser lösen, wenn man nur genügend Ressourcen dafür einsetzt. Das ist aber auch schon der Knackpunkt.
Die Frage ist außerdem, wie viel besser. Beweise zu Scheduling sind bei mir schon etwas her, aber es gibt ja durchaus Approximationsalgorithmen, die bei vertretbarem Aufwand, meistens greedy, eine relativ gute Auslastung hinbekommen. Ein perfektes Scheduling ist häufig NP-schwer, sodass es gar keinen Sinn machen würde, in diese Richtung zu entwickeln, da die Aufteilung der Prozesse für ein perfektes Scheduling dann unter Umständen schon mehr Zeit frisst, als die Prozesse selbst an Arbeitszeit verschlingen.