Directx pod C mozna?ktory kompilator tworzy najmniejszy kod?

0

Czy da się pisać w api dx pod zwykły C ? i który kompilator c++ tworzy najmniejszy kod ? Czy kompilator c tworzy szybszy kod od c++ ?

0
nieznany napisał(a)

Czy da się pisać w api dx pod zwykły C ?

A czy w C możesz używać klas?
dx to technologia obiektów COM, jeśli możesz ją obsługiwać możesz pisać pod dx

nieznany napisał(a)

i który kompilator c++ tworzy najmniejszy kod ?

ciężko powiedzieć, na pewno sporo zależy ustawień

nieznany napisał(a)

Czy kompilator c tworzy szybszy kod od c++ ?

bzdura, ok może co najwyżej mieć mniejszy runtime

0

@<b>crayze</b>: o ile pamiętam, interface'y COM są także zdefiniowane dla C, więc i pewnie DX jest, choć nie wiem czy dla najnowszych wersji.

0
0x666 napisał(a)

@<b>crayze</b>: o ile pamiętam, interface'y COM są także zdefiniowane dla C, więc i pewnie DX jest, choć nie wiem czy dla najnowszych wersji.

no, więc się da :>

0

z moich doświadczeń najszybszy kod tworzy Visual studio,
duzo zależy od ustawień i samego programisty, środowisko optymalizuje tylko część tego co można napisać lepiej.

Jeśli chodzi o C czy C++ to polecam C++.

0

Obecnie od modelu COM w DirectX odchodzi sie calkowicie na rzecz DirectX Managed czyli .NET, w ktorym, dzieki calkowitej zmianie architektury i komunikacji ze sterownikami, kod chodzi szybciej, szczegolnie przy duzej ilosci wywolan funkcji.

Wersja COM oczywiscie w pelni pozwala na pisanie w C++ (nie sadze by w C), ale zgodnie z zapowiedziami Microsoft, bedzie aktualizowana w drugiej kolejnosci, a w niedalekiej przyszlosci jej rozwoj zostanie zatrzymany - priorytetym jest DirectX Managed. Glownie przewodza tu wzgledy wsparcia dla urzadzen innych niz komputery osobiste (programowanie Windows Mobile czy XBox), ktore juz od jakiegos czasu wspieraja DirectX Managed (chocby w ramach Compact Framework); natomiast wersja COM jest gleboko zakorzeniona w architekturze desktopowych systemow Windows i obecnie nie jest przenosna.

DirectX SDK dostarcza obecnie obu zbiorow naglowkow jednoczesnie: i COM, i .NET. Ze wzgledow latwosci programowania, przejrzystosci kodu (sposob programowania DX w .NET jest calkowicie niezgodny z modelem COM!), ale i szybkosci, bez zastanawiania sie polecam uczyc sie DirectX Managed i zapomniec o modelu COM.

http://4programmers.net/DirectX

0

a jak to wygląda z przyrostem szybkości, konkretne liczby, jakieś testy?

0

Wtiam,

Kolega Szczawik chyba nie robił żadnych testów wydajnościowych odnośnie freamworka .NET. Jeśli ktoś jeszcze nie wie platforma .NET jest mozna tak powiedzieć "interpreterem kodu" tak jak wirtualna maszyna JAVA. Z tego względu kod wykonywany jest duzo wolniej.
Osobiście nie testowalem technologi DirectX, ale przeprowadzalem testy pisząc aplikacje w firmie i tak:
najszybszy jest oczywiście C++, po nim około 2 razy wolniejszy jest Menagned C, po nim C#.

Jeżeli ktoś nie wierzy to niech zainstaluje sobie tą samę grę na windowsie VISTA, z kartą graficzna wspierającą sprzętowo DirectX 10 oraz na kompie z windowsem XP na DirectX 9. Takie testy robiłem i:
-na Vista nie mogłęm ustawić maksymalnych parametrów, gra chodziła w miare dobrze na średnich ustawieniach

  • na XP dałem maksymalne ustawienia i chodziło bez najmniejszych problemów

Jeśli ktoś kiedyś pisał w C# lub w managned C i interesował się co jest wynikiem kompilacji, oraz dlaczego programy w tych dwóch jezykach są w pełni dekompilowalne(wraz z komentarzami) to potwierdzi moją wypowiedź.

Tak wiec C/C++ (ewentualnie asembler) jest jedynym słusznym językiem przy projektach wymagajacych dużej wydajności.
Pozdrawiam

0
g_all napisał(a)

Kolega Szczawik chyba nie robił żadnych testów wydajnościowych odnośnie freamworka .NET. Jeśli ktoś jeszcze nie wie platforma .NET jest mozna tak powiedzieć "interpreterem kodu" tak jak wirtualna maszyna JAVA. Z tego względu kod wykonywany jest duzo wolniej.
Osobiście nie testowalem technologi DirectX,

Skoro sam nie testowałeś, to czemu zarzucasz komuś, że tego nie robił? ;>

g_all napisał(a)

ale przeprowadzalem testy pisząc aplikacje w firmie i tak:
najszybszy jest oczywiście C++, po nim około 2 razy wolniejszy jest Menagned C, po nim C#.

A co konkretnie testowałeś?
I od razu nasuwa się drugie pytanie - dlaczego napisałeś taki beznadziejny kod w C#, że tak wyszło?

g_all napisał(a)

Jeżeli ktoś nie wierzy to niech zainstaluje sobie tą samę grę na windowsie VISTA, z kartą graficzna wspierającą sprzętowo DirectX 10 oraz na kompie z windowsem XP na DirectX 9. Takie testy robiłem i:
-na Vista nie mogłęm ustawić maksymalnych parametrów, gra chodziła w miare dobrze na średnich ustawieniach

  • na XP dałem maksymalne ustawienia i chodziło bez najmniejszych problemów

Moim zdaniem ten wątek jest akurat całkiem o czym innym :)

Ja raczej wierzę Szczawikowi, bo po pierwsze .NET jest jednym z flagowych produktów M$ i docelowo wszystko będzie z nim zapewne zgodne, a po drugie jak M$ integruje swoje produkty, to jest to pewno wydajniejsze, niż w przypadku integracji produktów firm trzecich.

g_all napisał(a)

Jeśli ktoś kiedyś pisał w C# lub w managned C i interesował się co jest wynikiem kompilacji, oraz dlaczego programy w tych dwóch jezykach są w pełni dekompilowalne(wraz z komentarzami) to potwierdzi moją wypowiedź.

Użyj obfuscatora.

g_all napisał(a)

Tak wiec C/C++ (ewentualnie asembler) jest jedynym słusznym językiem przy projektach wymagajacych dużej wydajności.

Ilu programistów na świecie jest w stanie napisać w ASM kod wydajniejszy od tego, który generują kompilatory C/C++?

0
g_all napisał(a)

Jeśli ktoś jeszcze nie wie platforma .NET jest mozna tak powiedzieć "interpreterem kodu" tak jak wirtualna maszyna JAVA. Z tego względu kod wykonywany jest duzo wolniej.

Jeżeli ktoś jeszcze nie wie co to JIT to nie powinien zabierać głosu w sprawie .NET - kod przed wykonaniem jest kompilowany do kodu natywnego, dokładnie takiego samego jak ten generowany statycznie podczas kompilacji kodu w C++. Różnica jest taka, że późna kompilacja i ew. profilowanie + przebudowa kodu pozwala pozbyć się narzutu wywoływania metod wirtualnych, sprawdzania zakresów itd. Jeżeli chodzi o 'interpretowanie' - tak, jest używane w JVM w trybie serwer - służy wstępnemu profilowaniu przed kompilacją do kodu maszynowego, dzięki czemu binarka jest jeszcze lepiej dostosowana do warunków środowiska wykonawczego, ma większą wydajność.

g_all napisał(a)

Osobiście nie testowalem technologi DirectX, ale przeprowadzalem testy pisząc aplikacje w firmie i tak:
najszybszy jest oczywiście C++, po nim około 2 razy wolniejszy jest Menagned C, po nim C#.

Kpisz czy o drogę pytasz? C++/CLI bo tak się prawidłowo to 'Managned C' nazywa ('managned', biedaku...) jeżeli nie tworzy się kodu mieszanego ma wydajność dokładnie identyczną z C#. Tak się składa, że ze 2-3 lata temu chłopaki bodaj na gamedev.net (nie pamiętam, nie chce mi się aktualnie szukać) robili testy wydajności - ten sam silnik zaimplementowany w C++, natywnie i w C#. Natywny DX - 55 fps, Managed - 50 fps. Jak wiesz, teraz mamy DX10, nowy .NET Framework, nadchodzi wersja 4.0 - wyniki kodu zarządzanego powinny być jeszcze lepsze.

g_all napisał(a)

Jeżeli ktoś nie wierzy to niech zainstaluje sobie tą samę grę na windowsie VISTA, z kartą graficzna wspierającą sprzętowo DirectX 10 oraz na kompie z windowsem XP na DirectX 9. Takie testy robiłem i:
-na Vista nie mogłęm ustawić maksymalnych parametrów, gra chodziła w miare dobrze na średnich ustawieniach

  • na XP dałem maksymalne ustawienia i chodziło bez najmniejszych problemów

A wiesz co to ma do rzeczy? Gra teoretycznie wymagająca DX10 po prostu olewa jego elementy jeżeli nie są dostępne - wykonywanie idzie szybciej bo jest mniej do roboty. Druga sprawa - Vista zjada znacznie więcej RAMu na urzymanie jądra i usług. Trzecia sprawa - DX10 to nie jest DX9 + dodatki. Ostatnia - inne sterowniki. Miałem zrobić aluzję do ekhm, liberalnych zachowań seksualnych ale się rozmyśliłem, jakość porównania byłaby taka sama.

g_all napisał(a)

Jeśli ktoś kiedyś pisał w C# lub w managned C i interesował się co jest wynikiem kompilacji, oraz dlaczego programy w tych dwóch jezykach są w pełni dekompilowalne(wraz z komentarzami) to potwierdzi moją wypowiedź.

Jakimi, k***a, komentarzami? Kod pośredni zawiera strukturę kodu źródłowego + nazwy symboli - z tego produkuje się i odpowiednio formatuje dekompilowany kod. Widziałeś kiedyś MSIL na oczy? Nie wiem co to ma do wydajności... Chyba, że mówimy o binarkach w trybie debug - wtedy programu w C++ nawet dekompilować nie trzeba - większość formatów debug info zawiera w sobie cały kod źródłowy modułów.

g_all napisał(a)

Tak wiec C/C++ (ewentualnie asembler) jest jedynym słusznym językiem przy projektach wymagajacych dużej wydajności.

A jedyną słuszną orientacją seksualną jest homoseksualizm, że posłużę się tutaj onetową argumentacją.
Wiesz, że C++ też może pracować na maszynie wirtualnej? Wiesz, że kod w C++ skompilowany z pomocą LLVM i odpalony pod jego VM w niektórych przypadkach jest nawet 10x wydajniejszy niż bezpośrednio skompilowany natywnie przy pomocy np. GCC? Znowu nie chce mi się iść po link do opisu ray-tracera, który takiego właśnie kopa na LLVM dostał. Inna sprawa, jest taki język jak D, też może pracować na LLVM, kompiluje się szybciej od C++ a trochę elementów języka faktycznie uprzyjemnia pisanie. D nadaje się równie dobrze co C++.

Za argument o assemblerze powinieneś do perełek trafić. Tak się składa, że aktualnie Haskell (tak, język czysto funkcyjny) kompilowany nowszymi wersjami GHC z paroma rozszerzeniami potrafi być nawet 2x szybszy od C++ w części zastosowań. Dlaczego? Im wyższa abstrakcja tym większe możliwości analizy i optymalizacji ma kompilator. Docelowo GHC 6.10.2 ma wspierać backend LLVM - wtedy dopiero będzie zabawa. W praktyce nie może być mowy o wydajności języka, co najwyżej o jakości narzędzi - dla C++ teoretycznie też da się zrobić analizator 'rozumiejący' zamysł programisty i odpowiednio go rozwijający, chciałbym coś takiego zobaczyć.

Podsumowując - szanowny pan g_all skończył się na kill'em all... ekhm, znaczy się na interpreterze PHP. O maszynach wirtualnych, dynamicznej kompilacji, zarządzaniu pamięcią... czy nazwach technologii(!) najmniejszego pojęcia nie ma. Wątpię też aby faktycznie pisał w C++, C# i asm i miał w nich wystarczające doświadczenie aby być w stanie je porównywać.

Dziękuję za uwagę, po prostu nie lubię jak ktoś pie***y jak potrzaskany. Popracujesz kolego przy implementacji VM, GC i JIT to pogadamy...

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0