Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
V tomto postu Miguel de Icaza porovnává paměťovou náročnost uložení pole čísel. Ukazuje to na příkladu pole pro 8 milionů integerů (tedy 32 MiB dat).
Pokud se v Monu int uloží do obecného pole objektů, tedy:
object [] e = new object [size]; for (int i = 0; i < size; i++) e [i] = 1;
Pak konstrukce sežere 178 MiB, což je hodně. Jedná se v podstatě o pole referencí na objekty a každý objekt má třeba ještě svůj mutex. Tedy režie je nezanedbatelná.
Pokud se použije generická konstrukce, tedy:
public class D<T> { public T [] t; public D (int size) { t = new T [size]; } } D<int> d = new> (size); for (int i = 0; i < size; i++) d.t [i] = 1;
Pak to podle něj sežere jenom 38 MiB, což je slušné. Zkoušel ještě Javu 6, ta mu zabrala také "slušných" 248 MiB.
Napadlo mě podrobit tomuto testu Python a Ruby. Nejprve jsem zkusil "implementovat" jeho příklad v Javě, abych se ujistil, že měřím to samé, co on. Můj kód vypadá takto:
public class M { public static void main(String[] args) throws Exception { int n = 8*1024*1024; Object [] x = new Object [n]; for (int i = 0; i < n; i++) x [i] = new Integer(i); int c = System.in.read(); System.out.println(x.length); } }
Měřil jsem tak, že jsem pustil htop a koukal se na sloupec RES. Vykoukal jsem 181 MiB. No dobrá, je to řádově stejné. Tak co náš Python?
n = 8*1024*1024 x = range(n) q = raw_input() print len(x)
Tento program zabral 131 MiB, což je IMO docela slušné. Přece jenom int je v Pythonu objekt se vším všudy. Dech mi ale vyrazilo Ruby:
x = [] n = 8*1024**2 for i in 0..n do x << i end $stdin.getc print x.size
Tento skript zabral pouhých (a naprosto neuvěřitelných) 34 MiB! To jsem opravdu nečekal. Asi je to díky jednomu triku, který Matz používá: integery skladuje přímo (žádné reference) s tím, že nejnižší bit určuje, jestli se jedná o číslo, nebo o referenci. Pak jsou integery jen 31 bitové, ale což. Navíc lze využít toho, že pointery bývají zarovnané (tedy sudé).
Tiskni
Sdílej:
Já bych neřekl, že Ruby bylo zvýhodněno. Prostě je tam šikovná optimalizace, který nikde jinde není.LISP pro jistotu z diskuse vynecháme úplně. Koho by zajímala prehistorie, že? Pro hnidopichy: trou prehistorií myslím to, že tato technika v lispu již dávno vyšla z módy (alespoň pokud jsem dobře informován).
Ta optimalizace je ve všech Lispech od konce šedesátých let...
Něco, co znemožňuje nad datovým typem integer efektivně provádět aritmetické operace, bych optimalizací rozhodně nenazýval...
Na vlastní oči jsem viděl věci, které jsou vyznavačům Lispu zapovězené...
Jak si představuješ, že při aritmeticko-logickejch operacích zachováš bez dodatečný režie spodní bity tak, aby pro lisp měl výsledek stále stejnej typ? Jak bez dodatečný režie použiješ instrukce porovnání (které jsou závislé na příznacích, které jsou závislé na výsledcích aritmetických operací...)?! Instrukce prakticky všech CPU jsou zkrátka navržený (a tudíž optimální) na to, že integer má n (8, 16, 32, ...) bitů, ne n-3...
; SLIME 2007-11-23 CL-USER> (declaim (optimize (speed 3) (safety 0) (debug 0))) ; No value CL-USER> (defun sel (x y z) (declare (type fixnum x y z)) (the fixnum (if (< x 42) (+ y z) (* y z)))) SEL CL-USER> (disassemble #'sel) ; 03689D6F: 4881FA50010000 CMP RDX, 336 ; no-arg-parsing entry point ; 76: 7C17 JL L1 ; 78: 488BD7 MOV RDX, RDI ; 7B: 48C1FA03 SAR RDX, 3 ; 7F: 480FAFD6 IMUL RDX, RSI ; 83: L0: 488D65F0 LEA RSP, [RBP-16] ; 87: F8 CLC ; 88: 488B6DF8 MOV RBP, [RBP-8] ; 8C: C20800 RET 8 ; 8F: L1: 488D1437 LEA RDX, [RDI+RSI] ; 93: EBEE JMP L0 ; 95: 90 NOP ; 96: 90 NOP ; 97: 90 NOP ; 98: 90 NOP ; 99: 90 NOP ; 9A: 90 NOP ; 9B: 90 NOP ; 9C: 90 NOP ; 9D: 90 NOP ; 9E: 90 NOP ; 9F: 90 NOP ; NIL CL-USER>Já nevím. Lispu je IMHO úplně ukradený, kolik bitů má slovo, 16, 32, 18, 36, 48 - není problém, byl implementovaný na tolika šílených architekturách, že se s tím autoři implementací naučili žít (a porvat). Ale můžeš zkusit tenhle stroják ještě urychlit.
Například:
; 7B: 48C1FA03 SAR RDX, 3
je krásná ukázka dodatečný režie (hodnotu proměnné musíš o 3, tedy počet bitů zabraný LISPem na informace o typu, aritmeticky zrotovat do prava, aby si proměnnou mohl pomocí IMUL vynásobit a výsledek byl správně), kterou daný způsob reprezentace přináší.
Ehm, tím "zrotováním" je samozřejmě myšlen klasickej aritmetickej shift... ale moji assembleristé mi jistě rozumí
Ptal ses na to, jak tato implementace znemožňuje efektivně provádět operace na integerech. To jsem ti snad ukázal jasně, i na tvém příkladu "optimálního" kódu.
To že máš představu, že jenom díky takové implementaci můžeš mít efektivní práci s pamětí a tudíž je to optimalizace je tvůj problém. Já prostě takovej handl za optimalizaci nepovažuju, když vím, že můžu mít obojí (minimální paměťové nároky i maximální rychlost vykonávání kódu)
$ lua -e 'print((0x100000000000000 + 1) % 2)' 0
Tahání více dat z RAM je dneska určitě větší zlo, než nějaké ty instrukce navíc, o tom žádná. Smysle příspěvku bylo ukázat, že neexistuje nic jako "optimální (ve smyslu rychlosti vykonávání kódu) vysokoúrovňový jazyk", ať se marketingové oddělení SUNu nebo Kyosuke snaží sebevíc. Vždy je to "něco za něco".
že v Javě to spotřebuje 43,5 MB
No jo, ale on potřebuje, aby sloupeček s Javou byl pětkrát vyšší, než Ruby. To tam nemůže dát 43.5MB.
Zkousel jsem jeste MS implementaci .net ve virt. stroji.
int[] pole;
pole = new int[8*1024*1024];
ma cely proces: 36900kiB.
skoro ekvivalent pomoci generiky jak bylo uvedeno v blogpostu: 37140kiB.
Pole typu object do ktereho se nasazeji zaboxovane Inty taktez podle blogpostu: 141648kiB
>>> from array import array >>> a = array('I', xrange(8*1024*1024)) >>> a[:5] array('I', [0L, 1L, 2L, 3L, 4L]) >>> a[-5:] array('I', [8388603L, 8388604L, 8388605L, 8388606L, 8388607L]) >>> len(a.tostring()) 33554432
Ukazuje to na příkladu pole pro 8 milionů integerů (tedy 32 MiB dat)
Co je to za platformu, kde má integer velikost 4.19B?