C# und zeitkritische Anwendungen (keine Grundsatzdiskussion)

Kramny

Hallo zusammen,

ich habe ein paar ganz spezielle Fragen zum Thema C#-Programmierung, und wurde auch nicht recht fündig mittels der Suchfunktion. Ich stehe gerade am Anfang meiner Diplomarbeit (als Nachrichtentechniker), und erwarte natürlich keineswegs, dass Ihr für mich die Arbeit macht. Viel mehr geht es mir darum, dass ich nicht schon von Anfang an in eine komplett falsche Richtung denke - ich bin sozusagen gerade beim Brainstorming.

Der Schwerpunkt meiner Diplomarbeit liegt zwar im Bereich der digitalen Signalverarbeitung (DSV), jedoch mit dem "Hinkefuß", dass das Ganze auf einem PDA mit Windows Mobile 5 realisiert werden soll.

Dabei bietet es sich (das ist natürlich nur meine Meinung) an, dass man auch das serienmäßig vorhandene .NET Compact Framework in Verbindung mit C# verwendet. Vor allem, da mir auch nur ein Treiber für meine Messdatenerfassung in C# vorliegt. Allerdings habe ich Bedenken, dass die zeitkritischen Abschnitte der DSV mit vielen Gleitkommaoperationen hier problematisch werden könnten.

Deshalb (endlich) zu meinen Fragen:

Ist es generell möglich, unter C# und .NET, zeitkritische Abschnitte in C-Librarys (DLL's) auszulagern, und diese (evtl. sogar in eigenen Threads) etwas schneller, da unmanaged, auszuführen?
Oder kann man davon ausgehen, dass das .NET (Compact) Framework zwar langsamer ist - Aber so langsam nun auch wieder nicht?

Da ich mit C# absolutes Neuland betrete, hoffe ich, dass Ihr mir vielleicht den ein oder anderen Tipp geben könnt.

Vielen Dank für eure Unterstützung

Gruß
Kramny

Die Interoperabilität mit "alten" Code ist ja gerade eine Stärke von .Net. Sprich die Verwendung von C Code ist erstmal prinzipiell möglich.

Ob das soviel bringt wie du dir erhoffst weiß ich aber nicht. Was reine Rechnerei angeht ist .Net nicht langsamer als unmanaged Sprachen. Wenn nötig nimmst halt unsafe Code und da kannst auch wie in C mit Pointern rechnen falls du dir dadurch mehr Geschwindigkeit erhoffst Gerade wenn dein Treiber eh in C# ist, musst du erst nach unmanaged marshallen, dann deine Berchnungen durchführen, und dann wieder zurückmarshallen. Das kostet auch. Je mehr Messwerten umso weniger darfst du den Marshal Aufwand vernachlässigen.

Ich meine, wenn sogar der Treiber für die Erfassung in C# geschrieben ist kanns doch nicht so schlecht sein oder Ich würde des einfach erstmal implementieren wie du magst, und wenns dir dann zu langsam ist halt Code auslagern und schaun ob das wirklich schneller ist. Oder vor der Entwicklung halt nen kleinen Versuch machen mit deinen Messwerten wieviel das marshallen kostet und dann entscheiden.

Die Interoperabilität mit unmanaged Code dürfte die Sache jedenfalls nicht schneller machen. Beim reinen Rechnen kochen da sowieso die meisten Sprachen und Frameworks auch nur mit Wasser. Eine einfache Berechnung dauert so lange, wie die CPU dafür braucht, nicht weniger und nicht mehr.

Unterschiede können sich eher dann ergeben, wenn du mit mehr low-level Arbeit mehr Performance herausholen kannst. Das ist jedoch keine Schwäche von C#. Mit unsafe Code kannst du richtig C-style programmieren, wenn du magst.

Also wir haben hier eine unmanaged C++-Anwendung die regelmäßig alle paar Millisekunden ein UDP-Paket mit einem unter vxWorks laufenden Echtzeitsystem austauscht.

Das habe ich mal benutzt um eine entsprechnende C#-Anwendung zu testen.

Ergebnis war das sich C# und C++ in der Performance dabei nichts nehmen, mit minimalen Vorteilen für C#.

Nur bei der Garbage-Collection legte die C#-Anwendung jedesmal eine Pause ein und verpennte einen Zyklus.

Deswegen würde ich auf jeden Fall zeitkritische Aktivitäten in einen eigenen Thread in einer unmanaged DLL halten.

Ob man dafür dann PInvoke in C# oder eine Wrapperklasse in C++/CLI verwendet ist eher Geschmackssache. In C++/CLI kann die Schnittstelle eher objektorientiert sein, bei PInvoke hat die DLL eher eine C-Schnittstelle.

Hmmm ja wir hätten erstmal klären müssen ob "zeitkritisch" performant oder garantierte Latenzzeit heißt. AFAIK ist das .Net Framework nicht für harte Echtzeitbedingungen geeignet. Wenn du nur weiche Echtzeitbedingungen hast, kannst du mit geeigneten Parametern eine extrem hohe Wahrscheinlichkeit erreichen, dass sie eingehalten werden und das passt. Harte Echtzeitbedingungen sind aber schon alleine wegen Windows Mobile gar nicht zu schaffen, weil man dafür ein Echtzeit-Betriebssystem braucht.

Also hoffe ich, dass du bei deinem Projekt keine harten Echtzeitbedingungen hast.

Kramny

Vielen Dank ersteinmal für die sehr informativen Antworten.

@optimizer und nn
Meine Anwedung erfordert keinen harten Echtzeitbetrieb - sie soll nur performant sein . (Ich glaube, dann hätte ich die Finger von diesem Thema gelassen). Das verwendete USB-DAQ-Modul (USB-Messdatenerfassung) hat einen internen 1MByte großen Puffer, in dem knapp 10 Minuten Messdaten zwischengelagert werden könnten. Was natürlich auch keinen großen Sinn macht.
Vielleicht sollte ich das auch einmal erwähnen: Insgesamt sollen drei Analoge Signale mit 200Hz (später evtl. noch schneller) abgetastet werden und anschließend mit verschiedenen Algortithmen (FFT, IIR) verarbeitet werden. Grob: so eine Art Spektrumanalyser für mechan. Schwingungen.

@Zwergli
es wird wohl auf den Ansatz hinauslaufen, dass ich ersteinmal alles in C# realisiere. Ob in meiner Arbeit noch ein Punkt (Performancegewinn/-verlust zw. C und C#) aufnehme, werde ich mit meinem Prof. klären, der zugegebnermaßen ein C und Assembler-Verfechter ist.

Insgesamt beruhigt es mich ja schon, dass es prinzipiell möglich wäre, dass man ggf. C-Code mit C# "mischen" kann. Für mich ist die .NET Umgebung neu, da ich Schwerpunktmäßig mit mit Microcontrollern/DSPs arbeite (studiere) und mir von daher C sehr vertraut ist. Aber das macht ja auch den Reiz einer Diplomarbeit aus, Neuland zu erschließen

Gruß
Kramny