Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Cílem tohoto zápisu je ukázat jak škáluje Q6600 při kompilaci kernelu. Obsahuje i odhad frekvence E6600 aby se v této úloze vyrovnalo Q6600.
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
Vzal jsem jádro linux-2.6.22-gentoo-r1 a zahrnul vše co šlo do jádra. Vznikl tím poměrně značný cvalík- bzImage téměř 12MB (pro srovnání běžně používané jádro má lehce přes 2MB). Abych co nejvíce vyloučil vliv IO provedl jsem nejdrříve 2 "zahřívací" kompilace a následně pomocí time měřil čas provedení make pro různou hodnotu parametru j (viz man make). Po každém měření bylo pochopitelně provedeno make clean.
Čas [s] -j 1 823,6 100% 1 -j 2 425,0 52% 1,94 -j 3 304,1 37% 2,71 -j 4 253,3 31% 3,25 -j 5 248,1 30% 3,32 -j 6 246,1 30% 3,35
Měřeni jsem chtěl zopakovat i pro 1 a 2 jádra ale to se ukázalo jako zbytečné- rozdil času make -j 2 na C2D a C2Q byl zanedbatelný a pro -j 3 se C2D chovalo stejně jako C2Q při přechodu z -j 4 na -j 5.
Interpretace
Při přechodu z -j 1 na -j 2 získáme o 48 % lepší čas. Je nutno dodat, že určité zrychlení se projeví i na počítači s jedním jádrem díky lepšímu využití času procesoru při čekání jednoho procesu na IO. I přes tento jev lze tento výsledek označit za velmi dobrý. Při přechodu z -j 2 na -j 4 získáme o 40 % času. Zde se již začíná citelněji projevovat to, že výkon procesoru není zdaleka jediným faktorem v této aplikaci. Projeví se omezení propustnosti sběrnic a paměti, zvýší se čas strávený čekáním na zámky v jádře a podobně. Celkově při přechodu z -j 1 na -j 4 ušetříme téměř 70 % času neboli urychlíme kompilaci 3.25x.Odhad frekvence E6600, které se vyrovná Q6600 @ 3GHz
Pokles času kompilace s rostoucí frekvencí není lineární a už vůbec neplatí, že n % nárustu frekvence povede ke stejnému procentuálnímu poklesu času kompilace. S něčím takovým se ale dost blbě počítá, proto jsem se rozhodl v okolí "pracovního bodu" 3GHz linearizovat. Experimentálně mi vyšlo, že 10% nárust frekvence vede k 7 % urychlení kompilace pokud taktujeme s procesorem současně i paměti a FSB. Je to značně nepřesné a nadhodnocující ale spokojme se s tím, že uděláme spodní odhad potřebné frekvence. Abychom stáhli čas 425s na 253s potřebujeme počítat o 59,5 % rychleji. K tomu potrřebujeme frekvenci 5.55GHz
Tiskni Sdílej:
However, the desktop PC is crap. It's rubbish. The experience is so bloated and slowed down in all the things that matter to us. We all own computers today that were considered supercomputers 10 years ago. 10 years ago we owned supercomputers of 20 years ago.. and so on. So why on earth is everything so slow? If they're exponentially faster why does it take longer than ever for our computers to start, for the applications to start and so on? Sure, when they get down to the pure number crunching they're amazing (just encode a video and be amazed). But in everything else they must be unbelievably slower than ever.
A ten HW neinicializuje BIOS, ale CPU, ktore je rychlejsie, v BIOSe je len program.Samozřejmě, že to dělá CPU a v BIOSu je jenom program. Všechno, co dělá BIOS, je program, který vykonává CPU.
Akoto, ze BeOS to dokaze tak rychlo?BeOS je operační systém, BIOS ne. Když spustím BeOS na PC (pakliže to vůbec jde) tak doba, za kterou BIOS inicializuje HW se vůbec nezmění.
Samozrejme, ze viem co je bios a co os, slo o to, ze kedze CPU je rychlejsie, aj start by mohol byt a tie timeouty ma vobec netrapia,...Timeouty tě vůbec netrápí, ale kdyby se vynechaly, tak by sis stěžoval, že ten a ten kus HW je špatný, protože ti nefunguje. Ostatně když jsi tak chytrý, tak proč nepracuješ na linuxbios? Ten startuje rychleji než BIOS obyčejný.
...cela PC architektura je na ho...No jasně, teď jsi to rozlousknul.
Pokud se doba nezměnila, přestože CPU se 100x zrychlilo, znamená to že se a) dělá 100x víc věcíTo jsem řekl v bodech 2 - 4.