Názory k článku Pohled pod kapotu JVM (11.část - instrukce pro tvorbu polí a přístup k prvkům polí)
-
atarist (neregistrovaný)
Jak tak studuju javovsky virtualni stroj, tak me porad prekvapuje, proc je tolik instrukcnich kodu obetovano pro nizkourovnove operace s cisly nebo se znaky, vzdyt to se ve velkych Javovskych projektech az tak moc nevyuzije. Nebylo by nahodou lepsi nechat vice instrukci pro nejake vysokourovnove operace (hmm zase jake ze?) Neco na zpusob Pythoniho bajtkodu, ktery se s nejakymi inty/chary moc netrapi :-)
Nebo takto: da se nekde najit studie, ktera ukazuje, ktere instrukce se pouzivaji s jakou frekvenci? Kdysi se takove studie delaly pri vyvoji novych CPU, dneska netusim.
-
Filip JirsákStříbrný podporovatelPodle mne to bude dáno tím, k čemu byla Java původně zamýšlena – počítalo se s ní na zařízení, která nemají zrovna přebytek výkonu. Ze stejného důvodu jsou v Javě primitivní datové typy nebo pole.
-
Pavel TišnovskýZlatý podporovatelNj. puvodne melo jit o jazyk (ci lepe receno platformu) pro rizeni toustovacu a mikrovlnek a potom se to zvrhlo na aplikacni servery :-) Ale ta "nizkourovnova" instrukcni sada nicemu moc nevadi, pekne se s ni pracuje v Hotspotu - mozna o tom taky neco napisu, az tomu vic porozumim do hloubky :-)
-
Pavel TišnovskýZlatý podporovatel
Ono pole jako datova struktura neni vubec spatne reseni a ze je pro to vycleneno nekolik instrukci bylo zpocatku (v dnes jiz znacne prekonane Jave 1.0) taky dobre. Syntakticky cukr v podobe [] za chvili budeme moci pouzivat i pro listy atd., takze by zdrojaky zase mely byt trosku jednodussi, no uvidime.
-
Pavel TišnovskýZlatý podporovatel
Je pro zamysleni pohled z druhe strany, od JS cloveka:
Brendan Eich:
Doug's point about source beating bytecode is good. My friend Prof. Michael Franz of UC Irvine long ago showed O(n^4) complexity (runaway compute cycles, denial of service) in the Java verifier. JS is strictly more portable and fast enough to lex/parse as minified source.
Source as "bytecode" also avoids the big stupid Java bytecode mistake: freezing a poorly designed lowered form of Java, then being unable to evolve the high-form source, i.e., the Java programming language for fear of breaking Java bytecode compatibility. This severely messed up the design of inner classes and then generics in Java -- and then Sun broke bytecode compat anyway!
-
atarist (neregistrovaný)
Kdyz uz jsme u toho, tedy predpokladam, ze tento clanek a nazory ctou spis lidi, co maji Javu a JVM v malicku :-), proc se pri podpore nizkourovnovych operaci zapomelo na indexovani retezcu? Operator + na retezce v Jave je, i kdyz neefektivni (to neva, kdyz clovek vi, co se pod tim skryva), ale "indexovani" pres String.charAt() nepochopim a nepochopim, kdyz i cecko nebo i pitomoucky Basic na to ma [] popr. ().
-
Jardík (neregistrovaný)
Já myslím, že je to jedině dobře. Alespoň je větší šance, že si někdo uvědomí, že String je utf-16 řetězec, kde můžou být surrogate páry. charAt pak říká, že chci ten prvek typu char (java tomu říká unicode code unit) na té pozici, pak je ještě codePointAt, která vrací unicode znak (jako int) na dané pozici.
-
Pavel TišnovskýZlatý podporovatel
Popravde receno mam sam dost problemy s kontrolou, jestli aplikace skutecne bude pracovat korektne i pro retezce se znaky mimo ucs-2. Samozrejme pro evropske jazyky (vcetne azbuky ci alfabety) neni zadny rozdil, ale jak programy s charAt() budou pracovat i pro 21bitove kodovani je nekdy ve hvezdach :)
