Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Jo, poskytovatel DNS, který zároveň bude umět dynamické DNS u A záznamu pro doménu by bylo řešení. Nečekal bych, že to někdo bude poskytovat zadarmo.Pokud vám stačí 3 zóny a 4 servery, umí to ClouDNS. Dynamické DNS záznamy se tam aktualizují jednoduchým HTTP GET požadavkem na určené URL, takže by mělo být jednoduché to kdekoli naskriptovat.
Asi vím, jaks to myslel, ale to co jsi napsal není pravda. Paměť není "RAM" (v původním významu toho slova) asi tak 25 let, stejně jako SSD není žádný disk :-) Podívej, jak je organizovaná L1 a L2 cache, jak dlouhé jsou cache line a zejména kolik jich je. To je omezující faktor, který se každou další dereferencí zhoršuje a zhoršuje, což je snadno měřitelné. Ano, nikdo nezaručí, že přečteš 100 MB pole tak, že budeš mít vše dopředu v cache, ale co bude u pole struktur/primitivních hodnot zaručeno je, že jak se určitý prvek dostane do cache line, budou tam i ty následující prvky. U pole referencí máš jen jistotu, že čtení dalších N referencí (ne hodnot!) bude možná v cache, možná ale taky ne, protože se to přeplácne načítanými strukturami.Problém vašeho tvrzení je v tom, že ani CPU nevypadá stejně, jako před 25 lety, a neběží na něm jediná úloha, jako před 25 lety.
To je pravda, ale stále bude velké množství hodnot u sebe.To je zajímavé, že tohle nepovažujete za platný argument, ale jakmile se vám to hodí, použijete ho také.
Zatímco, když použijete pole referencí, tak zvyšujete spotřebu paměti (v mém příkladu se zvýšila 6x)To je nesmyslný údaj, zvýšení spotřeby paměti záleží na ukládaných datech a může to být jakékoli kladné racionální číslo.
což mj. znamená, že plýtváte cachíNeznamená. To je pouze vaše tvrzení plynoucí z toho, že pravděpodobně nevíte, jak moderní CPU pracují.
Dále zvyšujete počet alokovaných objektů, jejichž dosažitelnost bude GC periodicky kontrolovat (je-li délka pole n, počet objektů se zvýší cca n krát) - tj. zbytečná zátěž pro CPU.Takže na ty vaše objekty v poli se nedá udělat reference? To je ale děsivé omezení a jakýkoli algoritmus, který s tím naprogramujete, je neefektivní…
A proč se to tedy plánuje přidat do Javy?Protože to tam není.
Reagoval jsem jen na tvrzení, že pole referencí je stejně efektivní jako pole pole hodnot.Což tady pokud vím nikdo netvrdil. Už jenom proto, že jsou různá hlediska efektivity, která jdou často proti sobě. A také různé způsoby použití.
Vytvoření pole referencí na objekty je javovinaA taky C++ovina, C#ovina, Pythonovina, JavaScriptovina, PHPovina atd. „Nativní“ je to možná tak v C.
nic to nepřináší (kromě zjednodušení garbage collectoru), co se týká přístupu do paměti je to neoptimálníCo se týče přístupu do paměti, je neoptimální pole objektů. Musíte předem vědět, jak je velké, jak velké jsou objekty, rezervovat místo na největší možný objekt, když s ním chcete něco dělat (filtrovat, řadit), musíte kopírovat celé objekty.
Nazývat převedení pole referencí na pole objektů předčasnou optimalizací je úplně mimo, pole objektů by měl být nativní přístup, ale není, protože Java...Abych pravdu řekl, pořád vám nevěřím, že máte opravdu takovou hrůzu z referencí. Myslím si, že ve skutečnosti reference normálně používáte, akorát to nechcete přiznat, protože pak byste najednou musel vysvětlovat, proč jsou reference někdy dobré, ale jakmile jde o pole, jsou špatné. Protože jestli seznam 1000 osob, z nichž každá může mít jméno, prostřední jméno, příjmení a rodné příjmení, každé po 100 znacích, opravdu vytváříte tak, že alokujete 400 kB, jenom abyste se vyhnul referencím, a říkáte tomu optimální využití paměti…
Jak to v Javě udělám?Především analyzuju, co ta příslušná část programu řeší, a budu se snažit najít nějaké jiné řešení. Nejčastěji to povede na jinou strukturu dat, možná jiný algoritmus. Pokud to náhodou bude ten výjimečný případ, kdy je potřeba mít data v paměti za sebou, uložím to třeba jako pole intů nebo bajtů.
Drtivá většina je co?Drtivá většina je 99 % všech aplikací.
Jste úplně vedle, s procesorem to vůbec nesouvisí. Jde o PAMĚŤ, protože pamět je násobně pomalejší než procesor. Jak funguje paměť je všeobecně známé, je mnohem rychlejší při sekvenčním čtení dat. Pokud mám velká data, vždy je výhodnější je mít v paměti za sebou. Není v tom žádná magie, je to úplně jednoduchý princip. Pokud nevíte, jak funguje pamět, tak raději zůstaňte u Javy, tam to ovlivnit nejde a budete spokojen.Nejvíce škod na výkonu aplikací napáchají programátoři, kteří pořád něco optimalizují, protože si myslí, že vědí, jak funguje paměť a procesor – myslí si, že přístup do paměti je O(1), pod přístupem do paměti si představují reálný režim i386 a to, že přístup do paměti mapuje runtime knihovna, operační systém i virtuální počítač zanedbávají, a optimalizují pro počítač s jedním procesorem a jedním vláknem, které provádí instrukce pěkně za sebou jak jsou ve spustitelném kódu.
Já ale nechci primitivní typy, chci normální objekty, proč bych to měl nějak hackovat?Protože jste zjistil, že je to výkonově kritické místo vaší aplikace, a bez hackování to optimalizovat nejde. To je dost dobrý důvod pro hackování. Rozhodně mnohem lepší, než „tady to určitě bude pomalé, tak to nahackuju preventivně“.
Cože???No jak je vidět i na této diskusi, do preventivních optimalizací se pouštějí především programátoři, kteří moc netuší, jak vypadá běh programu v moderním systému. Takže „optimalizují“ části programu, které to vůbec nepotřebují, „optimalizují“ tím, že hlavně znepřehlední kód, a občas ho pokazí tak, že už si s tím nic nezmůže ani kompilátor ani CPU, protože musí provádět ty nesmysly, které tam programátor při „optimalizaci“ napsal. Co se týče kvality výstupu, jsou na tom stejně, jako programátoři, kteří bez přemýšlení napíšou nějaký na první pohled nesmyslně zdlouhavý algoritmus, ale „optimalizátoři“ jsou proti nim nebezpečnější, protože si zpravidla nenechají vysvětlit, že dělají hlouposti.
Nic kopírovat nemusím. Naopak inicializace je mnohem rychlejší. Tam je ještě větší rozdíl než v průchodu. Nemusím alokovat paměť pro každou položku zvlášť.Nevytrhávejte věty z kontextu. O kopírování jsem psal v případě, kdy ty struktury vznikají v aplikaci v různém čase.
V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe.Když to bude pro výkon aplikace kritické, tak ta data (ne objekty) za sebe dám i v Javě. Klíčová je ta informace, že to v drtivé většině případů není důležité.
Jsou lidé, kteří chtějí, aby ty objekty byly v paměti za sebou, protože vědí, že je budou sekvenčně procházet.Ano, tohle je problém. Že si někteří lidé myslí, že vědí, jak funguje procesor, a snaží se program neuměle předem optimalizovat. V lepším případě to dopadne tak, že na výkonu nic nepokazí a jenom znepřehlední kód. V horším případě kód zkomplikují i pro procesor, takže ten „optimalizovaný“ program bude pomalejší, než neoptimalizovaný. A pak je hrstka těch programátorů, kteří dokážou změřit, kdy je potřeba kód opravdu optimalizovat, a opravdu ho zoptimalizují (což opět prokážou měřením). Přičemž ten program může být napsaný v libovolném jazyce.
Normálně se to řeší tak, že se vytvoří pole objektů (nikoliv pole referencí), což ale v Javě AFAIK nejde udělat.V Javě se to vyřeší například polem primitivních typů.
Problém nastane až s fragmentovanou pamětí, protože v Javě neovlivním, kde ten objekt bude v paměti fyzicky vytvořen.Což je dobře, protože problém ve skutečnosti nastane už v okamžiku, kdy to někdo začne „optimalizovat“.
Ten test je značně syntetický, normálně objekty vznikají v různém čase a nejsou v paměti za sebou.Ten test má porovnávat použití pole struktur a pole referencí. Pole struktur, které vznikají v různém čase, je velmi netypické použití. A pole struktur, které nejsou v paměti za sebou, není pole struktur. Pokud chcete porovnávat kód, kde objekty vznikají v různém čase a nejsou v paměti za sebou, zařaďte do testu i to, že ty struktury musíte do toho pole nejprve zkopírovat. A když už budete v tom testování, doporučuju změřit i paměťovou náročnost.
Diskuse se točí dokola, Jirsák odmítá uznat naprosto elementární fakta. Konkrétní příklady procházení pole jsem jsem popisoval už v příspěvku #32.Elementární fakta já uznávám. První, kdo sem nějaká fakta napsal, byl gl, a potvrdil, co tady celou dobu píšu:
Na mém počítači je průchod points dvakrát rychlejší než průchod ppoints2 a asi o 50% rychlejší než ppoints. Uznávám, čekal jsem větší rozdíl.
Zkus si porovnat rychlost průchodu dlouhého pole.Porovnat s čím? A co znamená „průchod pole“?
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.