Hersteller wie NI, Rohde&Schwarz, Keysight, Lecroy usw geben an, dass sich C# als Programmiersprache zur Entwicklung einer Messplatzsteuerung eignet. Tatsächlich wird dazu nicht einmal zusätzliche Treibersoftware wie die der IVI-Foundation benötigt. Es reicht eine I/O-Softwareschicht aus, z.B. VISA, die eine Abstraktionsschicht über den low-level Treibern darstellt. Meine Frage ist: welche Grenzen hat die Verwendung von C# in diesem Zusammenhang? Intuitiv wäre als hardwarenahe Programmiersprache die Hochsprache C oder C++ zu wählen. Deswegen meine These: bei der Aussage der hersteller handelt es sich nur um die halbe Wahrheit. Solange es sich ausschließlich um die Konfiguration der Messgeräte handelt, reicht C# aus. Sobald größere Datenströme, beispielsweise durch Auslesen der Wellenform aus dem Oszi, entstehen, die vom Host gespeichert werden, ist C zu wählen. Wobei ich mir nicht sicher bin, ob die Speicherung der Daten ein Problem darstellt. Wenn das Programm eine CSV-Datei erstellt und die Daten in dieser Speichert. Oder ob die Probleme erst bei einer Auswertung anfangen.
:
Bearbeitet durch User
Natürlich geht das mit c#... Hilfreich ist hier jedoch die Verwendung von dotnet, weil ohne hat c# nicht viel Sinn und dann ist c oder so vorzuziehen... Wobei hier auch die Verwendung von libs praktisch ist... Aber dann kann man gleich wiederum c# verwenden
Drahtverhau schrieb: > Natürlich geht das mit c# mir ist nicht ganz klar, worauf sich diese Aussage bezieht.
Du widersprichst dir in deinem Eingangsposting z. T. selbst - zum Einen beschreibst du ja explizit, dass bereits eine (zusätzliche) Abstraktionsschicht über den Low-Level-Treibern zum Einsatz kommt; andererseits möchtest du aber "hardwarenah" programmieren. Ohne deine genauen Tools und Schichten zu kennen, würde ich daher das, was du da vor hast, keinesfalls als "hardwarenah", sondern im Gegenteil als bereits relativ hardwarefern bezeichnen. Ergo sehe ich hier keinerlei Probleme mit C# - wo genau sollen diese herkommen; wo sollen diese liegen? Auch mit C# lassen sich (mit entsprechenden Mechaniken) durchaus "echtzeitfähige" Anwendungen bauen (sofern das deine Bauchschmerzen sind) - das gilt für die anderen Sprachen allerdings genau so. Mit anderen Worten: Ein C++-Programm zur Messplatzsteuerung, das unter Windows irgendwo im User Space läuft, ist per se keinesfalls "besser". Wenn es darum geht, große Datenmengen zu bewegen, sehe ich auch nicht, welchen primären Faktor hier die genutzte Programmiersprache spielen soll - im Gegenteil ist das dahinter stehende Framework (.NET) sehr mächtig.
Antonow B. schrieb: > ...reicht C# aus. Sobald größere Datenströme, beispielsweise durch Auslesen der > Wellenform aus dem Oszi, entstehen, die vom Host gespeichert werden, ist > C zu wählen. Wenn du es in C# nicht hin bekommst dann in C oder C++ genausowenig. Antonow B. schrieb: > Meine Frage ist: welche Grenzen hat die Verwendung von C# in diesem > Zusammenhang? Intuitiv wäre als hardwarenahe Programmiersprache die > Hochsprache C oder C++ zu wählen Was soll hier Hardwarenahe sein? Willst du eine Software schreiben die direkt auf dem µC des Messgerätes läuft? Du bewegst dich doch eher auf der Anwendungsebene oberhalb von einem Ausgewachsenen Betriebssystem wie Linux oder Windows die dir beide kräftig auf die Finger klopfen wenn du der Hardware zu nahe kommst ohne entsprechenden Treiber dazwischen. C wäre hier eher die letzte Wahl (außer man kann nichts anderes). Eventuell noch C++ oder C# je nach dem was man besser kann (ansonsten geben die beiden sich nichts). Viele würden hier eher so Sprachen wie Java, Python oder Perl nehmen wenn es darum geht zügig was zusammen zu bauen was Daten von einem externen Gerät auswertet.
Aber es wäre doch falsch zu sagen, ein c#-Programm hat die gleiche Dynamiki wie ein C-Programms. (Echtzeit/Geschwindigkeit)
:
Bearbeitet durch User
Antonow B. schrieb: > Aber es wäre doch falsch zu sagen, ein c#-Programm hat die gleiche > Dynamiki wie ein C-Programms. (Echtzeit/Geschwindigkeit) Das war vielleicht vor 20 Jahren so. Und ohne Framework stehst Du so und so auf dem Schlauch. Weisst Du eigentlich wie schnell die aktuellen PC überhaupt sind? Die heutige Kunst ist es Aufgaben zu parallelisieren. Ansonsten bekommst Du Deine 24 Kerne gar nicht an die Arbeit. mfg KLaus
Drahtverhau schrieb: > Hilfreich ist hier jedoch die Verwendung > von dotnet, weil ohne hat c# nicht viel Sinn Äh - ohne .NET geht gar nichts. Es muß sogar die korrekte .NET-Version installiert sein, sonst geht gar nichts.
Klaus R. schrieb: > wie schnell die aktuellen PC > überhaupt sind? wie du schon selbst sagst, es ist eine Frage des Rechners. Zur Verarbeitung großer Datenmengen steht der Grundsatz, dass C# weniger gut geeignet ist, als C. Und da wäre meine Frage, ob dies schon für die Speicherung von externen Daten in eine CSV-Datei gilt? Eine weitere Frage: worin liegt die geringere Dynamik begründet. Im Internet findet man alles mögliche. Beispielsweise dass es an der Verwendung des JIT-Compilers liegt. Stimmt das?
:
Bearbeitet durch User
nun ich behaupte mal wenn du in C die gleiche Qualität was Fehlerbehandlung und Ablauf erreichen willst wie in c# dann wird sich das Laufzeit Ergebnis nicht so weit unterscheiden. Deine Messgeräte werden die Daten in C nicht schneller liefern als in C#. Egal welche Sprache du verwendest, beim Speichern in eine Datei wirst du sicher keine großen Unterschiede feststellen
Thomas Z. schrieb: > Egal welche Sprache du verwendest, beim Speichern in eine Datei wirst du > sicher keine großen Unterschiede feststellen warum ist das so? hast du zufällig eine Quelle?
Antonow B. schrieb: > warum ist das so? hast du zufällig eine Quelle? Eine Quelle hab ich nicht, aber letztendlich muss immer in irgendeiner Form WritFile des Betriebssystems aufgerufen werden. Datei Funktionen sind nun mal Sache von Windows das hat mit der Programmiersprache wenig zu tun
Antonow B. schrieb: > Zur > Verarbeitung großer Datenmengen steht der Grundsatz, dass C# weniger gut > geeignet ist, als C. Und wie kommst du darauf? merciless
Antonow B. schrieb: > Tatsächlich wird dazu nicht einmal zusätzliche Treibersoftware wie die > der IVI-Foundation benötigt. Es reicht eine I/O-Softwareschicht aus, > z.B. VISA, die eine Abstraktionsschicht über den low-level Treibern > darstellt. ?!? Also doch Treiber, und an statt dass man sie direkt ansprechen kann, wie unter C/C++, braucht man zusätzlich eine Aufruferschicht, ähnlich JNI bei Java. Apropos Java: C# ist das Jave-Konkurrenzprodukt von Microsoft. Du kannst also auch fragen, ob sich Java zur Gerätesteuerung eignet. Klar, wenn es nicht zu zeitkritisch ist. Garbage-Collection verträgt sich nicht wirklich mit Echtzeit. Interrupts sind in C# auch nicht vorgesehen, bei C/C++ unter Windows/Linux aber auch nicht.
MaWin schrieb: > Treiber, und an statt dass man sie direkt ansprechen kann, > wie unter C/C++, Treiber für die Schnittstelle, nicht für die Geräte....
Antonow B. schrieb: > Dirk K. schrieb: >> Und wie kommst du darauf? > die geringere Geschwindigkeit Schonmal mit C# entwickelt? Ich denke nicht. Die einzige Geschwindigkeitseinbusse, die ich feststellen kann, liegt im ersten Start der Anwendung, weil evtl. DLLs im Hintergrund geladen werden müssen. merciless
Es ist ein Mythos, dass kompilierte Sprachen (z.B. C++) viel schneller sind als Bytecode-Sprachen mit Garbage-Collection (z.B. Java, C#, Javascript etc.). Nachfolgend möchte ich ein paar Beispiele nennen, wo dynamische Sprachen Vorteile gegenüber z.B. C++ haben können. Wohlgemerkt: ich behaupte nicht, dass das eine oder andere schneller ist. Grundsätzlich sind die Performanceunterschiede aber in einer Größenordnung, die bei heutigen CPUs keinen fühlbaren Unterschied mehr machen sollte. Und wenn, dann geht die Performance in miesen Algorithmen, Abstraktionsorgien oder sonstwie unnötig hoher Komplexität flöten. An der reinen Ausführungsgeschwindigkeit liegt es zu 99,x% nicht. Also, was sind die Hauptpunkte wo C++ Nachteile haben kann? 1. Garbage Collection vs. explizite Freigabe. Wenn in C++ ein Objekt aus dem Scope läuft wird zwingend der Destruktor aufgerufen und der Speicher dieses Objekts freigegeben. Wenn das viele Objekte sind kann das teuer werden, während ein Generational Garbage Collector das (unter Umständen) für 0 CPU-Cycles bekommt, indem er einfach den Eden-Space, wo neue Objekte angelegt werden, als frei deklariert. 2. JIT-Compiler mit Analyse zur Laufzeit ein JIT-Compiler hat mehr Informationen als ein normaler Compiler. Dabei wird i.d. Regel zuerst der Bytecode eine Zeit lang interpretiert und beobachtet, um dann durch optimierten Maschinencode, der den Standardfall abdeckt, ersetzt zu werden. Sollte dann doch mal was anderes kommen gibts immernoch den Interpreter als Fallback. Beispiele: - Loop-Unrolling (weil es immer 3 statt "x" Runden sind) - Auflösung von Polymorphie durch dynamisch erstellte Klassen. Der JIT-Compiler kann spezifische Klassen compilieren. Methoden können hart, ohne Lookup in einer virtuelle-Methoden-Tabelle, aufgerufen oder sogar ge-inlined werden. - Analog beim Zugriff auf Objektmember. Semantisch fühlt sich ein Java-Script-Objekt zwar wie ein Dictionary an und Zugriffe erfordern eine Suche irgendwo in der Objekthierarchie. Spezifisch kompiliert wird daraus aber ein struct mit fixen Offsets im Maschinencode. Klar, das sind Beispiele. Wo Licht ist ist auch Schatten. Garbage-Collection, Profiling, JIT-Compiling brauchen auch Zeit. Ich würde die Entscheidung für (oder gegen) eine Sprache aber nicht davon abhängig machen. Die Sprachkentnisse der Entwickler und der Support durch Tools und Bibliotheken sind viel entscheidender. Selbst wenn es anekdotisch einen Performanceunterschied um Faktor 2 (oder gar 10) geben sollte wäre das nicht mein Hauptkriterium.
Tilo R. schrieb: > Garbage-Collection, Profiling, JIT-Compiling brauchen auch Zeit. Und Speicher, nix ist gratis. leo
Antonow B. schrieb: > Meine Frage ist: welche Grenzen hat die Verwendung von C# in diesem > Zusammenhang? Kommt drauf an. Wenn du n Haufen native C-APIs ohne COM ansteuern musst, würde ich eher C++/CLI (Managed C++) nehmen. Die Gui drüber meinetwegen in C#. Das aber auch nur, weil das ganze PInvoke-Geraffel mit den Attributen eher unschön zu lesen ist, und nicht, weils nicht gehen würde. Bist halt mit C# weitestgehend auf Windows bzw. Mono begrenzt. Wenns portabel sein soll (OSX, Linux), wäre ich eher für Qt, schon alleine wegen des teilweise eher nichtdeterministischen GarbageCollectors bei .net. > Intuitiv wäre als hardwarenahe Programmiersprache die > Hochsprache C oder C++ zu wählen. Deswegen meine These: bei der Aussage > der hersteller handelt es sich nur um die halbe Wahrheit. Solange es > sich ausschließlich um die Konfiguration der Messgeräte handelt, reicht > C# aus. Sobald größere Datenströme, beispielsweise durch Auslesen der > Wellenform aus dem Oszi, entstehen, die vom Host gespeichert werden, ist > C zu wählen. Performance ist nicht alles, aber ohne Performance ist alles nichts. Klar: musste sehr große Datenraten verarbeiten, kann C++ Vorteile bringen. Ich selber würde ich die Datenraten-lastigen Funktionalitäten der Software auch in den C++-Teil hineinpartitionieren. Kommt aber drauf an, je embeddeder man arbeitet, desto mehr C/C++ gehört da rein. Ob man die GUI dafür dann mit Python, QML oder halt C# zusammenkläppert, ist ja eher Geschmackssache. > Wobei ich mir nicht sicher bin, ob die Speicherung der Daten ein Problem > darstellt. Wenn das Programm eine CSV-Datei erstellt und die Daten in > dieser Speichert. Oder ob die Probleme erst bei einer Auswertung > anfangen. 3-Schichten sind immer gut: Benutzerbedienung ganz oben (Frontend), Persistenz und Kommunikation mit Fremdsystemen ganz unten (Backend). Dazwischen bissl Middleware, die das eine mit dem anderen verbindet, schon wirds vertikal. Imho gehört Persistenz nicht in die GUI direkt hinein, höchstens bei schnellgestrickten Prototypen, nicht bei ausgereifter Software. Sind aber nur meine 2 cents.
Dirk K. schrieb: > Schonmal mit C# entwickelt? Ich denke nicht. > Die einzige Geschwindigkeitseinbusse, die ich > feststellen kann, liegt im ersten Start der > Anwendung, weil evtl. DLLs im Hintergrund geladen > werden müssen. Dann hast du wohl noch nie Sachen entwickelt, bei denen Performance wirklich eine Rolle spielt. Natürlich gibt es hier in vielen Fällen Performancevorteile, je näher der Codegenerator an der Maschine ist, auf dem der Kram am Ende läuft und je näher die Sprache an der Maschine ist, auf der der Kram am Ende läuft. Das Problem ist: beides ist von den jeweiligen Fähigkeiten abhängig, im ersteren Fall von den Fähigkeiten des Codegenerators (und dem Zeitpunkt seiner Ausführung, somit seinen Kenntnissen über die Zielmaschine) und im zweiten Fall von den Fähigkeiten des Programmierers selber und seinen Kenntnissen über Codegenerator und/oder die Zielmaschine. Sprich: der optimale Code kann immer nur in der Assemblersprache der konkreten Zielmaschine von einem sehr fähigen Assemblerprogrammierer erzeugt werden. Und selbst das gilt nicht immer, denn auch der hat keine Ahnung von den Seitenkanälen, die zur Laufzeit der konkreten Anwendung in der konkreten Umgebung einen Einfluss auf die Performance haben, was bei modernen Maschinen durchaus viele sein können. Gerade weil das inzwischen so komplex geworden ist, haben aber interessanterweise Sprachen mit fortgeschritten JIT-Compilern (also welchen, die Laufzeit-Profiling machen) teilweise sogar Vorteile gegenüber den "statischen" Programmiersprachen (sogar incl. Assembler samt fähigem Assemblerprogrammierer!), die zur Compilezeit nix über das Umfeld der konkreten Zielanwendung wissen, sondern bestenfalls umfassende Informationen über die Zielmaschine besitzen und diese optimal zu nutzen wissen. --- Übrigens sollte man bei der Diskussion eins nicht vergessen: Performance hat direkt erstmal nichts mit Echtzeitanforderungen zu tun. Das wird immer wieder durcheinander geworfen. Maximal bestimmt die erzielbare Performance, was bezüglich der Echzeit zu schaffen ist. Die Definition von Echzeit ist nämlich im wesentlichen: spezifiziere den worst case... Blöderweise ist aber gerade dafür von Vorteil, bei der Codegenerierung weit weg von der Laufzeit zu sein, insbesondere natürlich keinesfalls die Codegenerierung erst zur Laufzeit auszuführen, denn es ist schon aus rein theoretischen Gründen (Komplexität) ziemlich unmöglich, unter diesen Umständen irgendwelche (akzeptable) Echzeit zu garantieren. Ähnliches gilt für dynamisches Speichermanagement, ganz egal wie die Freigabe der Sache organisiert ist, ob explizit oder per garbage collection.
Antonow B. schrieb: > Deswegen meine These: bei der Aussage der hersteller handelt es sich nur > um die halbe Wahrheit. Solange es sich ausschließlich um die > Konfiguration der Messgeräte handelt, reicht C# aus. Ja, das würde ich so unterschreiben. Antonow B. schrieb: > Sobald größere Datenströme, beispielsweise durch Auslesen der Wellenform > aus dem Oszi, entstehen, die vom Host gespeichert werden, ist C zu > wählen. Ja, wenn du Hardware direkt ansprechen willst und nein, wenn du das mittels einer Zwischenschicht machst, die wiederum in C/C++ geschrieben ist, z.B. VISA. Der kritische Punkt an GC-Sprachen wie C#, Java oder Go ist nicht der Durchsatz (da erreichen sie typischerweise 80% gegenüber C, also mehr als ausreichend). Das Problem ist die Latenz, die durch den Garbagecollector zustande kommt. Wenn sich also dein C#-Programm gerade mal eine Denkpause gönnt und dadurch der Datenpuffer deines Messgerätes überläuft, weil die Daten nicht zeitig weggeschaufelt werden können, dann ist das definitiv ein Problem. Wenn du aber irgendeine Treiberschicht dazwischen hast, die etwa in C geschrieben ist (wie etwa VISA) und der C-Prozess die Daten aufnimmt und diese erst anschließend an den C#-Prozess durchgereicht werden, dann kann der C#-Prozess sich durchaus mal eine Gedenksekunde gönnen, so lange dem C-Prozess genügend Speicher zur Verfügung steht um die Daten für diese Zeit zu puffern.
:
Bearbeitet durch User
Christopher J. schrieb: > mal eine Denkpause gönnt und dadurch der Datenpuffer deines Messgerätes > überläuft, weil die Daten nicht zeitig weggeschaufelt werden können, > dann ist das definitiv ein Problem. Nö, das ist es natürlich nicht. Man muss halt einfach nur im Gerätetreiber oder der Middleware (also im Falle von DotNet dem SerialPort) genug Buffer zur Verfügung stellen. Die entsprechende Eigenschaft beim SerialPort heißt übrigens ReadBufferSize. Hätte man wohl auch alleine drauf kommen können... Jedenfalls wenn man zumindest eine grundsätzliche Idee davon hat, wie asynchrone Komunikation eigentlich ganz grundsätzlich funktioniert... Sprich: der Durchsatz ist nicht das Problem. Das Problem ist ggf. nur die Reaktionzeit bis zur Behandlung eingehendender Daten. Das gilt inbesondere dann, wenn abhängig vom Ergebnis der Behandlung dieser Daten irgendeine Rückwirkung auf den Sender ausgeübt wird...
Antonow B. schrieb: > Meine Frage ist: welche Grenzen hat die Verwendung von C# in diesem > Zusammenhang? Die gleichen wie C oder C++. >Intuitiv wäre als hardwarenahe Programmiersprache die > Hochsprache C oder C++ zu wählen. Was ist an Messplatzsteuerung hardwarenah? Dir werden die Messdaten geliefert und du sollst diese auswerten/darstellen/weiterverarbeiten... Da ist C#.Net sehr gut geeignet. Deswegen meine These: bei der Aussage > der hersteller handelt es sich nur um die halbe Wahrheit. Nein. > Solange es sich ausschließlich um die Konfiguration der Messgeräte handelt, reicht > C# aus. Sobald größere Datenströme, beispielsweise durch Auslesen der > Wellenform aus dem Oszi, entstehen, die vom Host gespeichert werden, ist > C zu wählen. Das sind keine größere Datenströme wovon du da redest, das kann sogar die Schildkröte Namens "LabView". Und wenn du mit NI's VISA arbeitest, lacht sogar ein 10 jahre alter PC drüber...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.