Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
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á ) a JIT kompilátor ho odladí, tak je Java stejně dobrý jazyk jako většina jiných. Problém je, že v Javě dost lidí vyvíjí uživatelské programy, které se spustí, vykonají nějakou práci a ukončí se, to vše interpretovaně a tedy většinou zbytečně pomalu. Takové nasazení Javy mi přijde, když použiju tvoje slova, "zavrženíhodné".
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: