C# Syntax und Compiler Probleme

Eddy schrieb:

Nativ ist das alles viel schneller da keine "uebersetzung" stattfindet waehrend der Laufzeit.

Definiere "viel schneller". Denn wenn wir das gleiche unter "viel" verstehen, dann kann ich dir nicht zustimmen. Ja, du kannst mit nativem Code etwas mehr rausholen. Aber selbst dann musst du a) wissen was du tust und b) ist das dann nicht soo viel. Im Gegenteil, wenn du mit nativen Sprachen nicht exakt weißt was du tust, hast du am Ende die weitaus größeren Probleme (inkl. Performanceprobleme) als mit C#. Deshalb meine konkrete Frage: Was verstehst du unter "viel schneller".

Eddy schrieb:

Nimmt man wie ich einen alten GCC, braucht man keine Laufzeit Sachen installieren.

Das kannst du so pauschal leider auch nicht sagen. Und auch der Visual C++ Compiler kann Assemblies erstellen welche nicht auf die Visual C++ Runtime angewiesen sind. So ähnlich wie du dir das beim GCC vorstellst.

Dazu kommt noch, dass ein JIT Compiler nicht auf "er optimiert die Befehlssätze je nach Platform" herunter gebrochen werden kann.

Und @Peter329: dann nimm .NET 2.0, das läuft selbst auf einer Palmeninsel.
Aber allgemein wäre da doch wohl eher der bessere Ansatz sowas als kleine WebApp zu machen.

Ich glaube kaum, dass das von C# in Nativen Code übersetzte Programm so viel performanter sein wird. Bezogen auf Startup und einzelne Funktionen glaube ich das gerne, aber im Gesamtbild, wohl nicht unbedingt.

Die .Net Runtime macht zur Laufzeit Optimierungen, die mit nativem Code gar nicht Möglich sind. Und ein Code der darauf ausgelegt ist nicht nativ zu laufen dann auf nativ zu übersetzen baut denke ich eher einige Hürden ein.
Abgesehen davon ist dann die schöne Plattformunabhängigkeit dahin(die mit Mono wirklich nicht schlecht ist)

@thefiloe Na gut "viel schneller" ist ungluecklich ausgedrueckt, aber nicht ganz falsch, haengt halt davon ab was du machst. Angenommen du suchst eine bestimmte Bytefolge in einer Datei(sagen wir 5MB gross), hast keinen Anhaltspunkt wo diese sein kann, durchsuchst die Datei von Anfang bis Ende, mit einer .net Anwedung dauert das u.U. eine ganze Weile hab jetzt keine Zeit da, aber bin sicher das waren locker 30+ Sekunden, mit C++ klappt das in weniger als einer Sekunde. Das wuerde ich als "viel schneller" bezeichnen, sogar als sehr viel schneller.

Peter329 schrieb:

auf allen Windows Rechnern

ohne Framework - da hilft C++.
Allerdings denke ich nicht, das das das ist, was Du willst.
Ein Framework gehört heute zu allen "moderneren" Windowsens, ältere Windows-Versionen werden nicht mehr supportet.
Neuere Programme laufen auf älteren Systemen nicht unbedingt.
Du musst also eine klare Grenze ziehen, z.B. sollte eine minimale Windows-Version da sein. Außerdem musst Du Dein Programm auf allen diesen Systemen testen, und ich gehe glatt davon aus, dass Du nicht alle Systeme rumliegen hast.

thefiloe schrieb:

Definiere "viel schneller"

MSDN schrieb:

With .NET Native optimization, apps start up to 60% faster
and use 15-20% less memory when compiled with .NET Native.

@Fakiz .NET Native im Bezug auf das .NET-Framework, ja. Das hat aber überhaupt nichts damit zu tun, ob nun Managed oder Unmanaged schneller sein soll.

Grüße

@Eddy: Dann ist dein C# Code falsch, denn beim auslesen von 5MB und einfachen durchsuchen ist IO idR der Flaschenhals und nicht das durchsuchen der Daten.
Und wie gesagt Laufzeitoptimierungen können bei manchen Dingen viel mehr Zeit bringen, als dies zur Compiletime möglich ist, denn zur Compiletime kann man nicht wissen, was auf welche Art wie oft aufgerufen wird, die JIT kann dies erkennen und entsprechend Code inlining o.ä. machen.
Die Hauptgeschwindigkeitsvorteile von Nativ liegen bei häufigen aufrufen, denn jeder Aufruf läppert sich, oder intelligentem Memory Management(was fraglich ist, ob das ein solcher Compiler entsprechend vorhersagen kann). Hingegen können dynamischer Code in zumindest C++ aufgrund der Durchsuchung der vtable langsam werden, etwas das bei C# gar nicht nötig ist.
Von miserabel wenig RTTI in den meisten nativen Sprachen will ich gar nicht anfangen, das nervt jedesmal, wenn man es selbst machen muss(natürlich ist es schön, wenn es nicht da ist, wenn man es nicht braucht).

Eddy schrieb:

eine ganze Weile hab jetzt keine Zeit da, aber bin sicher das waren locker 30+ Sekunden, mit C++ klappt das in weniger als einer Sekunde. Das wuerde ich als "viel schneller" bezeichnen, sogar als sehr viel schneller.

Ja und da muss ich ganz klar sagen, dann kannst du schlichtweg nicht programmieren.
Um das an einem praktischen Beispiel zu erläutern: Ich habe eine Audiobibliothek (CSCore) zu 100% in C# geschrieben. Diese beinhaltet unter anderem z.B. einen FLAC Decoder. Dieser decodiert FLAC Dateien mit einer mehr als ausreichenden Geschwindigkeit um auf Anfrage, schnell genug Daten zur Verfügung ohne diese extra puffern zu müssen. Ebenso bietet dieser die Möglichkeit FLAC Dateien beim Laden komplett zu parsen und alle FLAC Frames zu erkennen. Diese Dateien sind sehr viel größer als 5MB und die Frames entsprechend komplex aufgebaut und ich hatte Performance mäßig nie Probleme.
Dass C++ das 30-fache an Performance haben soll ist schlichtweg Schwachsinn. Auch das Szenario, nämlich das lesen von Dateien könnte nicht schlechter gewählt sein. Hier werden immer die IO Zugriffe der Flaschenhals sein, was nichts mit einer Sprache zu tun hat. .NET ist in manchen Punkten schneller als native Sprachen und in manchen Punkten langsamer. Die Startzeit ist garantiert so gut wie immer länger als bei nativen Sprachen, jedoch ob ein Programm ein paar ms länger zum Starten braucht oder nicht ist vernachlässigbar. Aber lies das doch mal im Detail nach: codeproject.com/Articles/21285…d-benchmark-Csharp-vs-NET

Fakiz schrieb:

With .NET Native optimization, apps start up to 60% faster
and use 15-20% less memory when compiled with .NET Native.

Wie gesagt: a) sprechen wir hier von StoreApps, welche du meiner Meinung nach schlecht vergleichen kannst, da da noch kp was alles im Hintergrund läuft, b) sind das alles Angaben von "up to" => heißt vom worst case zum best case (im Durchschnitt sehen die Werte ganz anders aus) c) bezieht sich das primär auf die Startzeit wo .net schlichtweg nicht so schnell sein kann und d) der Speicherverbrauch ist bei kleinen Applikationen in .NET immer vergleichsweise hoch, da die runtime, ... mitläuft, bei größeren Anwendungen relativiert sich der Unterschied. Dazu kommt, dass wenn du C++ nicht voll im Griff hast, dann hast du am Ende sehr hohe Chancen auf Memory Leaks was du bei .NET wiederum schlichtweg nicht hast.

thefiloe schrieb:

dann kannst du schlichtweg nicht programmieren.

Sehr nett deine Aussage . Gut ich kanns vieleicht nicht so gut wie manch anderer hier, aber ich habe weder eine Ausbildung noch ein Studium in diesem Bereich genossen. Bin auch noch nicht so lange dabei, aber die Ziele die ich mir vornam, habe ich bisher erreicht.

@Eddy Ja und?
Diese beiden Aussagen (das Zitat und Deine Erwiederung) widersprechen sich nicht unbedingt, insbesondere, wenn es beim Programmieren ums Eingemachte geht.
Sorry.

Das kam vll. etwas falsch rüber @Eddy. Aber Tatsache ist, dass wenn du einen Performanceverlust um das 30-fache hast, dass dann nicht die Sprache sondern schlichtweg du schuld bist. Das kein Vorwurf oder sonst was sondern nur eine Feststellung. Um ehrlich zu sein, fällt mir nicht mal ein wie man etwas derart verlangsamen kann, dass es gleich 30 mal langsamer wird. Daraus schließe ich einfach, dass dir das nötige Know-How fehlt.

Ja wirkte wohl anders als du meinstest, aber so wie du es jetzt im letzten Satz schriebst, klingt es aber auch deutlich hoeflicher . Das ist so aber auch richtig es fehlt mir bei manchen Sachen Know-How, dazu stehe ich auch. In Post28 dein erster Satz wirkte wirklich nicht nett, klingt so als koenne ich absolut nicht programmieren, was aber m.M.n. so nicht ganz korrekt ist(wie man "programmieren koennen" halt definiert). Aber es kann ja nur besser werden, alles ein Frage der Zeit.

Aber der Benchmark-Artikel ist interessant, den schaue ich mir jetzt noch mal ganz genau an.