Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Svobodný nemocniční informační systém GNU Health Hospital Information System (HIS) (Wikipedie) byl vydán ve verzi 5.0 (Mastodon).
a bastaTo je ale pádný argument
JIT překládá kód javy do instrukcí procesoru a na základě složitých analýz běhu provádí další optimalizace, díky kterým java může běžet stejně rychle (a někdy i rychleji) než zkompilovaný céčkový program.Trošku zjednodušeně: JIT překládá kód Javy na nativní a díky optimalizacím může ten program běžet rychleji než zkompilovaný céčkový kód. Nebo ještě zjednodušeněji: optimalizovaný nativní kód může běžet rychleji než nativní kód. To by jeden neřekl. Když byl JIT vypnutý, ábíčko se vleklo --> interpretovaná Java JE pomalá. Když se přeloží do nativní podoby, funguje mnohem rychleji, ale už to v podstatě není Java (procesor podle instrukcí těžko pozná, v jakém jazyce ten program byl napsán)
interpretovaná Java JE pomalá. Když se přeloží do nativní podoby, funguje mnohem rychleji, ale už to v podstatě není Java (procesor podle instrukcí těžko pozná, v jakém jazyce ten program byl napsán)Pak ale neni duvod zavrhovat javu. Ciste interpretovana java se vyskytovala tak v roce 1996, od te doby vznikly JIT kompilatory a byly vyladeny k maximalni optimalnosti. Java je narocna na pamet, ale v realnych aplikacich z hlediska rychlosti nezaostava za nativnimi programy (tim mam na mysli, ze by byla o nasobky ci rady pomalejsi).
Pak ale neni duvod zavrhovat javu.Jak kde... pokud jde o program, který běží několik týdnů v kuse někde na serveru (žádný příklad mě zrovna nenapadá
Nemyslím, že by interpret byl důvod nějakého výrazného zpomalení.Abych pravdu řekl, nechci se pouštět do nějakých porovnání jak velké zpomalení interpreter způsobí (Když to zjednoduším, Leoš v nadpisu tohoto blogu tvrdí že dvacetinásobné.) To, co tvrdím, je, že to zpomalení je zbytečné, když je tu možnost kód zkompilovat a interpreter úplně vynechat.
Vždy je to něco za něco. Kompilace něco stojí, i proto má Sunovské JRE dva režimy – v prvním se optimalizuje méně (tedy optimalizace je hotová dřív), takže start je rychlý, ale aplikace pak běží pomaleji. Ve druhém aplikace sice startuje dýl, ale optimalizuje se víc.Tady možná došlo k nedorozumění - já mluvil o možnosti kód zkompilovat z jazyka typu C++.
Stejně by se dalo říct, že je zbytečné používat operační systém. Pokud bude program přistupovat přímo k hardwaru, nebudou se "zbytečně" přepínat kontexty uživatelského prostoru a jádra a odpadnou "zbytečná" systémová volání, bude program taky rychlejší.Tohle srovnání tak trochu pokulhává - tohle už tu kdysi bylo a mělo to tu nevýhodu, že šlo spustit jenom jeden program naráz. OS je mezivrstva navíc, ale dle mého mínění ta možnost spouštět víc programů naráz a zabránit jim, aby se mezi sebou chybně ovlivnily, stojí za ten ztracený výkon. JVM nic takového neposkytuje, pro každý spuštění program v Javě se spouští znovu (a rozhodně neříkám, že je to špatně - proč by JVM měl řešit přepínání úloh, když to samé dokáže OS vyřešit za něj). Podle mě ta přidaná hodnota JVM (bez optimalizací) nestojí za to. Samozřejmě je tu velký prostor pro zlepšení. Napadá mě například situace (nevím, jak moc je reálná), kdy by JVM uměl provést optimalizace již při vývoji a testování programu a výsledky do programu uložit, aby je na nejrozšířenějších platformách vůbec nebylo nutné dělat (a aby se při opětovném spuštění mohly rovnou použít). To by podstatně měnilo situaci.
Podle mě ta přidaná hodnota JVM (bez optimalizací) nestojí za to.Dost lidí má asi jiný názor, když vznikají věci jako .NET, podpora virtualizace v Linuxovém jádru nebo virtualizační software. Někdy se to prostě vyplatí a jindy ne – záleží dokonce i na tom, co vše započítáte, takže i u jednoho a toho samého projektu může mít někdo názor, že přidaná hodnota VM je menší, než ztráta výkonu (protože počítá čistě efetktivitu běhu programu), někdo započítá i náklady na vývoj a údržbu programu, a najednou se nějaká přidaná hodnota vykoupená zpomalením vyplatí.
Samozřejmě je tu velký prostor pro zlepšení. Napadá mě například situace (nevím, jak moc je reálná), kdy by JVM uměl provést optimalizace již při vývoji a testování programu a výsledky do programu uložit, aby je na nejrozšířenějších platformách vůbec nebylo nutné dělat (a aby se při opětovném spuštění mohly rovnou použít). To by podstatně měnilo situaci.Při vývoji asi ne, během vývoje se program používá dost netypicky. Ale keš zkompilovaného kódu, která by přežila restart JVM, je jedno z možných řešení. Další možností je sdílení tříd mezi běžícími JVM (implementováno v Sunovském JRE od verze 1.5). Vzhledem k tomu, že např.
gcj
nejspíš nepředstavuje nějaké výrazné zrychlení proti klasické JVM, je spíš než kompilace do strojového kódu důležitá rychlost startu běhového prostředí (GC, classloader, "základní" třídy). Tedy spíš pomůže volitelné ponechávání JVM v paměti a nějaké optimalizace rychlosti startu GUI. Což jsou shodou okolností všechno věci známé z programů psaných v C++ – ať už je to ponechávání v paměti u OOo, Mozilly nebo MSIE, nebo různé prelink techniky grafických prostředí na Linuxu. Je vidět, že programy v Javě i C++ řeší vlastně stejné problémy if
v 99,9 % projde větví else
, takže vytvoří takový strojový kód, aby procesorové cache a "počítání napřed" šlo touhle větví (to je jen příklad, nevím, zda nějaká JVM konkrétně tohle dělá). Samozřejmě, V C si můžete takovou JVM naprogramovat taky, pak bude výsledný program i stejně rychlý – ale může to být zrychlení oproti klasickému Cčkovému if
u optimalizovanému pouze kompilátorem a procesorem.
Blahopřeju k odvaze se veřejně přiznat. Máš mé silné sympatie.
vim ~/.emacs
gcj
plně podporována. Myslím, že gcj
je slepá cesta…
eclipse
používá spoustu nativních knihoven. Mně osobně tedy připadá daleko nepochopitelnější ten Outlook a FF. Java také paměť využívá trochu jiným způsobem – naalokuje si od systému větší kus paměti, kterou si pak spravuje ve vlastní režii (GC). Taky jsem měl dříve pocit, že Java chce víc paměti, ale když to porovnám s FF, OOo, tak mám pocit, že víc paměti chce všechno… V té Javě se alespoň něco pro nižší paměťovou náročnost dělá.
Docela by mne zajímalo, kolik RAM máte a jaké aplikace na tom PC provozujete, protože 1 GB RAM podle mne už na Javu na desktopu stačí, eclipse trochu víc RAM neuškodí. Ne že by mne ty nároky na paměť těšily, ale obávám se, že je to všeobecný trend a paměťová nenažranost Javy se vyřešila/řeší tím, že takové paměťové nároky začínají být běžné.
0.05 0.18 0.21 1/220 10754To je rozdil
Tiskni
Sdílej: