Java: byte to 8 boolean

[RAII]

TO STAŘEŠINA: Hele, java na stacku pokud vím tak fakt nic neukládá, vše jede na heap. Pokud si Java guru, tak nepochybuju že mne můj názor vyvrátíš. Ale nevyvrátíš, že je java pomalá (a i GC je pomalé, je jedno jak je optimalizované, RAII bude vždy rychlejší->dokonce až 2 krát!!)....No, podle mého názoru fakt v jave s bitovejma operacema díru neudělá (s jeho přístupem). Spíš by dokázal ňákej program tímhle stylem rozbít. ALE, už jsem si uvědomil proč je takové tažení proti pointerům a RAII, takovídle tydýti z toho udělaj nástroj zkázy.

[Reklama]

[Stařešina]

TO STAŘEŠINA: Hele, java na stacku pokud vím tak fakt nic neukládá, vše jede na heap.

Tak proč by existovala volba -Xss která nastavuje velikost stacku (pro každý thread)? Faktem je že kromě návratových adres pro volání (viz stack trace) jsou v Javě na stacku primitivní datové typy a reference na objekty, objekty samotné jsou alokované na stacku (výjimečně, to je optimalizace) nebo na heapu, jak uzná JVM za vhodné. Jinak je stack v Javě dost hloupý, už třeba jen to že je pro všechny thready stejně velký a konstantní (není možné ho rozšířit) může být v některých případech nepříjemné.

[Pavel Tisnovsky]

TO STAŘEŠINA: Hele, java na stacku pokud vím tak fakt nic neukládá, vše jede na heap. Pokud si Java guru, tak nepochybuju že mne můj názor vyvrátíš. Ale nevyvrátíš, že je java pomalá (a i GC je pomalé, je jedno jak je optimalizované, RAII bude vždy rychlejší->dokonce až 2 krát!!)....No, podle mého názoru fakt v jave s bitovejma operacema díru neudělá (s jeho přístupem). Spíš by dokázal ňákej program tímhle stylem rozbít. ALE, už jsem si uvědomil proč je takové tažení proti pointerům a RAII, takovídle tydýti z toho udělaj nástroj zkázy.

V Javě vlastně ani klasicky pojatý zásobník není, jsou to jen svázané zásobníkové rámce, které navíc nemusí ležet za sebou (většinou ano, ale není to nutné). Hodnoty primitivních datových typů z lokálních proměnných v této oblasti zásobníku jsou, popř. se kopírují na zásobník operandů. Ale ono je to jedno, stejně se bajtkód později převede JITem do nativního kódu s již docela normálně pojatým zásobníkem, alespoň na těch zvrácených :-) architekturách, které něco podobného potřebují používat :-) Ale asi jsme úplně odbočili od původního tématu; pokud se tazatel zabývá bitovými operacemi, tak si to může prozkoušet i v Javě, prakticky se to použije při ukládání bitových polí, ale na to jsou v praxi lepší způsoby, BitSet, BigInteger atd.

[Natix]

... pokud se tazatel zabývá bitovými operacemi, tak si to může prozkoušet i v Javě, prakticky se to použije při ukládání bitových polí, ale na to jsou v praxi lepší způsoby, BitSet, BigInteger atd.

... EnumSet. 

[podlesh]

Ale nevyvrátíš, že je java pomalá (a i GC je pomalé, je jedno jak je optimalizované, RAII bude vždy rychlejší->dokonce až 2 krát!!)

Problém není ani tak v tvrzení "java je pomalá" (to je relativní, záleží s čím se porovnává), ale spíš v předchozím výroku "java je pomalá, takže nemá cenu optimalizovat" - to je self-fulfilling prophecy.

[Reklama]

[RAII]

TO PODLESH: pěkný rekurzivní výrok xD. Ale ne. Tak sem to nemyslel. Optimalizovat samozřejmě Javu také, ale používání bitových operací mi přijde (když to není vyžadováno...) na tak pomalí jazyk zbytečně hardcore optimalizace. C/C++ neřeknu ani slovo, tam je základní filozofie co nejefektivnější kód.

[Filip Jirsák]

tak pomalí jazyk

Teď nevím, zda jste si tím připravoval půdu pro omluvu, že za to „í“ nemůžete, protože čeština je tak chybový jazyk… Nebo jestli spojení „pomalý programovací jazyk“ myslíte vážně. Nenapadlo vás, že je možné zdrojový kód v jednom jazyce převést do zdrojového kódu v jazyce jiném? Že je možné ve dvou jazycích napsat takový kód, který povede na stejnou posloupnost instrukcí? To trochu nabourává vaší představu, že může existovat rychlý nebo pomalý programovací jazyk, nemyslíte?

[JSH]

TO PODLESH: pěkný rekurzivní výrok xD. Ale ne. Tak sem to nemyslel. Optimalizovat samozřejmě Javu také, ale používání bitových operací mi přijde (když to není vyžadováno...) na tak pomalí jazyk zbytečně hardcore optimalizace. C/C++ neřeknu ani slovo, tam je základní filozofie co nejefektivnější kód.

Nějak nechápu to porovnávání bitových operací a optimalizací. Pár brutálně optimalizovaných kousků kódu jsem už psal, ale na bitových operacích to teda nestálo ani omylem. Ale vzhledem k těm perlám, co tu trousíš, se až tak moc nedivím.

[RAII]

TO FILIP JIRSÁK: No hele, Java je interpretovaná ... = pomalá. TO JSH: To že nevíš jak vypadá optimalizace pomocí bitových operací ještě nic neznamená, asi toho nevíš víc (třeba ušetření místa hmm?).

[devnull]

Tak nejak mi to pripomnelo meho kamarada, ktery ve druhem ci tretim rocniku VS - informatika - vyrabel v ramci nejakeho projektu prevod byte do retezce v binarnim formatu (osm jednicek/nul). Delal to v pascalu. Jeho reseni vypadalo asi takhle:

Kód: [Vybrat]

if b = 0 then
    s := '00000000';
else if b = 1 then
    s := '00000001';
else if b = 2 then
    s := '00000010';
.....

Cili funkce na prevod zabrala neco lehce pres 512 radku a obsahovala 256 ifu.
Nejvic me ale dostalo, ze tam mel i opacny prevod - binarni zapis cisla na byte a tam bylo dalsich 256 ifu a samosebou cca dvakrat tolik radku.

Kamarad je dnes inzenyr

[Filip Jirsák]

No hele, Java je interpretovaná ... = pomalá.

Nerovná se. Navíc Javu můžete klidně překládat do nativního kódu, běžně používané JVM pro PC to tak dělají, pokud jim explicitně neřeknete, že mají bajtkód jen interpretovat. C může být také interpretované, takže podle vaší logiky je také pomalé.

To že nevíš jak vypadá optimalizace pomocí bitových operací ještě nic neznamená, asi toho nevíš víc (třeba ušetření místa hmm?).

To, že vy tvrdíte, že víte, jak vypadá optimalizace pomocí bitových operací, neznamená, že byste věděl cokoli jiného. Zatím jste se moc nepředvedl.

[Pavel Tisnovsky]

TO PODLESH: pěkný rekurzivní výrok xD. Ale ne. Tak sem to nemyslel. Optimalizovat samozřejmě Javu také, ale používání bitových operací mi přijde (když to není vyžadováno...) na tak pomalí jazyk zbytečně hardcore optimalizace. C/C++ neřeknu ani slovo, tam je základní filozofie co nejefektivnější kód.

Tak ona optimalizace na objem obsazene pameti je v tomto pripade uplne stejna v C ci v Jave, navic to vysledke bitove pole obsadi (podle "umeni" programatora) prakticky stejne mnozstvi haldy ne? (+pokud to nekdo nebude chtit prosevat GC, taky je to relativne snadne).

Pokud se jedna o optimalizaci na rychlost, nelze obecne rict, jestli bude lepsi pole intu ve funkci pole booleanu nebo to nacpavat do jednotlivych bitu - zalezi na spouste veci, takze by se stejne musel pouzit benchmark, popr. se mrknout na vygenerovany assembler.

[Pavel Tisnovsky]

Tak nejak mi to pripomnelo meho kamarada, ktery ve druhem ci tretim rocniku VS - informatika - vyrabel v ramci nejakeho projektu prevod byte do retezce v binarnim formatu (osm jednicek/nul). Delal to v pascalu. Jeho reseni vypadalo asi takhle:

Kód: [Vybrat]

if b = 0 then
    s := '00000000';
else if b = 1 then
    s := '00000001';
else if b = 2 then
    s := '00000010';
.....

Cili funkce na prevod zabrala neco lehce pres 512 radku a obsahovala 256 ifu.
Nejvic me ale dostalo, ze tam mel i opacny prevod - binarni zapis cisla na byte a tam bylo dalsich 256 ifu a samosebou cca dvakrat tolik radku.

Kamarad je dnes inzenyr

No a nejzajimavejsi na tom je, ze tento Tvuj prispevek je ted zaindexovan googlem a az si bude nekdy v budoucnu chtit nejaky student "vypomoci"  s domaci ulohou, treba zrovna na nej narazi a udela ^Cizi^Vlastni

[RAII]

TO FILIP JIRSÁK: Java má taktéž GC, což je zpomalení jak prase. Vzhledem k tomu že hello world sežere několik MB, tak prosím nemluv o efektivitě Javy. To zaprvé. A za druhé, jediná a opravdu velká výhoda Javy je v multiplatformnosti. A ta se ztratí když se program nepřeloží do bajtkódu.

[ded.kenedy]

Boze, boze, boze...

Java má taktéž GC, což je zpomalení jak prase.

Alokace v ramci GC je na par instrukci, schvalne srovnej s tim, jak vypada dvojice malloc/free. Navic GC preskladava data v pameti, tim je mnohem vic cache-friendly nez explicitni alokace, ktera nechava pamet fragmentovanou. V rade pripadu to vyjde +/- nastejno.

Vzhledem k tomu že hello world sežere několik MB

To nezere hello world, ale behove prostredi, ktere je nutne tak nejak z podstaty.

A ta se ztratí když se program nepřeloží do bajtkódu.

Prosim te, vygoogli si aspon pojem JIT preklad, nez se zacnas vyjadrovat k Jave nebo k necemu ze sveta pocitacu.