Příspěvky

5341

Software / Re:Prepis z audia na text

« kdy: 15. 03. 2014, 09:38:31 »

Zkušenosti s tím nemám, ale znám jenom tohle: Newton Dictate. Pak má nějakou službu také Google, používají to androidí zařízení - ale to je dostupné asi jen jako služba.

5342

Vývoj / Re:Java: byte to 8 boolean

« kdy: 15. 03. 2014, 08:56:44 »

Za druhé, kecy jenom prolítávám jak jsem říkal chci důkaz a to znamená zdroják který si vložím do Eclipse a spustím a poběží na stejném kusu HW rychleji než v Cčku.

A to bude důkaz čeho? Tvrzení, které tady nikdo nezmínil a nikdo neobhajuje?

Já jsem ty porovnávací zdroje svého tvrzení předvedl. Od oponentů očekávám totéž.

Nepředvedl. Předvedl jste jeden příklad. To jako důkaz všeobecného tvrzení nestačí.

To, co jste předvedl, je spíš názorná ilustrace toho, že špatně lze psát v libovolném jazyce. A že rozdíly mezi špatně a dobře napsaným programem jsou nesrovnatelně větší, než rozdíly plynoucí z použitých nástrojů. Jediný případ, kdy nástroje mohou ten rozdíl srovnat, je tehdy, pokud dokážou ten špatně napsaný program opravit (při optimalizaci).

Tak jsem se na to podíval ještě jednou, opět jsem použil matici 2000x2000. Verze psaná v C/gcc na to potřebovala cca 64 sekund. Ta verze v Javě na to potřebovala 88 sekund. Mnou upravená verze (jedno pole, transpozice před násobením) v Javě to zvládla za 5 sekund. A aby to bylo vtipnější, tak C verze přeložená icc to zvládne za 0.85 sekund.

Verze přeložená s icc byla ta samá, jako s gcc? Tedy ta s dvourozměrným polem a bez transpozice? To by mne tedy zajímaly ty instrukce, co z icc vylezly. To snad muselo provést tu transformaci i transpozici matice také a použít pak vektorové instrukce.

5343

Server / Re:Jakým způsobem mít /home na LAN?

« kdy: 15. 03. 2014, 08:36:51 »

Jde. Protože když si hra sežere celou volnou fyzickou RAM, tak na cache zbude +-0B, cimzpadem se vsechno bude cist primo z disku.

Pokud hra sežere 8 GB, pak by na systému se 4 GB pořád swapovala a byla nepoužitelná. 8 GB by pak nebylo "spousta paměti", ale "minimum, aby hra vůbec fungovala".

Neplatilo by to jedině v případě, že by hra zjišťovala celkové množství RAM a podle toho řídila svou spotřebu. Pak by tu RAM nejspíš používala jako keš a měla by umět data načítat dopředu.

Jinak může být rozdíl, zda se data čtou ze souboru nebo ze swapu. Třeba pokud je soubor na síťově připojeném /home, ale swap je lokální...

5344

Server / Re:Jakým způsobem mít /home na LAN?

« kdy: 14. 03. 2014, 21:10:05 »

S tou RAM si asi už nerozumíme. Já chtěl říct, že třeba Team Fortress 2 si vezme všechnu RAM, co je volná. Jiný hry to ale neumí...

Ale tady přece nejde o využití RAM hrou. Hra řekne OS "načti ze souboru X bajty 0 až 1024". OS se podívá, zda už data nejsou v cache, a pokud ano, příslušnou část paměti zpřístupní aplikaci. Pokud v cache nejsou, načte je z disku do paměti a zpřístupní paměť aplikaci. Pokud tedy bude hra číst datové soubory, které se vejdou do volná RAM (a nic jiného se z disku číst nebude), měla by většina dat už být načtená v cache, takže rychlost disku dobu čtení nijak neovlivní. Nevím ale, zda disková cache pracuje s vlastnostmi úložného zařízení - jestli tedy třeba síťový disk kešuje agresivněji.

5345

Server / Re:Jakým způsobem mít /home na LAN?

« kdy: 14. 03. 2014, 20:07:35 »

Jde o to, že mam velkou RAM. Hra má dost možná v sobě jakousi blokaci, která omezuje maximální využitou paměť. Navzdory tomu, že by se celá hra vešla do RAM... Smutné, ale pravda.

Na Linuxu to hra nemůže nijak zablokovat, protože disková keš je záležitost operačního systému a ta paměť patří operačnímu systému. Ta hra rozhodně nemůže systém nějak omezit v tom, kolik paměti pro keš použije. Může to ovlivnit jedině tak, že by sama hra měla velkou spotřebu paměti, tudíž by OS volnou paměť raději použil pro hru než pro diskovou keš.

Beru na vědomí, že diskové operace nelze u her zanedbat. Ale myslím, že ta závislost nebude tak přímočará, takže těžko odhadovat, jak by se to se síťovým diskem chovalo. Každopádně pořád máte možnost část /home s hrami nechat zase na lokálním disku, případně na SSD vyhrazeném pro hry.

5346

Server / Re:Jakým způsobem mít /home na LAN?

« kdy: 14. 03. 2014, 19:15:35 »

Ta hra neumí RAM využívat, takže nazdar bazar...

Jak by RAM měla hra umět využívat? Disková keš je záležitost operačního systému.

Chápu, že něčí empirická zkušenost říká, že SSD výrazně pomohlo (i když pak stále nevíme, zda pomohla menší latence nebo větší propustnost, případně obojí). Ale není mi jasné, proč to tak je.

5347

Server / Re:Jakým způsobem mít /home na LAN?

« kdy: 14. 03. 2014, 18:10:45 »

Co se stane, když na /home, kde je namountovanej třeba /dev/sda3, namountuju pomocí NFS něco vzdálenýho? Udělá se umount /dev/sda3 nebo ne? Jaký soubory v /home uvidím? Já se domnívám, že se prostě ten lokální home překreje tim z NFS a všechno pojede. Nepovažuju to za košer postup, jen se ptám.

Nic se neodmountuje, jednotlivé mounty se vrství přes sebe - mount jenom změní to, co je vidět v adresářové struktuře. Košer postup to je, takhle mountování funguje. Už při mountování toho /dev/sda3 na /home překryjete soubory a adresáři v /home na kořenovém disku.

Velké hry (například Arma) loadují textury v jednom kuse, přemístění na SSD zvedne FPS ze 30 na 70.

Kolik taková hra zabírá na disku? Myslel jsem, že bude mít vše potřebné v cache... "V jednom kuse" znamená fakt, že se z disku čte neustále (a není tedy šance něco načíst dopředu), nebo ře se čte hodně často, pak by ale latenci mělo řešit přednačítání dat.

5348

Server / Re:Jakým způsobem mít /home na LAN?

« kdy: 14. 03. 2014, 16:56:13 »

Jak /home připojit? Resp. jakým protokolem/službou? NFS, SSHFS, ...? NFS jsem už dřív zkoušel, nevyhovoval mi pouze požadavek shodných UID a GID. Má to někdo podobně?

NFS. Podobně to mají uživatelé unixů už desítky let. S ohledem na to byla i navržena standardní struktura unixových adresářů - aby nutná část mohla být lokálně a zbytek (včetně /home) na síti. To jenom desktopové počítače jsou taková anomálie, kde jde vše v lokálním počítači.

UID a GID nemusí být shodné, je možnost mapovat je podle jmen. Je k tomu potřeba podpora na obou stranách, ale Linux to podporuje. Problém by mohl nastat, pokud by ten server byl nějaký NAS, tam ne vždy mají podporu mapování zapnutou.

u her potřebuješ i latenci

Latence při čtení nebo zápisu na disk? U her? Co by ta hra z disku pořád četla nebo na něj dokonce zapisovala?

5349

Vývoj / Re:Java: byte to 8 boolean

« kdy: 14. 03. 2014, 06:58:47 »

Je pravda že novější verze to výrazně zlepšili

Chcete tím říct, že starší verze byly napsané v Javě a novější ne? Nebo jinak, existuje nějaký výklad tohoto tvrzení, který by vaše tvrzení "Java je pomalá" nevyvracel (ve smyslu, že je nepravdivé, nikoli ve smyslu, že je pravdivý opak), ale podporoval?

jsem tvrdil že optimalizovat v Javě bitovými operacemi je zbytečná práce

Bitové operace se nepoužívají jen k optimalizacím. Jakákoli optimalizace není zbytečná práce právě tehdy, pokud vím, že jí zlepším úzké místo v aplikaci. Na ničem jiném to nezáleží.

5350

Vývoj / Re:Java: byte to 8 boolean

« kdy: 13. 03. 2014, 21:29:06 »

Och já naivka si myslel že tu někdo konečně předvede důkaz

Nezapomněl jste napsat, důkaz čeho očekáváte? Důkaz, že neefektivní kód lze napsat v jakémkoli jazyce, jste podal vy sám. Jaký chcete další?

Důkazy máš všude kolem sebe. Pro příklad Android.

Tvrzení s velkým kvantifikátorem nelze dokázat příkladem. OpenOffice nebo Firefox také nedokazují, že C++ je pomalé.

5351

Vývoj / Re:Java: byte to 8 boolean

« kdy: 13. 03. 2014, 14:56:42 »

Ještě tu nezazněla jedna věc. Při násobení matic jsou jednotlivé prvky výsledné matice na sobě nezávislé, je to tedy ideální kandidát na paralelizaci – když máte dost jader, může jednu buňku matice počítat jedno jádro. Pak je možné řešit takové optimalizace, aby jednotlivá vlákna výpočtu s výhodou používala data načtená jiným vláknem.

5352

Vývoj / Re:Java: byte to 8 boolean

« kdy: 13. 03. 2014, 09:04:35 »

budu vděčen když mi někdo ukážete jakoukoliv možnost jak to zrychlit aby to bylo konkurenceschopné.

Obvyklý postup, jak něco zrychlit, je použít vhodný nástroj. Třeba pojídání polévky zrychlíte tak, že odložíte vidličku a místo ní použijete lžíci. Až se po polévce pustíte do řízku, je zase dobré místo lžíce použít vidličku. Na různé věci se totiž hodí různé nástroje – to, že použijete špatný nástroj, není chyba toho nástroje. Pokud někdo jí polévku vidličkou a usuzuje z toho, že vidlička je pomalá, je to především jeho hloupost.

Pokud potřebujete násobit velké matice, použijte k tomu výpočty na GPU. Volat je můžete jak z C tak z Javy.

5353

Vývoj / Re:Java: byte to 8 boolean

« kdy: 13. 03. 2014, 07:00:00 »

1) Hello world sežere v C++ 156 KB. Java SE Embedded? Nepoužívám, nejsem schopen říci kolik bere paměti.
2) Musel bych dokázat zpomalení? xD Důkaz je skoro každá aplikace napsaná v Javě xDD
3) Radši nic, nebo bych zas hodil nějakou osobní invektivu xD ...

Aha, takže nevíte, důkazy nemáte, a ještě si sám protiřečíte. To jsou opravdu pádné důvody pro způsob, jakým tady vystupujete. Čeština pro to má hezké rčení: prázdný sud nejvíc duní.

5354

Vývoj / Re:Java: byte to 8 boolean

« kdy: 12. 03. 2014, 16:18:56 »

No, takže, standardní C++ knihovny opravdu nesežerou MB RAMky...

Kolik tedy sežerou? A kolik sežere třeba Oracle Java SE Embeded? Určitě to víte, když jste takový odborník.

Takže, Java je pomalá protože je interpretovaná (jasně, používá JIT překlad no a?) a má GC.

Aby tohle tvrzení platilo, musel byste nejprve dokázat, že:

• Java je interpretovaná
• Interpretace nebo JIT překlad znamená zpomalení proti nativnímu kódu
• GC znamená zpomalení

Přeju hodně úspěchů při dokazování, zatím se to nikomu nepodařilo.

Jinak pokud je podle vás interpretace, JIT nebo GC taková brzda, proč nekritizujete také ostatní programy, které tyhle techniky používají? Třeba Linuxové jádro, tam musejí být některé části také hrozně pomalé, když používají GC nebo interpret.

Prosimtě, naprogramoval si někdy něco bez GC? Asi ne.

Zase vedle.

5355

Vývoj / Re:Java: byte to 8 boolean

« kdy: 11. 03. 2014, 23:43:42 »

To že sežere Java jen tak z podstaty několik mega právě považuju za špatné

Když plus mínus tu samou paměť sežere běhové prostředí C/C++ (základní knihovny), tak to za špatné nepovažujete?

Java má taktéž GC, což je zpomalení jak prase.

Nejdřív jste tvrdil, že je Java pomalá, protože je interpretovaná. Když jste byl usvědčen z omylu, zkusil jste něco jiného. A zase špatně. Například GC používá i spousta aplikací napsaných v C nebo C++. Dále existují různé způsoby, jak GC implementovat, jenom v JVM od Oraclu je jich implementováno několik. Výkon GC také závisí na tom, jak programátor s pamětí zachází. Takže opět, to, že něco má GC, nevypovídá vůbec nijak o rychlosti aplikace - může být kvůli špatnému GC a špatnému programu velmi pomalá, a taky může být díky dobrému GC a dobrému programu rychlejší, než aplikace s ruční správou paměti.

Zatím tu prezentujete jen pověry. A ve výsledku není rozdíl, zda programátor napíše program neefektivně kvůli tomu, že si neumí dohledat efektivní řadicí algoritmus, nebo kvůli tomu, že věří pověrám.