Nejlepší programy pro práci s operační pamětí

Zvažoval jsem vytvoření RAM disku pro práci při úpravách fotek, kdy bych si do něj nakopíroval nějakou dávku fotek a pak při práci bych to již jen z něj načítal, zpracoval a zpět ukládal. No a po skončení práce bych upravené fotky přemístil do příslušných složek. Případně při skenování fotek bych je napřed na něj uložila po zpracování teprve přemístil na konečné úložiště. Je moje představa k něčemu a pomohlo by mi to vůbec nějak v urychlení práce? Představoval jsem si, že bych pro něj vyčlenil 2GB ze4GB RAM.

Podle mě je to hloupost...

1) RAM disk není moc spolehlivý - vypadne proud a vše co na něm bylo je nenávratně pryč.

2) Skenování nebo načítání fotek je řádově pomalejší než dnešní běžné pevné disky - takže to že fotky budu ukládat na superrychlý RAM disk vůbec nic neurychlí, brzdit to bude něco jiného.

3) Při úpravách fotek, hlavně pokud upravuju velké fotky a pracuju ve Photoshopu s vrstvami apod., tak se hodně RAM paměti hodí, tak proč si ji zbytečně ubírat a dělat z ní RAM disk?

RAM disk je v tomhle případě k ničemu - lepší je dokoupit RAM a používat moderní systém, který ji dokáže využít (Vista a výše, Linux)

Těhle prográmků už byla plná pr.... před roky!!!

No a nejlepší jsou ty, které jsou placené. Takže navenek pak nezbývá konstatovat nic jiného, než to, že nejlepší program pro práci s paměti je "přikoupení další paměti"...

somariny

kedysi davno som cital clanok o O&O Clever cache a vraj splnal ucel... uz nepamätam aky casopis to bol

eBoostr predsa dokaze pouzivat aj RAM ako cache, nielen flash pamat. Si prosim precitajte aspon popis na hlavnej stranke produktu.

Přesně tak. Tady je totiž ten problém se srovnáním s ReadyBoost. Spousta lidí si myslí, že ReadyBoost je nějaké zvýšení kapacity RAM, a že systém danou "paměť" na flashce bude používat jako klasickou RAM. Jenže to není vůbec pravda. ReadyBoost paměť je použita pouze pro diskovou cache a jako úložiště pro cache funkce Superfetch.

A právě druhou funkci má za úkol i eBoostr. Jednoduše přednačítá soubory z disku do paměti a přístup k nim je pak několikanásobně rychlejší. Oproti klasickému Superfetchi lze ale vybrat i umístění tohoto úložiště, velikost, nebo na 32bitovém systému používat paměť nad 4 GB.

Ačkoli je tento program vhodný spíše pro starší Windows XP, tak je zajímavé, že podle testů (měřeno nezávislým uživatelem, nikoli vývojovým týmem eBoostr) přináší zrychlení i na Windows Vista. To pouze ukazuje, jak je Windowsovský Superetch "optimalizován".

Chtěl jsem přiložit i výsledek testu, ale když sem dám tu URL, tak to hodí, že příspěvek nesplňuje pravidla.

MemTest neni freeware, ale free, open-source software.

A není to jedno? Důležité je, že je zadarmo.

Mac Mini Mid 2011, 120 GB SSD, 500 GB HDD, 8 GB RAM, OS X 10.8 Mountain Lion
iPhone 3GS 32 GB white
Verze OS: 5.1.1 JB
iPad 2 3G 64 GB white
Verze OS: 6.0, nonJB
iPod Shuffle blue

Oznacit open-source program pod GPL jako "freeware" je skoro urazka Rozdil je samozrejme obrovsky, freeware muze obsahovat skodlivy kod a znemoznuje komunitni vyvoj, odhalovani chyb atd.

Osobne existenci freeware moc nechapu (mimo nejake snahy skryt trojany apod.). Proc neuvolnit kod programu, u ktereho dam svoleni k sireni zadarmo? Autorovi to nijak neuskodi, uzivatelum a programu samotnemu jednoznacne prospeje.

Nechápu jak může GPL licence sama o sobě zaručit neexistenci trojanu v kódu

Jediné co to zajistí je, že pokud se někdo bude snažit ho tam najít tak ho tam MŮŽE najít, což jsou dvě podmínky bez jejichž splnění to nemůže být nikdy zaručeno...

Význam freeware může být třeba v tom, že v něm používám stejné části kódu jako ve svém komerčním programu a nemám tedy zájem o zveřejnění zdrojáků...

Bavime se tady o samozrejmostech, ktere musi byt jasne triletemu diteti. Kdyz ma kazdy moznost si zdrojak precist, je sance, ze se na chybu/trojana narazi. Jinak ne (kdyz nepocitam disassemblovani a studovani zapisu v assembleru). Pokud je program rozsireny, ten zdrojak precte dostatek lidi na to, aby si nekdo skodliveho kodu vsimnul.

Pokud vim, jeste se nestalo, ze by v open source programu byl nalezen skodlivy kod. Kdyz je tak jednoducha moznost kontroly, nikdo si to proste netroufne.

Ten škodlivý kód také zveřejňovat nemusí a můžou ho tam přidávat až při kompilaci.

O všem se má pochybovat.

přesně... jediná jistota jak nemít trojana s GPL je si to kompilovat sám ze stažených zdrojáků, které si předem zkontroluju jestli neobsahují trojana

Ja budu i tak dal slepe duverovat spravcum repozitaru debianu a ubuntu, ze na me neplanuji kyberneticky utok

Ale stalo. Jenže to bylo v případech, kdy "autor" programu porušil GPL licenci díla, ze kterého dělal svou odvozeninu. Např. u modifikací DC++ je to běžný jev (Zion, GreyLink atd.).

Milé děti, více co je to ochrana paměti a virtuální paměť? Ne? No tak pak můžete věřit na defragmentátory a uvolňovače.

Jediná věc, čeho můžou tyto programy dosáhnout, je donutit systém, aby paměť vysypal do stránkovacího souboru (swapu) a zrušil diskové cache. A jak toho dosáhne? Naalokuje a dealokuje nějaký velký kus paměti. Když pustíte nějaký "velký" program, tak systém provede to samé sám od sebe.

Jinak volná paměť je na nic, moderní OS se snaží všechnu volnou paměť použít na diskové cache. A spolehlivost dnešních OS staví na tom, že procesy si nemůžou navzájem hrabat do svého paměťového prostoru. (Porovnejte s Windows 3.x, kde tomu tak nebylo.)

Samozřejmě že ty programy na uvolnění paměti jsou nesmysl, ale fakt je že pokud paměť uvolním už před spuštěním programu tak teoreticky může dojít ke zrychlení spuštění, protože nedochází současně ke swapování a načítání dat z disku což disku nedělá moc dobře a dost to spouštění zpomalí.

takze podla teba 2+3 je menej ako 3+2 :)

ja ked som 10r dozadu tieto programky skusal, jedine moje spomienky su na spomalenie systemu :)

vsak ja jsem nepsal ze ty programy zrychluji system je jasne ze pokud je nechame na pozadi prubezne odswapovavat pamet tak to bezici programy bezpochyby zpomali... jen rikam ze je urcity, marginalni pripad, kde to zrychleni MUZE nastat...

No, disku skutečně svědčí když nemusí dělat víc operací zároveň. Ale jak ukládání do swapu, tak spouštění nového programu mají spíše povahu náhodného přístupu než dávkové sekvenční operace, takže se to nevyplatí. Nevyplatí se to taky, že samotný uvolňovač potřebuje nějaké prostředky. A už vůbec se nevyplatí, aby se o to staral uživatel a takto ručně si připravoval spuštění programu.

ja jsem jasne napsal ze ty programy jsou nesmysl, ale v urcitem pripade to muze prinest urcite zrychleni

i kdyz jsou to obe nahodne operace, tak je jasne ze pokud se budou tyto nahodne operace provadet SOUCASNE, ze zpomaleni vlivem disku bude znacne, to je snad jasne...

Škoda té "defragmentace RAM" jinak pěkně zpracovaný článek.

O všem se má pochybovat.

Defragmentace RAMky? tak vetsi blbost jsem neslysel vzhledem k tomu, ze do RAMky se pristupuje "nahodnym" pristupem a umisteni dat do ruznych mist nezpusobuje zpomaleni tak, jako na disku

Z tech jmenovanych je k necemu jen Memtest. Kdyz uz ma clovek potrebu pouzivat nejaky program na RAMdisk, tak je vetsinou lepsim resenim RAMku prikoupit a vic se nestarat, je s tim jen vice prace nez uzitku.

So sayeth the Wise Alaundo

Súhlasím, tie články "Nejlepší program pro.." sú proste hrozné blbosti, ale toto je fakt výnimočné.

fajn, tak je nečti. nikdo ti to nepřikazuje. stejně jako ti ani nebrání v tom, abys v diskuzi na fóru zformuloval jejich podobu. ale plácnout sem nějakou blbost bez jakéhokoli argumentu je přeci mnohem snazší. tak proč byses namáhal...

a kdyz je cist nebude, tak to zmeni na faktu ze jsou to blbosti...co presne?

Tak ale třeba 32b systémy jsou stejně omezené kolem 3 GB, takže než to nechat ladem... Tak aspoň získáš daleko rychlejší disk než ti může nabídnout i ten nejlepší SSD.

O všem se má pochybovat.

Paměť fragmentována být může a ne že ne. 32b systémy nejsou omezeny 3GB ani 4GB paměti, viz třeba 32b serverové windows. http://msdn.microsoft.com/en-us/library/aa366778(VS... ... Každý 32b linux může adresovat až 64GB paměti, ale to nevim jistě.

Všechny 32b procesory od Pentia Pro výše mají rozšíření PAE, které umožňuje adresovat 64GB RAM. Virtuální paměť procesu však má stále 4GB RAM. (Tj. každý proces má 4GB a všechny procesy dohromady mohou mít až 64GB.) Linux lze zkompilovat s podporou PAE, bohužel při použití PAE klesá výkon jádra asi o 5% až 10%.

ta defragmentace mozna je .. a ma i svuj smysl ... ale rekl bych, ze je to ponekud precenovani smyslu ...

... smyslem muize byt mimojine setreseni pameti a vytvoreni vetsich souvislych bloku volne pameti, pro urychleni (resp. v nekterych pripadech vubec o umozneni) alokace vetsiho souvisleho bloku ....

to, co jsi napsal, je totální kravina...

program může mít naalokované třeba stovky MB (pro něj) souvislé paměti, přitom fyzicky jsou ty data různě poházena na RAM nebo i disku

defragmentace skutečně nadělá víc škody než užitku (resp. užitek to má nulový)

no ale je mi jasné, že obživa autorů podobných defragmentátorů a zrychlovačů paměti pramení právě z nevědomosti běžných uživatelů...

kdyz myslis...

Ano, je pravda, že program může mít naalokovanou paměť z nesouvislé oblasti. Problém je v tom, že jedna jediná alokace (nebo jak to nazvat) musí být ze souvislé paměti. To znamená, že když program bude chtít alokovat například dvakrát 1 MB paměti, tak tyto 2 MB nemusí být souvisle za sebou, ale každý MB musí být souvislá paměť. Pokud tak velká souvislá paměť neexistuje, tak alokační funkce vrací "Out of memory"

Dik .. Nechtelo se mi vysvetlovat mu to ...

To se trochu pletete. Než začnete plácat nesmysly, tak si nastudujte něco o architektuře procesorů x86. Systém (jedno jestli Linux nebo Windows) může programu přidělit procesu jakkoliv velký (u 32b max 4GB) souvislý blok který fyzicky nemusí být souvislý. O to se stará transparentně CPU který podle stránkovacích tabulek překládá virtuální adresy na fyzické, eventuelně vyvolává přerušení, pokud je stránka označena jako nepřítomná (třeba je ve swapu - systém se postará o uvolnění fyzické paměti a načtení stránky), nebo má CopyOnWrite flag (typicky u knihoven, které jsou sdílené pro více procesů a klopírují se až do ní chce nějaký proces zapsat)

NB1: Ubuntu 12.10 @ Asus F3F, NB2: Ubuntu 12.10 @ Lenovo W510, HTPC: Ubuntu 13.10 @ Intel i3, TABLET: Android 4.1 @ Asus Transformer TF300T

Přesně tak...

Jediný problém (o kterém asi píše BigMuscle) může nastat, pokud chce proces naalokovat nějaký velký souvislý kus paměti, který se ale do jeho adresového prostoru už nemá kam vejít (protože zde není tak velký souvislý volný blok) - pak je docela možné, že se objeví Out Of Memory. To ale tyhle "defragmentátory" nijak neřeší - ty asi jen způsobí, že si systém přeuspořádá paměť fyzicky v RAM, což je ale absolutně k ničemu (jestli vůbec, protože si nedokážu moc dobře představit, jak donutí memory manager, aby data naukládal nějak za sebe), do adresového prostoru procesů nesahají. Ono až na pár výjimek je technicky nemožné přeuspořádat procesu paměť tak, aniž by pak nezhavaroval

Lze o tom někde nalézt více informací? Zajímá mě to, protože pokud lze naalokovat nesouvislý blok paměti, pak je to v rozporu s několika fakty:

- proč funkce jako malloc, calloc, new apod. vrací chybu, pokud v paměti neexistuje souvislý blok o požadované velikosti?

- proč nelze dynamicky zvětšit pole a je nutné jej překopírat do souvislé oblasti? I např. funkce realloc, která slouží pro změnu velikosti alokované paměti, alokuje novou paměť, pokud by současný blok nebyl po zvětšení souvislý.

- s druhou otázkou souvisí i fakt, že knihovna STL jazyka C++ poskytuje dva kontejnery - vector a deque. Ty se liší pouze tím, že deque alokuje paměť po částech (takže bude uložen v nesouvislé paměti), zatímco vector vždy alokuje jednu oblast, která je souvislá a při přidávání prvků (tj. zvětšování interního pole) dochází k alokaci nové oblasti paměti, do které je stará paměť překopírována. Kdyby bylo možné alokovat nesouvislý blok, pak by existence obou kontejnerů zároveň postrádala smysl.

V prvé řadě musíš rozlišovat věci jako virtuální adresový prostor, ve kterém programy běží a fyzickou adresaci do konrétního místa na RAM nebo swapu...doporučuju někde nastudovat co je to vlastně virtuální adresa, jak funguje převod na fyzickou atd.

Proč může malloc apod. vrátit chybu, pokud neexistuje souvislé volné místo jsem už psal...prostě tu paměť už není kam adresovat. Rozhodně to není proto, že by např. na RAM nebyl tak velký souvislý úsek paměti - ten k tomu není vůbec potřeba.

Dynamicky zvětšovat pole bez kopírování by teoreticky možné bylo - ale muselo by tyhle funkce podporovat jádro OS (možná to nějaké umí, možná toho jde nějak docílit, nevím).

Rozdíl mezi vector a deque je v tom, že každé se hodí trochu na něco jiného, opět to s nějakou fragmentací vůbec nemá co dělat.

Já moc dobře vím, co je virtuální adresový prostor a všechno okolo, studovat to nepotřebuju, protože jsem to už vystudoval pouze mi nebyly jasné ty věci, co jsem jmenoval.

Rozdíl mezi vector a deque je pouze v alokaci paměti, jak jsem napsal. Až z toho vyplývá, že když deque alokuje paměť po částech, tak díky tomu lze snadno a rychle přidávat prvky nejen na konec, ale i na začátek kontejneru, protože se narozdíl od vectoru nemusí alokovat kompletně celé pole znovu. Tímto tématem jsem se zabýval i ve své bakalářské práci.

Každopádně, ať je to jak chce, tak jakýkoli defragmentátor paměti ničemu nepomůže, ale spíše uškodí.

S tou poslední větou 100% souhlas...

Jinak přemýšlel jsem o tom reallocu, aniž bych musel kopírovat data a teoreticky je to možné i na Windows třeba pomocí api fce VirtualAlloc - rezervuju si nějaký dostatečně velký adresový prostor a v něm si postupně alokuju nebo uvolňuju kusy paměti dle potřeby. Pokud je budu alokovat tak, ať na sebe navazují (u téhle funkce to jde), budu z nich mít z pohledu programu jeden velký kus paměti (fyzicky samozřejmě libovolně poházený na RAM, dle aktuální nálady jádra systému:))

Víceméně souhlasím, až na jednu maličkost. Zřejmě jsi nepochopil, jak funguje RAMdisk.

Ramdisk náhodou je užitečný - např. při programování je pro mě výhodné, aby se pomocné zkompilované soubory ukládaly na ramdisk. Je to opravdu _hodně_ rychlé a nezatěžuje se zbytečně harddisk (ty soubory nepotřebuju trvale ukládat, při příštích kompilacích se načtou bleskově z ramdisku, při dalším zapnutí PC se vytvoří znovu).