Bitové operace ve vyšších jazycích

[noef]

nedávno se tu někdo ptal, proč browsery žerou tolik paměti, tohle je tady asi odpověď base64 taky potkat nemůže? a jaké další operátory javascriptu teda znát nemusí?

Ale to je snad vec browseru (tj. C++, ne?), to JavaScript vyvojar nezachrani, kdyz pro byte, int, float a double ma na "vyber" z typu number.

A opravdu ne, kdyz delate front-end, tak bitove operace nepouzivate. Hexa cislo vidite tak maximalne pro vyjadreni barev a tam zase zadne bitove operace nepouzivate, jedine co s nim potrebujete delat je umet ho zkopirovat z jednoho mista na druhe. Zadne operace nad nim ani jakekoliv interpretace nepotrebujete.

Binarni oprace v JS si dovedu predstavit tak u hernich enginu nebo velmi optimalizovanych knihoven, kterymi se ale zabyva mizive cislo vyvojaru pracujicich v JS. To je stejne jako v Jave/C#/Pythonu/Ruby, proste konzumujete potunene knihovny na potunenem VM/interpreteru.

Jak pro pouziti base64 potrebujete umet plynule pocitat v binarni nebo hexa soustave? Po pravde pro pouziti base64 vam staci znat, ze base64 existuje, co resi a jake metody zavolat pro konverzi. Priznam se, ze ani v prubehu studia na vejsce jsem nikdy neprevadel base64 z hlavy nebo na papire a to jsme na skole delali rucne hodne divne a vetsinou zbytecne veci (napr. programovnani v C na papir - body dolu za kazdou drobnost, fuj).

PS: Cena pameti je zanedbatelna, mam otevrenych ~20 tabu a nejsem ani na 1GB. 8GB pameti je za doslova tisicovku a muzete na tom provozovat desitky, asi i stovku, tabu.

[Reklama]

[lopata]

A opravdu ne, kdyz delate front-end, tak bitove operace nepouzivate.

Frontend vývojář nikdy nepotřebuje celočíselně dělit dvěma? Jak jinak by to měl v JavaScriptu udělat, než takhle?
https://github.com/d3/d3-array/blob/master/src/bisector.js#L10
Nebo chceš tvrdit, že algoritmus hledání půlením intervalu je pro frontned vývojáře příliš pokročilý a nemusí ho znát ani nikdy implementovat? Tohle celou dobu tvrdíš?

[noef]

Ano, to tvrdim. A vzdyt jste nalinkoval presne to, co jsem psal - potunenou knihovnu. Normalne se nad VM takoveto mikrooptimalizace pri normalnim vyvoji (cti ne potunene knihovny, kde maji perf testy na kazdy radek) casto radeji ani nedelaji, protoze snizuji citelnost kodu, tj. udrzovatelnost, a navic nemusi vzdy ani zvysovat vykon. Nejde o to, jestli je ten algoritmus pokrocily nebo sebevic chytry, ale o to, ze dobry vyvojar nebude znovu implementovat kolo - radeji pouzije jiz hotove poradne kulate kolo, nez aby se placal se svym hranatym desetinasobne dele, nez by zabralo pouziti hotoveho, a ve vysledku tak jen marnil cas.

[noef]

A abych rekl pravdu, tak zrovna filtrovani/prohledavani dat se dela casteji na BE. Na projektech, na kterych jsem delal, tabulky vetsinou pres 100 polozek nesly, takze i pokud by se vyhledavalo hloupe po jednom, tak je to stejne zanedbatelne, protoze tech 100 porovnani je nic ve srovnani s parsovanim napr. obrazku nebo odpovedi od BE. Navic tedy malokdy v typickem front-endu, tj. nejakem IS, mate data serazena, takze ne, nemyslim si, ze zrovna hledani pulenim intervalu se moc pouziva na FE.

[lopata]

A vlastně proč ne, k čemu by frontend vývojář někdy potřeboval celočíselné dělení dvěma, to je na frontend už příliš velký hi-tech. Myslím, že nebude potřebovat ani odčítání, protože 99% výpočtů jsou stejně jenom nudné průměry, kde odčítání vůbec nevyužije. Odčítání také snižuje udržovatelnost, protože ostatní kolegové by to nemuseli pochopit a oproti sčítání ani nezvyšuje výkon. Objektivně vzato odčítání frontend vývojář taky nepotřebuje.

[Reklama]

[noef]

Kód: [Vybrat]

Math.floor(input/2);
^ Je proste citelnejsi. A pokud vim, tak toto se casto razi i jinde, nez v JS, ze se nepouzivaji shifty protoze jsou spatne citelne a davaji prednost deleni/nasobeni. Myslim, ze prave pro Javu jsem takova doporuceni cetl. A tedy v Jave to snad urcite muze optimalizovat prekladac (detekovat mocninu dvou a celociselny typ neni problem), takze tam to ani nezvysuje vykon, jen snizuje citelnost. V JS nevim, ale je mozne, ze lidi radeji davaji prednost udrzovatelnemu kodu, nez lustit veci typu:

Kód: [Vybrat]

((count << 2) + 3) >> 1
Priznavam, ze mozna pracuji na prilis podobnych projektech (IS), takze vzorek neni idealni, ale treba to deleni - verte neverte - pouzivam minimalne.

[Tuxik]

Ano, to tvrdim. A vzdyt jste nalinkoval presne to, co jsem psal - potunenou knihovnu. Normalne se nad VM takoveto mikrooptimalizace pri normalnim vyvoji (cti ne potunene knihovny, kde maji perf testy na kazdy radek) casto radeji ani nedelaji, protoze snizuji citelnost kodu, tj. udrzovatelnost, a navic nemusi vzdy ani zvysovat vykon. Nejde o to, jestli je ten algoritmus pokrocily nebo sebevic chytry, ale o to, ze dobry vyvojar nebude znovu implementovat kolo - radeji pouzije jiz hotove poradne kulate kolo, nez aby se placal se svym hranatym desetinasobne dele, nez by zabralo pouziti hotoveho, a ve vysledku tak jen marnil cas.

Ano, běžný programátor je dnes obyčejný lempl. Mikrooptimalizace v rámci jednoho řádku tu vždy byly, většinou neušetřili nic závratného (občas ve smyčce ano), ale na druhou stranu, těch několik málo jednoduchých operací znal každý tak dobře, že to čitelnost nijak nesnižovalo. Když se v asm objevilo xor ax,ax, každý věděl, že je to to samé, jako mov ax,0, jenom o takt rychlejší, to samé instrukce shr a shl, prostě to byla samozřejmost. A stejné postupy se dají použít - a kupodivu používají - dodnes a to i ve vyšších jazycích. Chápu, že u prototypování je to zbytečné řešit, můžu si dovolit používat monstrózní knihovny kvůli jedné pětiřádkové fičuře, ale očekával bych, že každej obyčejnej kodér, kterej nic nevymýšlí a v zásadě jen přepisuje do lepší formy hotovou aplikaci, tak by drobné optimalizační procesy měl znát, měl by je používat a měl by mít dost soudnosti (pokud ji neměl bastlíř před ním) na to, aby vyházel zbytečné závislosti, pokud je to otázkou 5ti minut.

[tisnik]

Myslel jsem v Javě (tam to dost dobře nejde), ale ok, příklad beru a je napsán imho dobře - nesnažíš se vše udělat v tom jediném-správném-úplně-nejlepším-jazyce (tímto zdravím pána, který není, ale skutečně není "lopata"), ale používaš low level jazyk pro low level operace a naopak.

V původním příspěvku jsem psal, že mluvím o pythonu. Javu moc dobře neznám, ale určitě podobné knihovny existují i tam.

Od javy 1.4 je sucast java api trieda ava.awt.Color , metody getGreen, getRed , getBlue, getAlpha.
https://docs.oracle.com/javase/7/docs/api/java/awt/Color.html

Ja by som asi radsej pouzil tie bitove posuny, ale da sa to bez posunov

Neda, resp. da, ale za to bych Te v teamu zabil. Vsimni si, ze java.awt.Color (mimochodem existuje od 1.0) je immutable, tj. jedina moznost prevodu je udelat new Color(r,g,b) a potom ty zminovane metody getGreen, getRed , getBlue, getAlpha. Fakt si pro prevod bitmapy o velikosti rekneme 1024x1024 pixelu (zadne HD) nasekas a hned v GC nechaz zrusit milion objektu?

On je totiz duvod pro to, ze v jave existuji i nizkourovnove API pro bitmapy (Raster, WritableRaster etc.), ale tam se jaksi pocita s tim, ze programator zna >>, <<, & a |

[Tuxik]

Kód: [Vybrat]

((count << 2) + 3) >> 1

Prostě se na to podívám a vidím to tam, aniž bych o tom musel vůbec přemýšlet.

[balki]

Myslel jsem v Javě (tam to dost dobře nejde), ale ok, příklad beru a je napsán imho dobře - nesnažíš se vše udělat v tom jediném-správném-úplně-nejlepším-jazyce (tímto zdravím pána, který není, ale skutečně není "lopata"), ale používaš low level jazyk pro low level operace a naopak.

V původním příspěvku jsem psal, že mluvím o pythonu. Javu moc dobře neznám, ale určitě podobné knihovny existují i tam.

Od javy 1.4 je sucast java api trieda ava.awt.Color , metody getGreen, getRed , getBlue, getAlpha.
https://docs.oracle.com/javase/7/docs/api/java/awt/Color.html

Ja by som asi radsej pouzil tie bitove posuny, ale da sa to bez posunov

Neda, resp. da, ale za to bych Te v teamu zabil. Vsimni si, ze java.awt.Color (mimochodem existuje od 1.0) je immutable, tj. jedina moznost prevodu je udelat new Color(r,g,b) a potom ty zminovane metody getGreen, getRed , getBlue, getAlpha. Fakt si pro prevod bitmapy o velikosti rekneme 1024x1024 pixelu (zadne HD) nasekas a hned v GC nechaz zrusit milion objektu?

On je totiz duvod pro to, ze v jave existuji i nizkourovnove API pro bitmapy (Raster, WritableRaster etc.), ale tam se jaksi pocita s tim, ze programator zna >>, <<, & a |

Teoreticky staci na jednu farbu jeden objekt Ale uz nebudem drazdit  hada  bosou nohou. ( Co ked pojdem pracovat do RH )

Image processing som este nerobil (respektive raz navysokej),  ale zo dna na den som sa stal embedakom (nie micro edition ale J9 od ibm), tam som musel riesit veci, ze mi do jedneho bajtu narvali tri hodnoty a bez bitovych operacii by som sa pokakal + tam bolo treba velmi setrit pamatou.

[Mirek]

Lidi, zajímalo by mně, jak jste z textu "Ahoj, jsem programátor a programuju ve vyšších jazycích (hlavně python). Byl jsem u pohovoru, kde jsem dostal na papíru vyřešit úkol, který vypadal zhruba takto:" dovodili, že daný pohovor byl na pozici vývojáře FrontEnd řešení v JavaScriptu?

[noef]

Tusim, ze tak, ze nekdo napsal, ze vsichni vyvojari potrebuji umet pocitat v binarni aritmetice. JS FE dev byl protiargument.

Stejne tak ale podle me bude platit i o webari (BE nebo full-stack) v Pythonu, Ruby, JavaScriptu, Jave, C#. To, ze to jazyk podporuje, neznamena, ze se to ma pouzivat, nebo ze to dev musi umet. Na urcitych pozicich se neocekava, ze budete kouzlit s jazykem za kazdou cenu usporeneho znaku nebo 0.1% vykonu - napr. mit nekolikrat zanoreny operator ?: v JS neni moc dobra praktika, prestoze to muze usetrit hodne mista oproti pouzivani if. Stejne tak pouzivani bin. posunu >>, << a bezznamenkovych posunu >>>, <<< na FE neni stastne.

Ja chapu, ze v embeded je to bezna vec. Tam ale opravdu potrebujete sahat na bity, protoze jste tak blizko HW. Tam se dokonce i ty mikrooptimalizace muzou vyplatit, protoze ten HW muze byt velmi slaby a/nebo mit velmi malo mista v pameti. Koneckoncu C/C++ je mnohem blize ASM a strojovemu kodu, nez JavaScript nebo Java a neprovadi se zadny JIT, mate tedy mnohem vetsi jistotu, ze vase optimalizace neni zbytecna a VM ji neudela lepe, protoze za behu vyzkousel a zmeril nekolik mutaci. Cim vys v jazycich a frameworcich jdete, tim vyssi vykon se od HW ocekava a tim vetsi abstrakce by jste meli pouzivat. A na ty opravdu vykonostne kriticke operace mate potunenou knihovnu, engine nebo VM.

[Kiwi]

Kód: [Vybrat]

Math.floor(input/2);

Přesně toto je právě odstrašující příklad. Kdyby mi toto někdo napsal u pohovoru, rozhodně bych se ho na to začal vyptávat. A velmi pochybuji, že by si to dokázal obhájit.

Přesně toto je ten fachidiotismus, o němž jsem tu psal. Pro mě by to byl jasný důkaz, že tomu člověku to prostě nemyslí, že u své práce nepoužívá hlavu a že v teamu udělá víc škody než užitku.

Lidi, zajímalo by mně, jak jste z textu "Ahoj, jsem programátor a programuju ve vyšších jazycích (hlavně python). Byl jsem u pohovoru, kde jsem dostal na papíru vyřešit úkol, který vypadal zhruba takto:" dovodili, že daný pohovor byl na pozici vývojáře FrontEnd řešení v JavaScriptu?

To je jeden z druhů argumentačního klamu. Už jsem se s ním vícekrát setkal při vedení pohovoru. Řekneš, že k něčemu obecnému je třeba X. A on si za něco obecného dosadí něco konkrétního, co se mu hodí, a tím se snaží dokázat, že mé původní tvrzení neplatí. Někteří, jako třeba v této diskusi, si tam dosadí i něco úplně jiného, co s tím něčím obecným vlastně vůbec nesouvisí.
V praxi to u nás funguje tak, že zadám úkol, a uchazeč místo jeho řešení, nebo aspoň nějakého pokusu o něj, začne rozvíjet teorie, k čemu že by to vlastně mohlo být dobré, že se to k ničemu nemůže hodit, "a co když...", "a co kdyby někdo chtěl...", "...a pak by se to dalo dělat tak a tak a na to už jsou knihovny a tak to vlastně nikdo ani nepotřebuje nikdy dělat..." Dříve jsem takovým uchazečům poděkoval za zájem o pozici a řekl jim, že práce, která by se po nich požadovala, by asi nebyla dle jejich gusta a že jistě snadno najdou někde jinde místo, které jim bude vyhovovat daleko více. Když jsem se jednou v reakci na toto uchazeče dotázal, zda někdy uvažoval o jiné profesi, nejlépe nějaké manuální, ještě si na mne pak stěžoval. Dnes to tedy řeším demonstrativním roztrháním jejich vytištěného životopisu a pozdravem "s bohem". Bohužel takto končívám pohovor čím dál častěji.

[javaman ((]

ROFL. Takový lopaty potkávám na pohovorech pořád častěji. Buď rád, že máš vůbec práci, když jsi tak mimo Tebe tak postavit maximálně k pokladně s tím přístupem.

Ale to je tak, když dostane zodpovědnost lopata...

[Kiwi]

ROFL. Takový lopaty potkávám na pohovorech pořád častěji. Buď rád, že máš vůbec práci, když jsi tak mimo Tebe tak postavit maximálně k pokladně s tím přístupem.

Ale to je tak, když dostane zodpovědnost lopata...

Potrefená husa zakejhala.