PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
Po půl roce od vydání verze 2.41 byla vydána nová verze 2.42 knihovny glibc (GNU C Library). Přehled novinek v poznámkách k vydání a v souboru NEWS. Vypíchnout lze například podporu SFrame. Opraveny jsou zranitelnosti CVE-2025-0395, CVE-2025-5702, CVE-2025-5745 a CVE-2025-8058.
Byla vydána nová verze 9.15 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Speciální zájmová skupina věnovaná programovacím jazykům (SIGPLAN, Special Interest Group on Programming Languages) Asociace pro výpočetní techniku (ACM, Association for Computing Machinery) vyhlásila na slavnostním ceremoniálu v rámci konference PLDI 2014 vítěze letošní Programming Languages Software Award. Ocenění získal projekt GNU Compiler Collection (GCC).
Tiskni
Sdílej:
Třeba násobení matic přeložené g++ běželo 64 sekund, ale verze kompilovaná icc běžela pouhých 0.85 sekund.Tak tohle vypadá jako problém, který by zasloužil podrobnější diagnózu. ICC má možná (nevím...) o něco lepší autovectorizer, ale tohle zní jako patologický případ, nemyslíte? (Zkoušel jste to disassemblovat?)
ICC by default uses a ‘fast-math’ like mode.
-floop-interchange
? Ve všech banchmarkách je ale gcc za msvc. Intel je zase vždy rychlejší, než msvc, a v krajním případě i dvojnásobně – měřeno průměrnými benchmarky.Pozor, tohle je dost zkreslené použitou sadou benchmarků. O ICC se tuší, že jejich vývojový tým tráví obrovské množství času optimalizováním překladu standardních benchmarků, takže na reálných programech dopadne srovnání překladačů často jinak, zvlášť pokud nekompilujete pro procesor od Intelu, ale od AMD :) Mé osobní testy naznačují, že ICC je sice hodně dobré, ale že GCC ho v mnoha konkrétních případech předhoní. Zejména díky globálním optimalizacím, ve kterých se GCC za posledních pár let výrazně zlepšilo.
By design má clang limitovánu rychlost výsledné binárky.Jak konkretne?
clang++ 3.4.1 : 1.84s g++ 4.7.3 : 2.60s icc 13.1.3 : 4.83sVe všech případech byl kód přeložen s parametry
-O3 -march=native
(pro Core i7 3630QM).
Rychlost překladu je nepřímo úměrná kvalitě kódu. Proto defaultně dobré kompilátory moc neoptimalizují.Jinak doufám, že si s touto větou děláte srandu. Jako vtip je to dobré.
-ipo
? U icc 14.0.3 to stáhne na nějakých pět sekund. U té starší verze jsem nepozoroval rozdíl.
A pak záleží na vyjadřovací síle toho mezijazyka, jestli vymáčknutelné maximum při optimalizace je o hodně horší, nebo jen mírně nižší, než u kompilátorů, které toto nedělají.LLVM i GCC pouzivaji IR zalozenou na SSA, ergo jejich moznosti optimalizovat jsou +/- stejne. IMHO kvalita vystupniho kodu je spis dana poctem clovekohodin, ktere byly do toho ktereho prekladace vlozeny.
Znovu zopakuji klíčový termín z toho, co jsem napsal: „pevně definovaný mezijazyk“.Uvedomte si, ze vase tvrzeni o nevhodnosti pevne dane IR jsou jen vase domenky, ktere vydavate za fakt. Ve skutecnosti IR LLVM je mnohem expresivnejsi nez v pripade GCC.
nepočítačový člověk jasně chápeTakto to chape asi nepocitacovy clovek. Nicmene realita je malinko jina, protoze i IR v GCC je de facto pevne dana (jen to mozna nevite), takze tady popirate vlastne sam sebe. Pocitacovy clovek vi, ze k ziskani dobreho vysledku jsou dulezite datove struktury a s nimi pracujici algoritmy. Jelikoz v LLVM i GCC se pouziva reprezentace zalozena na SSA, mnozina pouzitelnych optimalizacnich algoritmu je stejna.
clang/llvm má pvně daný mezijazyk přímo jako součást standardu projektu. Když zjistíte jeho nedostatky, vylepšovat ho budete těžko.Kdyz se zjisti nedostatky v pripade IR u LLVM, tak se zmeni IR a vyda se nova verze a budou se muset upravit vsechny front-endy. Kdyz se zjisti nedostatky v pripade IR u GCC, tak se zmeni IR a vyda se nova verze a budou se muset upravit vsechny front-endy. Nejdete deset rozdilu.
Kromě toho, RTL v gcc je zaměřen na to, aby byl blízko strojového kódu, tedy co nejlépe optimalizovatlenýUz jsme doma! Vite, pise se rok 2014 a GCC vypada uplne jinak, nez v minulem stoleti.
Stejně tak stačí mezijazyky porovnat, trváte-li na tom: https://gcc.gnu.org/onlinedocs/gccint/RTL.htmlBylo by dobre podivat se o kapitolu vys: https://gcc.gnu.org/onlinedocs/gccint/Tree-SSA.html#Tree-SSA Ale ja vam to vysvetlim, at se tu priste neztrapnujete: Kod je prolozen do interni reprezentace, ktera se oznacuje jako (GENERIC/GIMPLE), ktera je naprosto nezavisla na jazyku i cilove platforme (stejne jako v pripade LLVM), nad tim se dela spoooousta optimalizaci a pak je prelozena do RTL a az z toho se generuje binarka.
Llvm má v zásadě úplně stejnou konmcepci jako .NET nebo Java.To je fakt hodne prehnane pripodoneni.
llvm má mezijazyk jako standarndí rozhraní a jako jeden jazyk, který můžete používaLLVM ... odpovida back-endu gcc, clang ... front-endu v gcc. V cem je problem?
optimalizace je druhořadá při návrhu toho mezijazyka.Zajimave... a pritom LLVM vzniklo puvodne jako vyzkumny projekt zamereny na optimalizace....
Gcc, bez ohledu na to, co je v něm DNES, nemá pevně daný mezijazyk.Aha, a GENERIC+GIMPLE se mažou na chleba, že...
Ještě by se dalo dodat, že kdyby llvm architektura umožňovala lepší optimalizaci, tak už jí šupito presto začne používat jak Intel, tak Microsoft. Ale oni nemají tendenci se jí inspirovat a dobře vědí proč.Jako by se stalo. :-]] Ve skutecnosti GCC s verzi 4.0 presel na architekturu, ktera odpovida LLVM.
Vidíte, dáváte mi zcela zapravdu.Ne.
Když ho bude chtít změnit, tak jedině tak, že llvm jako projekt zanikne jako celek. A pojede se od nuly jinde.Tohle je falesna dichotomie.
Já sice chápu, že deda.jablko mě osobně nesnáší,To je nesmysl. Ve skutecnosti jste mi uplne lhostejny.