Performance von Anwendung maximieren (inline assembler?)

Moin,

ich frage mich gerade wie es denn so um die Performance von C# bestellt ist, da es ja immer wieder etliche Personen gibt, die behaupten es wäre einfach keine echte Sprache weil es zu langsam ist.

Daher, was kann man denn alles aus seiner Anwendung herauskitzeln (an geschwindigkeit gegenüber nativem c++) und wo sind die grenzen?

Es ist ja möglich c++ code in eine c# anwendung zu integrieren (beispielsweise bei der Bildverarbeitung), ist das auch mit inline-assembler möglich oder irgendwie möglich zu machen?

C# selbst kann, soweit mir bekannt, kein Inline Assembler.

Aber da du ja schon P/Invoke ansprichst (Unmanaged Code in C# nutzen), verweise ich (mal wieder) auf eine meiner Lieblings-Anleitungen zu dem Thema:
CodeKicker: Using Unmanaged Code and assembler in C#

Hoffe, dass dir das ein wenig weiterhilft...

so far
Karill

Aber da du ja schon P/Invoke ansprichst (Unmanaged Code in C# nutzen),

Naja ich meinte eigentlich so unsafe codeblocks wo man eben auch pointer nutzen kann aber gut.

BtW: Kann ich mit Visual Studio eigentlich auch Nicht-.NET-Bezogene C++ programme schreiben?

Hallo Pria,

wie sollte Inline-Assembler mit C# funktionieren, wenn nach IL kompiliert wird.

Für den Rest gilt: miss einfach. Pauschal kann das nicht gesagt werden, denn es hängt von der Anwendung und speziell den Aufgaben ab.

so unsafe codeblocks wo man eben auch pointer nutzen kann

Geht mit unsafe 😉

Kann ich mit Visual Studio eigentlich auch Nicht-.NET-Bezogene C++ programme schreiben?

Klar, wenns installiert ist. Aber sowas kannst du ja leicht selbst rausfinden.

mfG Gü

Hallo Pria,

wie immer gilt: "premature optimization is the root of all evil". Solange du also keine konkreten Anhaltspunkte hast, dass das, was du vorhast, in C# zu langsam wäre, brauchst du keine Optimierungen und keinen inline assembler.

C# kann durch den JIT in bestimmten Szenarien sogar schneller sein als native Sprachen.

herbivore

Ich kann mich an einen Vortrag auf einer Konferenz erinnern. Ein Entwickler stellte dort sein Projekt für eine große Versicherungsgesellschaft vor, bei dem es um die Verarbeitung riesiger Datenmengen ging. Er erstellte seine Anwendungen in C#, obwohl viele seiner Kollegen lieber C++ bevorzugten und ihn kritisch beäugten.

Er hatte sich sehr intensiv mit dem Thema C#/IL und Performance beschäftigt und alles bis ins Detail nachgemessen. Sein Fazit: C# kann genauso schnell sein wie C++, richtig angewendet. Beim Numbercrunching spielen viele Dinge eine Rolle: Die Objektinitalisierungszeit, die (sehr hohen) Kosten für Fehlerbehandlung (try/catch), oder Finessen bei Berechnungen.

Wie schon gesagt: Pauschalaussagen sind da wenig hilfreich, Messungen schon.

Es sind meist eher die schlechten C++ Entwickler, die behaupten, C# sei zu langsam. Du kannst es getrost ignorieren. Als ich vor etlichen Jahren mit Delphi angefangen habe, haben auch alle gesagt, das ist keine richtige Sprache, weil der C++ Compiler besser optimiert und schnelleren Code erzeugt. Das interessiert keinen. Es kann viele Gründe geben, sich für die eine oder die andere Programmiersprache zu entscheiden und Performance ist nur einer davon, meist ein unwichtiger.

Zusätzlich zu "premature optimization is the root of all evil" möchte ich noch anfügen "The best optimizer is between your ears" 😉 Es geht nicht wirklich oft um Performance, und wenn, kann man durch clevere Algorithmen meist viel mehr rausholen, als du Micro-Optimierungen in Assembler. C# bietet dir andere Optimierungsmöglichkeiten als C++, so kannst du in C# recht einfach dynamisch Code generieren, um nur ein Beispiel zu nennen.

Unter "premature Optimization" vermeiden verstehe ich aber nicht, dass während der Entwicklung nicht auf Performance geachtet werden sollte, sondern vielmehr, dass das Optimieren sich auch auszahlen muss, was man ohne Messen oft nicht beurteilen kann. Und viele Optimierungen verschlechtern wiederum andere Code-Eigenschaften. Feature by Design ist so ein weiterer Slogan, was wieder zu der optimization zwischen den Ohren passen würde.

Wie gesagt, da ich im momment im Spielebereich mit beidem zu tun habe und unser Prof natürlich größe Stücke auf C++ hält, bin ich im Momment etwas nachdenklich. Mit der Performance von unserem Script (was nahezu wenn nicht sogar exakt an die geschwindigkeit von C# heran kommt) bin ich relativ zufrieden, was die OpenGL basierte Grafik angeht, bin ich mir nicht sicher. Klar, die 8000fps von javas slick sind schon beeindruckend und die 6000 von ATIs performancetest sind auch nicht zu verachten, obwohl ich natürlich weiß, dass es mit der Bildwiederholrate des Monitors absolut nicht zu machen ist, jedoch sind das erstmal beeindruckende zahlen. Da kann das OnPaint Ereignis von einem C# Form nicht mithalten, geschweigedenn mit dem renderloop in einer while(true) schleife, welcher öfter in c++ beispielen auftaucht. Unser Code ist noch kein Stück optimiert, jedoch sind uns bei Funktionen, die Daten über die Cpu an die Grafikkarte senden die Hände gebunden, da wir weder das direkt tun können, noch mal eben n par Register herumschieben können.

Wobei ich glaube, dass die Branche natürlich c++ und DirectX geprägt ist und sich das so schnell auch nicht ändern wird aber dem sei mal so dahin gestellt.

Ist eine Funktion mit unsafe eigentlich grundsätzlich schneller?

Hallo Pria,

Ist eine Funktion mit unsafe eigentlich grundsätzlich schneller?

nein, natürlich nicht. Womit wir den Thread wieder von vorne beginnen könnten. Sollte wir aber nicht.

Da kann das OnPaint Ereignis von einem C# Form nicht mithalten

Da kannst du dann aber auch mit Assembler nichts rausreißen. Auf die richtige Grafik-Technologie kommt es an. Siehe auch [FAQ] Wie finde ich den Einstieg in die 3D-Programmierung mit C#?.

Ich bin immer wieder über deine etwas naive Herangehensweise überrascht. Die andere Erklärung - wie schon in anderen deiner Threads vermutet - du bist ein Troll. Deshalb mach ich hier auch mal zu.

herbivore