Portál AbcLinuxu, 1. května 2025 14:23
8.12.2007 02:03
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
8.12.2007 02:10
alblaho | skóre: 17
| blog: alblog
8.12.2007 02:35
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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).
(link) Aneb když něco funguje, proč to měnit?
A hádej, odkud ji Matz vzal.
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.
Osobně si ale myslím, že současné implementace jsou pro většinu aplikací Good Enough(TM).
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)
Tohle jsou jen neboxované samostatné fixnumy, nikdo netvrdí, že uvnitř struktur, složitějších objektů a polí potřebuju typetagy. Porušovat přírodní zákony ovšem nejde, a samostatný 64b integer není objekt (tj. nezná svůj typ).
Myslíš, že kompilátor neprovede ty kontroly jinde, třeba v případě, že se ta funkce někde použije? Koneckonců ví, co vygeneroval, myslíš, že je sklerotický? Ostatně:
1) Tohle je jen ilustrace fixnumů s type tagy - čteš i kontext, že jo? Tudíž mi šlo čistě jen o to, co je třeba provádět s type-tagged integery navíc v porovnání s untagged integery. Koerce do bignumu a generování výjimky se obojího dotýká úplně stejně. Nebo snad C/C++ používá nějaký nedokumentovaný režim i386, kde IMUL i LEA dělaji pro untagged integery automaticky INTO?
2) Nikdy bych nedal (safety 0) do provozního kódu, pokud bych neměl nade vší pochybnost zaručené (třeba kontrolami okolo nebo invarianty dat), že tím něco nezbourám, přeci nejsem magor. BTW, spousta kódu psaného v Cčku pořád ještě funguje, dokonce i ten zabugovaný binární search v poli v Javě celé roky nikomu nevadil.
3) Povětšinou se zúženou deklarací typu můžu i tomu přetečení vyhnout staticky, koneckonců 64b čísla jsou dost velká takřka pro cokoli a aplikační data většínou mají nějaký konkrétní smysl.
4) Netuším, proč předpokládáš, že aplikační kód musí být uniformní. Není přeci problém mít většinu kódu kompaktní a vnitřní smyčky a exponovaná místa rychlá. To se přeci dělá úplně normálně, ne? Take bezpečný vysokoúrovňový kód můžu mít 99 % aplikace a tam, kde potřebuju, si prostě zamažu ruce.
S floaty to bude u SBCL asi horší, ale stejně bych si moc nestěžoval - stejně přemýšlím o tom, že na intenzivní floating-point aritmetiku udělám takový menší framework, protože s vektorovým kódem jsou dneska tak trošku na štíru i kompilátory Cčka a dokopat je k něčemu rozumnému asi nebude triviální (i když už se situace lepší a dokážou už rozpoznávat nějaké ty smyčky). Možná bych se mohl naučit Fortran, ale integrace kódu v několika jazycích mě moc nebere.
Tohle je spíš věc implementace, ne věc jazyka, i když je v pravda, že v dynamickém a interaktivním systému se některé věci dělají složitěji než treba v Haskellu. Do SBCL bohužel nikdo tolik peněz nenapumpoval 
, ale firmě by to asi bylo stejně jedno, tak pro ni tak drahé ACL zase není a mně osobně je to víceméně ukradený. Já se spokojím s možností psát inline SSE assembler a zbytek výkonu je mi putna, pokud to nebude pomalý jako Python, což není.
, ale co když podteče přesnost? To se taky dá detekovat, že kupříkladu poslední součet byl nepřesný? Taky se mi to nějak nezdá.
$ lua -e 'print((0x100000000000000 + 1) % 2)' 0
Kdyby to měly všechny FPU jednotky, dalo by se uvažovat o nové implementaci bignumů pro OpenMCL, hmm... Mně totiž štve, že jen CLISP má tak brutálně rychlou multiprecision aritmetiku a jiné implementace v porovnání s ním mají prd. Asi do něj autor nasypal při vaření špetku černé magie.
A s tím, jak se rozevírají nůžky mezi rychlostí ALU a rychlostí paměti, jeho dřívější nevýhody postupně mizí. (Akorát si nejsem jist, zda se u něj dá mluvit o jednoduchosti, ono napsat si vlastní nadstavbu Cčka bylo sice od Bruna Haibla geeky, ale vůbec tomu kódu nerozumím. )
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".
) a navíc ne ve všech aplikacích.
8.12.2007 08:12
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
ž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?
8.12.2007 20:17
Josef Kufner | skóre: 70
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.