Učit se Javu nebo C++?

[omg]

Moorovo pravidlo prestalo platit.

• Stale jsme se nedostali na uroven lidskeho mozku, co se tyce pomeru spotreby a vypocetniho vykonu nebo pameti. Samozrejme, mozek funguje dobre jen na neco, ale tohle stale znamena, ze je patrne jeste mozne inovovat pocitacovou architekturu
  

Kolik matic za sekundu dokaze tvuj mozek vynasobit tak, aby si je dokazal sdelit dal? Tim co naznacujes vpodstate kopes hrob IT jak ho zname. To co si predstavujes bude resit odlisne ulohy na jinych principech.

Moorov zakon uz hori na vzdalenosti kterou urazi elektron za takt. Staci se podivat co se deje s frekvenci. Uz je na maximu soucasnych materialu. Zachrani to na par let jen supravodice pri pokojove teplote.

http://commonsenseatheism.com/wp-content/uploads/2013/05/Moores-law.png
http://www.saphana.com/servlet/JiveServlet/showImage/38-1752-2298/Screen+Shot+2013-04-18+at+6.40.54+AM.png

Moorov zakon byl spojovan s odpovidajicim prinosem vykonu. I kdyz to neni primo to co rika, tak je tim co se od nej ocekava. Jenze tenhle vyklad uz delsi cas jen "podvadeji" pridanim dalsich jader. Jenze cela historie civilizace stoji a pada napric obory na transakcich. Vykon dostupny pro transakci za jednotku casu nam uz nejaky ten rok preslapuje na miste. Ano daji se dilci podukoly transkace paralelizovat, jenze pri sebelepsi snaze pokazde narazis na minimalni hierarchicky celek, ktery musi probehnout a pro ten zadny prinos par let uz nic znatelneho nebylo. Ted se jen pridavaji dalsi jadra - zvysuje stadni pristup k poctu podukolu na transakci. Kde jeste vykon roste dobre jsou nesynchronizovane/netransakcni ulohy - bud lockless struktury a algoritmy, ktere ovsem zahrnuji znacnou miru neefektivity a obcas i nejistoty a nebo zcela bezintegritni ukoly typu herni mmo servery nebo podpora stadniho pristupu cim vic ovecek tim vic baca hlavne, kdyz se ty ovce nesouperi o prostredky a pasou se hezky kazda na svym.

Se spotrebou co si zminil narazi na problem s preslechy sumu, kdyz se bude technologie blizit kvantovym energetickym minimum.

A alternativy?

Na frekvencni strop beztaktove procesory? Uz se v podstate pouziva ve forme vykonavani instrukci mimo poradi. Takt uz ma od te doby jen polovicni vypovidaci hodnotu o vykonu.
Na mezni vzdalenost sireni signalu? Uz se v podstate pouziva pyramidoveho vrstveni drobnych podukolu do jedne instrukce ktera pokryje cele funkcni bloky (MMX,SSE)
skoro se da rict, ze cele odvetvi ted ceka na supravodice pri pokojove teplote a doufat, ze licencovani ARM a Power proslape cesticku zcela nove instrukcni sade navrzene primo s cilem obelstit soucasne meze.

[Reklama]

[Kolemjdoucí]

Moorov zakon uz hori na vzdalenosti kterou urazi elektron za takt.

Konec Moorova zákona se prorokuje už od dob Pentia II 266 MHz, že už to nikdy rychleji nepojede

Na frekvencni strop beztaktove procesory? Uz se v podstate pouziva ve forme vykonavani instrukci mimo poradi. Takt uz ma od te doby jen polovicni vypovidaci hodnotu o vykonu.

Out-of-order není nic o beztaktovitosti, vše funguje při starém, vše je řízeno hodinovým signálem tak jako vždycky.

Na mezni vzdalenost sireni signalu? Uz se v podstate pouziva pyramidoveho vrstveni drobnych podukolu do jedne instrukce ktera pokryje cele funkcni bloky (MMX,SSE)

MMX a SSE není nic o podúkolech, je to o paralením provádění jedné stejné operace nad několika sadami dat. Zatímco standardní instrukce zpracuje najednou až 3x32/3x64 bitů, tak MMX instrukce až 3x64 bitů, SSE instrukce až 3x128 bitů, AVX až 3x256 bitů.

licencovani ARM a Power proslape cesticku zcela nove instrukcni sade navrzene primo s cilem obelstit soucasne meze.

ARM a Power zcela jistě neprošlape cestičku k vyšším výkonům a to kvůli architektuře RISC, jež je zcela nevhodná pro dnešní o dva řády zaostávající paměti. Proto se i do ARMů z velké nouze přidávají VLIW instrukce známé z x86 světa.

[omg]

Out-of-order není nic o beztaktovitosti, vše funguje při starém, vše je řízeno hodinovým signálem tak jako vždycky.

no tak podle detailu dole to neni syndrom jednookeho mezi slepymi, ale proste jen terminologicka cistota nazvoslovi.
nez vysvetlovat vyvoj od sekvencniho zpracovani co instrukce to takt, pres sekvencni zpracovani pul a vicetaktkovych instrukci az k nesekvencnimu zpracovani, ale sekvencnimu vstupu a prezentaci/vystupu ... nez tak zdlouhave, tak je lepsi pouzit zkratku toho kam se to cele riti a kde uz zpracovani vzhledem k taktu je dnes - jen volne zavisle.

MMX a SSE není nic o podúkolech, je to o paralením provádění jedné stejné operace nad několika sadami dat. Zatímco standardní instrukce zpracuje najednou až 3x32/3x64 bitů, tak MMX instrukce až 3x64 bitů, SSE instrukce až 3x128 bitů, AVX až 3x256 bitů.

opet stejny pripad. n-iterace nahrazena n-arni operaci. m n-arnich operaci nahrazenych m paralelismem... je to jen o tom kde jestli to chce clovek videt cele panorama vyvoje nebo utrzek nejakeho stavu a o tom slovickarit.

ARM a Power zcela jistě neprošlape cestičku k vyšším výkonům a to kvůli architektuře RISC, jež je zcela nevhodná pro dnešní o dva řády zaostávající paměti. Proto se i do ARMů z velké nouze přidávají VLIW instrukce známé z x86 světa.

Vystouchnuti x86 instrukcni sady z monopolniho postaveni zpracovani "dennich vypocetnich ukolu" urcite prinese nejaky vyvoj. Jen se momentalne u Intelu ceka az bude vetsina zakazniku zmenu zadata a zacne hlasovat penezi. Dokud hlasuji pro zpetnou kompatibilitu, tak neni dvakrat velky duvod jim servirovat neco noveho..

Jinak ano moorov zakon neni mrtev tam, kde ho doposud nikdo neprotlacoval. viz treba http://4.bp.blogspot.com/-98RZFDXSVqQ/Ti6vLM04j2I/AAAAAAAAFOI/VcfM-mQExbk/s1600/03.jpg
A spojenim uloh do APU jeste nejaky ten patek prezije. I kdyz to pro nemalou cast lidi bude znamenat jen dalsi "podraz" jak udrzet mrtvou legendu pri zivote.

A mezi tim se while, loop, repeat a sekvence kodu stane optimalizacne nejdrazsi cast. V prekladacich se treba dockame rozpoznavani paralelizovatelnych prechodovych stavu a rozeznavani mist, ktere slouzi jako bariera. http://helix.eecs.harvard.edu/index.php/DAC2012

[Kolemjdoucí]

Nelíbí se mi zavádění nových zmatečných pojmů jako "beztaktový procesor", které nadělají víc škody než užitku. Říkejme prostě třeba procesor řady Core i7. Laikovi to stačí a odborník ví.

Jen se momentalne u Intelu ceka az bude vetsina zakazniku zmenu zadata a zacne hlasovat penezi. Dokud hlasuji pro zpetnou kompatibilitu, tak neni dvakrat velky duvod jim servirovat neco noveho.

Na to Intel čeká od roku 1985. Intel chtěl x86 zlikvidovat společně s ukončením výroby 80286 a chtěl přejít na i860, ovšem zákazníci si vynutili pokračování x86 a tedy 80386. Druhý pokus byl u příležitosti přechodu na 64-bit v roce 2001 s Itaniem, ovšem zákazníci to opět odmítli a vynutili si x86_64. Na základě tohoto vývoje je jisté, že x86 tady bude ještě velmi dlouho.

A mezi tim se while, loop, repeat a sekvence kodu stane optimalizacne nejdrazsi cast. V prekladacich se treba dockame rozpoznavani paralelizovatelnych prechodovych stavu a rozeznavani mist, ktere slouzi jako bariera.

O tom se mluví od vzniku P4 s HT, ale zjistilo se že jen poměrně málo běžných úloh se dá paralelizovat byť ručně, natož strojově. Tedy na tomto poli nelze očekávat zázraky, jako že třeba Word se prožene über-kompilátorem a bude najednou využívat 16 jader na 100 %.

[omg]

Nelíbí se mi zavádění nových zmatečných pojmů jako "beztaktový procesor", které nadělají víc škody než užitku. Říkejme prostě třeba procesor řady Core i7. Laikovi to stačí a odborník ví.

A bude trvat na tom zanedbatelnem casovem useku minulosti nedavne az pritomnosti a nepodiva se ani zpet ani dal do budoucna. a just ne.

[Reklama]

[wljrlrkjewrjwel]

Osobně do budoucna fandím C++ (a kompilovaným jazykům obecně) před Javou. Boom platformně nazávislých jazyků typu Java apod.
je totiž pouze dočasný jev daný chaosem v hardwaru a neskutečným množstvím výrobců. Nicméně výroba stovek různých druhů procesorů a systému, a chaos který přináší nebude trvat navždy. Časem nastane řád. Je to tvrdě konkurenční prostředí, dochází k monopolizaci a většina vychcípe a zůstane jen několik velkých hráčů. Ať se nám líbí nebo ne, nejsilnější zvítězí. A když těch platforem nebude tolik jako dnes, tak jazyky typu Java nebudou mít moc smysl protože výhody která mají už nebudou tak zástadní a zůstanou jejich nevýhody. Jejich úspěch je pouze dočasný daný historickými okolnostmi roztříštěnosti výroby hardwaru. Toliko můj názor.

[slanecek]

Ať se nám líbí nebo ne, nejsilnější zvítězí.

A proto všichi budou programovat v javě

[perceptron]

hlavne sa kazdy zakope na svojom poli a bude mu tam dobre, tak ako to je teraz.

v jave sa nezacnu pisat masove gui aplikacie prave tak ako sa v c++ nezacnu pisat velke enterprise riesenia

aj ked sa mozno dockame dalsich wtf dejinnych zvratov typu "java ako dominantny jazyk na smartfonoch" alebo "velky navrat objective-c" budeme programovat v haskelli alebo co.

[Kolemjdoucí]

A proto všichi budou programovat v javě

To se hlásá od roku 1995 a pořád to nenastalo a s krachem SUNu je jasné že už to ani nenastane.

Je také docela možný návrat k nativním aplikačkám, protože BFU hodně používají mobilní zařízení a jsou nas*aní z malé výdrže na akumulátory a nativní aplikačka je reálná možnost k delší výdrži.

[hmmm]

Je také docela možný návrat k nativním aplikačkám, protože BFU hodně používají mobilní zařízení a jsou nas*aní z malé výdrže na akumulátory a nativní aplikačka je reálná možnost k delší výdrži.

sprostost ... radsej vyrobia silnejsiu baterku ako by sa mali zaoberat nejakymi nativnymi aplikaciami, nezaplatil by sa tym vyvoj

[x14]

Odpověď je už v otázce – před 'nebo' není čárka – učit se je oba a klidně i nějaké další, i třeba neprogramovací, i třeba jen základy. Vyplatí se to, i když nakonec budeš používat něco úplně jiného.

A pokud jde o ty nativní aplikace, tak mně žere na Androidu nejvíc displej a data/WIFI, dále GPS a poslech hudby. Něco by se asi ušetřilo, ale je otázka kolik. Víc než deset procent? Těžko.

[Martin Šulák]

Osobně do budoucna fandím C++ (a kompilovaným jazykům obecně) před Javou. Boom platformně nazávislých jazyků typu Java apod.
je totiž pouze dočasný jev daný chaosem v hardwaru

1. Java je kompilovaný jazyk, výstup překladače je virtuální strojový kód. Narozdíl od interpretovaných jazyků není možno kód měnit za běhu, není zde eval jako v javascriptu.
2. Java není jen o abstrakci HW (a taky OS), ale i o pohodlí programátora (garbace collector, výjimky, hlídání indexů).

Osobně fandím C++, protože má lepší šablony, makra, přetížení operátorů a hlavně strukturované typy (java classy nepočítám). C struktury jsou rychlejší a v některých případech zjednodušují deserializaci externích dat.
Jinak platilo a bude platit C++ jako lowlevel pro výkonově náročnou část aplikace a Java pro rychlou a zpravidla jednoúčelovou implementaci zákazkového systému. Pro krabicový desktopový SW je určitě vhodnější C++ než Java. Java je vhodnější na serverové aplikace s nízkým nárokem na výkon.

[noef]

1. Java je kompilovaný jazyk, výstup překladače je virtuální strojový kód. Narozdíl od interpretovaných jazyků není možno kód měnit za běhu, není zde eval jako v javascriptu.

Neni pravda, viz ASM nebo Javassist (sice jde spis o generovani nez zmenu kodu, ale vyjde to nastejno; navic mam pocit, ze existuji nejake oracle VM-specific metody jak vymenit i uz nactenou tridu - tj. menit kod za behu).

Osobne fandim JVM, tj. Jave a hlavne Scale.

[perceptron]

je také docela možný návrat k nativním aplikačkám, protože BFU hodně používají mobilní zařízení a jsou nas*aní z malé výdrže na akumulátory a nativní aplikačka je reálná možnost k delší výdrži.

bfu sa naucia pchat mobil do nabijacky na vecer + iphonacky ios je omnoho viac pri zeleze nez java a nevyzera to tak, zeby zdominoval trh alebo zeby vydrz bola dramaticky lepsia + (vid x14) najviac zere displej, 3g modul, wifi

k tej zmene kodu za behu - na roote bezi serial o javassiste, tam sa daju robit krasne zveriny, oracle java ma hotswap, kde sa moze vymenit pocas behu kompletny kod metody triedy, a taky jrebel umoznuje cez vlastny vm agent za behu menit cele struktury tried (pridavat / odoberat metody, menit ich kod).

[omg]

v jave sa nezacnu pisat masove gui aplikacie prave tak ako sa v c++ nezacnu pisat velke enterprise riesenia

pobavil si. a nebo jen slovickarime na "nezacnou".
tech systemu co se jim pocita zdrojak v radech 10mil radek c++ kodu tu je z obdobi 1980-2000 pomerne dost a nikam se nechystaji.