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

Offline vashpan

  • Użytkownik
    • Strona

# Luty 01, 2007, 18:46:39
revo - no dobrze.. tylko ze kod kompilowany "na zywo" jest wolniejszy od tego natywnego, jakichkolwiek optymalizacji by nie stosowal przy jitowaniu.... 


Offline Mr. Spam

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

Offline Steel_Eagle

  • Użytkownik

# Luty 01, 2007, 19:01:45
revo - no dobrze.. tylko ze kod kompilowany "na zywo" jest wolniejszy od tego natywnego, jakichkolwiek optymalizacji by nie stosowal przy jitowaniu.... 
Dosc odwazna teza ;) Wlasnie plusem jitowania jest to ze kod jest komilowany pod konkretna architekture komputera, wiec moze byc szybszy niz kod wyprodukowany przez zwykle kompilatory. Tyle tylko ze samo jitowanie zabiera troche czasu przy pierwszym uruchomieniu.

Ze kod interpretowany jest wolniejszy to sie zgodze, ale nie o tym mowimy  ;)

Offline vashpan

  • Użytkownik
    • Strona

# Luty 01, 2007, 19:19:01
Hm.  Wiem co powiedzialem. Ale zaskoczyles mnie tym ze kod JIT' owany moze byc szybszy. Jak ? Jezeli dobrze rozumuje Just in Time, to kompilacja odbywa sie w locie..., czesto przed wykonaniem danej funkcji/klasy. A wiec musi sie ona tak czy inaczej odbyc. Ogolnie rzecz biorac, te wszystkie optymalizacje jedynie zblizaja, pod wzgledem wydajnosci program w jezyku posrednim do tego skompilowanego.

Chyba ze sie nie zrozumielismy... i piszesz ( ecie ) o samym kodzie juz po zJITowaniu, jakby na stale... Wowczas rzeczywiscie taki kod moze byc szybszy niz ten wczesniej skompilowany z mysla o wiekszym spektrum platform. Ja zas mowie o programie w ogole.

Wiec jak to z tym jest ?

Offline novo

  • Użytkownik
    • my devblog

# Luty 01, 2007, 20:32:46
Steel_Eagle, co innego teoretyczne zalozenia, a co innego swiat rzeczywisty :D Napisz cos w C#, to samo w c++ i sprawdz co szybciej dziala :P Nie mowie tu o czasie pisania, bo wiadomo ze na tym polu C# wygrywa i co do tego nie ma watpliwosci, ale dyskusja jest na temat czasu wykonania.
.NET, tak jak napisal revo, ma ta zalete, ze latwo laczy sie moduly pisane w kilku jezykach.

Pozdr.
novo.

Offline Steel_Eagle

  • Użytkownik

# Luty 01, 2007, 21:37:23
Cytuj
Chyba ze sie nie zrozumielismy... i piszesz ( ecie ) o samym kodzie juz po zJITowaniu, jakby na stale... Wowczas rzeczywiscie taki kod moze byc szybszy niz ten wczesniej skompilowany z mysla o wiekszym spektrum platform. Ja zas mowie o programie w ogole.
Wlasnie chodzi o to ze kazda metoda jest jitowana tylko raz i jej kod natywny jest przetrzymywany w pamieci komputera. Przy pierwszym wejsciu do tej metody powstanie narzut spowodowany kompilowaniem, ale przy kolejnych juz nie. Metoda jest jitowana z bitkodu, wiec proces takiej kompilacji jest duuuzo szybszy niz zwyklej. Dodatkowo mozna zupelnie zniwelowac ten narzut zachowujac wszystkie plusy jitowania, jezeli zjituje sie kod do natywnego na maszynie uzytkownika. Mozna to zrobic uzywajac ngen'a zaraz po instalacji gry, lub przed jej pierwszym uruchomieniem. No to chyba takie podsumowanie tematu  :)

@Novo:
[półżartem]No tak, ale gdyby c++ tez moglby byc jitowany w ten sposob to tez moglby byc szybszy  ;)[/półżartem]
Pozatym ze c++ jest szybszy kazdy wie, ale jezeli dobrze pokombinowac to C# bedzie zaledwie krok za nim, a zalet pisania w C# jest wiele  ;) Dla mnie .Net ma taki plus, ze jest to potezna biblioteka  :P W sumie szkoda, ze nia ma takiej do c++...

Offline revo

  • Użytkownik

# Luty 01, 2007, 22:07:47
Steel_Eagle, co innego teoretyczne zalozenia, a co innego swiat rzeczywisty :D Napisz cos w C#, to samo w c++ i sprawdz co szybciej dziala :P Nie mowie tu o czasie pisania, bo wiadomo ze na tym polu C# wygrywa i co do tego nie ma watpliwosci, ale dyskusja jest na temat czasu wykonania.
.NET, tak jak napisal revo, ma ta zalete, ze latwo laczy sie moduly pisane w kilku jezykach.

Pozdr.
novo.

Kiedyś na kursie "Programowanie pod Windows .net" na UWr, jednym z zadań było napisanie biblioteki do operacji na liczbach zespolonych, a następnie porównanie jej wydajności z implementacją tej która jest w STL - bardzo się zdziwiłem, gdy okazało się, że moja w C# jest szybsza, mimo, że napisana na odwal i bez żadnych optymalizacji ;P

Offline counterClockWise

  • Użytkownik

# Luty 05, 2007, 01:28:00
Tak czasem jest. Mój własny DrawLine - zaimplementowany w C# jako dwustronny algorytm Bresenhama (fakt, że zoptymalizowałem go jak tylko potrafiłem) odwołujący się bezpośrednio do pamięci w trybie "unsafe" działa wyraźnie szybciej niż Graphichs.DrawLine(...).
Nie mam już dokładnych wyników pomiarów wydajności ale był zdecydowanie szybszy.

Offline vashpan

  • Użytkownik
    • Strona

# Luty 05, 2007, 13:37:17
No zapewne wszystko dlatego, ze program kompiluje sie przed wykonaniem, wiec roznic miedzy C++ a C# juz wtedy nie widac. Tez to zreszta zauwazylem ,elcz pozniej doszedlem do wniosku ze program byl zbyt prosty by wykazac przewage C++ :) ale przy duzym projekcie, sama kompilacja moze juz troche zajmowac. No i uzycie pamieci przez .net jest znaczaco wieksze.

Jeszcze jedno techniczne pytanie: Czy podczas JIT'owania tych wszystkich klas etc, sa kompilowane takze wykorzystywane biblioteki .net ? ( Tj: czy kompilowane sa tylko raz i przechowywane w buforze, tak jak to ma miejsce z naszym kodem )

Czy ngenem mozna skompilowac sobie biblioteki .net ?

Offline revo

  • Użytkownik

# Luty 05, 2007, 13:41:23
Jeszcze jedno techniczne pytanie: Czy podczas JIT'owania tych wszystkich klas etc, sa kompilowane takze wykorzystywane biblioteki .net ? ( Tj: czy kompilowane sa tylko raz i przechowywane w buforze, tak jak to ma miejsce z naszym kodem )

Czy ngenem mozna skompilowac sobie biblioteki .net ?

Biblioteki frameworka są kompilowane podczas instalacji (co już zostało gdzieś tutaj wcześniej wspomniane)

Offline vashpan

  • Użytkownik
    • Strona

# Luty 06, 2007, 03:00:46
Nie zauwazylem... No i nie wiedzialem o tym....


To nie jest tak zle z tym C# w takim razie :)

Offline blackstar

  • Użytkownik

# Luty 06, 2007, 14:55:46
Glownym powodem, dla ktorego jezyki .NET sa kompilowane do MSIL nie jest przenosnosc, ale weryfikowalnosc kodu. Chodzi o to, zeby ulatwic pisanie narzedzi do analizy statycznej kodu, uniemozliwic powstawanie wyciekow pamieci, wiszacych wskaznikow, przekraczania zakresow tablic, wykraczania poza przestrzen adresowa procesu, itd..

W przypadku jezykow .NET kompilator moze dodatkowo zagwarantowac duzo wiecej nt. tego jak bedzie sie wykonywal dany kod. Najprostszy przyklad: *p=b; foo(a); Kompilator C++ zazwyczaj nie wie na co wskazuje wskaznik p wiec prawdopodobnie po takim przypisaniu bedzie musial wygenerowac kod, ktory wczyta z pamieci zmienna a, nawet jesli wartosc a jest juz w jednym z rejestrow procesora (bo nie wie czy p==&a  !). W .NET nie ma takigo problemu.

Kolejnym powodem, dla ktorego .NET (i ogolnie jezyki z automatycznym zarzadzaniem pamiecia) moze byc szybszy od C++ jest to, ze alokacja pamieci jest duzo szybsza i czesto (choc nie koniecznie w .NET) sprowadza sie do zwiekszenia wskazinka wskazujacego na pierwszy wolny bajt pamieci. W porownaniu do np wyszukania bloku o odpowiednim rozmiarze z calej sterty. Podobnie natychmiastowa dealokacja pamieci nie jest potrzebna i moze byc odlozona do czasu kiedy np program czeka na dostep do dysku. Sprobujcie napisac cos takiego w C++... [da sie, ale po co].

Cytuj
[półżartem]No tak, ale gdyby c++ tez moglby byc jitowany w ten sposob to tez moglby byc szybszy  Wink[/półżartem]
[100% serio]VS2005 (nie wiem czy starsze tez) traktuje C++ (z pewnymi modyfikacjami) jako pelnoprawny jezyk .NET. Nawet jesli nie chcesz korzystac z .NET, mozesz C++ skompilowac do MSIL praktycznie nie zmieniajac kodu.

BTW O ile dobrze pamietam(!) Quake skompilowany na platforme .NET dzialal szybciej (http://channel9.msdn.com/ShowPost.aspx?PostID=23493).

Offline KriS

  • Użytkownik
    • KriS

# Luty 06, 2007, 15:07:49
BTW O ile dobrze pamietam(!) Quake skompilowany na platforme .NET dzialal szybciej (http://channel9.msdn.com/ShowPost.aspx?PostID=23493).

Jaki sens ma porownywanie programow, w ktorych wiekszosc obciazenia przypada na karte graficzna, a nie procek?

Np tutaj: "Managed code in games" pisze o spadku 160fps->60fps po przedkompilowaniu pod .NET'a.
« Ostatnia zmiana: Luty 06, 2007, 15:09:24 wysłana przez KriS »

Offline blackstar

  • Użytkownik

# Luty 06, 2007, 15:31:52
Jaki sens ma porownywanie programow, w ktorych wiekszosc obciazenia przypada na karte graficzna, a nie procek?

Np tutaj: "Managed code in games" pisze o spadku 160fps->60fps po przedkompilowaniu pod .NET'a.

Heh w zasadzie masz racje.

Offline zarius

  • Użytkownik

# Luty 15, 2007, 01:36:00
BTW O ile dobrze pamietam(!) Quake skompilowany na platforme .NET dzialal szybciej (http://channel9.msdn.com/ShowPost.aspx?PostID=23493).

Jaki sens ma porownywanie programow, w ktorych wiekszosc obciazenia przypada na karte graficzna, a nie procek?

Np tutaj: "Managed code in games" pisze o spadku 160fps->60fps po przedkompilowaniu pod .NET'a.

Taki sens ze przy gamedev i tworzeniu gier wiekoszsc przypada na karte nie procek. Poza tym jesli kolegs pisze Quake to nie ma na mysli renderera ale gre.

No i na koniec: dupny koder nawet i w C++ bedzie pisal dupne programy jesli chodzi o wydajnosc, tak samo tutaj. Wszystko zalezy od znajomosci jezyka stylu programowania i doswiadczenia. C# wcale nie jest duzo wolniejszy a ma ogrom innych zalet.

A co do JIT to jest jeszcze jedna strona medalu, kompilowanie na rzadanie kodu zrodlowego ;]

C++ tego na pewno nie potrafi a jest to duza zaleta ;)

Offline novo

  • Użytkownik
    • my devblog

# Luty 15, 2007, 01:57:52
zarius: to moze przy pisaniu renderera wiekszosc przypada na karte a nie procek. Zeby nie byc goloslownym potestuj sobie HL2. Dosc dlugo siedzialem na scenie CS:Source i mialem stycznosc z wieloma osobami, jak wiadomo kazdy dazyl do tych magicznych 100 klatek :D. I w wypadku tej gry(CS:S) zmiana karty graficznej najczesciej dawala niewielkiego boosta, za to zmiana proca juz konkretnego kopa. Dla porownania w moim przypadku podkrecenie karty graficznej GF 5900XT z 390/700 na 450/780 dalo mi ok 5-7fps, podkrecenie procka(AMD Barton-M 2500+) z 1833 na 2300, dalo okolo 30fps.

Przy pisaniu gier trzeba wlasnie zbalansowac koszt wykonania na CPU/GPU tak zeby zadne z tych podzespolow nie czekalo na drugie(tracisz na wydajnosci). Takze porownywanie KriS ma racje, takie porownanie jest z deczka bez sensu.

Pozdr.
novo.