Wie schätzt Ihr die Weiterentwicklung von .NET ein?

**Assarbad**

Ich gehe jede Wette ein, dass ich jedes Programm welches Insider2004 in Delphi schreibt, mindestens genauso performant, wenn nicht sogar performanter auf Basis von .NET implementieren kann. Voraussetzung ist, dass zum Vergleich die Sourcen offen liegen - und er sich überhaupt auf die Wette einlässt.

Wunderbar. Fehlt nur noch:

Lauffähig ab Windows 2000
Rechner muß mindestens 7 Jahre alt sein und darf nicht mehr als 512 MiB RAM und einen Einkernprozessor haben
Delphi 2009 oder neuer muß verwendet werden, damit kein unfairer Vorteil aufgrund der Nutzung von ANSI-Funktionen entsteht (die nur Wrapper um die Unicode-Funktionen und damit ein wenig langsamer sind)
Der gleiche Rechner wird zum Test beider Programme benutzt und frisch vor jedem Testlauf gebootet

Noch dabei?

Oder wolltest du mit deiner Aussage nur nachweisen, daß der durch Caching, Mehrkernprozessoren, mehr billigen RAM und diverse andere Entwicklungen der jüngsten Vergangenheit stärker herausgearbeitete Flaschenhals des Festplattenzugriffs der eigentlich begrenzende Faktor ist und das native Programm auf einer neueren Architektur irgendwann nur nicht mehr fühlbar schneller läuft?

Setzen wir doch einfach mal realitätsnahe Bedingungen für den Test an. Außer Entwicklern und Spielern haben viele nämlich noch immer alte PCs. Auch Windows 2000 ist noch verbreitet, wenn uns Entwicklern das auch nicht so lieb sein kann ...

Übrigens, du hast auch nicht gesagt welche .NET-Version zum Einsatz kommen soll! Ich habe das versucht in obige Bedingungen einfließen zu lassen - Windows 2000 sollte hier hinreichend einschränkend wirken.

Akzeptabel?

Nachtrag:

Zitat von Bernhard Geyer:

Wenn's man richtig macht dann hat man in managed Umgebungen keine Performance oder Ressourcenprobleme.

Basierend auf welcher Rechnerspezifikation? Mindestanforderungen für, sagen wir, Windows Vista?

Wem die Tricks mit verzögertem Laden des .NET Caches usw. nicht bewußt ist, der braucht nur auf einem XP oder 2003 ein .NET-Programm direkt nach dem Hochfahren zu starten ... und zu waaaarten. Aber ist schon toll, wie dieser Trick immer wieder in den Augen des Publikums funktioniert. Ging bei MS Office auch jahrelang. Bis OOo einen "Schnellstarter" nachgerüstet hat. Bei MS Office war der nur schon seit Jahren drin, so daß die eigentliche Arbeit schon getan war, als der Benutzer glaubte das Programm zu "starten" (welches zu großen Teilen längst im Speicher war).

Und wenn ich die entsprechenden Dienste deaktiviere, sieht es auch nicht mehr so rosig aus. Nur weil in Vista und 7 diese Caches nicht mehr abschaltbar sind, berührt das noch nicht die Gültigkeit der Aussage daß - und hier ist es wo offenbar Phoenix und Insider2004 Äpfel mit Birnen vergleichen - .NET bei eingeschränkter Verfügbarkeit von RAM und CPU immer (auch fühlbar) langsamer sein wird.

Ich nehme nämlich mal ganz stark an, daß Phoenix hier sehr schnell zurückrudern würde, wenn seine Wette eben mit den o.g. Bedingungen versehen wäre. Dann ist nämlich nicht die Festplatte der gemeinsame begrenzende Faktor, wie dies bei modernen Systemen meistens der Fall ist, sondern der Speicher und die CPU ...

**hanspeter**

Zitat von Thom;
Nenne mir bitte nur eine einzige Sache, die ich mit nativem Delphi [I:

nicht[/I] hinbekomme, sondern nur mit NET (abgesehen von der - eingeschränkten - Plattformunabhängigkeit!

Alles was mit 64 bit zu tun hat. z.B. Shellerweiterung, Win CE, Compactframework. (Mono Linux, Mac). Kurz alles was nicht ausschließlich mit Win 32 zu tun hat.
Unabhängig davon bevorzuge ich auch native Programmierung, da ich meine das der Performancegewinn moderner Systeme der Applikation zugute kommen sollte und nicht im Betriebssystem verbraten werden sollte.

**Assarbad**

Zitat von hanspeter:

Alles was mit 64 bit zu tun hat. z.B. Shellerweiterung, Win CE, Compactframework. (Mono Linux, Mac). Kurz alles was nicht ausschließlich mit Win 32 zu tun hat.

Aber deswegen empfiehlst du hoffentlich jetzt nicht eine Shellerweiterung in .NET hinzubrezeln?

**hanspeter**

Zitat von Assarbad:

Aber deswegen empfiehlst du hoffentlich jetzt nicht eine Shellerweiterung in .NET hinzubrezeln?

Nein.
Für Windows bevorzuge ich native Programmierung.
Es gibt allerdings Systeme, wo man an gemanagten Code (egal ob Net oder Java) nicht vorbei kommt.
Ich habe mal Software für einen Mainframe gebaut, da war nur gemanagter Code zugelassen.
Grund ein Programmierfehler bringt schlimmstenfalls die VM mit der gemanagten Runtime zum Absturz und nicht die ganze Maschine mit den paar hundert parallen Prozessen.

**Assarbad**

Zitat von hanspeter:

Es gibt allerdings Systeme, wo man an gemanagten Code (egal ob Net oder Java) nicht vorbei kommt.
Ich habe mal Software für einen Mainframe gebaut, da war nur gemanagter Code zugelassen.
Grund ein Programmierfehler bringt schlimmstenfalls die VM mit der gemanagten Runtime zum Absturz und nicht die ganze Maschine mit den paar hundert parallen Prozessen.

Wohl wahr. Diese Fälle gibt es und die haben meist auch ihre Berechtigung. Die hat .NET auch. Die Frage ist nur ob man dogmatisch oder pragmatisch (egal in welcher Richtung) mit Technologien umgeht. Und mit Phoenix und Insider2004 scheinen hier zwei Dogmatiker der jeweils anderen Seite aufeinandergeprallt zu sein.

**Daniel**

Das ist aber mal ein spannender Aspekt: Wenn ich also eine .NET-Anwendung habe und die "Amok" läuft, dann ist das Risiko, dass sie dabei den gesamten Rechner runterreißt geringer als bei einer nativen Anwendung? Lässt sich das pauschalieren oder gibt es auch hier wieder gewisse Rahmenbedingungen, die diese Sicherheit erst ermöglichen?

**Phoenix**

@Oliver: Nein. Bereits Mitte 2008 war der

Marktanteil von Windows 2000 bei 2,25 %. Ende letzten Jahres taucht es schon gar nicht mehr in der

Auflistung der Marktanteile auf. Mit Windows XP kann ich leben, und ob nun ein- oder Mehrkernprozessor ist mir persönlich schnuppe, und auch auf 1/2 GB ram kann ich arbeiten, wobei ich der Meinung bin dass es solche Sachen im Consumer-Markt nicht mehr gibt. 2 sind wahrscheinlich schon eher Standard.

Mir geht es zudem nicht um fühlbare, sondern um faktisch messbare Performance. Von mir aus darf auch gerne jeder für sich festlegen, wo die Performance gemessen wird.

@Thom: Mein

Brötchengeber hat keine Software die Verkauft wird, sondern ist ein Dienstleister, für den ich in der R&D Abteilung arbeite. Meine Tätigkeit bei RO ist eine kleine Nebentätigkeit, der ich just for Fun nachgehe um damit ein bisschen nebenher zu verdienen. Meine Begeisterung für .NET ist rein persönlicher Natur, weil ich von der Leistungsfähigkeit der Plattform für uns Entwickler durch eigene Erfahrung massiv begeistert bin. Und da ich als alteingessener Delphianer noch ein wenig dem Object Pascal nachhänge und eh regelmäßig auf Konferenzen unterwegs war hat sich das einfach angeboten.

@Insider: Dass Du Dich darauf nicht einlassen willst ist mir klar. Nur ein "Ich behaupte es, also ist es so" lasse ich nicht gelten.
Die .NET Plattform ist eine vom System bereitgestellte Laufzeitumgebung, genauso wie die Delphi RTL eine einkompilierte Laufzeitschicht ist. Wieso eines von beiden schneller oder langsamer sein soll ist mir unklar. .NET hat gegenüber einem vollständigen nativem Kompilat den Vorteil, dass es aus einem Vorkompilat erst auf dem eigentlichen Zielsystem ein für genau dieses System optimiertes Endkompilat erzeugt welches letztlich auch in nativem Code resultiert und als solcher ausgeführt wird. Warum sollte ein für ein Zielsystem optimiertes Kompilat langsamer sein, als ein Einheitsbrei-Zeug in One-fits-it-all Size?

Ich fordere Dich auf Deine Aussage dass .NET Code langsamer sei entweder nachvollziehbar und nachmessbar zu beweisen, oder endlich aufzuhören solche Märchen zu erzählen, die jeglicher logischer (und vor allem wissenschaftlicher) Grundlage entbehren.

**Phoenix**

Zitat von Daniel:

Das ist aber mal ein spannender Aspekt: Wenn ich also eine .NET-Anwendung habe und die "Amok" läuft, dann ist das Risiko, dass sie dabei den gesamten Rechner runterreißt geringer als bei einer nativen Anwendung? Lässt sich das pauschalieren oder gibt es auch hier wieder gewisse Rahmenbedingungen, die diese Sicherheit erst ermöglichen?

Ja, diese Rahmenbedingungen sind die sogenannten Application Domains, die es in .NET gibt.
Stürzt ein .NET Programm ab, betrifft das nur die einzelne Application Domain, in der es läuft. Natürlich kann man mehrere Applications in einer Domain laufen lassen, aber man kann sie auch isolieren.

Bei ASP.NET ist es z.B. besonders interessant, da man hier mehrere Webanwendungen parallel laufen lassen kann und keine von diesen den gesamten Prozess des Webservers betrifft sondern nur die einzelne Applikation. Das funktionierte in älteren IIS-Versionen so gut, dass inzwischen mit IIS 7 und 7.5 die komplette Pipeline des IIS in Managed code läuft und sogar ISAPI-Extensions inzwischen von Managed code aus in unterschiedlichen Appdomains geladen werden, damit diese nicht den gesamten Webserver abschiessen können.

**Phoenix**

Zitat von Assarbad:

Die Frage ist nur ob man dogmatisch oder pragmatisch (egal in welcher Richtung) mit Technologien umgeht. Und mit Phoenix und Insider2004 scheinen hier zwei Dogmatiker der jeweils anderen Seite aufeinandergeprallt zu sein.

Ganz und gar nicht. Ich mag natives Delphi

Aber ich kann es auf den Tot nicht ausstehen, wenn hier jemand so penetrant einen absoluten geistigen Dünnschiss von sich gibt, der beweisbar falsch ist. .NET ist nunmal nicht pauschal 5-10 mal langsamer als nativer Code.

**Assarbad**

Zitat von Daniel:

Das ist aber mal ein spannender Aspekt: Wenn ich also eine .NET-Anwendung habe und die "Amok" läuft, dann ist das Risiko, dass sie dabei den gesamten Rechner runterreißt geringer als bei einer nativen Anwendung?

Nein. Es gibt keinen Unterschied. Relevant wäre es erst wenn eins von beiden im Kernelmode ausgeführt würde.