Cloud, buducnost, prevara ili zabluda?

Kompajliranje prolazi (iz VC++2010 beta2) ali sam malo umoran da sad pogledam sta i kako radi... sutra.

---

Dakle, treba proveriti da li radi ovaj program



Treba da ispiše 24 i 1.

Dalje, ako radi, treba proveriti da li intelisens radi potpuno unutar šablona. Eclipse ima intelisesns za ISO C++, ali malo osakaćen za šablone i isto to za intelisens u VS za klasičan C++. Ako i to prođe, onda MS ima dovoljno brz parser, jer je Eclipse rađen u Javi, a u VS rađenom u C++ je dovoljno brzo.

Na kraju krajeva MS ima prilično brz kompajler. No, C++ se svakako sporije žvaće nego delfi, a da li ne neko uspeo da ga satera unutar onoga što treba za on the fly, videćemo.

---

LOL

Da, ispisuje 24 i 1, evo i ja stavio taman VS 2010 b2.. Intellisense izgleda nešto i ne mož da se proveri ("Unavailable for C++/CLI" :-).. možda što je beta 2, a možda ja nemam pojma :-)


Mogao bi ti sam da staviš VS a ne da smaraš. Mislim kad si već toliko zapeo da pričaš o svemu tome, očekivao bi čovek da imaš VS (kako uopšte onda umeš da oceniš da "MS ima prilično brz kompajler" ??!)..

---

Čekaj, zar Visual Studio nije prilično skup alat? :)

Ja probao sa GCC-om, kaže "druže, ne znam ja o čemu se ovde radi" :D

---

Pa, mogu, jer ga imam, ali sam trenutno na SUSE-u zbog posla.

Kod mene g++ kompajlira i izvrsava bez problema.

No, intelisens ipak nije dostupan za C++.

---

jes, radi ko sat

srdjan@Zverko:~/Desktop/C-Progs$ g++ 3.c
srdjan@Zverko:~/Desktop/C-Progs$ ls
1.c 1-p 2.c 2.c~ 2-p 3.c 3.c~ a.out
srdjan@Zverko:~/Desktop/C-Progs$ chmod +x a.out
srdjan@Zverko:~/Desktop/C-Progs$ ./a.out
24
1
srdjan@Zverko:~/Desktop/C-Progs$

---

Na temu sablona, da u pure managed modu C++ compiler ce primeniti sablon dok god moze da "odradi" sablon compile time. Ako ne moze koristice generics (Naravno uvek ostaje stara fora sa mixed codom i "native" sablonima)

Npr kad se prevede kod koji ste dali dobije se sledeci decompile (ocekivano):



Ovaj treci poziv je u stvari poziv u



i isti je pretvoren u generic metod int FactorialT<int>(int num)

Btw, ne znam sto se toliko tripujete oko vs2010, za managed C++ intelisense radi sasvim fino i na vs2008 bar sto se tice tipova i sablona/genericsa (rade cak i documentation tagovi, mada malo brljavo)

---

Ako rekurzije u šablonima tretira kao generike, onda to bitno menja stvari po pitanju parsiranja. Tada gramatika više nije ista i pada u kontekstno slobodne, pa i uže.

Naime, onda će C++/CLI prihvatiti i neke konstrukcije koje nemaju izlaz iz rekurzije, koje se compile time ne mogu obraditi, jer bi kompajler radio neograničeno dugo.

Da, skup prihvatljivih jezičkih konstrukcija jeste širi, ali je gramatika prostija, jer više nemamo problem zaustavljanja.

http://en.wikipedia.org/wiki/Halting_problem

Dok native C++ kompajler mora da razvije šablone do kraja, C++/CLI ne mora time da se bavi, već guta zdravo za gotovo. Time se gramatika proširuje u smislu skupa dopustivih konstrukcija, ali pojednostavljuje u smislu matematičke hijerarhije složenosti.

---

Pa dovoljno je kao primer. Sve sto je u .NET dodato od v2.0 na ovamo je iskljucivo i samo na nivou biblioteka (uz eventualne dodatke kompajlerima), bez obzira sto MS marketing tim besomucno inkrementira broj verzije ni IL ni CLR se nisu znacajnije menjali (sem nekih optimizacija GCa i slicnih stvari). Ne znam kako ne uvidjas problem, zato sto se na kraju i AsParallel instrukcije svode na automatsko startovanje worker threadova kroz biblioteku JIT nikad nece moci da optimizuje taj kod vise nego sto moze da optimizuje kod biblioteke koja to radi, samim tim JIT nema sanse da bilo sta smisleno izanalizira iz payload koda koji ti threadovi rade niti moze bilo sta smisleno da tu optimizuje. Samim tim ne moras ni da cekas VS2010 za AsParallel(), to si mogao i sam da uradis kroz IEnumerable<T> ekstenziju gde ces svaku iteraciju da pobacas na worker thread pool. Vec godinama nam prodaju muda za bubrege i teraju u sto vecu apstrakciju na ustrb performansi. Sto opet ja razumem, to omogucava zaposljavanje C- programera ali opet6 me uzasno nervira kad se tvrdi da je to DOBRO.



ne pratis me, ja se slazem sa slikom realnosti koju ti slikas, nisam ja pao sa drveta pre pola sata i zato vec godinama pazim gde cu se zaposliti i ko ce mi biti kolege, problem nije u tome sto ti tvrdis, problem je sto ti smatras da je to DOBRO resenje za softversku industriju. A za ovo poslednje nisi u pravu i postoje firme koje ne razmisljaju na taj nacin i koje zaradjuju fine pare. Medjutim upravo takvim firmama cloud najvise kvari posao jer direktno konkurise na istu klijentelu, ljude koji su se opekli na mediokritetske ISV-ove, s tim sto cloud ulazi u pricu sa svojim brandom.



Itekako imaju, samo ti to odbijas da vidis zato sto dozivljavas CLR kao varijantu JavaVM-a sto on nije. Samo zato sto vodi racuna o svojoj memoriji ne cini ga virtuelnom masinom.



Ne znam za tebe ali meni ovo izgleda kao x86 instruction set. CLR nije virtuelna masina, at best to je forsirani API u kome je unmanaged malloc zamenjen sa managed verzijom i u kome je apstrakcija postignuta time sto je programeru uskracena puna kontrola nad izlazom iz JIT-a u high level jezicima kao sto je c# ili vb.net. C++/CLI ti omogucava bez pardona da u bilo kom trenutku napustis managed context i da predjes na pure native kod (bila je neka tema na .NETu pre nekog vremena gde smo uradili trostruki prelaz). Ta tranzicija nije nikakva mudrost i svodi se bukvalno na cleanup stek-a i jos par sitnica, CLR se cak ni ne trudi da sacuva svoj managed heap, sve strukture su direktno dostupne iz unmanaged koda (s tim sto bi bilo lepo da ih pinujes prvo da ih GC ne bi pomerao). To ide do te mere da mozes komotno da zaobidjes i sama CLR ogranicenja kao sto je string immutability, dakle ne postoji nikakav sandboxing koda.
Singularity ti je npr konkretan primer toga, ceo OS je managed, tj kernel JE kernel+HAL+CLR i sav kod je "apstraktovan" na nivo ILa, dakle ako imas HAL i JIT za odredjeni hardver imas i automatsku kompatibilnost Singularity aplikacija, user mode drajvera, itd.

---

Pa, dobro mmx, možeš li mi reći, kada se već .NET bajtkod prilikom pokretanja/instaliranja prevodi u native, kako stoje stvari sa odnosom brzine izvršavanja i da li to važi samo za MS-ovu implementaciju ili i za Mono?

---

Nisam merio Mono/MS predjenje, mada pretpostavljam da moze da se iskopa na netu ako je to neko radio. Kao sto vidis iz listinga ima tu nekih nelogicnosti (silni nopovi), ali generalno mi deluje sasvim poredivo sa izlazom iz C++ aplikacija. Narafski ako se dohvatis asemblera uvek to moze bolje, ali to bi vec bio overkill.

Problem sa JITovanim kodom u smislu performansi je u odrzavanju CLR konteksta, posto nije VM i posto kod radi na metalu CLR nema direktnu kontrolu nad izvrsavanjem (CPU to radi), samim tim da bi CLR bio "u toku" sa managed kodom JIT generise odgovarajuce pozive u mscorlib.dll za odredjenje akcije (npr za odrzavanje try/catch/finally stukture, itd). Ti pozivi nisu bas retkost i oni generalno usporavaju managed code u poredjenju sa slim native kodom. U nekoj linearnoj aplikaciji to se ne oseca ni blizu, ali ako imas puno iteracija (npr kad pravis hypercube simulaciju) onda se itekako oseti i tu nema pomoci sem da izadjes u pure native kod. Mi smo npr inicijalno napravili celu simulaciju u managed C#-u i to je radilo dosta sporo, narocito baratanje matricama i pozivi u System.Math. Iz tog razloga smo kupili nMath i prebacili sav heavy lifting na njega (nMath je mixed mode C++/CLI wrapper oko BLAS/LAPACK) i to nam je ubrzalo simulacije tri puta.

---

Može C da bude brži i od asemlera, a oba programa su pisali vrhunski maheri. Šta misliš kako?

---

Instruction pipelining i bubbling?

Btw, jos jedna stvar koju skoro uvek vidim kao proizvod losih .NET programera su string operacije, profiler to otkriva ko iz puske. Posto su stringovi immutable, svaka operacija na stringovima kreira novi string (sa sve managed alokacijom i generisanjem/kopiranjem karaktera). Nije uopste nevidjeno da cak i 80% execution time-a ode na glupave operacije kao sto je spajanje stringova u petljama (ono c = c + " dodato "). Sve string operacije u .NETu su uzasno skupe a malo ljudi obraca paznju na to. Apstrakcija i realnost, sta ces.

---

Napiše ekstra mega vau programer 1988 godine program za IBM PC XT koji radi sa matricama na asembleru. Njegov kolega, ekstra mega vau giga programer uradi na C-u.

Posle toga nađu se oni 2008 da testiraju svoje programe. Drugi programer je sačuvao C sors i iskompajlira ga opet. Prvi programer je takođe sačuvao (asemplerski) sors. Šta misliš, koji će program brže da radi?

---

Pa nije bas toliko bistar koliko mu dajes credit-a On jednostavno pravi diferencijaciju izmedju sablona i template-a po osnovu toga dal su value ili type based, prve evaluira compile-time, a ako su type based onda ide na generice. Cak ni ne dozvoljava da iskoristis value sablon preko promenljive (npr int x = 4; Factorial<x> nije dzovoljeno).


Btw, ako probas da compile-time uradis specijalizaciju koja nije izvodljiva (npr Factorial<1000>) CL pada ko klada




A za infinite recursion ima resenje, mislim da CL interno specijalizuje sablone kroz genericse (Factorial<4>, pa Factorial<3>, dok ne naleti na postojeci Factorial<0> gde definise value) bez obzira na to sto te genericse ne publikuje u izlazni asembli (optimizacija verovatno iskida to) pa ukoliko postoji inifinite loop u nekom trenutku ce odustati i prijaviti da value ne postoji u Factorial<N> sto je malo misleading, ali bar sljaka.

---

A ako pokusas da uradis nesto ovako:



dobijes:
fatal error C1202: recursive type or function dependency context too complex

---

Odmah da emantujem sebe, nije ni ovoliko pametan bas, to radi sam kod bas ociglednih mrtvih petlji, sa iole malo kompleksnijim:



Pokusava da odradi rekurziju i u svakoj iteraciji pokupi "value not defined" dok ne ispuca maksimalan broj fatalnih gresaka i ne izbaci:
Error 102 fatal error C1003: error count exceeds 100; stopping compilation

Da moze da se poveca iznad 100 verovatno bi vrteo dok ne sprzi sopstveni stek i baci novi APPCRASH.

---

Dakle, može li onaj faktorijel da radi bez generika ili ne?

---

Ma moze, to smo vec utvrdili (pod uslovom da ne izazove overflow ili ne ubije stek kompajlera).

---

A gde sam ja rekao da je to resenje DOBRO? Vrlo retko smatram da je neko resenje DOBRO, vecina resenja koje rade su u okvirima moguceg i zadovoljavajuceg. Ali ajde kad smo kod paralelnog razvoja, niko ne moze da kaze da je paralelno programiranje lako i da ne zahteva prilicno jake programere... e sad da ne duzim, cinjenica je da se single core zabio na 3-4GHz, sakrivanje latencije sa nivoima kesa i ostalim "magijama" u jednom jezgru nam donosi ubrzanja tipa 5-10% u najboljem slucaju, i industrija je krenula u multicore zbog toga. E sad imas u masini 4 jezgra uskoro stize 6, 8 pa nadalje sa verovatnocom da za nekoliko godina imas 32 ili mozda cak i vise jezgra na stolu (o serverima da ne govorimo) i sad sva ta jezgra stoje i nista ne rade jer imas glupavi sekvencijalni kod. I ko ce da ti pise paralelni kod tih 12 programera koje imas na trzistu? Kazi mi koja je alternativa? Ja bih voleo da je sav softver na svetu savrsen i da su svugde zaposleni Ajnstajni ali to nije realno.

90% vremena u velikoj softverskoj firmi sam provodio kopajuci po kodu ko neki idiot da bih skontao sta je HTML guy koji se prihvatio malo VB-a naucio malo da programira i onda seo za C# hteo da kaze kad je napisao najgoru skalameriju od koda koji se da zamisliti. I pazi koliko god bilo neverovatno taj kod radi i donosi pare firmi (znam da je to bezveze ali vecina softverskog razvoja je "death march") a alternativa je da nemas softver jer ne mogu A+ i A programeri sve da napisu, fizicki je nemoguce. Ne govorim ti o "critical level" softveru koje bi stvarno trebali samo A+ programeri da rade nego o 90% softvera na svetu bez cega bi sijaset stvari i dalje bilo samo u domenu naucne fantastike. Kazi mi zar nije bolje da jedan broj tih A+ programera stvara alate, biblioteke i dodatnu apstrakciju da recimo ja koji sam mozda A a mozda samo B+ programer ne provodim 90% vremena kopajuci po kodu B i C programera? Na kraju krajeva koliko puta i A ili B+ programer odradi posao daleko ispod svog nivoa jer su ga bacili u domen u kome nema iskustva i dali mu rok da sve to dovrsi do kraja nedelje, i sta onda radi i A programer, koristi konstrukcije koje su mu pali napamet na osnovu iskustva u drugoj oblasti programiranja gde je mozda ekspert. E sad verovao ili ne ti B i C programeri su bili zaposleni i pre 10 godina kada je apstrakcija bila na nizem nivou i guess what... proizvodili su daleko losiji kod nego sto proizvode danas sa ovom dodatnom apstrakcijom. To se desava to je realnost.

Ne znam zasto neko misli da proizvodjaci alata i platformi rade u vakumu i prave nesto po svojoj volji ili nesto sto je dobro samo na Marsu? Svi oni imaju zahteve klijenata, u realnoj industriji nisu svi glupi veliki deo menadzera vidi gde su problemi a narocito vecina A+ i A programera i svi komuniciraju te probleme Microsoftu, Sun-u i ostalima a i Open Source zajednica radi na slicnim resenjima bas iz razloga sto imamo problem i treba da ga nekako resimo ili bar ublazimo. Niko ne radi apstrakciju iz religioznih razloga nego zato sto to zaista pomaze da softverska industrija ne kolapsira.

Sto se tice CLR-a i JavaVM-a, opet ne vidim gde si procitao da sam rekao da je CLR = JavaVM? Nikad nisam ni pomislio na to kada znam da nije... govorio sam u kontekstu apstrakcije... ideja JavaVM i CLR je u sustini ista samo sto je CLR drugacije implementiran (izmedju ostalog iz razloga sto MS ne zanima non-Windows platforma pa nema ni razloga da pravi sandbox, niti su hteli da bace milione i milione linija native razvoja nego su morali da smisle nacin kako da uvedu apstrakciju ala JavaVM ali da zadrze ono sto im je bitno iz native sveta. S druge strane .NET i CLR su samo dodatno dobili napravljeni i za Web (CLR je uvek bio zamisljen kao prirodan naslednik COM-a), dok je cela ideja Jave u startu bila totalno okrenuta prema Web-u. Znaci jos jednom poredjenje dva sistema je bilo iskljucivo zbog apstrakcije. Naravno apstrakcija u ovakvom smislu nije svugde potrebna niti pozeljna, ima i C i C++ svoje trziste i to trziste se cak i siri (bez obzira sto svi misle da se suzava), samo sto ga sve manje i manje ima u razvoju poslovnih resenja.

Inace kao sto sam rekao nista nije nemoguce (u rukama Mandusica Vuka svaka puska...) znaci u nekoj krajnjoj perspektivi sve je moguce uraditi u native okruzenju, moguce je pisati objektni kod i u C-u pa i u assembleru ali pitanje je kolika je cena toga? Ja sam ovde sa Nedeljkom imao neku mini raspravu oko toga da li CLR (i JavaVM) uticu na porast produktivnosti ili je cela stvar samo posledica jezika poput Jave i C#-a. Na to si ti jos dodao RAD alate... i sve to zajedno stvara porast produktivnosti. Ja nikad nisam tvrdio suprotno, ono sto sam rekao da apstrakcija koju donosi CLR ima veci uticaj na porast produktivnosti nego recimo C# i da je C# tako produktivan bas zato sto je u simbiozi sa CLR, Nedeljko se ne slaze sa time, naravno isto tako sam rekao da su i neka resenja u RAD alatima moguca ili bolje receno lakse dostupna zbog CLR-a odnosno mehanizma koja omogucava managed kod. Naravno ne mora da znaci da sam u pravu, rasprava i sluzi da bismo jedni od drugih nesto naucili :) ali na kraju i dalje mislim da je tako (a Nedeljko verovatno i dalje misli suprotno).

Na kraju najbitnija stvar u razvoju softvera da isporucis softver (ali kako Alan Cooper kaze oslanjajuci se na Petera Druckera ne treba se obavezati i predati se neoptimalnoj strategiji) znaci bitno je ispravno odmeriti probleme koje treba resiti, naci optimalnu soluciju i komunicirati tu soluciji hrpi hardvera (i softvera) da bismo imali prakticno resenje. Za sve to trebamo alate i kada se radi o kompleksnom softveru za sve to treba apstrakcija i to na svakom nivou, pogotovo na nivou programerske komunikacije prema hardveru.

Da ne zaboravis... koja je alternativa?

---