Vývojáři postmarketOS vydali verzi 24.06 tohoto před sedmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, KDE Plasma a Sxmo. Aktuálně podporovaných zařízení je 50.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Google Blog ČR informuje, že mobilní aplikaci Gemini a NotebookLM lze používat už také v Česku.
Byla vydána nová major verze 8 duálně licencovaného open source frameworku JUCE (Wikipedie, GitHub) pro vývoj multiplatformních audio aplikací.
Od 18. června bude možné předobjednat notebook DC-ROMA RISC-V LAPTOP II od společnosti DeepComputing s osmijádrovým 64-bit RISC-V AI CPU a s předinstalovaným Ubuntu.
Byla vydána verze 1.79.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Byly zveřejněny výsledky průzkumu (infografika) mezi uživateli FreeBSD.
Na konferenci DevConf.CZ 2024 je na stánku Furi Labs prezentován linuxový telefon FuriPhone FLX1. Jeho cena 499 dolarů.
Bylo vydáno Eclipse IDE 2024-06 aneb Eclipse 4.32. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-2 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Tento zápis navazuje na Škálování quadcore při kompilaci jádra. Akce prováděne při instalaci software v Gentoo se od překladu jádra značně liší- zdrojáky je třeba stáhnout, rozbalit, opatchovat, nakonfigurovat a po kompilaci ještě nainstalovat a/nebo vytvořit balíček.
Hardware a software
Q6600 @ 3GHz, 4GB DDR2 datarate 830MHz CAS 5
Jádro linux-2.6.22-gentoo-r1, gcc 4.1.2
Metodika měřeni
/var/tmp/portage je umístěn na tmpfs. Měření se provádí pomocí
time emerge nazev > /dev/nulls volbou MAKEOPTS="-j4" resp. MAKEOPTS="-j2". Pozn. Doporučené je nastavit j na hodnotu počet_CPU+1 ale to jsme zde nemohli aplikovat. Pozorováním jak se mění čas při použití -j4 a -j5 jsem zjistil, že výsledek je ovlivněn pouze zanedbatelně. Výběr balíčku: co mi zrovna přišlo pod ruku Všechny potřebné soubory byly předem staženy pomocí emerge -f.
Běžné balíčky
-j2 [s] -j4 [s] j4/j2 mc 4.6.1-r4 33,17 30,2 91,04 % gnupg 2.0.5-r1 42,26 38,77 91,75 % vim-7.1.042 (+vim-core) 73,11 66,45 90,90 % gtk+ 2.10.14 177,63 145,02 81,64 % mysql 5.0.4-r1 250,75 202,11 80,60 % kaffeine 0.8.5 98,77 95,14 96,33 % krusader 1.80.0 129,42 110,04 85,02 % qt 3.3.8-r2 284,4 185,34 65,17 % mplayer 20070622-r3 110,2 75,74 68,73 % amarok 1.4.6-r4 227,3 191,74 84,35 % wine 0.9.42 356,92 240 67,24 % ---------------------------------------------- 1783,91 1380,54 77,39 %Je vidět, že urychlení ve velké míře záleží na aplikaci, potažmo na poměru neparaelizovatelných činností (rozbalení, patchovani, configure faze...) oproti samotnému překladu a taktéž na tom, jskou míru paraelizace dovoluje Makefile.
Ošklivé balíčky
Bohužel u části balíčků (samozřejmě přesně dl Murphyho zákonů jsou to ve velké míře zrovna ty, které trvají nejdéle) se žádného zrychlení nedočkáme.
-j2 [s] j4 [s] kdevelop 3.4.1 1158,13 1160,24 100,18 % kdelibs 3.5.7-r2 988,1 987,12 99,90 %kdevelop ma vynuceno -j1 už v ebuildu a vytíží proto pouze jedno jádro. kdelibs generuje v průmeru load 1,2.
Quadcore ano či ne?
Pokud uděláme průměr mezi všemi testovanými balíčky (a zamítneme možnost paraelního spouštění emerge) zjistíme, že celkové zrychlení činí pouhých 10 %. Opět si dovolím odvážně zaspekulovat- k dosažení výkonu Q6600@3GHz v této aplikaci by bylo zapotřebí E6600@3,42GHz, což je poměrně běžně dosahovaná hodnota. Na druhou stranu na quadcore si můžete zahrát při kompilaci třeba UT2004 a čas kompilace to zvýší u většiny balíčků pouze zanedbatelně Rozhodnutí nechám na vás.
Tiskni Sdílej:
Na E vám 4 nezávislé procesy pojedou v podstatě poloviční rychlostí než na Q.A co z toho pro uzivatele plyne? Lide nejsou zvykli takhle pracovat. V naproste vetsine chteji, aby byla hotova co nejrychleji jedna konkretni uloha a smitec.
tmpfs
?
/var/tmp/portage je umístěn na tmpfs.
Tipnul bych si, že v procesoru integrovaný řadič by v tomhle případě asi hodně pomohl, ale AMD ještě čtyřjádrové procesory neprodává, takže porovnání nebude.Taky bych čul problém tady. FSB je na intelí platformě nejužší místo a s rostoucím počtem procesorů se musí zužovat čím dál tím víc.
Neco takoveho jsem chtel presne napsat. V pocitaci je proste spousta komponent sekvencni (pameti, disky, ...). Ceka se take casto na sdilena data.
Dalsi problem bych videl v tom, ze napsat neco pro n vlaken, kde si n dopredu stanovim treba na 2 je jeste pomerne snadne. Ale napsat spolehlive neco pro n, kde se n odvodi az za behu je mnohem slozitejsi. Navic ono pokud si neco vicevlaknoveho zkusite napsat, tak zjistite, ze vas paralelni program zas tak paralelni byt nemusi.
Nesdileji mezi vlakny a tedy mezi jadry zadna data atd. Takze tady bych v tomto pripade problem opravdu nevidel.Nešlo mi o sdílení dat mezi jádry, ale o paměťovou propustnost. Překlad programu je na práci s pamětí dost náročný...
Kdyz A zavisi na B a B zavisi na C tak tyto tri cinnosti je proste nutne provest sekvencne.Tady vyloženě záleží na tom, jak je program napsán a rozdělen do souborů. AFAIK překlad většinou probíhá tak, že se nejdřív ze všech *.c zdrojáků přeloží *.o a ty se nakonec slinkují dohromady. Tu první část lze vcelku snadno provést paraleleně. Samozřejmě když je všechno v jednom souboru, tak už to tak jednoduché není.