Dávám Windows šanci aneb Vista z pohledu Linuxáka [6] (diskuse)

[alvyn]

Zdravím, díkes za pěkné víkendové čtení. Jelikož jsem si na začátku týdne kupoval nový PC a vzal jsem i Vistu hodí se mi ještě daleko víc. Jinak, čekal jsem hrůzné věci, ale nakonec se nedějou. Jsem docela příjemě překvapen. Ten systém celkem funguje :) No nic, jdu si na druhou partišnu instalnout suse, ale nějak jsem zatím neměl potřebu ten linux mít.

[Luk]

Hodnotit těžko, když Linuxu chybí protikus.Vista má zkrátka velký plus za krok správným směrem při řešení jednoho z nejnepříjemnějších úzkých hrdel současných systémů.

V Linuxu se vyskytuje nanejvýš (v některých distribucích) to, že se přednačtou soubory ze staticky definovaného seznamu. Čili i když používám KDE, nachroustají se tam kvanta dat pro GNOME apod., která vůbec nebudu potřebovat. Už jsem se o zmiňoval ("Chytrý přednačítač") o tom, jak hodně je potřeba to vyřešit. Do jisté míry se to také řešilo tady, ale reálné výsledky nevidím.

[Josef Kufner]

V Linuxu to lze do jisté míry vyřešit ručně ramdiskem (tmpfs). Ale není to ono. Možná nějak logovat přístupy pomocí inotify a pak to zanalyzovat a nakešovat automaticky... (to by nevyžadovalo zásah do jádra).

[Luk]

Ono jde v podstatě o jediné: najít a implementovat vhodný algoritmus, podle kterého by se vyhodnocovalo, jaká data kdy načíst do paměti. Pokud by se pracovalo s granularitou na úrovni souborů, nevyžadovalo by to zásah do jádra. Ovšem pokud by to mělo být srovnatelné se SuperFetchem, tedy na úrovni bloků, už by se to bez patchování jádra neobešlo.

[Josef Kufner]

No ono by to chtělo zpřístupnit do userspace nějaké nastavování priority kešovaných souborů. Pak by nějaký démon jen analyzoval a říkal jádru něco jako: "Tenhle soubor si nech v paměti, tenhle ne a tamhleten, když zbyde místo".

[Josef Kufner]

Tak mě tak napadá, že pokud by tu byl někdo, kdo se trošku víc zajímá o jádro, mohl by to nadhodit v LKML. Třeba se toho někdo chytne. Přecejen, tohle API by nemuselo být nijak veliké a ani celkově by to nemusel být nijak velký zásah do existujících algoritmů...

[Luboš Luňák]

V (nejen) LKML to uz bylo nahozeno tak asi milionkrat. Dokud to nekdo neudela a nedotahne to do konce, tak nahazovani muze byt treba i lopatou a nic. Bohuzel.

[Luk]

Bohužel je to tak. Požadavků jsou mraky a lidí málo. Dělá se to, co nejvíc hoří, a například ovladače různých zařízení mají rozhodně vyšší prioritu než něco, co "jen" zvedá výkon.

[Martin Tůma]

Vůbec se nedivim, že se do toho nikomu nechce, když to s příchodem "masově použitelnejch" SSD disků již brzy prakticky nebude potřeba.

[Michal2]

Aneb proc resit cokoliv kdyz stejne vsichni pojdeme?

Pokud si myslis, ze v dobe SSD disku nebude cache zapotrebi tak se asi pletes. Soucasne SSD disky maji porad o vice nez dva rady nizsi propustnost nez pamet a radove pomalejsi pristupovou dobu. S tim mozna pujde nejak hnout ale od 300MB/s se narazi na limitaci SATA2. A pak uz jen takova drobnost v podobe ceny ~250Kc/GB. I pri poklesu na polovinu kazdy rok se to na pouzitelnou hladinu dostane za 4 roky.

[Luk]

Byls rychlejší Problém se SATA2 bych neviděl, do té doby vzniknou rychlejší sběrnice (nehledě na to, že SSD může být třeba i přímo na kartě připojované do PCI Express).

[Michal2]

Adaptace nove sbernice, to je plan na nekolik let. Vyjdou desky, vyrobci disku nechteji pouzit rozhrani, ktere ma jen par lidi atd. Uzivatele krouti nosem protoze kvuli instalaci stavajicich OSu na takovy disk je treba delat psi kusy... Nez se kolotoc roztoci jsou minimalne 2 roky fuc.

S tim PCIe to take nevidim prilis slavne. Vyrobci se takovemu reseni brani jako cert krizi. A neni divu. Museli by napsat podporu nejakeho noveho rozhrani do systemu coz asi nebude trivialni ukol. Kolik radku kodu ma libsata v jadru Linuxu a jak dlouho trvalo to napsat a odladit?

[Martin Tůma]

Pokud si myslis, ze v dobe SSD disku nebude cache zapotrebi tak se asi pletes

Rozhodně si nemyslim, že bude zbytečná cache. Ale prefetch™ tak jak je dneska znám z Vist, tzn. odhad, dle nějakého "magického" algoritmu co by asi tak uživatel mohl chtít spustit.

V linuxu jsou mnohem horší "Achilovy paty", co se týče desktopu, například katastrofálně pomalé (co se "reakční doby" týče) gtk, které by potřebovaly vylepšit, prefetch je až to poslední co hoří*. Ono totiž existují tři scénáře využití aplikace:

1. Aplikace jednou spuštěná, která dále běží po celou dobu "sezení" uživatele (WWW browser). Zde prefetch pomůže, ale uživatel většinou první delší načítání "skousne". Většinou lidi tyto aplikace startují ihned po přihlášení, takže je otázka jestli vůbec na prefetch stačí dojít. Při použití SSD se navíc doba spuštění o dost přiblíží startu "z cache".
2. Aplikace neustále spouštěné dokola, otevírání dokumentů vždy se spuštěním aplikace (známé otevírání "poklikáním na ikonu dokumentu") - tohle řeší obyčejná cache s LRU. (první spuštění viz 1.)
3. Aplikace spouštěné ve speciálních případech - tady ani prefetch nepomůže

* než si tady zase nějakej "linuxák" začne otvírat hubu, jak jemu na jeho "hyper ultra mega" stroji běží v linuxu i Firefox krásně rychle, poznamenám, že spravuju firemní linux síť s ~30PC, reálným HW, a naprostými BFU uživateli, takže mám velmi dobrou představu o tom, co na linuxovém desktopu nejvíc hoří (tzn. na co uživatelé nejvíce nadávají a argumentují při tom: "Ale ve Windows...").

[Luboš Luňák]

> prefetch je až to poslední co hoří

No rozhodne to neni to posledni. Vykonnostni I/O problemy zpusobuji asi ztrojnasobeni doby startu KDE a zhruba ve stejnem stylu to bude i pri spousteni aplikaci a tak podobne. A co je jedna z hlavnich veci, na co si uzivatele u KDE stezuji? Spravne, ze vsechno se spousti moc dlouho.

[miho]

Algoritmus není magický nýbrž statistický a funguje docela dobře pokud není chování uživatele zcela nepředvídatelné. V takovém případě by nepřinesl sice žádný užitek, ale ani žádnou škodu. Plus vždy je možnost to vypnout. SSD bych ale teď neřešil, to se dostane do mainstreamu tak za tři-čtyři roky pro systémový disk. Pro datový kdoví kdy. Skuste zákazníkovi říct: no mys sice známe řešení jak váš problém (pomocí chytrého řešení) alespoň částečně řešit. Když ale za čtyři roky tady bude lepší (založené na brute force) řešení tak my to dělat nebudeme. Co asi řekne?

[happy barney]

koľko užívateľov má multiuser systém ? Kto a za akých podmienok by mal mať prioritu pred ostatnými ?

[Luk]

Jak to s tím souvisí? Vždyť se to přece nehodnotí per-user, ale v rámci celého systému. Je to úplně stejné jako např. plánování úloh na procesor nebo využití normální diskové cache.

[Ignor]

A pak uz jen takova drobnost v podobe ceny ~250Kc/GB.

Takže budou asi malé. Pak se teda bude muset řešit úloha, které soubory dát na rychlý disk a který na velký disk (a kdy...). Co mi to připomíná?

[Luk]

Ono to bude ještě chvíli trvat, než budou SSD přijatelně levné, aby mohly plně nahradit klasické mechanické disky. Masový přechod na SSD nevidím dříve než v horizontu 4-5 let (což je ve vývoji OS zatraceně dlouho, za tu dobu byly některé věci v kernelu i několikrát totálně překopány).

Ale i tak pořád zůstává rozdíl v rychlosti, který se hned tak nepodaří srovnat - zatímco nejlepší SSD jsou dnes někde na úrovni 100 MB/s, operační paměti se pohybují o dva řády výše (okolo 10 GB/s). Proto ještě dlouho bude mít taková optimalizace smysl.

[trekker.dk]

Teď se na LKML ohledně tohohle objevila krásná myšlenka - vývoj jádra neurčují ti, co mluví o tom, co by rádi v jádře viděli, ale ti, co posílají patche.

Jinak řečeno, chceš přednačítání, napiš si ho sám, zaplať někomu, ať to udělá nebo někoho přesvědč.

[miso]

Mne to velmi "krasne" nepripada

Skor je to vystizny postreh

[trekker.dk]

Zajímavým nástrojem v této kategorii je "Sledování výkonu". Umožňuje vynést do grafu libovolný počet z mnoha možných sledovaných číselných hodnot (čítačů), sledovat maximum, minimum a průměr dané hodnoty. Množství sledovaných hodnot je vskutku impozantní, od sledování zatížení procesoru přes počet zavedených tříd v .NET runtime, procentuální úspěšnost diskové vyrovnávací paměti až po počet odeslaných Echo zpráv přes ICMPv6.

Mám pocit, že něco podobného v menším provedení bylo již ve Windows 95 nebo 98. V XP jsem to neviděl, zdá se, že to zase vzkřísili.

[Heron]

V XP to je taky. Tohle je nástroj už od dob NT.

[trekker.dk]

Aha, tak jsem to jenom nenašel...

[Heron]

Start / Administrative Tools / Performance, případně Start / Control Panel / Administrative Tools / Performance

[filo]

Díky za článek, ač Vistu nepoužívám, tak se na každý díl tady na ABC těším, pěkně se to čte.

[Josef Kufner]

Jj, je to zajímavý a střízlivý pohled k sousedům...

[skeptik]

+1

[rADOn]

• Superfetch je jiste fain ale rekl bych ze pripojeni tmpfs do /tmp a spravnej IO planovac resi plusminus to samy. ano, nekesujou se tak hezky binarky ale to AFAIK ani ve vistach uz moc ne pacz si tam kazda app muze drzet vlastni instance dllek.
• Sledovani systemu by byl _skvelej_ nastroj kdyby k dostupnym senzorum byla kvalitni dokumentace. Takhle je to na draka, casto clovek hledanim vyznamu nejakyho podivne pojmenovanyho senzoru stravi vic casu nez hledanim samotny chyby. Casto kvantita dostupnych senzoru prevysuje kvalitu merenych hodnot (cti: spousta balastu) ale to zalezi na app, treba pri ladeni vykonu SQLserveru jsou nektery senzory opravdu k nezaplaceni.

Jinak moc peknej zapis, bude taky neco o eventlogu ? V predchozich widlich me srdecne sral, docela by me zajimalo jak se zlepsil.

[Luk]

Superfetch je jiste fain ale rekl bych ze pripojeni tmpfs do /tmp a spravnej IO planovac resi plusminus to samy. ano, nekesujou se tak hezky binarky ale to AFAIK ani ve vistach uz moc ne pacz si tam kazda app muze drzet vlastni instance dllek.

To není pravda. Kvalitní I/O plánovač je samozřejmost, o tom není třeba diskutovat. Ale problém neřeší. Neřeší ho ani použití tmpfs, protože mnoho programů vůbec s dočasnými soubory nepracuje. Největší brzdou je načítání mnoha malých souborů, zejména pokud jsou rozcourané po disku. Tam by chytré přednačítání mohlo výrazně pomoci - zejména tam, kde je po startu velká část paměti nevyužitá a mohla by se bez problémů využít právě k přednačtení souborů, které budou v nejbližších chvílích použity.

[Kvakor]

Největší brzdou je načítání mnoha malých souborů, zejména pokud jsou rozcourané po disku. Tam by chytré přednačítání mohlo výrazně pomoci - zejména tam, kde je po startu velká část paměti nevyužitá a mohla by se bez problémů využít právě k přednačtení souborů, které budou v nejbližších chvílích použity.

To by slo realizovat i bez sahani do jadra, stacilo by jen sledovat syscally open, read a mmap (myslim, ze tyhle tri staci, nebo ne?), pripadne pres preload knihovny zahakovat jim odopvidajici funkce z libc. Pak je treba jen udaje ulozit, vyhodnotit a podle nich pri staru nekde v initscriptech spustit demona, co bude mit nizkou I/O prioritu (pres ionice -c 3) a seznam souboru, co proste jen otevre a precte, pripadne seznam rozsahu odkud-pokud ma soubor precist.

[Luk]

To by slo realizovat i bez sahani do jadra, stacilo by jen sledovat syscally open, read a mmap (myslim, ze tyhle tri staci, nebo ne?), pripadne pres preload knihovny zahakovat jim odopvidajici funkce z libc.

To nestačí. Např. při použitím mmap() by to sledovalo jen samotné namapování, ale už ne skutečné využití (tj. kam to doopravdy sahá). Nehledě na řadu dalších volání. Pokud bych chtěl sledovat jen přístup k souborům, stačilo by využít inotify - bez nutnosti kamkoliv hrabat. I když nevím, jaké by to mělo výkonnostní dopady, protože by to znamenalo vytvořit na každém adresáři v systému jeden watch. Někdy to zkusím změřit.

Pak je treba jen udaje ulozit, vyhodnotit a podle nich pri staru nekde v initscriptech spustit demona, co bude mit nizkou I/O prioritu (pres ionice -c 3) a seznam souboru, co proste jen otevre a precte, pripadne seznam rozsahu odkud-pokud ma soubor precist.

Takového démona už někde mám, ale je (stručně řečeno) k prdu. Aby to mělo smysl, musí takový démon fungovat dynamicky, tedy na základě dat, které má k dispozici, volit v reálném čase soubory k přednačítání (např. vědět, že když si spustím nějaké IDE, tak za chvíli budu potřebovat gcc). A to není vůbec triviální a jde o jádro celého pudla.

[Kvakor]

Hmm, to by bylo opravdu netrivalni. Ja mel na mysli jenom prednacitani pri startu - pokud napr. nekdo po startu hned spusti nejakou aplikacei, co se nacita relativne dlouho, napr. OpenOffice, tak by se mu spustily stejne rychle, jako kdyz by je pred tim spustil a zase ukoncil. Napr. u onech uz zminovany OO je to u mne 9 sekund pri startu napoprve vuci trem sekundam pri startu naporuhe. Pro nekoho, kdo ma dost pameti, ale pomaly disk (typicky pripad na noteboocich), by to znamalo usporu casu, ktera by byla temer "zadarmo".

Ale prednacitat dat podle toho, co uzivatel dela, to je problem, na jehoz reseni je treba opravdu sofistikovany algoritmus. Ten by musel odhadovat, co uzivatel dela (mozna by musel dokonce chytat i udalosti z mysi a klavesnice) a podle toho dynamicky volit akce. Takovy algoritmus by musel mit prvky umele inteligence a schopnost uceni se ze sbiranych dat, navic by se musel ucit "opatrne", protoze nikdo by prece nechtel neco, co by mu pri spusteni mp3 prehravace zaclo nacitat do pameti vsechny mptrojky, co najde na disku .

[rADOn]

Kvalitní I/O plánovač je samozřejmost, o tom není třeba diskutovat.

Proto jsem psal spravny a ne kvalitni, jeden planovac tezko bude optimalni pro vsechny typy zateze. Takze co jsem tim mel na mysli nebyl jeden nejlepsi™ planovac ale moznost vybrat si.

Největší brzdou je načítání mnoha malých souborů...

Stejny pripad - zalezi na vyberu, tentokrat filesystemu. Tahle moznost me ani nenapadla, uz jsem moc dlouho mimo widli eko(no)system abych vyber filesystemu povazoval za neco mimoradnyho.

Vzato kolem a kolem, cim vic to tady ctu tim vic mam pocit ze superfetch bude pro widle velky zlepseni ale ze je to jen skryvani priznaku a ne reseni zdroje problemu.

[Heron]

Stejny pripad - zalezi na vyberu, tentokrat filesystemu.

No to ani ne. Pokud hlavička disku bude poskakovat po plotně - protože pořadí načítání jednotlivých souborů je jiné, jako jejich uspořádání na disku - tak každý FS pohoří. Najít uspořádání dat na disku tak, aby vyhovovalo všem situacím je v podstatě nemožné. V podstatě by to šlo částečně řešit změnou API tak, že OS dostane od aplikace seznam souborů, které daná app bude potřebovat - namísto součastného otevířání po jednom - a OS už ví, jak jsou ty soubory na disku a v tomto pořadí je může načíst.

[rADOn]

Pokud hlavička disku bude poskakovat po plotně - protože pořadí načítání jednotlivých souborů je jiné, jako jejich uspořádání na disku - tak každý FS pohoří.

... a prave proto maji filesystemy pro pevne disky veci jako interni cache, readahead buffery a antifragmentacni algoritmy. Mozna se to bude zdat neuveritelne, ale vyvojari filesystemu nejsou az TAK pitomi.

[Luk]

Ale i tak - když disk během startu programu musí udělat jen 100 seeků po pouhých 10 ms, už je to vteřina navíc. V praxi to leckdy bývá mnohem horší.

[happy barney]

štart nie je podstatný, aplikácie spúšťam tak raz mesačne (napr. Seamonkey), popr raz za reboot (3-12 mesiacov, napr. xemacs)

podľa mňa sa snažíte vyhnúť sa dôsledku, a nie príčine.

[Ignor]

No, nevím jestli člověk, co vznáší argumenty jako "koľko užívateľov má multiuser systém?" může zároveň napsat "štart nie je podstatný, aplikácie spúšťam tak raz mesačne (napr. Seamonkey), popr raz za reboot (3-12 mesiacov, napr. xemacs)" bez ztráty tváře

Nějak si nedovedu představit, že bych se např. před odchodem z počítačové učebny neodhlásil. Ale dejme tomu, že bych byl tak odvážný. Jak by se asi systém popral s těmi tisícovkami spuštěných a odswapovaných aplikací, se stovkami uživatelských sezení?

[happy barney]

chcel som tým poukázať na dlhovekosť aplikácií, ktoré navyše otvárajú veľa súborov málo krát.

ad druhý odstavec ... oddeliť aplikačné data od aplikácií

[miho]

Filozofie práce na desktopu, to je zase téma na celý článek. Naprostá většina lidí ale takovýmto způsobem nepracuje- aplikace, zejména ty velké, ukončuje.

Jak ale píšu v každém dílu- máš možnost si sám podle sebe určit váhy. Pokud ti po roce na pozadí běží X her, Y kancelářských balíčků, Z vývojových prostředí, P grafických programů..., tak si tam dosaď nulu.

[happy barney]

z môjho pozorovania je to záležitosť virtuálnych screen-ov. Ak ich človek používa, väčšinou neukončuje, ak ich nemá (napr windows), väčšinou zatvára

[Mandarinka]

?

APlikace, používané na tomto strojku (a hrubá spotřeba RAM v MB): Bentleyview: 120 Allplan: 150... až dejme tomu 300 Firefox: No, znáte to; navíc počítejte s tím, že se někdy třeba načítají pluginy jako quicktime X( Word, Excel 2000 obojí kolem 25 mB, tuším Winamp: 20-50 (hodně závisí na velikosti souboru) Freecommander: 20 7-zip: 20 Scannersoft: 20 XnView: 50-100 (i víc, záleží na tom, jak moc se těma fotkama hrabete a kolik zůstává přednačteno) IE7: jako firefox VLC, SMPlayer,BSplayer: vše kolem 30 OpenOffice: 150 a víc Acrobat Reader 100+

Stroj má 1 GB paměti. Nemyslíte, že kdybych všechno pořád nechával otevřené, tak bych se nedostl do problémů (i s 2 GB)? Měl bych nehoráznou spotřebu swapu; zaneřáděný taskbar... A proč to všechno? Navíc když by se nějaký program rozhodl říct si o řekněme 100MB paměti (například spuštění nějakého programu mimo standard), tak by to chvilku trvalo...

[Luk]

Příčinou problémů je pomalost disku (především pomalost přesunu hlav). Nejlepším řešením by bylo disk nahradit něčím lepším (např. SSD), ale to v současné době není cenově přijatelné (zhruba 100 Kč/GB oproti 4 Kč/GB u disků). Zatím to tedy musíme řešit jinak, a to různými optimalizacemi. A jestliže je v systému k dispozici operační paměť, která není využita, proč ji nevyužít k tomuto?

[happy barney]

jednou z príčin problémov je imho lenivosť. Lenivosť programátorov naprogramovať svoje aplikácie lenivé. Nie "potrebujem", ale "budem potrebovať". Príklad: save dialog ... hoci nezobrazí obsah adresára, aj tak načíta jeho obsah (gtk 2.8.13)

Pamäte budú vždy pomalé a pomalšie. Ani SSD vám nepomôže.

btw, optimalizovať by sa malo vždy

[Luk]

Lenivosť programátorov naprogramovať svoje aplikácie lenivé.

Snad naopak, ne? Ale jinak souhlasím.

Príklad: save dialog ... hoci nezobrazí obsah adresára, aj tak načíta jeho obsah (gtk 2.8.13)

Tohle už jsme tu řešili. Typický případ špatného řešení.

Pamäte budú vždy pomalé a pomalšie. Ani SSD vám nepomôže.

Není pravda. Latenci v desítkách ms mít SSD nebude. Navíc u něj nezáleží na umístění dat, takže není potřeba řešit optimalizaci vzhledem k pozici.

optimalizovať by sa malo vždy

Pokud se to vyplatí. Většinou nemá smysl prodloužit čas vývoje na dvojnásobek, pokud se tím získá 5% nárůst výkonu.

[happy barney]

Snad naopak, ne? Ale jinak souhlasím.

lenivé v zmysle nerobiť veci v aktuálnom čase zbytočné. Chovanie aplikácií štýlom "toto možno budem potrebovať, tak mi to priprav (thread na pozadí?), ja si neskôr na to možno počkám", a nie "toto možno budem potrebovať, tak si to teda teraz pripravím".

[Luk]

Já jsem to pochopil jinak. Že programátoři jsou líní dělat programy tak, aby líné nebyly - tedy optimalizovat je. A to obvykle líní jsou. Nějak to udělají, ono je to desekrát pomalejší, než by to mohlo být. Nemluvě o případech, kdy někdo použije operačně složitý algoritmus (např. O(n^2) nebo dokonce O(m^n)), protože si řekne: "Vždyť mi to chodí rychle.", a přitom to zkouší na velmi malých datech. Ale běda, když to někdo poštve na trochu větší data.

[Ladicek]

Lenivosť programátorov naprogramovať svoje aplikácie lenivé.

Snad naopak, ne? Ale jinak souhlasím.

Myšleno zřejmě bylo psát aplikace tak, aby nedělaly hned, co mohou udělat později Tedy ne lenivé z pohledu výkonu, ale z pohledu množství vykonané práce. Prostě něco jako kapitola 3.5 v SICP

[Jirka P]

Myšleno zřejmě bylo psát aplikace tak, aby nedělaly hned, co mohou udělat později

Tohle by bylo asi na delší diskuzi, není až tak jednoznačné, co je správně. Buď můžete

• být líný a provádět věci více méně sériově (musíte čekat, než víte, že tu práci budete potřebovat)
• být horlivý a (snad) provádět některé věci paralelně, s tím že možná nějakou práci na konci zahodíte

Samozřejmě, že provádět práci zbytečně a navíc sériově je z hlediska času běhu jednoznačně horší než oba tyto přístupy. Na druhou stranu, může být lepší z hlediska zabrané paměti (viz Haskell).

Nicméně rozhodnout mezi těmi dvěma možnostmi je dost těžké, vpodstatě pokud máte přebytek prostředků (třeba, ale nejen CPU), vyplatí se paralelizovat a spekulovat, ale ani tohle není 100% zvlášť když ty prostředky sdílíte.

[Josef Kufner]

Pamäte budú vždy pomalé a pomalšie. Ani SSD vám nepomôže.

Není pravda. Latenci v desítkách ms mít SSD nebude. Navíc u něj nezáleží na umístění dat, takže není potřeba řešit optimalizaci vzhledem k pozici.

Ono hlavně taky ten procesor nebude stačit. Datové struktury, které Gtk používá v TreeView jsou poněkud neefektivní. Jediné co to umí jsou seznamy a stromečky, které se obtížně a pomalu procházejí a celé to trvá nechutně dlouho. Je úplně jedno jak rychlý disk bude. Než Gtk vyrobí seznam, než ho patřičný widget zobrazí, než se to seřadí, než se tam umístí kurzor,... blé...

Krásným příkladem ja gmpc vs. xmms a vyhledávání v seznamu skladeb (v xmms klávesa 'j'). Při stejném množství položek v seznamu to xmms stíhá v reálném čase (rychleji než píšu na klávesnici) a gmpc asi minutu chroustá. Do zdrojáků jsem koukal a gmpc nic zvrhlého ani náročného nedělá. Položek je cca 14 297.

[Josef Kufner]

A teď jsem kouknul do zdrojáků xmms a to to dokonce dělá hůř než gmpc. xmms seznam vyprázdní a vytvoří znovu, gmpc jen nastaví filtrování v seznamu.

[Luk]

Já vím

[dustin]

Pokud spouštíš Seamonkey jednou za měsíc, zřejmě nepoužíváš flash plugin.

[Heron]

ale vyvojari filesystemu nejsou az TAK pitomi.

Ulevilo se ti alespoň? Pokud vezmu za příklad těch 100 Lukových souborů, tak všech možných pořadí jejich čtení je:

93326215443944152681699238856266700490715968264381621468592963895217\
59999322991560894146397615651828625369792082722375825118521091686400\
0000000000000000000000

Pro tohle nelze žádný FS optimalizovat. Kdyby ten FS dostal od aplikaci informace o souborech, které bude potřebovat, mohl by si je nachystat do cache a číst je v pořadí v jakém jsou uloženy na disku. Ve chvíly, kdyby je program skutečně potřeboval, již by byly v RAM.

[happy barney]

no, myslím, že tento prístup by bol hoodne veľký patch plus priority, plus no-disk-cache operácie, plus runtime zmena. Aplikácia bežiaca v popredí má iné nároky ako v pozadí, a pod.

[miho]

bude taky neco o eventlogu ?

Už bylo- čtvrtá část, oddíl "Pro voyery" :)

[miso]

Existuje vobec v linuxe nieco ako top pre I/O?

Uz viackrat som to potreboval, vacsinou si len podla "ps ax" tipnem, co asi pracuje s diskom.

[Luk]

iotop ?

[miso]

Nemam v kerneli zapnutu podporu ioaccounting (/proc/self/io) , ale dik, nastudujem si to

[miso]

Tak s distribucnym kernelom to nepojde, musim mat zakompilovanu podporu CONFIG_TASK_IO_ACCOUNTING

[fracty]

Je to tu moc pěkně popsané, ale zdá se mi, že jste nevěnoval moc času tomu hledání/zkoušení.

imho s prelink/preload se dá dosáhnout ještě lepších výsledků než s SuperFetch. Další důležitá věc je, že plno notebooků s Vistama ani ten SuperFetch nevyužijí, mají zaplácanou pamět plno blbostma {Symantec Firewall a já nevím co jim tam ještě výrobci dávají} a ten systém je i s těma skvělýma vychytávkama neuvěřitelně pomalý.

[Heron]

V tom případě je chyba na straně výrobce toho NTB (např ACER a jeho NTB s 512MB RAM). Visty bych na PC s méně než 2GB nepustil, za optimum bych viděl 4GB.

[miho]

Prelink je metodou jak ulevit při startu aplikace _procesoru_ takže stoji trochu stranou zájmu tohoto dílu. Je to ale zajímavý námět na jeden díl- jak se liší dll od dynamických/statických knihoven v linuxu, jak je řešená meziprocesová komunikace, těžkotobážní procesy ve windows vs procesy v linuxu, thready, síťování, oops to je námět na několik dílů

Na preload se podívam. Jak už bylo ale řečeno výše, obávám se, že ádro neposkytuje nyní dostatek údajů pro běh takového démona.

[miho]

Prozkoumal jsem zběžně preload. Tady je asi nejrelevantnější čtení http://preload.cvs.sourceforge.net/preload/preload/doc/proposal.txt?revision=1.1&view=markup

Zpusob predikce je velmi zajímavý a odlišný od toho, který je aplikovaný v superfetchi. Nedokážu posoudit, zda je lepší predikce typu (množina spuštěných programů) -> příště spuštěný program nebo (uživatel, den v týdnu, čas) -> příště spuštěný program.

Je tam každopádně limitace, která již byla zmíněná dříve. Vyvází se z výpisu mapy paměti procesu a to je podle mě málo. To může být jen zlomek dat načítanýchpři startu aplikace- binárka, knihovny, mmapované soubory. A neřeší se které části souboru je třeba načíst.

O tomto programu jsem nevěděl a moc rád bych byl kdyby se našel nějaký uživatel. Je to v nějaké distribuci implicitně zapnuté nebo vůbec obsaženo? CVS mi přišlo dosti mrtvé.

[Luk]

Kdysi jsem to zkoušel. Nepřipadalo mi, že by se práce nějak znatelně zrychlila - testoval jsem to ale s 512 MB paměti, což je dost málo. Projekt mi připadá mrtvý. Jsou tam sice nějaké commity před 8 měsíci, ale jinak se nic dalšího neděje.

[jenda]

uz je tech dilu v tom blogu nekolik, presto mi porad unika ta havni myslenka, co autor sleduje. Chce prokazat, ze skutecne plati, ze kazda hul ma dva konce?

[alvyn]

Jednak ukazuje, že Visty nejsou tou "sračkou" za kterou jí spoust lidí milně pokládá. S čím musím po týdením průzkumu souhlasit. Navíc porovnáním ukazuje, co by stálo zato "okopírovat" v Linuxu. Pěkně se to čte a je to zajímavé.

[Luk]

Navíc porovnáním ukazuje, co by stálo zato "okopírovat" v Linuxu.

S tím okopírováním v Linuxu je to ošemetné. Mnoho věcí (zrovna třeba SuperFetch a mnoho dalších) je kryto řadou patentů. Tady nás to nemusí trápit, ale např. v USA ano a proto i když třeba implementace vznikne, v mnoha distribucích nebude.

[alvyn]

Jasný, však proto jsem to psal do uvozovek. Ovšem speciálně tato funkce by se hodila snad všude a myslím, že způsob, jak to naprogramovat jinak nežli ve vistě se určitě najde.

ps: soráč za tu hrubku v minulém komentu a to jsem to po sobě i četl :)

[miho]

Mohl bych se vám snažit nalhat, že za celým seriálem je nějaký skrytý, vzletný cíl. Pravda je ale mnohem prozaičtější. Seriál je prostý jakékoliv hlavní myšlenky. První díl vznikl dva dny po instalaci a klidně to mohlo celé dopadnout tak, že po druhém dílu bych byl z Visty do té míry rozladěň, že by už žádný třetí díl nikdy nebyl. Podezírat mě z toho, že bych znal výsledek už na začátku je zcela liché; vždyť já ani nevím co budu mít dnes k večeři

[Luk]

Chce prokazat, ze skutecne plati, ze kazda hul ma dva konce?

Spíš že každá p.... má dvě půlky

[xvasek]

Předchozí díly mi přišly plus mínus dobře udělané, ale v tomto vidím jeden zásadní bug v sekci začínající "Pokud řešíte nějaký problém...". Já osobně, pokud řeším nějaký problém, používám v Linuxu strace. Oproti tomu ve Vistě "je nejlepším řešením vytvoření tzv. sady kolekce dat". Chápu, že nějaké řešení to je, ale rozhodně bych nepoužil přívlastek "nejlepší" a zcela jistě bych nehodnotil Vistu líp, než Linux.

Nedávno jsem řešil dramatický propad výkonnosti ERP systému - spustil jsem si strace na běžící proces a okamžitě na mě vypadlo, kde to vázne. Ve vistě bych ve stejném případě měl začít vytvářet "sadu kolekce dat"? To teda pěkně děkuju.

(Ano, nějaké pokusy o strace pro Windows jsou - používal jsem to od Razoru a teď jsem našel ještě jakésix jiné - ale rozhodně to není tak dobře zmáknuté, jako v Linuxu.)

[miho]

Strace je přeci zcela jiná kategorie. To bych mohl rovnou napsat, že ve všech systémech to je stejne páč každý má něco na způsob GDB A mimochodem, strace je i v ve windows (cygwinu)...

[xvasek]

Ano, máš pravdu, je to k něčemu jinému - narozdíl od toho bazmeku ve Windows to má v praxi reálné využití.

[Marián Kyral]

spustil jsem si strace na běžící proces

Sákryš, mě ani nenapadlo, že by to mohlo jít i takhle. Člověk se pořád učí

Díky