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.
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?