Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Po pěti měsících vývoje byla vydána nová verze 0.15.1 programovacího jazyka Zig (GitHub, Wikipedie). Verze 0.15.0 byla přeskočena. Přispělo 162 vývojářů. Přehled novinek v poznámkách k vydání.
Před sedmi lety společnost Valve představila fork projektu Wine s názvem Proton umožňující v Linuxu přímo ze Steamu hrát počítačové hry do té doby běžící pouze ve Windows. Aktuální přehled podporovaných her na stránkách ProtonDB
Společnost DuckDuckGo rozšířila svůj AI chat Duck.ai o GPT-5 mini (𝕏). Duck.ai umožňuje anonymní přístup bez vytváření účtů k několika modelům umělé inteligence. Aktuálně k GPT-4o mini, GPT-5 mini, Llama 4 Scout, Claude Haiku 3.5 a Mistral Small 3.
Marek Tóth v příspěvku DOM-based Extension Clickjacking: Data ve správcích hesel v ohrožení na svém blogu popsal novou clickjacking techniku s několika variantami útoků a otestoval ji proti 11 správcům hesel. Výsledkem bylo nalezení několika 0-day zranitelností, které mohly ovlivnit uložená data desítek milionů uživatelů. Jedno kliknutí kdekoliv na webové stránce kontrolované útočníkem umožňovalo ukrást uživatelská data ze
… více »Na dnešní akci Made by Google 2025 (YouTube) byly představeny telefony Pixel 10 s novým čipem Google Tensor G5 a novými AI funkcemi, hodinky Pixel Watch 4 a sluchátka Pixel Buds 2a.
Java je dneska ve složitých výpočtech stejně rychlá jako C++. Výkonostní rozdíly jsou zanedbatelné, ať už je v konkrétním případě Java pomalejší nebo rychlejší, a programátor by měl raději upřednostňovat rychlost vývoje.Ano, a proto Peter Norvig prohlašuje, že výkon Javy je žalostný i v 21. století? Proč tedy Google na ty složité výpočty používá kombinaci C++ a Pythonu a ne Javu?
g++ -c -pipe -O3 -fomit-frame-pointer -march=pentium4 binarytrees.gpp-2.c++ ...
) a kolik pro Javu (způsob překladu autor vůbec neuvádí - jaký byl cílový bytecode? stripnul debug informace? jaký použil překladač? způsob spouštění: java $JDKFLAGS -server -Xbatch
). Nemluvě o tom, že tihle autoři znají akorát sunovskou Javu...
I nejnovější g++ a super zoptimalizovaný kód přeložený g++ generuje velmi výrazně horší a pomalejší kód, než Microsoft Vistual Studio 6 z roku tuším 1996 bez jakéhokoli nastavování optimalizačních parametrů.Vzpomínám na jeden výpočetně orientovaný program v C++. Zkusil jsem ho zkompilovat (vždy s maximální optimalizací) na MSVC++ a na g++. Microsoftím kompilátorem zkompilovaný program byl o cca 7 % rychlejší.
Java je dneska ve složitých výpočtech stejně rychlá jako C++.Tak tomu snad sám nevěříte... Docela by mne zajímalo, jak jste na to přišel. Z osobních zkušeností si jsem naprosto jist, že ve složitých výpočtech je Java pomalejší. Například, když pracuji s neuronovými sítěmi, tak jsem první implementaci projektu napsal v C, trénování sítě trvalo mezi 20-21 hodinami, následně jsem chtěl s kódem trochu experimentovat, což se mi s céčkovou implementací zdálo nepohodlné, tak jsem kód přepsal do Javy a doprogramoval nějaká rychlostní vylepšení - dnes mi Javová aplikace seběhne v čase většinou o půl hodiny pomalejším. Tu samou zkušenost mám s kompresními algoritmy, kterým se dnes sice až tak nevěnuji, ale opět třeba Range kodér s modelem řádu nula byl v C++ vždy znatelně rychlejší, než stejná implementace v C# v .NET Frameworku 1.1 a později i 2.0 ve Windows. Musím však uznat, že co se pohodlí týká, tak Java a C# vedou nad C a C++, ale to asi není nic nového.
Kdyby Javu zakazali, tak spotreba elektriny celosvetove klesna aspon o 10%.
A co potom takové Gentoo
Ano, souhlasím. S tím, že ty jiné jazyky dosahují stejnou rychlost jako Java za výrazně nižší spotřeby systémových zdrojů - především paměti.
To musí být opravdu silná nenávist, když v každé větě, který by jinak vyzníval pro Javu alespoň neutrálně, uvedete nějaké negativum.
Ač uznávám, že ta potřeba použít asm je v 0,01%, MI asi nebude moc dobrá škola, pokud prohlásí jednoznačný nepravdivý závěr bez dalšího.
Matematická Informatika, Přírodovědecká fakulta University Palackého v Olomouci. Že to není dobrá škola jim řeknete Vy, nebo to mám udělat za Vás?
Byla řeč o x86 PC, které tehdy měli 512MB RAM a za rok budou mít 8GB. S procesory, které si přehazují instrukce podle aktuální situace. S instrukční sadou doplňovanou s každým dalším modelem. Psát 100% odladěný kód v ASM, to bych nedělal nic jiného, než nonstop studoval změny v nových CPU. Naopak jsem rád, že to za mě na 80% udělá překladač. U jednočipů jsem měl vždy větší problém se vejít do paměti, proto jsem ASM optimalizoval na velikost, rychlost byla taky důležitá, ale vejít se to tam prostě muselo.
Byla řeč o x86 PC, které tehdy měli 512MB RAM a za rok budou mít 8GB.Hmm, a těch 8GB do paměti dostanete jak? A z paměti do procesoru? A to všechno je zadarmo?
Jestli to opravdu všechno leží jen na té rychlosti (jak se mohu domnívat z vašeho příspěvku), tak se to časem umlátí silou HW. Dnes už přece také nikdo nemá potřebu vyvíjet hratelné gamesky do pamětí řádů kB a procesorů typu Z80, ne?Na to jsem reagoval, že není pravda, že Java je pomalá a že ani neplatí rovnítko ASM=rychlé. Pak došlo na HW (a týkalo se to především CPU). Přečtěte si to sám. Nikde jsem nepsal o jednom stále stejném algoritmu hůře a hůře napsaném nebo přeloženém a proto vyžadujícím více RAM a CPU. Naopak. Jestli má někdo pocit, že dnešní programy umí stejně jako ty co před šesti lety, ale potřebují k tomu šekrát větší výkon, tak nechť otevře oči.
"Jestli má někdo pocit, že dnešní programy umí stejně jako ty co před šesti lety, ale potřebují k tomu šekrát větší výkon, tak nechť otevře oči."Ehm, v mnoha případech tomu tak je.
Když se tak kouknu na to, kolik výkonu si vzaly programy před pár lety a co berou teď, tak mi je z toho chvílema poněkud nevolno.Když se kouknu na to, jak pomalé je dnešní GTK, je mi chvílemi opravdu nevolno
java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)
java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b05) Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode)
Například Azureus, nebo Eclipse jsou nechutně pomalé, že se nedají skoro ani používatAzureus se nedá používat? Mně tu běží rovnou 2x a používat se dá dost dobře
Ale v globále ani jeden z výše zmíněných virtuálních strojů se příliš nehodí na dynamicky typované jazyky, takže třeba pro Perl, nebo pro Python se vyvíjí Parrot a další virtuální stroje.A co DLR?
vim ~/.emacs
To je velmi optimistické. Já bych toto netvrdil. Ale řekněme, že obecně je větší tolerance vůči nenažraným programům, než byla dříve. Přesto bych řekl, že Java to dost přehání - a mnoho lidí prostě Javu odmítá vůči pomalosti/žravosti. Pro jistotu napíšu, že je jedno, jestli za to může Java, nebo neschopný Javista co to naprogramoval - uživateli je to zcela jedno. Javovské programy mají speciální pověst - a mnoho lidí, kteří ani neumí programovat odmítne program v Javě, má-li náhradu v čemkoli jiném.
Tohle jsem tu četl už tolikrát, že na to konečně musím reagovat. Podívejte se to poradny a najděte si tam dotazy ohledně spotřeby paměti v Linuxu. Dotaz je typu: "Mám 768MB RAM a volný jen 52MB, přitom mám spustěný jez Firefox. To jsou ty linuxi tak žravý na paměť???" Následuje vysvětlení, že 600MB je cache.
Na tom samém portálu se neustále dočítám, že Java je náročná na paměť. Přečtěte si prosím něco o tom, jak JVM hospodaří s pamětí. Linux má své cache, JVM taktéž (akorát se to jmenuje jinak). Pokud ván Java app žere moc paměti, změnte si parametry JVM.
"Pokud ván Java app žere moc paměti, změnte si parametry JVM."To jsem zvědav, jestli mi zrovna tohle to využití paměti XEPem srazí z těch 1.4 GB někam rozumně dolů.
V nějakém příspěvku výše se rozplýváte, jak g++ je třeba nastavovat s optimalizačními parametry, zatímco o Javu se není třeba starat - byl to případ benchmarku. A teď z Vás vypadne, že g++ stačí nastavit jednou při kompilaci a uživatelé to mají bez práce, zatímco Javu aby si nastavoval každý uživatel včetně posledního BFU, jinak mu pojede špatně.
Spletl jste si uživatele, o g++ jsem nic nepsal.
A opravdu si myslíte, že všichni kromě Herona jsou nýmandi, co nejsou schopni zjistit skutečnou spotřebu paměti procesem?
To rozhodně ne a ani to z mého komentáře neplyne. Jen jsem se pozastavoval nad tím, že na stejném portálu lidi vysvětlují jak je to se spotřebou paměti v linuxu (a že je to takto dobře) a na druhé straně nadavájí na "stejně" spotřebovanou pamět v JVM (kde je to podle nich špatně).
Pokud se bude potřebná paměť blížit té, které jste JVM dal, bude gc makat jak vzteklé a efektivita jde prudce dolů. Prostě Java potřebuje plýtvat pamětí - je to podmínka efektivního běhu javovského procesu.
Totéž co výše. Dejte Linuxu, Windows, Macu 1GiB RAM a spusťtě tam program (třeba v C++), který reálně potřebuje 1000MB. Uvidíme, jak to pojede.
Pokud dáte programu v Javě, který potřebuje 1 GB RAM přesně 1 GB RAM, JVM se umlátí na častém spouštění garbage collectoruTohle snad děláte schválně
Program v C++ nepotřebuje nadbytek paměti pro efektivní běh.
Ale potřebuje. Jenže se to maskuje jako buffers a cache v systému pod ním. Pod programem v javě je co? Ano správně JVM. Má-li OS pro C++ program k disposici 600MB cache, dopřejme to i JVM.
Ale potřebuje. Jenže se to maskuje jako buffers a cache v systému pod ním. Pod programem v javě je co? Ano správně JVM. Má-li OS pro C++ program k disposici 600MB cache, dopřejme to i JVM.Opravdu si myslíte, že se JVM obejde bez té cache v systému pod ním?
Inak ked sa ti zda ze java aplikacie su rovnako rychle, skus si nainstalovat solaris kde ich je podstatne viac a potom nam o tom nieco povedz.Pokud vím, tak zrovna na Solarisu je Java nejpomalejší a nejžravější. Je to docela pikantní, vzhledem k tomu, že je obojí produktem téže firmy a mělo by to tedy být nejlépe sladěno.
A pan Kyosake by si asi taky rval vlasy, kdyby se někdo pokusil jeho oblíbený LISP přechroustávat na Java mašině a on to musel používat.Zase mně przníte.
velmiDlouheIdentifikatoryKtereSeBezIdeTemerNedajiNapsatPříklad z praxe bude?
FormatFlagsConversionMismatchException
ffcmex
, který bez manuálu nikdo nerozluští.
Na druhou stranu je to (hlavně u méně používaných věcí) názornější než mít identifikátor ffcmex, který bez manuálu nikdo nerozluští.No to každopádně.
Obzvlaste v (dnes jiz ustupujicimu) trendu co nejrychlejjsi cpu a ram az co "zbyde".Tohle bývalo (a ještě do značné míry je) doménou PC v hypermarketech. Dají do letáku údernou hodnotu rychlosti procesoru a k tomu nízkou cenu. Šetří samozřejmě na grafice, disku, a hlavně operační paměti.
"samozdrejme ne objektove ale jako parametr"Fuj, za tohle bych střílel lidi u zdi. Co jiného je příjemce zprávy, než skrytý (v případě Smalltalku, Javy, C++ a podobně - v případě CLOSu/Dylanu je naopak viditelný) parametr, nad kterým se dispatchuje? Až tyhle jazyky konečně budou umět dispatch podle více parametrů, budou "méně objektové" či co?
Donekonečna omýlaný argument. Podle Moora (nebo jak se jmenuje), se výkon PC zdvojnásobí za jeden až dva roky. A to platí i o paměti. PC se většinou tak často nekupuje. Nevšiml jsem si, že by na stejném PC stejná aplikace (pravidelně aktualizovaná) jela stále a stále pomaleji - většinou se optimalizuje a jede lépe. Naopak, když už koupím nový stroj, většinou na něj naložím mnohem víc, než co běželo na tom původním starém, nebo je to výrazně kvalitnější (teď mám výkon, tak zkusím 16xFSAA - třeba).s rozšiřováním stále nabouchanějších počítačů, klesá handicap větších nároků na strojový čas a paměť....tak todle je presne argument kterej neberu! prece si nebudu kupovat novy stroj jenom kvuli tomu aby mi to bezelo zase stejne pomalu...
... A nez si ve svem Ccku/Lispu/Pythonu atd vyresite data storage, konfiguraci, formulare apod ja mam hotovy tri dalsi programy.Ano, někdo potřebuje sekat programy jako baťa cvičky a někdo potřebuje psát programy o kterých se vám zjevně ani nezdálo ať už co do požadované komplexity, spolehlivosti, nebo výkonu.
persistent-class
místo standard-class
), nulovou konfigurací...co proti tomu postavíš, Hibernate? Chm. Lidi jen leckdy nevědí, co pro tyhle jazyky existuje. (Samozřejmě, Franz si účtuje za tyhle věci šílený prachy. Ale taky poskytuje dokonalý služby...)
Visty byly puvodne napsane v C#. Kvuli kompatibilite a vykonu se vse prepsalo znova v C++.Což je docela škoda.
Tiskni
Sdílej: