Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Odkazy
minetestmapper.py
pre generovanie obrázku z aktuálnej mapy. Vygenerovanie mapy s týmto nástrojom trvalo približne hodinu, čo spôsobovalo prehrievanie CPU. Preto (a samozrejme aj zo zvedavosti) som sa rozhodol prepísať tento nástroj do C++. Dnes som sa tento program pokúsil použiť ako malý nesytetický benchmark kompilátorov. Okrem neho v blogu nájdete zopár informácií o fungovaní hry minetest.
Minetest je slobodný klon hry minecraft napísaný v C++. Zdrojové kódy hry sú dostupné na Github-e. Aplikácia používa engine irrlicht. Skriptovanie je možné v jazyku LUA, možnosti sú však zatiaľ dosť obmedzené kvôli chýbajúcemu API. Napriek spomínaným obmedzeniam v tejto hre vznikajú podobné „divočiny“ ako v pôvodnom minecrafte. Malú ukážku je možné nájsť v minetest fóre.
Celá hra minetest je podobne ako minecraft založená na voxeloch (obdoba pixelov v 3D). Mapa sa skladá z kociek pevnej veľkosti, ktoré môžu byť rozmiestnené len na presných pozíciách v štvorcovej mriežke.
Svet môže mať rozmery 4096 blokov vo všetkých 3 rozmeroch. Každý blok sa skladá z 16 ∗ 16 ∗ 16 voxelov. Svet môže mať teda rozmery 65536 ∗ 65536 ∗ 65536 (281 474 976 710 656) voxelov. Pri takomto množstve voxelov samozrejme nie je možné rozumne pracovať s celou mapou a tak mapa obsahuje len už vygenerované v minulosti použité bloky.
V aktuálnej verzii minetestu sa mapa ukladá do SQLite databázy (áno čítate správne). Databáza obsahuje jedinú tabuľku s dvomi stĺpcami - pos (long) a data (blob). V stĺpci pos sú zakódované všetky 3 súradnice. Súradnice sú 12-bitové signed čísla, spolu zaberajú 36 bitov, čo sa bez problémov zmestí do 64-bitového typu long.
Prvých 8 bitov každého bloku obsahuje číslo verzie. Pri ďalšom popise budem predpokladať, že obsahuje najnovšiu verziu. Po pár-bytovom offsete nasledujú dva bloky dát komprimované zlib-om. Pre generovanie mapy je pre nás podstatný len prvý obsahujúci 16 ∗ 16 ∗ 16 16-bitových čísel (až sa vám to zdá šialene nadýchnite sa na chvíľu, lebo to čo príde rozhodne nebude pekné), ktoré odkazujú do tabuľky materiálov bloku (k tej sa dostanem v nasledujúcom odseku).
Po prečítaní (a zahodení) metadát sa dostaneme k tabuľke materiálov. Každý blok má svoju vlastnú tabuľku materiálov, čo je zoznam dvojíc id materiálu - názov materiálu. ID je 16-bitové číslo a názov je reťazec maximálnej dĺžky 65536 znakov. Základné materiály majú anglické názvy ako „air“, „water“, „sand“ … Materiály definované v skriptoch majú väčšinou tvar prefix_skriptu:názov
.
Materiály sa prevádzajú na farbu podľa konfiguračného súboru colors.txt. Prvá položka riadku je názov materiálu, za ktorým nasledujú hodnoty červenej, zelenej a modrej farby. Celý prevod materiálu voxelu na farbu vyzerá teda nasledovne:
Pri generovaní obrazu sú voxely mapované presne na pixely. Pre každý pixel mapy je potrebné najskôr nájsť neprehľadný materiál na najvyššej pozícii na y-ovej osi. Podľa materiálu sa na danej x a z pozícii vykreslí pixel.
Počas vykresľovania obrazu sa pre každý pixel zaznamenáva aj y súradnica. Podľa nej sa následne vykresľuje tieňovanie terénu.
Pôvodný generátor mapy je napísaný v pythone. Najviac procesorového času je tu spotrebovaného na jednoduché operácie ako bitové posuny, logický OR, posuny v streame … Tie sú v C++ vykonávané väčšinou 1 taktom CPU. Python však interpretuje bytecode a každá jednoduchá operácia preto trvá niekoľko taktov CPU.
Nasledujúce časy sú namerané pre moju malú testovaciu mapku (752px ∗ 512px). Testovací stroj ma CPU Intel Core2 Duo T5250 (1.5GHz):
Interpret | Čas |
---|---|
Python 2.7 | 120,04s |
PyPy 1.9 s JIT | 87s |
Môj pomerne chaotický prepis Python verzie do C++ je možné nájsť na Github-e. Kód nie je úplne ekvivalentný, ale výstup je takmer na pixel rovnaký (python verzia má nejaký bug, ktorý sa mi nepodarilo opraviť).
Pri benchmarkovaní bol každý test spustený 50x. Meraný bol čas od spustenia po ukončenie aplikácie (tj. nie len procesorový čas, ale aj I/O a čas strávený systémovými volaniami). Pri optimalizácii O1 a vyššie bol zapnutý flag -march core2
. Súhrnné výsledky sú v nasledujúcej tabuľke.
Kompilátor | Priemer | Interval spoľahlivosti (90%) | Minimálny čas | Maximálny čas |
---|---|---|---|---|
gcc-4.5 (O0) | 2.515 | 2.486 - 2.544 | 2.489 | 2.576 |
gcc-4.6 (O0) | 2.523 | 2.498 - 2.549 | 2.497 | 2.573 |
gcc-4.6 (O0, lto) | 2.518 | 2.495 - 2.541 | 2.493 | 2.545 |
gcc-4.7 (O0) | 2.553 | 2.529 - 2.577 | 2.532 | 2.577 |
gcc-4.7 (O0, lto) | 2.541 | 2.518 - 2.563 | 2.519 | 2.571 |
llvm-3.1 (O0) | 2.464 | 2.425 - 2.502 | 2.435 | 2.586 |
gcc-4.5 (O1) | 1.525 | 1.508 - 1.541 | 1.509 | 1.548 |
gcc-4.6 (O1) | 1.517 | 1.503 - 1.531 | 1.503 | 1.532 |
gcc-4.6 (O1, lto) | 1.498 | 1.475 - 1.520 | 1.480 | 1.519 |
gcc-4.7 (O1) | 1.469 | 1.452 - 1.487 | 1.452 | 1.505 |
gcc-4.7 (O1, lto) | 1.484 | 1.469 - 1.500 | 1.468 | 1.504 |
llvm-3.1 (O1) | 1.648 | 1.629 - 1.666 | 1.631 | 1.669 |
gcc-4.5 (O2) | 1.443 | 1.423 - 1.462 | 1.428 | 1.484 |
gcc-4.6 (O2) | 1.441 | 1.425 - 1.458 | 1.425 | 1.467 |
gcc-4.6 (O2, lto) | 1.439 | 1.424 - 1.454 | 1.424 | 1.456 |
gcc-4.7 (O2) | 1.456 | 1.439 - 1.473 | 1.441 | 1.478 |
gcc-4.7 (O2, lto) | 1.443 | 1.424 - 1.462 | 1.428 | 1.491 |
llvm-3.1 (O2) | 1.420 | 1.405 - 1.435 | 1.405 | 1.442 |
gcc-4.5 (O3) | 1.424 | 1.408 - 1.440 | 1.408 | 1.448 |
gcc-4.6 (O3) | 1.438 | 1.422 - 1.455 | 1.421 | 1.457 |
gcc-4.6 (O3, lto) | 1.439 | 1.422 - 1.456 | 1.422 | 1.459 |
gcc-4.7 (O3) | 1.443 | 1.427 - 1.459 | 1.426 | 1.462 |
gcc-4.7 (O3, lto) | 1.442 | 1.425 - 1.460 | 1.429 | 1.467 |
llvm-3.1 (O3) | 1.418 | 1.401 - 1.436 | 1.404 | 1.439 |
gcc-4.5 (OS) | 1.568 | 1.549 - 1.588 | 1.552 | 1.591 |
gcc-4.6 (OS) | 1.562 | 1.544 - 1.581 | 1.546 | 1.610 |
gcc-4.6 (OS, lto) | 1.531 | 1.510 - 1.551 | 1.510 | 1.555 |
gcc-4.7 (OS) | 1.563 | 1.547 - 1.579 | 1.544 | 1.582 |
gcc-4.7 (OS, lto) | 1.566 | 1.550 - 1.583 | 1.549 | 1.587 |
llvm-3.1 (OS) | 1.452 | 1.437 - 1.467 | 1.436 | 1.474 |
Nasledujúci graf je vizualizáciou tabuľky. Priemer je znázornený čiernou značkou. Obdĺžnik je 90% interval spoľahlivosti. Vrchné a spodné modré značky sú minimálnou a maximálnou nameranou hodnotou.
Kód prepísaný do C++ je na mojom stroji približne 60x rýchlejší než python kód.
Prvenstvo v rýchlosti kódu napriek mojim odhadom nezískalo g++ so zapnutou link time optimalizáciou, ale relatívne mladý kompilátor llvm s frontendom clang.
Tiskni Sdílej:
gcc 4.7 s -O3 a -lto má s -fprofile-use (samozrejme predtým som spúšťal s -fprofile-generate) prakticky totožné výsledky ako v testoch v blogu: priemer 1.4497, int. spoľahlivosti 90% 1.4283-1.4717, min 1.427, max 1.494.
Na najnižšej úrovni by bolo vhodné funkciu aplikovanú na pixely prepísať do C.Ještě lepší variantu představuje cython, kde je snadné přepsat jenom tu kritickou část do ekvivalentního C-like staticky typovaného kódu.
Po prečítaní (a zahodení) metadát sa dostaneme k tabuľke materiálov. Každý blok má svoju vlastnú tabuľku materiálovJinak chválím použití SQLite. Je to lepší, než vymýšlet vlastní yet another db a potýkat se s problémy, které jsou už dávno vyřešené.
Proč má každý blok svoji vlastní tabulku (to je tedy zřejmně onen druhý blok dat v jednom záznamu) materiálů?
Neviem prečo má vlastnú tabuľku keď by sa to dalo riešiť goláblnou. Druhý blok komprimovaných dát sú metadáta, čo je key-value datastore na rôzne účely (napr. rôzne krabice, vlaky ... používajú položku "inventory" pre záznam objektov uložených v inom objekte). Tabuľka je uložená až za metadátami v nekomprimovanej forme.
Jinak chválím použití SQLite. Je to lepší, než vymýšlet vlastní yet another db a potýkat se s problémy, které jsou už dávno vyřešené.
Táto implementácia je len prenesenie pôvodnej súborovej implementácie do databázy. Prvé verzie mali mapu uloženú ako množstvo malých súborov s rovnakým názvom ako stĺpec pos v databáze a rovnakým obsahom ako stĺpec data.
SQLite je dobrá keď má obsluhovať jedného klienta. V minetest serveri sa mi zdá, že je diskové IO hlavnou prekážkou väčšieho množstva hráčov.
SQLite je dobrá keď má obsluhovať jedného klienta. V minetest serveri sa mi zdá, že je diskové IO hlavnou prekážkou väčšieho množstva hráčov.S jakoukoliv databází na disku nemáš šanci. Tohle musíš udržet v paměti a čas od času (jednotky minut) udělat záložní kopii na disk. Pokud máš návaznost na okolní svět (jiná aplikace), tak pak držet záznam o provedených operacích pro případný rollback nebo rekonstrukci.