Warsztat.GD

Programowanie => Językoznawstwo => C# => Wątek zaczęty przez: Steel_Eagle w Styczeń 30, 2007, 00:12:25

Tytuł: C# - performance
Wiadomość wysłana przez: Steel_Eagle w 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 ?
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: khak w 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...
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: MoN w 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.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: Steel_Eagle w 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 (http://msdn2.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx) 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?!
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: khak w 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... :]
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: vashpan w 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...

Tytuł: Odp: C# - performance
Wiadomość wysłana przez: revo w 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 ;)
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: Steel_Eagle w 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
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: Xion w 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.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: vashpan w 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 ?
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: revo w 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
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: Steel_Eagle w 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
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: vashpan w 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...
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: revo w 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.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: Steel_Eagle w 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...
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: vashpan w 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.... 

Tytuł: Odp: C# - performance
Wiadomość wysłana przez: Steel_Eagle w 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  ;)
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: vashpan w 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 ?
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: novo w 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.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: Steel_Eagle w 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++...
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: revo w 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
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: counterClockWise w 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.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: vashpan w 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 ?
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: revo w 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)
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: vashpan w 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 :)
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: blackstar w 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).
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: KriS w 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" (http://gamedeveloper.texterity.com/gamedeveloper/sample/) pisze o spadku 160fps->60fps po przedkompilowaniu pod .NET'a.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: blackstar w 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" (http://gamedeveloper.texterity.com/gamedeveloper/sample/) pisze o spadku 160fps->60fps po przedkompilowaniu pod .NET'a.

Heh w zasadzie masz racje.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: zarius w 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" (http://gamedeveloper.texterity.com/gamedeveloper/sample/) 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 ;)
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: novo w 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.
Tytuł: Odp: C# - performance
Wiadomość wysłana przez: bies w Luty 15, 2007, 02:28:23
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 ;)
C++ nie potrafi, ale C# też nie. Mieszasz pojęcia. To maszyna witualna (wbudowana w .NET) potrafi JIT-ować. A jakie są przeciwwskazania, żeby napisać VM-a z font-endem do C++ i JIT-em w środku. Ja nie wiem. Autorzy LLVM też nie wiedzą bo właśnie coś takiego zrobili. Więc może zanim będziesz znowu wygłaszał jakieś kategoryczne tezy doczytaj. Bo może ktoś zechcieć taki np. ,,ogrom zalet'' sprawdzić. A moim zdaniem, trzymasz co najwyżej parę dziesiątek. No i wreszcie ,,żądanie'' - oczy bolą.