Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)
Tak zrovna tady je to jen o tom, že něco lze spočítat již v době kompilace. V takovémto případě může kompilátor rovnou do binárky hodit výsledek…
Tak. A o tom to je.
Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.
Sorry, já to tam stále nevidím. Jsou to věci, které by si v nějaké podobě mohl kompilátor vygenerovat sám (a asi je jedno, v jakém pořadí se serializují jednotlivé složky barvy), pokud mu to pomůže. Takže moc nevidím, v čem pomůže, když to napíšu ručně.
Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.
Hlavně, počítá se začátek a konec. To mezi tím je nedůležité (nadsázka).
A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?
Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:
let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1
budou tři 256prvkové pole.
v čem pomůže, když to napíšu ručně.
Ty mu řekneš, že na vstupu a výstupu je pořadí barev je RGB. To on neví, to mu musíš určit. Ale mezi tím si ty barvy pomíchá třeba na BGR. Nebo po klastrech.
Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude.
Haskell je lazy už v sémantice, takže to musí kompilátor zajímat…
Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.
473 Odpovědí
96510 Zhlédnutí