Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
1. července Mozilla vypne službu Fakespot pro detekci podvodných recenzí v internetových obchodech. Mozilla koupila Fakespot v květnu 2023.
8. července Mozilla vypne službu Pocket (Wikipedie) pro ukládání článků z webu na později. Do 8. října si uživatelé mohou vyexportovat data. Mozilla koupila Pocket v únoru 2017. Několik měsíců byl Pocket integrovanou součástí Firefoxu.
Turris OS má aktuálně problém s aktualizací související s ukončením podpory protokolu OCSP u certifikační autority Let's Encrypt.
Nevidomý uživatel Linuxu v blogu upozornil na tristní stav přístupnosti na linuxovém desktopu (část první, druhá, závěr), přičemž stížnosti jsou podobné jako v roce 2022. Vyvolal bouřlivou odezvu. Následně např. Georges Stavracas shrnul situaci v GNOME. Debata o jiném aspektu přístupnosti, emulaci vstupu pod Waylandem, také proběhla na Redditu.
DevConf.CZ 2025, tj. open source komunitní konference sponzorovaná společností Red Hat, proběhne od 12. do 14. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Byla vydána nová major verze 28.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
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
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í.