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

@crayze: 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)

@crayze: 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...

0

COM można używać w C. Widziałem nawet kod w assemblerze, który używał DX.
Jak ktoś chce zobaczyć jak wygląda użycie COM z poziomu C to może sobie przejrzeć kod GLQuake'a - tam używają akurat Dx input.

0
LV napisał(a)
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?

tu Ci moge objasnic, bo mialem juz okazje naprostowywac glowy napakowane zlymi wyjasnieniami C#/.Net'a.. delikwentowi chodzilo o ... meta-opisy ///<summary>, <remarks> ...

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

ja to czytajac tamto nawet nie mialem sily odpisywac ze smiechu:} moje uznanie za rozlegla i celna odpowiedz

0

http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp.html
http://shootout.alioth.debian.org/

najnowsza java jest 2 - 3 razy wolniejsza od c++ (pod linuxem).

znalazlem tez inny:
http://reverseblade.blogspot.com/2009/02/c-versus-c-versus-java-performance.html
w ktorym c++ juz nie jest tak duzo szybsze od c++ - zapewne tutaj tez faworyzuja jave i podobne - czesto w benchmarkach kod javowy jest duzo lepiej napisany niz ten w c++.
chodzi w tym jednak o jedna rzecz - java chodzi duzo szybciej w porownaniu do .net pod linuxem, proporcje wydajnosci sie mocno zmieniaja przy testach na windows i linux.

tak czy siak jezeli piszemy na jedna platforme np do grania playstation2, albo sterowniki i chcemy wykrzesac jak najwiecej to jezyki managed odpadaja.

mimo wszystko jestem za managed code ;) oczywiscie o ile jest co najwyzej 2 - 3 razy wolniejszy od kodu w c++/ unmanaged.

0

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

Hehe, jak gadasz tylko z ludźmi którzy pisali JVM to musisz być naprawde samotny [roNfl]
Szkoda, że samych postów nie można przenosić do perełek bo ten by się naprawde nadawł.

A jeżeli chodzi, o Haskella, że niby szybszy od C++ to ja radzę zagrać sobie w klona jakiejś gierki dosowej (bodajże Dooma, ale nie chce mi się teraz sprawdzać) pisanego w Haskellu.. Na Dual Corze, 2G RAM gierka z grafiką sprzed 15 lat muli, że aż miło :D
A benchmarki pokazujące, że Haskell jest szybszy od C++ to często wykorzystują leniwą ewaluację podczas gdy pisany na potrzeby testów kod C++ nie wykorzystuje. Po prostu niezła manipulacja, równie dobrze można zmienić algorytm i twiedzić, ża jakiś język jest szybszy od innego.

0

Rnd, nie zachowuj się jak tamten osobnik. Post do perełek, dobre - widać nawet go nie zrozumiałeś. Nie powiedziałem, że mam coś wspólnego z JVM, raczej z eksperymentalnymi zabawkami zaopatrzonymi w faktycznie ciekawe rozwiązania. Dlaczego jak wspomnieć o VM to wszyscy tylko o JVM myślą, innych nie ma? Właśnie, a co z podniesieniem wydajności C++ poprzez użycie LLVM? Hm?

Do Twojej wiadomości - na codzień zajmuję się programowaniem niskopoziomowym, gdzie C++ to wyżyny abstrakcji.

Co do Haskella to chyba napisałem, że w konkretnych zastosowaniach? Tak się składa, że te szybsze implementacje, które widziałem używały strict evala, leniwa nie wszędzie ma sens. Wiesz, GHC udostępnia mutowalne tablice - można identyczne algo napisać w Haskellu i w C++. Przepraszam bardzo, ale co ma leniwa ewaluacja do algorytmu? To tylko kwestia implementacji, algo pozostaje to samo.

Haskell i gry to generalnie pomyłka. Chociaż dać się da, ale to sztuka dla sztuki.

Na koniec - pisałem, że porównywanie wydajności języków to pomyłka, można porównywać co najwyżej narzędzia.

Jeszcze jedno - Singularity i Midori. ...i trochę pokory, 'widziałeś gierkę', tak samo niewydajne są niektóre twory w C++.

0

Panowie, OT robicie. Tu jest o DX pod C i najmniejszych binarkach, a wy się w świętą wojnę bawicie.

0

Hehe, jak gadasz tylko z ludźmi którzy pisali JVM to musisz być naprawde samotny [roNfl]
Szkoda, że samych postów nie można przenosić do perełek bo ten by się naprawde nadawł.

rnd, nie dość że offtopic kompletny już jedzie, to jeszcze personalne wjazdy zaczynasz.
Na razie umownego warna masz.

O krytyce haskella sobie wątek załóż - nie tylko nie ten topic, ale i dział pomylony.

Jak ktoś chce o VM Javy pogadać - też inny dział. Zwłaszcza że z .NET jest to luźno powiązane.

A z DirectX to już kompletnie.

Nie denerwować mnie, bo zaraz 75% wątku do śmieci za offtopic i pyskowanie poleci.

LV, do roboty zapieprzaj, nie marnuj [CIACH!] żydzie czasu na forum ;]

0

kod w asemblerze do obslugi com i dx jest dostepny na przyklad w paczce flatassemblera pod windows:
http://flatassembler.net/download.php
flat assembler xxxxx for windows
rozpakowac
examples/usecom - uzycie com
examples/ddraw - uzycie directx
include/macro/com32.inc - makra do interfejsow

mozna rozczajac ;)

lv podaj link do tego raytracera jestem ciekawy szczegolow sprawy ;)

0
nieznany napisał(a)

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++ ?

DXSDK od wersji 8 nie zawiera w nagłówkach wsparcia dla C. W 7 jeszcze były define'y odpowiednio utworzone dla __cplusplus / c i w tym drugim wypadków makra tworzące vtable COM-a.
Wiec koledzy dobrze Ci podpowiadają, że można odpalić DX w C, musiałbyś tylko przerobić headery z C++ z nowych DX-ów analogicznie do tych dla C z DX7. A czy warto ? nie warto - nie ma co się wyrzekać pewnych korzyści płynących z C++ choćbyś nawet pisał kod C-like - np. bez klas czy wyjątków.

Co do COM, to obsługa tegoż w DX jest w zasadzie transparentna, nie ma żadnej konieczności zagłebiać się w jego funkcjonowanie - zwłaszcza, ze będziesz je tylko używał, a nie tworzył. jak byś się uparł, to nagłówki do DX-a możesz zrobić i dla C i dla assemblera(tutaj nawet znajdziesz na necie kilka).

Co do wielkości kodu, to włączona obsługa SEH w msvcpp dorzuca trochę kodu do exe-ka przy kompilowaniu C++ i linkowaniu statycznym. Natomiasy sam kod użytkownika powinien być generowany w identyczny sposób dla C i C++.

0

Mimo wszystko dodam pewien komentarz w ramach wyjasnienia:

W 2003 roku, Tom Miller, slynny wspoltworca DirectX Managed, obecnie rowniez XNA i autor ksiazek o tematyce DirectX Managed (chocby jednej z najbardziej kluczowych publikacji o tej tematyce: "Managed DirectX 9 Kick Start: Graphics and Game Programming") na swoim blogu opublikowal ponizej wskazany temat, w ktorym (po dokonanych przez siebie testach, kiedys znalazlem do nich linka, jak ktos z was na niego wpadnie, podajcie go, prosze) odpowiedzial, ze Managed DirectX nie moze byc szybszy od wersji COM, bo korzysta z tego samego API do sterownikow:

http://blogs.msdn.com/tmiller/archive/2003/12/23/57538.aspx

Do tego czasu, inni tworcy bibliotek wykorzystywali zmienione API tylko po to, by programowalo sie latwiej. Po tej wypowiedzi Microsoft przystapil do zmiany niskopoziomowego API do komunikacji ze sterownikami. Od strony programisty aplikacji .NET nic sie nie zmienilo, ale od strony osoby tworzacej sterowniki, pojawily sie opcje implementacji istniejacych wywolan w inny sposob, bardziej odpowiadajacy nowej architekturze.

Nie chodzi o to, czy aplikacja C# dziala szybciej/wolniej niz C/C++, ale o to, ze waskie gardla tworza czesto dwie rzeczy (pomijajac niezdarny kod, ktory programista mogl stworzyc): operacje wykonywane przez urzadzenie renderujace oraz same wywolania funkcji DirectX. Do likwidacji tych pierwszych daza producenci sprzetu. Zmiana architektury DirectX spowodowala, ze te drugie przestaly odgrywac tak znaczaca role.

Zatem w procesie: operacje aplikacji -> wywolanie do DX -> wywolanie do sterownika -> operacje urzadzenia -> powrot do sterownika -> powrot do DX -> powrot do aplikacji, czas krokow zwiazanych z DX i sterownikami ulegl skroceniu (bo pozbyto sie obciazenia bibliotek w stylu COM).

Nie mowie, ze kod C# lub C++ dziala szybciej. Mowie, ze kod, wywolujacy z C# do Managed DirectX jest realizowany szybciej niz C++ do COM DirectX; a im wiecej krotkich wywolan, tym efekt bardziej widoczny. Natomiast sam chetnie zobaczylbym powazne benchmarki czasu dzialania aplikacji, bedacego realna skladowa obu czynnikow.

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