Du bist nicht angemeldet.

Werbeanzeige

1

20.08.2004, 14:41

performanceunterschied zw. C#/.NET & C/C++

hey,

ich hab mit c# & .net ein d3d programm das ein object mit ca. 3500 faces
rendert gebastelt und das bei ganzen 32 fps. das is arm...bei ner normalen c/c++
anwendung wären sicher deutlichst mehr.
kann der geschwindigkeitsunterscheid wirklich nur von .net her
stammen? ich hab das modell nämlich nicht mit nem c-prog getesetet,
also weis ich nicht wie schnell es da laufen würde, daher könnte es
theoretisch auch an was anderem leigen.
aber hat vielleicht schon mal der ein oder andere
d3d mit c#.net gecoded?

sers 23h

2

20.08.2004, 14:59

Hab bis jetzt noch keine .NET D3D Prog programmiert. Aber ich denke der Performanceunterschied wird nicht so gravierend ausfallen. Ich glaub die 32FPS liegen woanders dran, z.B. wieviel Fläche das Objekt auf dem Bildschirm belegt.


Ich denke der größte Unterschied liegt an der Sprache, sondern am Compiler der die Sprach in CPU-Sprache übersetzt. Z.B. soll der Intel-Compiler sehr viel schnelleren Code erzeugen als der von VisualC++. Konnte es allerdings net testen da die Installation des Intel-Compilers meine VC++ Installation gefrackt hat.
Wichtig! Ich übernehme keinerlei Verantwortung für eventl. Datenverlust oder Schäden am Rechner ;D

Nox

Supermoderator

Beiträge: 5 282

Beruf: Student

  • Private Nachricht senden

3

20.08.2004, 16:25

Also ich proge c++ udn mein kumpel c#. Wir haben uns lange gestritten, wir haben lange diskutiert, wir haben viele testberichte gewälzt und wir haben rumgetestet und haben rausgefunden, dass die beiden in oop kaum unterschiede haben und c++ nur einen knappen vorsprung bei linearen programmen hat. C# hat den "Vorteil" das es plattformunabhängig ist und das es 100% auf jeden system funktioniert was das framework drauf hat. Die alternative ist C7 dieses ist nicht die c# an das .net gebunden. Also alles in allem ist es recht egal was man benutzt, solange man es richtig nutzt.

4

20.08.2004, 17:21

hm okay dann muss es an was anderem liegen.
aber is schon echt selstam wenig......
naja ich portier das c#-teil grad nach c++ mal schaun wies da läuft.

aber NOX: so ganz plattform unabhängig ist .net aber nicht oder?
immerhin spuckt der compiler doch windows-code aus. also ich denk nicht
dass das selbe binary das ich unter windows compiliere auch unter linux mit
mono läuft.....

Jumping Jack

Treue Seele

Beiträge: 142

Wohnort: Hamburg

Beruf: Schüler

  • Private Nachricht senden

5

20.08.2004, 17:52

Zitat


immerhin spuckt der compiler doch windows-code aus.


AFAIK spuckt der compiler nen Java ähnlichen bytecode aus der eben portabel ist.

6

20.08.2004, 17:52

hm...also ich habs jetzt nach c++ portiert und da hab ich ~270 fps
bei exakt dem gleichem auf dem bildschirm.....
seltsam. ich dachte erst ich hätte vielleicht nen fehler beim
fps-berrechnen gemacht aber wenn ich gar nix rendere hab ich
bei beiden versionen die gl. framerate......

kann das irgendwie am treiber liegen? ich hab dieses beta 4.9 ati-doom3
-treiber installiert könnte es damit zu tun haben ne odeR?

hm also selstam wenn ihr sagt ihr hab keinen unterschied gemerkt.....

7

20.08.2004, 17:55

@jumping jack:
aso.... ich dachte nur weil das file auch mit nem mz-header-dos-stub anfängt und dann ein PE-Header kommt
MZ   ÿÿ ¸ @ € º ´ Í!¸LÍ!This program cannot be run in DOS mode.

$ PE L þ&A à   @ p n] ` @    à         ] S ` Y À   H .text t= @  `.rsrc Y ` ` P @ @.reloc À  ° @ B

Jumping Jack

Treue Seele

Beiträge: 142

Wohnort: Hamburg

Beruf: Schüler

  • Private Nachricht senden

8

20.08.2004, 18:07

hm, ja, ich bin mir atm garnicht sicher ob der MSIL bytecode wirklich portabel ist. Man kann ihn denke ich aber portable machen. Wie weit portabel der code gemacht werden kann weiß ich allerdings nicht. Jedenfalls laufen "einfache" C# programme (durch mono und DotGNU) auch unter Linux. Naja, wie weit das noch portabler geht wird man ja noch sehen.

9

20.08.2004, 18:27

nur so ne idee aber beim .net liegen die managed objecte
was bei c# ja alle classes umfasst nicht im adressraum des programms sondern im framework....bilde mir zumindest ein mal sowas gelesen zu haben.
naja und da ich DrawUserPrimitives benutze könnte der bottleneck vielleicht
beim übertragen der daten zur karte liegen, eben bedingt durch
den adressraumwechsel??????

nur ne theorie :)

Klaus

Treue Seele

Beiträge: 245

Wohnort: Stuttgart

Beruf: Schüler

  • Private Nachricht senden

10

20.08.2004, 19:07

Zitat von »"Jumping Jack"«

hm, ja, ich bin mir atm garnicht sicher ob der MSIL bytecode wirklich portabel ist. Man kann ihn denke ich aber portable machen. Wie weit portabel der code gemacht werden kann weiß ich allerdings nicht. Jedenfalls laufen "einfache" C# programme (durch mono und DotGNU) auch unter Linux. Naja, wie weit das noch portabler geht wird man ja noch sehen.


Der Code an sich ist nicht das Problem. Die Frage ist nur, was nun schon alles in der Runtime Umgebung implementiert ist. Auf er Homepage des Mono-Projekts kann man genau nachschauen, welche Namespaces und Klassen bereits fertig sind, welche bekannten Bugs es noch gibt usw.
Vom Code her lässt sich aber eigentlich jedes Programm auf mono portieren.

Mich würde gerade mal interessieren, obs schon irgendwie ne OGL-Implementation mit dem Interface der Microsoft.DirectX.dlls gibt. Dann könnte ich meine C#-Engine auch mal auf Linux laufen lassen ;)
Das wär klasse - man müsste sich um nichts mehr kümmern und könnte 3D-Apps für jedes Framworktaugliche Betriebssystem schreiben *grins*

@FPS-Rate:
Ich hab mein Partikelsystem + Spriteengine zuerst dynamisch aufgebaut, um keine Höchstanzahl an Partikeln/Sprites zu haben. Dazu hab ich eben System.ArrayList benutzt, in FrameMove und Render Listeneinträge geaddet und nach dem rendern die Liste wieder gecleared. Doch dieses ganze Dynamische Zeugs für Hunderte und Tausende von Partikeln ist einfach viel zu zeitaufwändig.
Fazit: Es kommt sehr darauf an, was man codet. Das Framwork bietet so herrliche Möglichkeiten (ja, ich liebe es! Das ist ein richtiges Wunderland ;)), doch *nicht alles* ist schnell genug für realtime 3D graphics.

bye
Klaus
Mozilla Firefox
The Browser - reloaded

Werbeanzeige