od York » 6. 12. 2017, 20:51
Resurrection píše: ↑6. 12. 2017, 20:30Predstav si, ze si procesor.
Krásně mi nahráváš na další kapitolu
Optimalizace
V drtivé většině praktických aplikací není limitní výkon procesoru, ale čas strávený vývojem.
Pokud přece jen výkon hraje roli, tak v drtivé většině případů jde o omezení bandwithem, tzn. nejde o to, jak rychle procesor chroustá instrukce, ale kolik se toho posílá po netu - nejčastěji kolik se toho musí poslat před tím, než se poprvé zobrazí další stránka. Dneska se hodně mluví o optimalizacích (reactive design), ale týká se to načítání webových stránek.
Další velkou oblastí, kde stojí za to optimalizovat, jsou chyby ve stylu, že dáte nejdřív stahovat data a až pak se udělá render - takže uživatel má pocit, že se mu stránka zasekla. To opět nemá nic společného s procesorem.
Další v pořadí jsou chybně zvolené algoritmy (typicky exponenciální složitost, když by mohla být lineární nebo třeba n*log(n)) nebo datové struktury. Rozdíl mezi exponenciální a lineární složitostí fakt nezachráníš pár procentama ušetřenejma na L2 cache misses.
Když už fakt potřebuješ optimalizovat na výpočetní výkon, tak typicky drtivou většinu výkonu žere mizivé procento tvých funkcí. To znamená, že optimalizací většiny svého kódu získáš absolutně minimální zvýšení výkonu. Z toho plyne, že když už musíš optimalizovat, tak si nejdřív pusť profiler, abys věděl, co je vlastně optimalizovat potřeba.
A v neposlední řadě - týmy, které pracují na překladačích (např. gcc) nebo enginech (např. v8 javascriptový engine) jsou v tom o dost lepší než ty, takže s největší pravděpoboností to, co ti přijde neoptimalizované, v browseru běží úplně stejně jako ta druhá varianta (a někdy i rychleji, protože tyhle týmy se celkem logicky zaměřují hlavně na kód, který skutečně reálně někdo napsal).
[quote=Resurrection post_id=520616 time=1512588619 user_id=1198]Predstav si, ze si procesor.[/quote]
Krásně mi nahráváš na další kapitolu ;-)
[size=115][b]Optimalizace[/b][/size]
:arrow? V drtivé většině praktických aplikací není limitní výkon procesoru, ale čas strávený vývojem.
:arrow? Pokud přece jen výkon hraje roli, tak v drtivé většině případů jde o omezení bandwithem, tzn. nejde o to, jak rychle procesor chroustá instrukce, ale kolik se toho posílá po netu - nejčastěji kolik se toho musí poslat před tím, než se poprvé zobrazí další stránka. Dneska se hodně mluví o optimalizacích (reactive design), ale týká se to načítání webových stránek.
:arrow? Další velkou oblastí, kde stojí za to optimalizovat, jsou chyby ve stylu, že dáte nejdřív stahovat data a až pak se udělá render - takže uživatel má pocit, že se mu stránka zasekla. To opět nemá nic společného s procesorem.
:arrow? Další v pořadí jsou chybně zvolené algoritmy (typicky exponenciální složitost, když by mohla být lineární nebo třeba n*log(n)) nebo datové struktury. Rozdíl mezi exponenciální a lineární složitostí fakt nezachráníš pár procentama ušetřenejma na L2 cache misses.
:arrow? Když už fakt potřebuješ optimalizovat na výpočetní výkon, tak typicky drtivou většinu výkonu žere mizivé procento tvých funkcí. To znamená, že optimalizací většiny svého kódu získáš absolutně minimální zvýšení výkonu. Z toho plyne, že když už musíš optimalizovat, tak si nejdřív pusť profiler, abys věděl, co je vlastně optimalizovat potřeba.
A v neposlední řadě - týmy, které pracují na překladačích (např. gcc) nebo enginech (např. v8 javascriptový engine) jsou v tom o dost lepší než ty, takže s největší pravděpoboností to, co ti přijde neoptimalizované, v browseru běží úplně stejně jako ta druhá varianta (a někdy i rychleji, protože tyhle týmy se celkem logicky zaměřují hlavně na kód, který skutečně reálně někdo napsal).