[es] - native image generator (ngen) problem ?!

nikomak
Nikola Makić
Beograd

Član broj: 177053
Poruke: 65
*.eunet.yu.

+1 Profil

native image generator (ngen) problem ?!

^{28.03.2008. u 14:49 - pre 207 meseci}

Pozdrav.

Imam cudan problem sa ngen-om. Naime, cini mi se da skoro svaki native image koji kreiram putem ovog alata radi sporije od "normalnog".

Npr., danas sam napravio jednostavnu Forms aplikaciju u C# koja sadrzi samo glavni meni i nekoliko podmenija; kada prevedem i pokrenem program on radi ok. Medjutim, kada upotrebim ngen, aplikacija koja se dobije je uzasno spora, potrebno je nekoliko
sekundi da se meni iscrta, a kada se iscrta i prikaze onda aplikacija zauzme dosta procesorskog vremena i jednostavno se blokira, pa moram da "nasilno" prekinem proces.

Na netu sam pronasao nekoliko slicnih problema, ali nijedno ponudjeno resenje (rebuild image cache-a i slicno) nije dalo rezultata.

Hvala svima unapred.

P.S.:
Inace, koristio sam VS2008 Express i .net 2.0 framework za aplikaciju.

TurboDispatchJumpAddressEnd
----
Knocka Fia
----
And so we meet, again in a different time

Odgovor na temu

nikomak
Nikola Makić
Beograd

Član broj: 177053
Poruke: 65
*.eunet.yu.

+1 Profil

Re: native image generator (ngen) problem ?!

^{02.04.2008. u 20:16 - pre 207 meseci}

*bump*
Anyone ?

U svakom slucaju probacu da li ce ngen da odradi pri instalaciji na klijentovom racunaru ;)

TurboDispatchJumpAddressEnd
----
Knocka Fia
----
And so we meet, again in a different time

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: native image generator (ngen) problem ?!

^{03.04.2008. u 19:47 - pre 207 meseci}

A sto se uopste petljas sa time?

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

nikomak
Nikola Makić
Beograd

Član broj: 177053
Poruke: 65
*.eunet.yu.

+1 Profil

Re: native image generator (ngen) problem ?!

^{03.04.2008. u 20:40 - pre 207 meseci}

Onako, igram se :P
To make my assemblies (almost) native fast, man :)

TurboDispatchJumpAddressEnd
----
Knocka Fia
----
And so we meet, again in a different time

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: native image generator (ngen) problem ?!

^{03.04.2008. u 22:29 - pre 207 meseci}

.NET nije kao Java ili VB6, dakle nije interpreter. Svaki put kad se asembli ucitava JIT kompajler ngen-uje kod ako ngen image nije direktno dostupan u kesu. Dakle tvoji asembliji su vec native fast, man ;)

Odgovor na temu

nikomak
Nikola Makić
Beograd

Član broj: 177053
Poruke: 65
*.rcub.bg.ac.yu.

+1 Profil

Re: native image generator (ngen) problem ?!

^{04.04.2008. u 12:24 - pre 207 meseci}

Naravno da nije interpreter, ali radi se o sasvim drugoj stvari :) Naime, ngen se koristi da PREkompajlira asembli i da sacuva dobijeni rezultat u kes, da bi se izbeglo JIT-anje svaki put pri koriscenju programa. Problem je u tome sto se na mojoj kucnoj masini taj kes nekako osteti, ili se ne kreira kako bi trebalo (iako se kes programa uredno upise u C:\Windows\assembly\NativeImages_v[VERZIJA] ).

Evo kratkog "testa" sa masine na kojoj sve radi ok:
1. Instalirao sam .NET SDK
2. Download-ovao sam Vista Manager (.NET program) i pokrenuo ga nekoliko puta.
3. Korstio sam Process Explorer da "ispitam" performanse JIT-a

4. Generisao sam image kes na sledeci nacin: ngen install VistaManager.exe
5. Korstio sam Process Explorer da "ispitam" performanse JIT-a :)

Pokusajte i sami, pa uporedite rezultate.

Dalje, ne znam da li ste primetili da se posle instalacije Visual Studia ili update/instalacije .NET framework-a, itd. proces mscorsvw.exe pokrene i zapocne da "radi nesto u pozadini". Naravno, to je .NET optimization service koji vrsi prekompilaciju najvaznijih asemblija koji se nalaze u queue (ngen install [assembly] /queue).

:bye:

TurboDispatchJumpAddressEnd
----
Knocka Fia
----
And so we meet, again in a different time

Prikačeni fajlovi

jit1.jpg - 42.94k

jit2.jpg - 42.33k

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: native image generator (ngen) problem ?!

^{04.04.2008. u 19:13 - pre 207 meseci}

To je inace velika prevara

Do pre .NET2 ngen generisani asembliji su imali veliki problem sa bindingom metoda, tj, posto u trenutku kreiranja native image-a nijedan metod nije znao ko ce ga pozivati niti gde su metode koje ce pozivati iz drugih asemblija pa su svi pozivi bili realizovani od strane ngen-a preko malih "stub" metoda koju su sracunavale virtuelne adrese stvarnih metoda i obavljale virtuelni poziv, sto ce reci svaki poziv metoda je imao dodatni trosak CPU vremena pri svakom mogucem pozivanju propertija i metoda. Dakle nisi platio na mostu i preskocio si JIT, ali zato placas na cupriji tokom celokupnog zivota aplikacije. JIT iako malo jednokratno uspori ucitavanje asemblija, u trenutku kad se aktivira zna sve virtuelne adrese i ne generise te stub-ove.

.NET2 ngen je dodao mogucnost za hardbinding gde se pozivi realizuju direktno virtuelnim pozivima, ali je problem sto da bi to funkcionisalo CLR mora da ucita SVE asemblije odjednom, tako da kad ti aplikacija koristi dosta asemblija koji se ne ucitavaju odmah na pocetku vec po potrebi kasnije (asembli se nece ucitati dok se ne referencira neki tip iz njega), zapravo gubis i taj mali dobitak na vremenu koji ti preskakanje JITa daje jer program nece poceti dok se svi asembliji ne ucitaju, sto ume da potraje dosta duze nego startup JITovanje par pocetnih asemblija.

Moj predlog, osim ako ti asembli ne ide u GAC, nemas potrebe da ga ngen-ujes.

Odgovor na temu

nikomak
Nikola Makić
Beograd

Član broj: 177053
Poruke: 65
*.eunet.yu.

+1 Profil

Re: native image generator (ngen) problem ?!

^{05.04.2008. u 16:59 - pre 207 meseci}

Hmmm, ne znam, ali sudeci po svemu sto sam procitao o ngen-u mi se cini da aplikacija ima kraci "cold-start" (nema jit-anja), a i manji memory footprint (ngen image moze da se "memorijski deli", za razliku od jit-anog msil-a).
Opet, sve je to diskutabilno i zavisi od use case-a i zato bih zeleo da detaljno istestiram performanse (ali prokletinja jednostavno ne radi na mojoj masini :)

Sto se tice hardbinding-a, on me ne brine posto broj mojih lazy/delay loaded assembly-a koje koristim nije veliki; vise me brine rebasing image-a (pri update-ovanju, patch-ovanju itd.) i potreba za "pazljivim odredjivanjem" base address-a da se working set size ne poveca, kao i naravno citav throughoutput ngen-ovane aplikacije.

Sve u svemu, preinstaliracu sistem pa cu probati.

Ah, da, umalo da zaboravim ovde http://msdn2.microsoft.com/en-us/magazine/cc163610.aspx se nalazi sjajno i detaljno objasnjenje "svih aspekata ovde pominjanih" :)

To NGEN or not to NGEN, that is the question ... :P

:bye:

TurboDispatchJumpAddressEnd
----
Knocka Fia
----
And so we meet, again in a different time

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: native image generator (ngen) problem ?!

^{07.04.2008. u 08:35 - pre 207 meseci}

rebasing moze da se desi SAMO ako koristis NGEN. JIT vec zna gde ce smestiti modul i dinamicki odredjuje base adresu za native asembli i samim tim vec ima minimalni working set ako DLL nije deljen izmedju vise aplikacija

A ako asembli hoces da sharujes izmedju vise aplikacija, onda mu je mesto u GACu i onda treba da bude NGENovan, ali ces i onda tesko da nadjes "sigurnu" base adresu koja se nece poklati sa nekim drugim GAC asemblijem ili native DLLom koji u pozadini koristi neki unsafe asembli a za koji ti ni ne znas. Ako assembli nije deljen onda jednostavno nemas nikakve direktne koristi, iako ce on uci u shared DLL prostor i nece biti deo tvog private working set-a on ce i dalje biti ucitan negde u memeoriju i bice deo necijeg private working set-a.

Stvarno, mislim da zestoko gubis vreme sa ovim. Taj tekst je ok i sve sto pise tamo vazi, bar u teoriji, i mogu da razumem da se takvim stvarima pokloni paznja u huge enterprise projektima gde imas gomilu asemblija od po stotinjak megabajta i slicno, ali za realnu upotrebu .NETa jednostavno je bezveze gubiti vreme sa tim. Uostalom taj tekst vise sluzi toj autorki da pokaze kako i oni tamo u tom timu rade nesto korisno

Kao sto si ovo uradio sa JIT CPU vremenom, izvuci i velicine private working set-a za aplikaciju sa i bez ngen-a pa vidi koliko si desetina kilobajta ustedeo

Pa to uporedi sa kompletnim setom, to bi trebalo da te uputi na uzaludnost tog posla.

Odgovor na temu