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

[Tuxik]

Na úrovni CPU je bitový posun odjakživa rychlejší.

Jak kdy.
Asi od 80386 je nejrychlejší násobení 1,2,4,8. Interně to je asi shift, ale v assembleru se to zapisuje jako násobení konstantou.
Na druhém místě je instrukce shl a na třetím místě imul. Od Pentium 2 trvá násobení jen 4 cykly a propustnost jeden cyklus, takže to asi není třeba řešit. Pro zajímavost, instrukce cyklické rotace přes carry flag (rcr,rcl) trvají na Skylaku 6 cyklů, tedy déle než násobení.

To násobení se dokonce kompilovalo jako posuny, to byla mikrooptimalizace některých kompilerů. Jinak v průběhu doby se děly různé věci, byly drobné rozdíly mezi Intel, AMD, Cyrixem a nevím, kdo ještě to kopíroval. V pentiích byly floating point operace rychlejší než celočíselné atd atd...

[Reklama]

[javaman ((]

Na úrovni CPU je bitový posun odjakživa rychlejší.

Jak kdy.
Asi od 80386 je nejrychlejší násobení 1,2,4,8. Interně to je asi shift, ale v assembleru se to zapisuje jako násobení konstantou.
Na druhém místě je instrukce shl a na třetím místě imul. Od Pentium 2 trvá násobení jen 4 cykly a propustnost jeden cyklus, takže to asi není třeba řešit. Pro zajímavost, instrukce cyklické rotace přes carry flag (rcr,rcl) trvají na Skylaku 6 cyklů, tedy déle než násobení.

To násobení se dokonce kompilovalo jako posuny, to byla mikrooptimalizace některých kompilerů. Jinak v průběhu doby se děly různé věci, byly drobné rozdíly mezi Intel, AMD, Cyrixem a nevím, kdo ještě to kopíroval. V pentiích byly floating point operace rychlejší než celočíselné atd atd...

A tohle Java dělá za mě, takže se můžu soustředit na opravdovou práci. Lopaty budou přemýšlet, jestli použít posun

[Petr M]

Ale i kdyby, tak bych ani na to nevzal někoho, kdo neumí základní programátorskou latinu, protože bych neměl tušení, co všechno ještě neumí. Ostatně podívá-li se člověk namátkou na JS kódy spousty webů, jen to dokazuje, že je to zmatlané bez elementárního přemýšlení, neefektivně, nepřehledně, nešikovně. Prostě amatérsky.

No, ale to jsem v podstate napsal - na urcitych pozicich a zamerenich se naopak preferuje kdyz pouzivate takove ficury jazyka, se kterymi umi delat zbytek tymu. Takove obraty v kodu, ktere jsou na prvni pohled pro vetsinu lidi na dane pozici/zamereni jasne, a pripadne budou jasne i potencionalnimu budoucimu "udrzovateli" kodu. Tomu se rika udrzovatelny kod.

Ale houby. Dobrá aplikace je psaná tak, aby byla funkční a efektivní. A když něco píšu, tak to napíšu tak, jak nejlíp umím. Nebudu prasit ani architekturu, ani kód jenom proto, že může přijít nějaký Pat nebo  Mat. A když tomu nerozumí, tak ať se to naučí, nebo jde dělat weby.

[gl]

Ale i kdyby, tak bych ani na to nevzal někoho, kdo neumí základní programátorskou latinu, protože bych neměl tušení, co všechno ještě neumí. Ostatně podívá-li se člověk namátkou na JS kódy spousty webů, jen to dokazuje, že je to zmatlané bez elementárního přemýšlení, neefektivně, nepřehledně, nešikovně. Prostě amatérsky.

No, ale to jsem v podstate napsal - na urcitych pozicich a zamerenich se naopak preferuje kdyz pouzivate takove ficury jazyka, se kterymi umi delat zbytek tymu. Takove obraty v kodu, ktere jsou na prvni pohled pro vetsinu lidi na dane pozici/zamereni jasne, a pripadne budou jasne i potencionalnimu budoucimu "udrzovateli" kodu. Tomu se rika udrzovatelny kod.

Ale houby. Dobrá aplikace je psaná tak, aby byla funkční a efektivní. A když něco píšu, tak to napíšu tak, jak nejlíp umím. Nebudu prasit ani architekturu, ani kód jenom proto, že může přijít nějaký Pat nebo  Mat. A když tomu nerozumí, tak ať se to naučí, nebo jde dělat weby.

Noef píše o dělání webů.

[Tuxik]

Na úrovni CPU je bitový posun odjakživa rychlejší.

Jak kdy.
Asi od 80386 je nejrychlejší násobení 1,2,4,8. Interně to je asi shift, ale v assembleru se to zapisuje jako násobení konstantou.
Na druhém místě je instrukce shl a na třetím místě imul. Od Pentium 2 trvá násobení jen 4 cykly a propustnost jeden cyklus, takže to asi není třeba řešit. Pro zajímavost, instrukce cyklické rotace přes carry flag (rcr,rcl) trvají na Skylaku 6 cyklů, tedy déle než násobení.

To násobení se dokonce kompilovalo jako posuny, to byla mikrooptimalizace některých kompilerů. Jinak v průběhu doby se děly různé věci, byly drobné rozdíly mezi Intel, AMD, Cyrixem a nevím, kdo ještě to kopíroval. V pentiích byly floating point operace rychlejší než celočíselné atd atd...

A tohle Java dělá za mě, takže se můžu soustředit na opravdovou práci. Lopaty budou přemýšlet, jestli použít posun

Ano, java vyrábí pro každou platformu bugy a díry zvlášť. To, že něco neumíš, prostě neokecáš. JVM, stejně jako fyzický HW pracuje s jedničkama a nulama a jestli se ti to nelíbí, zůstaň u své oblíbené lopaty a nepleť se mezi inteligentnější lidi. Stejně to z tebe lepšího člověka neudělá, akorát jseš víc a víc za šaška.

[Reklama]

[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 |

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.

My jsme v RH docela hodni :-) toho bych se nebal (btw tech objektu muze byt az 2^24, tedy dost). Btw na cem ta J9 valila? Skutecne nejaky embedded procesor?

[Mirek]

Ale i kdyby, tak bych ani na to nevzal někoho, kdo neumí základní programátorskou latinu, protože bych neměl tušení, co všechno ještě neumí. Ostatně podívá-li se člověk namátkou na JS kódy spousty webů, jen to dokazuje, že je to zmatlané bez elementárního přemýšlení, neefektivně, nepřehledně, nešikovně. Prostě amatérsky.

No, ale to jsem v podstate napsal - na urcitych pozicich a zamerenich se naopak preferuje kdyz pouzivate takove ficury jazyka, se kterymi umi delat zbytek tymu. Takove obraty v kodu, ktere jsou na prvni pohled pro vetsinu lidi na dane pozici/zamereni jasne, a pripadne budou jasne i potencionalnimu budoucimu "udrzovateli" kodu. Tomu se rika udrzovatelny kod.

Ale houby. Dobrá aplikace je psaná tak, aby byla funkční a efektivní. A když něco píšu, tak to napíšu tak, jak nejlíp umím. Nebudu prasit ani architekturu, ani kód jenom proto, že může přijít nějaký Pat nebo  Mat. A když tomu nerozumí, tak ať se to naučí, nebo jde dělat weby.

Noef píše o dělání webů.

Správně. "Dělání webů" není programování.

[gl]

Ale i kdyby, tak bych ani na to nevzal někoho, kdo neumí základní programátorskou latinu, protože bych neměl tušení, co všechno ještě neumí. Ostatně podívá-li se člověk namátkou na JS kódy spousty webů, jen to dokazuje, že je to zmatlané bez elementárního přemýšlení, neefektivně, nepřehledně, nešikovně. Prostě amatérsky.

No, ale to jsem v podstate napsal - na urcitych pozicich a zamerenich se naopak preferuje kdyz pouzivate takove ficury jazyka, se kterymi umi delat zbytek tymu. Takove obraty v kodu, ktere jsou na prvni pohled pro vetsinu lidi na dane pozici/zamereni jasne, a pripadne budou jasne i potencionalnimu budoucimu "udrzovateli" kodu. Tomu se rika udrzovatelny kod.

Ale houby. Dobrá aplikace je psaná tak, aby byla funkční a efektivní. A když něco píšu, tak to napíšu tak, jak nejlíp umím. Nebudu prasit ani architekturu, ani kód jenom proto, že může přijít nějaký Pat nebo  Mat. A když tomu nerozumí, tak ať se to naučí, nebo jde dělat weby.

Noef píše o dělání webů.

Správně. "Dělání webů" není programování.

Je jedno jak tomu říkáš. Ten pohovor se možná týkal dělání webů.

[Mirek]

Ale i kdyby, tak bych ani na to nevzal někoho, kdo neumí základní programátorskou latinu, protože bych neměl tušení, co všechno ještě neumí. Ostatně podívá-li se člověk namátkou na JS kódy spousty webů, jen to dokazuje, že je to zmatlané bez elementárního přemýšlení, neefektivně, nepřehledně, nešikovně. Prostě amatérsky.

No, ale to jsem v podstate napsal - na urcitych pozicich a zamerenich se naopak preferuje kdyz pouzivate takove ficury jazyka, se kterymi umi delat zbytek tymu. Takove obraty v kodu, ktere jsou na prvni pohled pro vetsinu lidi na dane pozici/zamereni jasne, a pripadne budou jasne i potencionalnimu budoucimu "udrzovateli" kodu. Tomu se rika udrzovatelny kod.

Ale houby. Dobrá aplikace je psaná tak, aby byla funkční a efektivní. A když něco píšu, tak to napíšu tak, jak nejlíp umím. Nebudu prasit ani architekturu, ani kód jenom proto, že může přijít nějaký Pat nebo  Mat. A když tomu nerozumí, tak ať se to naučí, nebo jde dělat weby.

Noef píše o dělání webů.

Správně. "Dělání webů" není programování.

Je jedno jak tomu říkáš. Ten pohovor se možná týkal dělání webů.

Možná. Možná taky ne. A možná to bylo na nějaké embedded věci. Není tam o tom ani slovo.

[javaman ((]

Ano, java vyrábí pro každou platformu bugy a díry zvlášť. To, že něco neumíš, prostě neokecáš. JVM, stejně jako fyzický HW pracuje s jedničkama a nulama a jestli se ti to nelíbí, zůstaň u své oblíbené lopaty a nepleť se mezi inteligentnější lidi. Stejně to z tebe lepšího člověka neudělá, akorát jseš víc a víc za šaška.

Neokecávám to, prostě to není potřeba. Lopaty často považují zbytečnosti za důležité, protože ony samy to umí a vůbec nechápou, že existují i jiné věci, protože jim nerozumí.

[hawran diskuse]

Ano, java vyrábí pro každou platformu bugy a díry zvlášť. To, že něco neumíš, prostě neokecáš. JVM, stejně jako fyzický HW pracuje s jedničkama a nulama a jestli se ti to nelíbí, zůstaň u své oblíbené lopaty a nepleť se mezi inteligentnější lidi. Stejně to z tebe lepšího člověka neudělá, akorát jseš víc a víc za šaška.

Neokecávám to, prostě to není potřeba. Lopaty často považují zbytečnosti za důležité, protože ony samy to umí a vůbec nechápou, že existují i jiné věci, protože jim nerozumí.

[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.

My jsme v RH docela hodni :-) toho bych se nebal (btw tech objektu muze byt az 2^24, tedy dost). Btw na cem ta J9 valila? Skutecne nejaky embedded procesor?

Bohuzial uz si nepamatam, ale bol to nejaky velmi podtaktovany arm, aby to malo malu spotrebu, operacny system bol custom, 16 MB RAM, nejake 4 MB na uzivatelske data, okrem mojich veci tam bezali ine, takze ja som mal k dispozicii 1 MB, pricom som vzdy loadoval nemale podklady. Osobne som sa divil, preco tam bezi java. Normalne som zacal mat obdiv k programatorom, co programovali kedysi pre 48 kB RAM.

[Petr M]

Noef píše o dělání webů.

Jenomže ještě nepochopil, že opravdový profesionál bez ohledu na obor má nějakou profesní čest. A ta mu nedovolí odflinknout dílo. Profík si netroufne prodávat stůl s kratší nohou, přesolený žrádlo, jiskřící rozvaděč, lak na autě samou bublinu nebo program, u kterýho neví, jak vlastně funguje.

Vymlouvat se, že to sám umí líp, ale ostatní jsou matláci a jenom se jim přizpůsobuje, a ještě se tím chlubit, zvládne jenom ten "nejlepší z nejlepších".

[Petr M]

A ke zpracování signálů na jednom řádku - mezi zpracování signálů se dá započítat třeba FIR filtr 1. řádu u ADC na potlačení šumu.

Třeba derivační článek x_n+1 = 7/8*x_n + 1/8*a se napíše v C v přerušení 12b ADC takto:

Kód [Vybrat] Rozbalit



volatile uint16_t x = 0;

void ADC_ISR(void) {
  x = ((x << 3) - x + ADC_VALUE) >> 3;
}


Třeba u ARMu s barrel shifterem je to velice efektivní metoda. Jenom vědět, jak na to bez násobení a floatů.

Python nedělám, ale pokud by chtěl stejně filtrovat data, tak princip bude pořád stejný. A taky se to asi vejde na jednu lajnu...

[javaman ((]

Osobne som sa divil, preco tam bezi java.

Tak to já se vůbec nedivím. Prostě chápali, co je nejlepší.