Wow. Ich merke ihr entwickelt für ein komplett anderes Marktsegment. Wenn bei uns ein großer Kunde sagt daß sie gern eine Lösung für's komplette Netzwerk hätten und dort Windows 2000 das Ausschlußkriterium auf unserer Seite wäre, dann wäre das Geschrei aber groß. Ja, wenn bei insgesamt 2000 Rechnern zwei dabei sind die Windows 2000 haben, dann wäre dies genug unserer Produkt nicht zu nehmen.
Und Statistiken glaube ich ohnehin nur wenn ich sie selber fälschen dufte.
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.
Bei
neuen Rechnern ganz sicher. Und genau darauf wollte ich hinaus.
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.
Sobald sie fühlbar wird, ist sie einfach auch ohne Profiler objektiv meßbar. Nicht mehr und nicht weniger war in dieser Aussage enthalten.
Die .NET Plattform ist eine vom System bereitgestellte Laufzeitumgebung, genauso wie die Delphi
RTL eine einkompilierte Laufzeitschicht ist.
Irrtum. Das ist sie erst seit Windows Vista. Wenn du dich so intensiv damit beschäftigt hast, sollte dir dies bewußt sein.
Wieso eines von beiden schneller oder langsamer sein soll ist mir unklar.
Mehr Abstraktion, weniger Abstraktion ... eigentlich mit der von dir zitierten Logik einfach zu begreifen
.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?
Hohoho. Jetzt mal langsam. Entweder wir reden hier von nativen Anwendungen oder wir reden von Delphi-Anwendungen. Leg dich mal fest.
Es gibt genügend Compiler die in der Lage sind sehr gut optimierten Code zu erzeugen. Es gibt sogar "CPU-Weichen" in derlei optimiertem Code. Einfach mal nen Disassembler zur Hand nehmen und selber gucken ...
Wenn Delphi das alles nicht so perfekt beherrscht, ist dies noch kein Argument
für deine Behauptung
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.
Was aber nichts mit Systemabstürzen zu tun hat, denn dazu existieren ganz andere Mechanismen für die man sich ein wenig mit dem Windows-Kernel beschäftigen sollte.
Wenn ich unfair wäre, würde ich noch schnell ein paar der Mechanismen erwähnen, die dann greifen wenn das System wenig Speicher hat. Und daß das .NET Fx dafür der Grund sein könnte, würde ich dann ganz unschuldig anfügen ...
Aber es geht uns ja hier darum die Wahrheit herauszuarbeiten ...
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.
Pauschale Aussagen sind immer Unsinn, aber die Kernaussage war, daß .NET-Code langsamer läuft. Und mit einem hinreichend genauen Profiler ließe sich dies auch nachweisen, nur kenne ich leider keinen Profiler der die .NET-VM als das betrachtet was sie ist und bei dem man dann die Messungen absolut auf gleicher Ebene (nämlich
Win32) durchführen könnte. Nur damit ließen sich derlei Aussagen entkräften oder unterstützen.
Wobei eine Art Supervisor die Applicationen überwacht hat und gnadenlos rausgekickt hat, wenn sie sich nicht benehmen konnten.
Klingt ein wenig nach dem Microkernel-Prinzip.