Typový system versus unittesty

[listoper]

Zde bych si dovolil nesouhlasit.

Právě expresivnost jazyka nám, minimálně teoreticky, dovoluje agresivně optimalizovat. Tudíž se docela dobře na tu úroveň cache můžeme dostat.

Příklad: mám kolekci objektů, u které si kompilátor z typové signatury odvodí, že jsou imutable, tak mohu nejenom neřešit zámky, ale klidně můžu tu kolekci umístit na stacku, nebo ji inlinovat/rozkopírovat. Mě, jako uživatele to nezajímá, a kompilátor má volné ruce.

Puvodne jsem tam mel napsany cancy o tom jak kompilator to zoptimalizuje daleko lip nez ja bych kdy dokazal.
Ale pak sem si predstavil jak mi tu nekdo napise, ze to ze ja sem lama neznamena, ze ostatni to taky neumi, a moje ego mi nedovolilo to postnout ;-).

Ale myslenka zustava stejna. Ja jako programator nemuzu ve vysokourovnovem jazyce optimalizovat na nizke urovni.
Musim spolehat na kompilator. A asi je to vetsinou dobre (v mem pripade urcite  :-D)

[Reklama]

[Honza]

Příklad: mám kolekci objektů, u které si kompilátor z typové signatury odvodí, že jsou imutable

Pardon že se vám do toho pletu, ale co má immutabilita společného s datovými typy? Takovou optimalizaci můžu stejně tak udělat i v dynamicky typovaném jazyce. V typovém systému to žádnou výhodu navíc mít nebude.

[gll]

To je ale dost nizkourovnova zalezitost. Myslim, ze v jazycich vyssi urovne s tim stejne moc neudelame, protoze jsme tak daleko abstrahovali od HW, ze nemuzeme optimalizovat na urovni l1 a l2 cache.
To je dan kterou platime za expresivnost jazyku.

Zde bych si dovolil nesouhlasit.

Právě expresivnost jazyka nám, minimálně teoreticky, dovoluje agresivně optimalizovat. Tudíž se docela dobře na tu úroveň cache můžeme dostat.

Příklad: mám kolekci objektů, u které si kompilátor z typové signatury odvodí, že jsou imutable, tak mohu nejenom neřešit zámky, ale klidně můžu tu kolekci umístit na stacku, nebo ji inlinovat/rozkopírovat. Mě, jako uživatele to nezajímá, a kompilátor má volné ruce.

V praxi se to i dost ukazuje: http://funkcionalne.cz/2015/04/bez-typu-se-obejdeme-ale/

V kontextu tohoto vlákna: kompilátor píšou parta lidí, kteří se soustředí na různé tyto optimalizace. Obvykle můžeme očekávat špičky ve svém oboru. V případě, kdy to samé dělám testy, tak to píšeš zas a znova, a optimalizovat musíš opět zas a znova ty sám. Snad je z toho vidět ta motivace po typech.

iterátor neumožňuje náhodný přístup, z toho plyne ten problém, o kterém psal jirsák. Typy prvků vám nepomohou.

[Filip Jirsák]

Kde? Asi jsem prehledl...

Zde.

To je ale dost nizkourovnova zalezitost. Myslim, ze v jazycich vyssi urovne s tim stejne moc neudelame, protoze jsme tak daleko abstrahovali od HW, ze nemuzeme optimalizovat na urovni l1 a l2 cache.
To je dan kterou platime za expresivnost jazyku.

Nikoli, tohle výrazně ovlivňuje výkon i u jazyků vyšší úrovně, třeba těch běžících nad JVM. Tam, kde je to kritické, se i kód v těchhle jazycích optimalizuje tak, aby se např. data vešla do řádku cache a minimalizoval se cache miss.

Jmeno toho vlakna naznacuje, ze jde o srovnani toho co jde a nejde udelat typy vs unit testy.
Takze nevim jak BoneFlute, ale za me:
Az uvidim unit test ktery pri behu na Xeonu zahlasi ze dana funkce selze na 486 zacnu resit jak je mozne, ze tohle nedokaze typovy system.

Důležitější je asi obsah, než název. Název vlákna naznačuje, že jde o srovnání, ale text prvního příspěvku je jednoznačný pokus (úspěšný) o rozpoutání flamewar.

Navíc ta vaše podmínka je přísnější, než co požadoval BoneFlute. On se ptal na to, co jde vyřešit testem a nejde to podchytit typovým systémem. A tohle je jeden z příkladů. Je možné napsat test, který na Xeonu selže, protože testovaná funkce byla napsána pro 486 a na Xeonu je příliš rychlá. Typovým systémem toto podchytit nelze.

[BoneFlute]

To je ale dost nizkourovnova zalezitost. Myslim, ze v jazycich vyssi urovne s tim stejne moc neudelame, protoze jsme tak daleko abstrahovali od HW, ze nemuzeme optimalizovat na urovni l1 a l2 cache.
To je dan kterou platime za expresivnost jazyku.

Zde bych si dovolil nesouhlasit.

Právě expresivnost jazyka nám, minimálně teoreticky, dovoluje agresivně optimalizovat. Tudíž se docela dobře na tu úroveň cache můžeme dostat.

Příklad: mám kolekci objektů, u které si kompilátor z typové signatury odvodí, že jsou imutable, tak mohu nejenom neřešit zámky, ale klidně můžu tu kolekci umístit na stacku, nebo ji inlinovat/rozkopírovat. Mě, jako uživatele to nezajímá, a kompilátor má volné ruce.

V praxi se to i dost ukazuje: http://funkcionalne.cz/2015/04/bez-typu-se-obejdeme-ale/

V kontextu tohoto vlákna: kompilátor píšou parta lidí, kteří se soustředí na různé tyto optimalizace. Obvykle můžeme očekávat špičky ve svém oboru. V případě, kdy to samé dělám testy, tak to píšeš zas a znova, a optimalizovat musíš opět zas a znova ty sám. Snad je z toho vidět ta motivace po typech.

iterátor neumožňuje náhodný přístup, z toho plyne ten problém, o kterém psal jirsák. Typy prvků vám nepomohou.

Iterátor nemá typ? To, že neumožňuje náhodný přístup je typová vlastnost. Iterátor jsem zvolil z nějakého důvodu. Pokud ten důvod nemám, tak nebudu kompilátoru tvrdit, že má použítá iterátor, ale nechám to na něm.

[Reklama]

[BoneFlute]

Důležitější je asi obsah, než název. Název vlákna naznačuje, že jde o srovnání, ale text prvního příspěvku je jednoznačný pokus (úspěšný) o rozpoutání flamewar.

Já jsem o žádné flamewar zájem neměl. Text mého příspěvku k flamewar nenabádal. Ale beru tě jako nutné zlo.

[BoneFlute]

Příklad: mám kolekci objektů, u které si kompilátor z typové signatury odvodí, že jsou imutable

Pardon že se vám do toho pletu, ale co má immutabilita společného s datovými typy? Takovou optimalizaci můžu stejně tak udělat i v dynamicky typovaném jazyce. V typovém systému to žádnou výhodu navíc mít nebude.

Nepřímou.
Ale v tom odkazovaném článku je to pěkně rozebráno. I to, na co narážíš. Shrnuto - pokud jsou typy blbé, je pro komplilátor výhodnější je ignorovat a odvodit si vlastní.

[Filip Jirsák]

Ja jako programator nemuzu ve vysokourovnovem jazyce optimalizovat na nizke urovni.

Můžete. I u toho vysokoúrovňového jazyka můžete mít zaručené, že pole ten jazyk ukládá jako jednotlivé prvky v paměti vedle sebe. Takže když použijete pole primitivních hodnot, nejde se vám do řádku cache několik hodnot. Když použijete spojový seznam, bude každá položka uložená v paměti někde jinde a procesor bude při průchodu kolekcí pořád jen čekat, než se nahrají data z paměti. A tohle je třeba rozdíl mezi java.util.ArrayList a java.util.LinkedList. Připadají vám Java, Scala nebo Clojure jako dostatečně vysokoúrovňové jazyky? Ano, Java je jen assembler nad bajtkódem, ale stejně…

[BoneFlute]

Ale myslenka zustava stejna. Ja jako programator nemuzu ve vysokourovnovem jazyce optimalizovat na nizke urovni.
Musim spolehat na kompilator. A asi je to vetsinou dobre (v mem pripade urcite  :-D)

Ano. To prakticky vždycky. Rád na přednáškách tvrdím, že je třeba psát kód tak, aby ho kolegové mohli intuitivně použít i když budou našrot.

[Filip Jirsák]

Já jsem o žádné flamewar zájem neměl. Text mého příspěvku k flamewar nenabádal.

Jasně. V názvu tématu se na něco ptáte, v textu rovnou odpovíte, arogantně a bez jakéhokoli vysvětlení. A pak to celou dobu přiživujete tím, že sice úplně nechápete základy, ale někde jste zahlédl něco úžasného, z čeho se všichni musí posadit na zadek. To vůbec není odstartování flamewaru…

[Filip Jirsák]

Rád na přednáškách tvrdím,

Tohle je nejhorší zpráva z celého tématu.

[listoper]

Ja jako programator nemuzu ve vysokourovnovem jazyce optimalizovat na nizke urovni.

Můžete. I u toho vysokoúrovňového jazyka můžete mít zaručené, že pole ten jazyk ukládá jako jednotlivé prvky v paměti vedle sebe. Takže když použijete pole primitivních hodnot, nejde se vám do řádku cache několik hodnot. Když použijete spojový seznam, bude každá položka uložená v paměti někde jinde a procesor bude při průchodu kolekcí pořád jen čekat, než se nahrají data z paměti. A tohle je třeba rozdíl mezi java.util.ArrayList a java.util.LinkedList. Připadají vám Java, Scala nebo Clojure jako dostatečně vysokoúrovňové jazyky? Ano, Java je jen assembler nad bajtkódem, ale stejně…

ArrayList v jave bude vedle sebe ukladat jen reference. Kdyz chci hodnotu tak stejne musim hledat nekde v halde.

[v]

Já jsem o žádné flamewar zájem neměl. Text mého příspěvku k flamewar nenabádal.

Jasně. V názvu tématu se na něco ptáte, v textu rovnou odpovíte, arogantně a bez jakéhokoli vysvětlení. A pak to celou dobu přiživujete tím, že sice úplně nechápete základy, ale někde jste zahlédl něco úžasného, z čeho se všichni musí posadit na zadek. To vůbec není odstartování flamewaru…

IMHO není, záleží na backgroundu

[Filip Jirsák]

ArrayList v jave bude vedle sebe ukladat jen reference. Kdyz chci hodnotu tak stejne musim hledat nekde v halde.

Podstatné v této diskusi je, že prvky kolekce ukládá do pole a javovské pole je v paměti uložené v souvislé paměti. Takže když primitivní typy uložíte přímo do pole nebo do kolekce, která umožňuje ukládat primitivní typy, má procesor ty hodnoty v paměti hned vedle sebe. Jinak ano, kolekce ve standardní knihovně Javy umožňují ukládat jen objekty, takže rozdíl mezi java.util.ArrayList a java.util.LinkedList je v tom, že první má odkaz, zatímco druhý má odkaz na odkaz.

[A. F.]

Já jsem o žádné flamewar zájem neměl. Text mého příspěvku k flamewar nenabádal.

Jasně. V názvu tématu se na něco ptáte, v textu rovnou odpovíte, arogantně a bez jakéhokoli vysvětlení. A pak to celou dobu přiživujete tím, že sice úplně nechápete základy, ale někde jste zahlédl něco úžasného, z čeho se všichni musí posadit na zadek. To vůbec není odstartování flamewaru…

Neříká se tomuhle, co to Filip Jirsák předvádí trollování?

Co se mě týče, tak po dlouhé době je to téma které je zajímavé, takže já dávám BoneFlute +1.