Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Pro porovnání jsem to zkusil pustit na RAM disku v RAM, co používám na dočasný bordel, a výsledek byl 26 GB/s a 33GB/s. Použit imDisk, R7 7840u, LPDDR5x-6400.
Tohle je samozrejme totalni nesmysl :). Myslim tim RAMDisk ve V-Cache. Vzhledem k principu fungovani te cache nejde urcit, kam se ty data fyzicky umisti. V tomto pripade akorat ta cache urychluje praci s RAMDiskem pri opakovanych pristupech. Pokud byste tam neco nahrali a pristoupili k tomu az za delsi dobu, tak se zadne zrychleni konat nebude...
"Pokud byste tam neco nahrali a pristoupili k tomu az za delsi dobu, tak se zadne zrychleni konat nebude..."
Proč ne? Ty nahrané soubory do RAM disku přeci stále budou umístěné ve V-Cache. Dokud je nesmažete nebo nerestartujete počítač, tak nezmizí.
Prave ze nebudou. V-Cache uz tou dobou bude cachovat uplne jine veci (ty, ke kterym bylo pristoupeno nedavno) a obsah RAMDisku bude pouze nekde v RAM. Proste je to "jen" cache pro celou RAM. Nelze na ni nic napevno alokovat.
Aha, tak podle místního článku mně přišlo, že ten OSFMount umí alokovat přímo V-Cache. Ale podle zdrojového článku dělají klasický RAM disk v RAM, který pak má ty vlastnosti, jak tvrdíte - tedy nestálé zrychlení díky automaticky plněné V-Cache.
Při pozorném čtení (na screenshotu CrystalDiskMarku) si je možné všimnout, že RAMDISK měl kapacitu cca 512MB, tj. podstatně více než velikost L3 cache (96MB). Velikost testovacího souboru byla 32MB, kterážto měla šanci na pro-L3-cacheování.
Tak i jen tu je jasné, jak to bylo, omlouvám se za nepozornost. Jen mně pak nedává moc smysl ten poslední odstavec s omezenou velikostí :-)
Těžko říct. Aplikací s takto omezenými datasety (řádově MB), které nebudou pracovat v in-memory režimu (tj. s daty přímo dostupnými v paměti tj. bez průběžného přístupu skze IO API) bude patrně minimum, pokud vůbec nějaké. Nakonec i in-memory aplikace budou úměrně profitovat z dosaženého cache-hit-ratio.
Dobry postreh, pretoze cache sa v rannych fazach behu procesora pouzivaju ako RAM. Je to dane tym, ze kym sa nenatrenuju radice DDR, "externa" RAM nie je pristupna. Cache su ale na procesore a tam nic trenovat netreba.
Tak nejako som predpokladal, ze existuje sposob, ako V-cache prepnut na namapovany region RAM, ktory sa neprekryva s existujucou RAM aj neskor, pocas behu OS.
Tohle šlo u některých serverových Intel CPU.
HBM na čipu šlo nastavit do režimu paměť nebo LLC/SLC.
32 MB je ideál na Dosbox. M602 by sa na tom spustil mrknutím oka.
Mrknuti oka trvá údajně 250ms, za což by to měly dát i běžné HDD. ;-)
Tak také Duke3D sa mi spúšťa cca 21s pri 1,7 GHz (Dosbox nastavený na 79700), tak tá hra spustená v 3D cache by už mohla byť rýchlejšia ak by ju nebrzdil CPU. Alebo vo Virtual Boxe.
Značná část zpoždění půjde patrně na zpracování (dekompresi?) herních dat do RAM. IO-based zpoždění bude asi minimální.
V dávno minulých dobách DOS provozovaném na reálném železe, jsem obětoval 16MB na Ram Disk a spoštěl z něj .. Death Ralye
Samotnou hru to sice nezrychlilo (naštěstí), ale doby načítání kdečeho to v porovnání s HDD zrychlilo .. hodně.
Hezké vzpomínky.
Zazraky vedelo urobit uz proste zavedenie diskovej cache. Potom clovek bojoval, ci bude mat spusteny smartdrive, alebo si spusti ten program, ktory so smartdrivom nadava, ze "Program is too big to fit into memory".
Presne. Aj inštalácia W98 s a bez smartdrv.exe je nebe a dudy.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.