Autor Wątek: C# - performance  (Przeczytany 8629 razy)

Offline Steel_Eagle

  • Użytkownik

# Styczeń 30, 2007, 00:12:25
Czy istnieje jakis zrodlo zawierajace opis wykonania C# "pod maska" z naciskiem na koszty operacji? Interesuje mnie co dokladnie krok po kroku robia rozne twory tego jezyka ze wzgledu na czas wykonania.

Z tego co mi wiadomo kod C# przetworzony do MSIL jest kompilowany podczas wykonania... Jak dzieje sie to dokladnie? Czy jest jakis sposob, zeby przekompilowac caly program przy starcie? CLR orientuje sie ktory kod jest przekompilowany i tego uzywa, ale ile taki kod jest przetrzymywany na maszynie? Do zakonczenia aplikacji, do restartu kompa(xD), czy moze jakos innaczej ?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline khak

  • Użytkownik

# Styczeń 30, 2007, 00:52:00
Hmmm...

Nick Wienholt - "Maximizing .NET Performance"
Deborah Kurata - "Best Kept Secrets in .NET"
John Mueller, John Paul Mueller - ".NET Framework Solutions: In Search of the Lost Win32 API"

A jeśli interesują Cię prawdziwe "bebechy", to są dwie hardkorowe pozycje:

Kevin Burton - ".NET Common Language Runtime UNLEASHED"
Serge Lidin - "Inside Microsoft .NET IL Assembler"

P.S.: Nic nie wiem o polskich wydaniach...

Offline MoN

  • Użytkownik

# Styczeń 30, 2007, 10:23:30
Afaik kod msilowy moze byc tez interpretowany, ale to szczegol. Tak czy siak, jak jest kompilowany to caly. Microsoft za to twierdzi, ze kod ten jest bardzo szybki, poniewaz zastosowywane sa dodatkowo optymalizacje pod konkretny komputer.

Offline Steel_Eagle

  • Użytkownik

# Styczeń 30, 2007, 12:49:07
Cytuj
Tak czy siak, jak jest kompilowany to caly. Microsoft za to twierdzi, ze kod ten jest bardzo szybki, poniewaz zastosowywane sa dodatkowo optymalizacje pod konkretny komputer.
No wlasnie chyba nie bardzo caly...

Cytuj
JIT is the process of compiling MSIL code units just when needed at runtime. The JIT compiler in the Common Language Runtime (CLR) compiles MSIL instructions to native machine code as a .NET application is being executed. Compilation occurs when a method is called and is not compiled more than once during program execution; because, JIT-compiled code is cached in memory.
Troche lipa, ale w sumie kompilacja bajtkodu jest duzo szybsza niz ta zwykla i chyba nie powinna stwarzac duzych problemow... W kazdym badz razie dogrzebalem sie do narzedzia ngen.exe ktore potrafi przekompilowac bajtkod do natywnego. Caly myk polega na tym, ze zeby zachowac plusy JITa (kompilacja pod architekture konkretnego komputera) trzeba ngena odpalic najlepiej zaraz po instalacji gry :)

@khak: thx poczytam ;p Dlaczego w IT do wszystkiego sa ksiazki srednio 500 stronicowe?!

Offline khak

  • Użytkownik

# Styczeń 30, 2007, 15:11:34
Cytuj
@khak: thx poczytam ;p Dlaczego w IT do wszystkiego sa ksiazki srednio 500 stronicowe?!

Bo każdy musi sieknąć wprowadzenie do tematu... :]

Offline vashpan

  • Użytkownik
    • Strona

# Styczeń 30, 2007, 15:23:09
Nie znajac w pelni tematu zastanawiam sie dlaczego programy .netowskie nie sa kompilowane do kodu natywnego podczas instalacji ? Po prostu pytam sie tych co maja wiecej wspolnego z ta technologia...


Offline revo

  • Użytkownik

# Styczeń 30, 2007, 15:50:03
Nie znajac w pelni tematu zastanawiam sie dlaczego programy .netowskie nie sa kompilowane do kodu natywnego podczas instalacji ? Po prostu pytam sie tych co maja wiecej wspolnego z ta technologia...

Pewnie dlatego, żeby były bardziej przenośne i  kompilacja zajmuje czas. Pozatym, jeśli chodzi o aplikacje biurowe to wszystko działa szybko i sprawnie bez kompilowania na początku do wersji natywnej ;)

Biblioteki .net'a są kompilowane w jednej z faz instalacji pod daną maszynę, żeby wszystko ładnie działało, a często w małych aplikacjach i aplikacjach biurowych odwołuje się do nich, a nie do własnego kodu - czas wykonania kodu, który piszemy jest pewnie rzędu kilku % w zwykłych aplikacjach, a jeśli mamy jakieś bardziej wymagające metody to i tak zostaną przecież skompilowane JIT.

Tak czy siak wydaje się to niepotrzebne, chyba, że nasza aplikacja ma w założeniach zjadać 90% mocy procesora ;)

Offline Steel_Eagle

  • Użytkownik

# Styczeń 31, 2007, 11:47:52
Cytuj
Nie znajac w pelni tematu zastanawiam sie dlaczego programy .netowskie nie sa kompilowane do kodu natywnego podczas instalacji ? Po prostu pytam sie tych co maja wiecej wspolnego z ta technologia...

Wlasnie do tego sluzy ngen.exe  :) I czesto komercyjne produkty sa w ten sposob kompilowane

Offline Xion

  • Moderator
    • xion.log

# Styczeń 31, 2007, 11:51:41
Nie znajac w pelni tematu zastanawiam sie dlaczego programy .netowskie nie sa kompilowane do kodu natywnego podczas instalacji ? Po prostu pytam sie tych co maja wiecej wspolnego z ta technologia...
Może też dlatego, że przecież nie każdy program jest rozprowadzany wraz z programem instalacyjnym, podczas którego kompilacja mogłaby być przeprowadzana. A trudno żeby samo uruchomienie .netowskiego EXEka miało zostawiać nam w systemie jakieś śmieci w postaci wersji skompilowanej, która to byłaby faktycznie odpalana przy kolejnych uruchomieniach.

Offline vashpan

  • Użytkownik
    • Strona

# Styczeń 31, 2007, 13:22:43
Przenonosc .NET'a to i tak raczej marketing niz praktyka. Microsoft nie zrobil praktycznie nic by jego kod naprawde byl przenosny pomiedzy czyms wiecej niz windowsami. Bo Mono to wytwor nie Microsoftu a Novella. Swoja droga dziwie sie dlaczego MS sam nie stworzyl wersji swojej platformy na innych popularnych systemach.

Slyszalem tez ze pracuja nad czyms co nazywa sie "Bartok" - prawdziwy kompilator dla C# (?) Nie wiem dokladnie ale chyba na cos takiego to wyglada.

Zreszta teraz rzeczywiscie sie zastanawiam czy kompilacja malych programikow ma sens, bo chyba cala biblioteka .NET jest w MSIL'u ? Wiec sam skompilowany programik niewiele tu pomoze pod wzgledem wydajnosci, bo wiekszosc rzeczy i tak jest robiona za pomoca samej biblioteki. ( jak napisal revo ) Ale wiekszych... czemu nie ? Po pierwsze kompilacja nie trwalaby dlugo, bo MSIL to raczej niskopoziomowy jezyk i jezeli mozna go kompilowac JIT to tym bardziej "na raz". Owszem aplikacje dzialaja w miare szybko ale czemu mialyby nie dzialac jeszcze szybciej malym kosztem ?

No ale ja tu sobie marudze a MS raczej wiedzial co robic :)
I na koniec gluipe pytanie: Czy program ktory napisze i skompiluje sobie w Visual C#, ta sama binarke, uruchomie na Linuksie z Mono ? Czy trzeba "cos" z tym robic dodatkowo ?

Offline revo

  • Użytkownik

# Styczeń 31, 2007, 19:32:21
I na koniec gluipe pytanie: Czy program ktory napisze i skompiluje sobie w Visual C#, ta sama binarke, uruchomie na Linuksie z Mono ? Czy trzeba "cos" z tym robic dodatkowo ?

Uruchomisz, o ile wszystko czego używasz jest dobrze zaimplementowane w mono ;P Kiedyś uruchamiałem swoje aplikacje napisane na zajęcia na uczelni i te w trybie tekstowym działały bez większych problemów, natomiast z wykorzystującymi Windows Forms były już problemy.

Poza tym, .net'owi przyświeca inna idea niż javie (do której to przenośności jest porównywany) - w javie jest jeden język, wiele platform, natomiast w .net jest jedna platforma a wiele języków ;P

Offline Steel_Eagle

  • Użytkownik

# Styczeń 31, 2007, 23:47:06
MS raczej nie bedzie zalezalo, zeby byly dobre implementacje CLI na inne systemy niz windows :p

Cytuj
Zreszta teraz rzeczywiscie sie zastanawiam czy kompilacja malych programikow ma sens, bo chyba cala biblioteka .NET jest w MSIL'u ? Wiec sam skompilowany programik niewiele tu pomoze pod wzgledem wydajnosci, bo wiekszosc rzeczy i tak jest robiona za pomoca samej biblioteki. ( jak napisal revo ) Ale wiekszych... czemu nie ? Po pierwsze kompilacja nie trwalaby dlugo, bo MSIL to raczej niskopoziomowy jezyk i jezeli mozna go kompilowac JIT to tym bardziej "na raz". Owszem aplikacje dzialaja w miare szybko ale czemu mialyby nie dzialac jeszcze szybciej malym kosztem ?
No wlasnie z tego co sam rozumiem to przy instalacji .net framework, czy visual c# wszystkie assembly sa kompilowane za pomoca ngen.exe, ktory tworzy czysta binarke i nic nie stoi na przeszkodzie, zeby to samo robic ze swoimi programami. No ja tak mysle  :P

Offline vashpan

  • Użytkownik
    • Strona

# Luty 01, 2007, 15:34:44
A jak jest z wydajnoscia tego co przetworzy ngen ?

Jezeli ms nie zalezy na dizalaniu .netu na innych platformach niz windows, to po kiego w ogole tworzyl MSIL ? Windowsy dzialaja w 99% na procesorach x86.. Wiec... Nie widze sensu .NET w takim razie. Dobrze ze istnieje mono. Ktore zreszta jak mowicie tez nie jest idealne...

Offline revo

  • Użytkownik

# Luty 01, 2007, 17:23:41
Jezeli ms nie zalezy na dizalaniu .netu na innych platformach niz windows, to po kiego w ogole tworzyl MSIL ? Windowsy dzialaja w 99% na procesorach x86.. Wiec... Nie widze sensu .NET w takim razie. Dobrze ze istnieje mono. Ktore zreszta jak mowicie tez nie jest idealne...

Procesory mogą być 32, 64 bitowe, jedno lub kilko rdzeniowe - pozatym komputer może mieć więcej niż jeden procesor - takie rzeczy są (a przynajmniej powinny) być używane, żeby stworzyć jak najbardziej wydajny kod wynikowy. Co do MSIL'a jeszcze - tak jak mówiłem - jedna platforma wiele języków - kod pośredni znacznie ułatwia współpracę między modułami napisanymi w różnych językach.

Offline Steel_Eagle

  • Użytkownik

# Luty 01, 2007, 17:29:49
Jezeli ms nie zalezy na dizalaniu .netu na innych platformach niz windows, to po kiego w ogole tworzyl MSIL ? Windowsy dzialaja w 99% na procesorach x86.. Wiec... Nie widze sensu .NET w takim razie. Dobrze ze istnieje mono. Ktore zreszta jak mowicie tez nie jest idealne...
To sie nazywa marketing ^^ Dobra platforma programistyczna -> wiecej aplikacji -> wiecej uzytkownikow -> tylko na windowsa -> wiecej kasy w MS :) A ta przenosnosc to jak narazie tylko teoretyczna, zeby zbyc wszystkich narzekajacych na jej brak  :P

Z tego co MS pisze to jakos powinna byc taka jak jitowanego kodu, ale bede googlowal jeszcze...