Vlákno názorů k článku
Firefox 4.0 navyšuje velikost diskové vyrovnávací paměti
od huhuhu - Nie je to zbytocne vela pri dnesnych rychlostiach...
-
Karel (neregistrovaný)
Aha, takže než něco najít v cache na mém disku (řádově desítky milisekund) je podle vás rychlejší poslat dotaz po internetu na server, ten to najde ve své cache a data mi pošle? Asi toho o internetu a HW moc nevíte :-) Předpokládám, že když si vybíráte procesor, tak také chcete nějaký model, který nemá cache, protože je přeci rychlejší číst instrukce přímo z paměti místo zdržovat se nějakým hledáním v cache :-) Zkrátka, hrubě jste nepochopil fungování cache. Zjevně si to představujete jako změť souborů na disku a vyhledávání v ní si představujete jako zkoušení každého jednoho souboru, zda to není on. Jenže to není cache a ani by to nefungovalo (jak chcete zjistit, jestli je to ten správný soubor?) Základem cache je asociativní tabulka, která si pro každý klíč pamatuje hodnotu. Tedy například si pamatuje že „http://root.cz/obrazek.gif“ je uloženo v souboru abc.gif. Tato tabulka je velmi malá (řádově desítky až stovky kilobytů) a její kopie je neustále v paměti. Pro hledání v cache tedy na disk vůbec nechodíte. A věřte tomu, že váš HDD nemá problém přečíst desítky až stovky malých souborů za sekundu, zatímco vaše internetové připojení s tím bude mít dost zásadní problém. Přesněji řečeno, vystavovací doba vašeho HDD je řádově jinde než váš ping.
-
Karel (neregistrovaný)
Cache je asociativní tabulka. Ta se neprohledává. Bohužel řada lidí toto neví a cache si představují jako šuplík u stolu, kam házím věci a když potřebuji, tak šuplík prohledám a věci možná najdu. Jenže taková věc by třebas u procesoru byla silně na obtíž. Proto cache vždy obsahují asociativní pole, kde pro zadaný klíč ihned vím, zda to v cache mám (a kde), nebo ne. Hashovací tabulka je jedna z nejčastějších implementací cache – spočítám hash a ten použiji rovnou jako index do pole. Žádné vyhledávání, jdu na jisto. Na hledání není čas.
-
Honza (neregistrovaný)
Závidím Vám 200Gb/s připojení k internetu srovnatelné s rychlostí čtení z pevného disku. Pro běžná připojení v řádech jednotek Mb/s je cache zcela zásadní.
Naopak si myslím, že 250MB je při dnešních velikostech disků a objemu multimediálního obsahu na internetu extrémně málo. Klidně by tam mohli jako výchozí hodnotu nastavit nějaký ten gigabajt.
Já osobně prosurfuji minimálně 1GB za den. Kdybych měl cache jen 250MB, postrádala by smysl, protože by se přepsala během pár hodin. -
huhuhu (neregistrovaný)
Ak to bol preklep a malo tam byt 200 MB/s, tak to je tiez obrovske cislo pre rychlost disk.
Bezne desktopove PC moze dat 30, max 40 MB/s pri citani SUVISLEHO velkeho bloku dat.
Cache s velkostou 250 MB moze znamenat milion malych suborov ⇒ pre HDD s rotujucou platnou a pohyblivou citaciou hlavickou velky vykonnostny problem pri hladani jedneho maleho objektu v cache. -
to by mě zajímalo, jak si představujete jít na jisto.
když před Vás někdo položí mísu s tisícem a dvaceti třemi červenými a jednou modrou kuličkou, tak Vy se podíváte, možná hrábnete a „pujdete na jisto“ a vyberete tu modrou, ale zkuste si to naprogramovat. Nechť máte množinu záznamů o requestech, které jsou uloženy v cache, jak najdete ten záznam, který přísluší Vašemu requestu.
hledání v cache (podle Vás zcela na jisto) si představuju tak, že se najde a otevře(nebo použije otevřený) soubor s posloupností záznamů o uložených objektech v cache(vždycky jsem se divil, že k haváriím těchto záznamů dochází tak málo často, jen při scrashích počítačů). Sekvenčně se vyhledá záznam který odpovídá requestu, který se má provést. Zřejmě se ale využívá nějaký sofistikovaný způsob jak ten záznam najít rychleji než porovnávat záznamy jeden po druhém.
V případě, že se záznam našel, podle aktuálního času a vlastnostech objektu uloženého v cache se může odeslat na server dotaz, zda-li existuje novější verze.(Odešle aktuální ETag data uloženého v cache a server vrátí „304 Not Modified“ nebo nová data) a případně se najde soubor s daty.
já tomu asi nerozumím, protože nevím, kde by se v takovéto situaci dalo chodit na jisto. -
„Sekvenčně se vyhledá záznam který odpovídá requestu, který se má provést. Zřejmě se ale využívá nějaký sofistikovaný způsob jak ten záznam najít rychleji než porovnávat záznamy jeden po druhém.“
Nikoliv. Najdi si info o hashovací tabulce a algoritmech a případně si ji zkus naprogramovat. Složitost čtení položky je O(1) (konstantní), nic se (lineárně ani logaritmicky) neprohledává.
Do cache se opravdu jen sáhne pro odpovídající záznam.
-
Bilbo (neregistrovaný)
30 MB/s? To mozna tak notebookove disky… Dnesni nove desktopove disky (7200 otacek, kapacita radove 500 GB a vic) maji pri cteni souvisleho bloku dat rychlost tak 100–130 MB/sec.
Jinak cache v objektech nehleda, prohlizece maji v cache navic i jeden soubor s indexem se zaznamy typu:
„http://www.root.cz/“ = „soubor12345“
Ten index pak je i v pameti, takze pri pozadavku na danou url proste nactou primo dany soubor. Je to rychlejsi nez to tahat ze site, ledaze by nekdo mel extremne rychlou sit a k tomu hodne pomaly disk.
Navic prohlizece maji i dalsi (obvykle mensi) cache primo v RAM, takze nekdy nemusi ani lezt na disk. -
Dva roky starý Samsung F1
hdparm -tT /dev/sda /dev/sda: Timing cached reads: 12032 MB in 2.00 seconds = 6021.64 MB/sec Timing buffered disk reads: 282 MB in 3.00 seconds = 93.91 MB/sec
Rok starý Seagate 7200.12
hdparm -tT /dev/sde /dev/sde: Timing cached reads: 11960 MB in 2.00 seconds = 5986.62 MB/sec Timing buffered disk reads: 354 MB in 3.01 seconds = 117.68 MB/sec
Běžné levné SSD (Kingston SSDNow V+), Crystal Disk Mark (mám to na Windows, čtení/zápis):
220MB/s 103MB/s
