[jabu]

Kommt AMD also immer noch nicht von dem .NET-Ranz weg, schade.

[Multithread]

Kommt AMD also immer noch nicht von dem .NET-Ranz weg, schade.

Noch nicht ganz. nein. Allerdings haben Sie inzwischen den Teiber deutlich überarbeitet, auf den .NET Teil der AMD Settings fällt man nur noch selten zurück.

[jabu]

Noch nicht ganz. nein. Allerdings haben Sie inzwischen den Teiber deutlich überarbeitet, auf den .NET Teil der AMD Settings fällt man nur noch selten zurück.

Danke erst mal. Insgeheim hatte ich natürlich gehofft, dass sie die Abhängigkeit vom .NET schon herausgekickt hätten. Leider läuft es wieder falsch herum, weil das .NET zunehmend unproblematischer wird, schon aufgrund seiner voranschreitenden Integration in das Betriebssystem sowie wegen der immer besseren Leistungswerte der PCs. Bisher hat es sich richtig falsch angefühlt, während es künftig nicht mehr so ganz schlimm wäre.

Dass ich so gegen das .NET rante, hat natürlich seinen Grund:

Bei Rapid Prototyping/Development will man so was haben, insbesondere für verschiedenste Unternehmensbereiche. Man könnte eine müßige Diskussion darüber führen, ob es nicht vielleicht auch dafür bessere Lösungen gäbe, wenn man die Weichen einst anders gestellt hätte, was ich so sehe, aber was allgemein kontrovers diskutiert wird.

Wenn es jedoch um Treiber geht, möchte man, selbst bei einer GUI, lieber etwas haben, was weder auf vielen, fragilen, nicht unbedingt verfügbaren noch auf laufzeit- oder speicherintensiven Abhängigkeiten beruht.

Leider sind hier alle Kriterien gerissen, die ich in diesem Bereich an hochqualitative Software als Grundvoraussetzung stellen würde, bevor eine einzige Zeile Code geschrieben ist. Das gilt für die vergangenen Jahre natürlich sehr viel mehr als für die künftigen.

[Multithread]

Wenn es jedoch um Treiber geht, möchte man, selbst bei einer GUI, lieber etwas haben, was weder auf vielen, fragilen, nicht unbedingt verfügbaren noch auf laufzeit- oder speicherintensiven Abhängigkeiten beruht.

Leider sind hier alle Kriterien gerissen, die ich in diesem Bereich an hochqualitative Software als Grundvoraussetzung stellen würde, bevor eine einzige Zeile Code geschrieben ist. Das gilt für die vergangenen Jahre natürlich sehr viel mehr als für die künftigen.

Ich weiss nicht genau was du für eine Vorstellung von .NET hast, aber das was du hier schreibst, deckt sich überhaupt nicht mit meiner Erfahrung. Gerade im bereich GUI hat .NET(C#) eine Grundstabile Basis. Schlechte Abhängigkeiten sind meist von unfähigen programmierern gemacht. Genauso wie GUI blockierende aufgaben, das würden die aber auch unter C oä. verbocken.

Im gegensatz zu Durchschnittlichem C Code ist durchschnittlicher C# Code auch längst nicht mehr langsamer, im Gegenteil: Ohne Performance Optimierten C Code hat C# bei der Performance sogar die Nase vorne, genauso wie Java. Ua auch weill CPU Spezifische erweiterungen zur Laufzeit eingebunden werden, ergo kann der JIT aus dem GLeichen Code Optimierte Code versionen für AMD und Intel CPU's bauen, während C code meist nur auf einer Architektur Performant läuft.

Zb. Performance eines grossen Loops bei dem man mit jedem Element etwas macht: in C# braucht man nicht mal ne Extra Zeile um das zu Paralellisieren, wobei sich die Laufzeit umbegung dannach sogar darum kümmert wie viele Threads verwendet werden sollen, je nachdem wie der Code in der Forschlaufe aussieht.
Das kommt nicht ganz an das heran was ein guter (auf seiner Sprache) Programmierer heraushohlen kann, aber es ist mehr als wohl 90% aller Programmierer da draussen überhaupt hinbekommen würden.


Zusammenhang zum AMD Treiber: Es ist wohl mehr als nur ein Gerücht das man beim GUI neu angefangen hat, weil das alte so schlecht Programmiert war, das es mehr einem Fliockenteppich als sauberem Code gleicht.
Offiziell würde sowas niemand sagen, aber die Performance von Alt auf neu deutet genau darauf hin.

[jabu]

@ Multithread:

Ketzerische Gedanken:
Was müssen die armen Entwickler in den 90ern des letzten Jahrhunderts für Tode ausgestanden haben, als sie mit C für einen Einkerner entwickelten, wo absolut gar nichts parallelisiert wurde und dennoch die Programme schneller starteten und einen Bruchteil an CPU-Takten verbrieten und noch nicht mal einen größeren Workload als ein ganzes (damaliges) Windows hatten. Die müssen sich alle geirrt haben. Sie wussten doch noch nicht, wie toll das .NET-Framework mal sein würde, und Java war auch noch nicht erfunden, weshalb sie noch nicht verstehen konnten, welche Vorteile es hat, auf milliarden PCs massenhaft Ressourcen zu verbraten und die User in Update-Höllen zu jagen.

Die hier irren sich sicher genauso wie ich:

Crimson has been developed in QT, a cross-platform application framework that AMD says is much quicker than the old .NET framework CCC used to use. The company claims that start-up time has been reduced from eight seconds to 0.6 seconds on a mid-performance AMD E-350-based laptop; high-end desktops will be even faster.

Bei mir sind es übrigens rund 30 Sekunden Startzeit beim CCC, während die Festplatte durchweg rödelt, wenn ich es am Autostart hindere. Selbst mit Autostart sind es noch 3 Sekunden. Es braucht übrigens etwa so viel Speicher wie ein Windows 98 als reines Workload (nicht der reservierte Wert, der ist ungefähr viermal so groß).

Ich glaube dir, dass man das CCC selbst unter dem .NET noch stark verbessern könnte, aber nicht bis in die Größenordnung hinein, wie es früher mal üblich war, bevor man diesen Fimmel bekam.

So simple Programme brauchen in richtigem Maschinencode nur Mikrosekunden für den Code, den du selbst geschrieben bekommst und verharren die meiste Zeit irgendwo in den Aufrufen von System-APIs oder überfetten Frameworks, weshalb die Optimierungen, die du meinst, nicht zum Tragen kommen. Der Flaschenhals ist also in den Funktionen, die du aufrufst und bei dem darunterliegenden Betriebssystem und seinem IO, bis zum Speichermedium runter. Selber schafft ein halbwegs erfahrener Programmierer es gar nicht, so viele CPU-Zyklen zu verbraten, dass man was merkt, es sei denn, er lässt andauernd irgendwelche Dateien parsen, gibt die Handles frei, fordert neue an, öffnet dieselbe Datei nochmal, andauernd auf, Datei neu schreiben zu, wieder auf usw., etwa so elendig zäh wie Visual Studio bei der Installation. Und dort kommt das Verhalten der Frameworks wieder ins Spiel, ob sie überflüssige Aktionen veranlassen und wie sie den Entwickler unterstützen, um solche zu vermeiden.

Im Grunde sind solche Programme kaum mehr als eine Aneinanderreihung von Aufrufen an bereits fertigen Code, worin der Großteil der nutzbringenden Laufzeit liegt, weshalb dort die größten Performanceunterschiede zu finden sind. Wenn du direkt das Windows-API ansprichst oder einen schlanken Layer auf DirectX benutzt, dann ist das - unter den gegebenen Umständen - jeweils, maximal performant. Das .NET hingegen bietet komplexen Code oben drauf, weshalb das gar nicht schneller sein kann. Außerdem müssen die Assemblies in allen Lebenslagen passen, weshalb viel unreferenzierter Code mit vielen Indirektionen drin ist. Wenn du hingegen nativen Code hast, kann beispielsweise ein C- oder C++-Compiler Überflüssiges herausschmeißen, was er auch tut, wenn man es ihm nicht verbietet. Aus den .NET-Assemblies bekommst du ihn nicht mehr heraus. Das kannst du zwar zur Laufzeit optimieren lassen, aber irgendwo sitzt die Instanz, die das macht, z.B. in einem Thread. Wenn man diesen Aufwand nicht mitmisst, funktioniert diese "Selbsttäuschung" solange, wie der Gamingbolide kaum ausgelastet ist. Auf ganz normalem Alltagsgerät sind die Grenzen hingegen sehr schnell erreicht. Aber selbst der Bolide hätte ein Problem, wenn die ganzen anderen Programme auf derselben Technologie aufsetzen würden. Kleinvieh macht eben doch Mist.


Benchmarkergebnisse mit wenig Praxisrelevanz, wie man sie kennt, kann man z.B. so erhalten:

Fall 1, Parallelisierung von Loops
Es wird dabei gerne ausgeklammert, dass

a) Loops in realen Programmen sich meistens nicht zum Parallelisieren eignen, weil sie auf den Werten aufbauen, die sie selbst brauchen, ganz typisch, indem die innere Loop die Werte aus der äußeren weiterverarbeitet. Wenn du das als parallelisiert schneller hinbekommst, solltest du dich fragen wollen, was der ganze Senf überhaupt in der Loop zu suchen hat. Wo es sich trotzdem lohnt, sollte es sich auch lohnen, einen Thread hinzuschreiben, weil es in den meisten Anwendungen nur ein oder zwei von solchen fetten Loops gibt, wo es sich erkennbar auswirkt. Diese Loops sind dann meistens richtig fett, weshalb es auch wieder egal ist, wie hochoptimiert oder doch nicht die Threads zusammenarbeiten. Dieser häufige, mittlere Fall, sodass die ganze Anwendung profitiert, ist sehr selten. Wenn du ständig Strings, Arrays, Strukturen oder Listen umkopieren bzw. konvertieren musst, weshalb sich ein separater Thread dafür lohnt, solltest du dich fragen, was deine Architektur taugt. In Einzelfällen mag es trotzdem gerechtfertigt sein, aber das sind nicht die Flaschenhälse simpler GUIs, mit denen man ein paar Settings macht.

b) das Programm schon länger zum Starten braucht.

c) die Ressourcen zum Optimieren wegbrechen, wenn es an reale Anwendungen geht, die genügend Last produzieren oder mit anderen konkurrieren.


Fall 2, Vergleich unter Verwendung von Libs:

Man vergleicht Library-Funktionen und zieht z.B. so eine von C heran, welche die Länge der Zeichenkette immer wieder erneut ermitteln muss, als ob das alternativlos wäre.
Oder man nimmt eine der Containerklassen aus C++ und nutzt aus, dass die in üblichen Implementierungen nicht viel Heapspeicher im Voraus alloziieren lassen, als ob auch das alternativlos wäre.
Wie leicht man sich in C oder C++ eine eigene Speicherverwaltung machen kann oder wie leicht man in C++ das Verhalten beeinflussen kann, wird natürlich ausgeblendet und ebenso, dass man direkten Zugriff auf den Stack hat, wo das Problem gar nicht besteht. Andere Sprachen, andere Paradigmen, Äpfel mit Birnen und so.

Natürlich schreitet die Technik voran, Parallelisierungsoverhead wird reduziert, sodass die Optimierungen bei Managed Code besser greifen können und was weiß ich noch, sodass du irgendwann alles in Managed machen kannst. Vielleicht ist die Performance, über alles gesehen, dann sogar besser. Aber worüber wir hier reden, ist doch etwas anderes, weil eben Maschinencode, den du für ein solches GUI schreibst, in Mikrosekunden abgelaufen ist, während der Rest in den Frameworks verbleibt, wo es einen großen Unterschied macht, was du verwendet. Derzeit ist das .NET selbst noch nicht so hochoptimiert, wie man es gerne hätte, was irgendwann kommen mag, streite ich gar nicht ab.

Ich weiss nicht genau was du für eine Vorstellung von .NET hast, aber das was du hier schreibst, deckt sich überhaupt nicht mit meiner Erfahrung. Gerade im bereich GUI hat .NET(C#) eine Grundstabile Basis. Schlechte Abhängigkeiten sind meist von unfähigen programmierern gemacht.

Selbst wenn die den besten Job der Welt gemacht hätten, ist ein Abhängigkeitsgehörn (CLI/.NET selbst), welches auch noch fetten Updatepaketen unterliegt und nicht zu den Kernkomponenten eines Betriebssystems gehört und sich der Kontrolle des Anwendungsentwicklers entzieht und bei Versagen ansonsten nicht mal auffällt, niemals so robust wie direkte Aufrufe an so grundlegende Komponenten wie z.B. kernel32.dll, user32.dll und gdi32.dll. Natürlich ist auch QT bereits viel zu fett, aber noch wenig im Vergleich zum .NET.

Genauso wie GUI blockierende aufgaben, das würden die aber auch unter C oä. verbocken.

Dieser .NET-Gedenkmoment ist in allen .NET-Anwendungen drin. Ich stimme aber mit dir überein, dass man das trotzdem auch mit dem .NET noch um einiges verbessern kann.

Im gegensatz zu Durchschnittlichem C Code ist durchschnittlicher C# Code auch längst nicht mehr langsamer, im Gegenteil: Ohne Performance Optimierten C Code hat C# bei der Performance sogar die Nase vorne, genauso wie Java.

Es gibt aber bei C sowie bei C++ keinen performancekritischen Code, bei dem die Optimierungen des Compilers abgeschaltet sind. Dann ist es ein Versehen, Bug, oder wie man es auch immer nennen mag. Optimierungen unter C oder C++ sind was ganz anderes als die von einem JIT, indem so viele Entscheidungen wie möglich zur Kompilierzeit getroffen werden, sodass der Codehaufen auf das effizienteste oder kleinste Maß abgeschmolzen wird, je nachdem, wie smart der Compiler ist. Hinten fällt der Maschinencode heraus, Overhead zur Optimierung während der Laufzeit ist unnötig und sogar kontraproduktiv.

Wenn du für QT eine Lizenz erwirbst, dann darfst du statisch linken, sonst nicht. Beim statischen Linken, ist es üblich, dass viele Optimierungen auf die Linkzeit verschoben werden, weshalb diese sogar über die Grenzen der Libraries hinweg greifen können, sodass die komplexen Abstraktionen mit ihren bedingten Indirektionen zerfallen können. Unter den GNU-Tools funktioniert LTO leider nicht so richtig, aber bei Microsoft ganz ausgezeichnet.

Die meiste Laufzeit wird in irgendwelchem Library- oder Framework-Gehörn (und darunter, eine andere Baustelle) verbraten, weshalb es also umso besser ist, wenn in der ausführbaren Datei nicht viel mehr landet, als was man wirklich braucht. Schlanke Anwendungen, die besonders zuverlässig sein und trotzdem nicht die Festplatte vollspammen sollen, will man derart statisch linken und einkondensieren lassen. Das ist genau die richtige Strategie für einen Treiberdialog. Andere können es doch auch.

Ich will nicht erst ein Betriebsystem im Betriebsystem booten müssen, um mal einen Haken zu setzen. Welche theoretischen Höchstleistungen danach in gestellten Szenarien möglich sind, ist irrelevant.

Ua auch weill CPU Spezifische erweiterungen zur Laufzeit eingebunden werden, ergo kann der JIT aus dem GLeichen Code Optimierte Code versionen für AMD und Intel CPU's bauen, während C code meist nur auf einer Architektur Performant läuft.

Auch bei Maschinencode können Weichen einkompiliert werden. Aber ich stimme zu, dass ein JIT viel flexibler ist und dass auch ältere Programme dann von einem verbesserten JIT profitieren könnten. In manchen Szenarien mag das dann die Nase vorn haben, künftig mehr als heutzutage. Allerdings sind das, wie gesagt, nicht die Flaschenhälse. Wenn der JIT so smart ist, das er die .NET-Assemblies komplett vorausoptimiert, soweit das möglich ist, dann braucht er dafür Zeit und Ressourcen, was beim ersten Durchlauf stört und erst beim zweiten hilft. Eine andere Anwendung referenziert aber anderen Code aus denselben Assemblies auf andere Weise, was Optimierungen über die Schnittstellengrenzen hinweg selbst theoretisch nicht bei ersten Durchgang ermöglicht, während statisches Linken mit LTO (Link Time Optimization) unter C oder C++ ganz gewöhnlich ist.

Zb. Performance eines grossen Loops bei dem man mit jedem Element etwas macht: in C# braucht man nicht mal ne Extra Zeile um das zu Paralellisieren, wobei sich die Laufzeit umbegung dannach sogar darum kümmert wie viele Threads verwendet werden sollen, je nachdem wie der Code in der Forschlaufe aussieht.
Das kommt nicht ganz an das heran was ein guter (auf seiner Sprache) Programmierer heraushohlen kann, aber es ist mehr als wohl 90% aller Programmierer da draussen überhaupt hinbekommen würden.

Alles durchaus beeindruckend und klug, dennoch:
*Freundlich Hüstel*.

Die würde ich nicht unterschätzen wollen, denn in anderen Sprachen werden andere Paradigmen verfolgt. Ein C oder C++-Programmierer hat immer Heap, Stack, Pointer und manchmal auch Alignment (und mit alldem implizit Performance) im Hinterkopf, was bei einem C#-Programmierer nicht zu den direkt beeinflussbaren Größen gehört. Ein C- oder C++-Programmierer ist sehr viel mehr daran gewöhnt, sich seine Abstraktionen selbst zu stricken (obwohl es inzwischen reichlich fertige gibt), was anstrengend sein kann. Wegen der anderen Arbeitsweise sind das auch eher Projekte mit langen Lebenszyklen (wo viel an Details optimiert wure). Deswegen lohnt es sich auch gerade für Treiberdialoge, welche von ihrem Grundaufbau her mal ein Jahrzehnt oder länger halten können. C++ ist nicht gut für kurzlebige Projekte geeignet, weil eine genügend mächtige Klassenbibliothek mit kurzer Einarbeitungszeit fehlt. Es liegt also gar nicht an der Sprache selbst. Hingegen bietet das .NET all dieses, und C# hat reichlich Sicherheitsgurte, die einem vor den eigenen Fehlern bewahren. Das ist wegen des leichten Eintiegs und weil alles fertig vor einem liegt, verführereisch (und manchmal sogar gut), aber trotzdem nicht immer, was man will.

Zusammenhang zum AMD Treiber: Es ist wohl mehr als nur ein Gerücht das man beim GUI neu angefangen hat, weil das alte so schlecht Programmiert war, das es mehr einem Fliockenteppich als sauberem Code gleicht.
Offiziell würde sowas niemand sagen, aber die Performance von Alt auf neu deutet genau darauf hin.

Vielleicht hat man wegen der beabsichtigten Portierung mal alles auf den Prüfstand gestellt und ist zu ungefähr denselben Schlüssen gekommen, wie ich sie dargelegt habe. Auch die Verteilung, jeweils im Rahmen der Portierung, dürfte mit QT weitaus unproblematischer als mit dem .NET ausfallen.

[Multithread]

Ketzerische Gedanken:

Bedenke: Mehrkernprozessoren kamen erst vor 10 Jahren langsam auf (beim Endkunden). Bis dahin konnte mit Multithreading in dem Bereich kein Leistungsgewinn erziehlt werden.
Der rest ist aber so, gute C Programme dürften immer schneller sein als JIT Code.

Ich beneide die Leute die C können etwas. Versuche gerade C nach CL99 zu lernen, bzw. C# code in solchen Parallel Code umwandeln.
aber wenn Ich dann so dinge sehe wie: Ideale Vektorgrösse: 8, dann kratze Ich mir als C# Entwickler mächtig am Hinterkopf, insbesondere wie man C# Code dahingehend Optimieren soll

Die hier irren sich sicher genauso wie ich:

Das bestreitet niemand. Beim CCC ist einiges schief gelaufen bei der Entwicklung. Ist vermutlich sogar einer der Letzten Treiberteile die noch von ATI Zeiten her mitgeschleift werden.

Ich glaube dir, dass man das CCC selbst unter dem .NET noch stark verbessern könnte, aber nicht bis in die Größenordnung hinein, wie es früher mal üblich war, bevor man diesen Fimmel bekam.

Ich würde das nicht unbedingt bezweifeln. Heutige Software ist mMn einfach überladen. Wenn man aber Software macht die aufs wesentliche reduziert ist, gibt es einen Aufschrei wo denn die ganzen schönen gimmiks abgeblieben sind.

Und mir ist bewusst das C# eben for dem starten selber erstmal den JIT hochfahren und anwerfen muss. Danach ist aber der Code und die Performance sehr ähnlich(Geschwindigkeit variiert je nach Entwickler) wie das was bei einem C Programm am ende raus kommt.

So simple Programme brauchen in richtigem Maschinencode nur Mikrosekunden für den Code, ...

Nein, das .NET startet eben keinen Komplexen Code oben drauf wie es zb. Javascript lange zeit tat (das wird heute auch Precompiled). Sondern Compiliert lediglich den Zwischencode in Maschinencode. Dort ist ganz klar ein Overhead, je nach Programmgrösse auch ein ziemlich grosser (ne leere C# .exe ist 10KB gross). Das passiert aber pro Assembly im normalfall nur einmal.
Überflüssiges wird da in 2 schritten entfernt: Beim Komilieren in .NET Code, dort wird nur ganz grob Optimiert. Um die eigentliche Optimierung muss sich das JIT Team kümmern, und die entfernen dann genauso groszügig Code wie ein C Compiler.

Ich weiss auch nicht wie weit du Programmierst. Ich bin aktuell in der Webentwicklung mit asp.net Tätig. Wenn der IIS irgendwann dann mal läuft, hat man relativ schnell ne brauchbare Webside zusammen. Grössere Projekte darin sind aber dennoch alles andere als einfach.

Unser IIS braucht 10-12 Sekunden zum Starten, plus weitere sekunden um den Copde nachzukompilieren (echte aspx seiten brauchen extrem lange bis Sie mal Kompiliert sind: ca 3 Stück /Sekunde möglich).
Danach liegt die schlechte Performance aber fast nur noch am Entwickler welche überhaupt kein Auge für Performance mehr hat (zb. Funktionen innerhalb eines loops aufrufen, welche man nur einmal aufrufen müsste).
Wir sind 5 Entwickler, aber wenn es darum geht Performance Löcher zu finden, kommen alle zu mir Dabei schaue Ich nur welche Funktions/Property aufrufe lange dauern und Prüfe ob die wirklich so oft aufgerufen werden müssen. Performanceoptimierung auf hoher Ebene, das könnte wohl jeder. Das ist dann manchmal nur noch Kopf -> Tisch, aber man bleibt ja freundlich

Sind 10-15 Ticks für das auslesen eines wertes aus einem Dictionary eigentlich ein guter Wert in C?

Benchmarkergebnisse mit wenig Praxisrelevanz, wie man sie kennt, kann man z.B. so erhalten:

Fall 1, Parallelisierung von Loops
Es wird dabei gerne ausgeklammert, dass ....

a. Ist mir jetzt doch eher selten so ein Loop in die Finger gekommen, also einer der unbedingt auf den Vorherigen Ergebnissen aufbauen muss. Viel öfters muss man doch einfach für jedes Element in einer Liste das gleiche machen. Zumindest meiner Erfahrung nach (bisher erst 3 Firmen).

b. Das ist natürlich ganz mies

c. Wie oben erwähnt: der JIT Optimiert im normalfall nur einmal, danach hast du Maschinencode, welcher dem Code eines C Compilers sehr ähnlich ist (beim gleichen Programm).
Punkt b bleibt damit natürlich bestehen und wird sogar eher verschärft.

Fall 2, Vergleich unter Verwendung von Libs:
...

Ich glaube nicht das man .NET selbst noch so massig Optimieren kann, vermutlich ist das erstellen des Maschinencodes schon sehr stark optimiert.
Da sehe Ich viel mehr Potenzial beim Entwickler. Findest du es eine gute Idee den aufbau des GUI's zu blockieren bis das schöne hintergrundbild geladen ist? Nein? Dann wind wir schon 2. Genau das scheinen aber viele C# Entwickler zu machen.

Gleiches bei Datenbankzugriffen: die müssen nicht alle nacheinander ablaufen, und alles was man dort paralell (async ist in dem Fall auch io) macht, spart gerne mal ne halbe ms, trotz zusätzlichem Overhead. einfach weil die Verbindung zur Datenquelle so langsam ist (gilt eigentlich für alle Datenquellen).

Eine eigene Speicherverwaltung, sowas möchtest du nicht von einem C# Entwickler, das wäre extrem unperformant.

Ich weiss Nicht wie viele 10k Linien kollisionen Ich im C# berechnen konnte pro Sekunde, es waren aber einige, obwohl Ich keine Ahnung habe wie man so eine Berechung Optimiert, der Code ist also auch entsprechend ineffizient. Parallelisiert ist dabei auch noch nichts.

PS: Ich weiss das Ich zu dem Punkt etwas abgeschweift bin, das mit den Bibliotheken ist in .NET so ne Sache, Was man dort hauptsächlich benutzt sind hochsprachen Bibliotheken welche bereits ganz bestimmte aufgaben erleichtern/abnehmen, da der rest bereits im .NET drin ist.

Es gibt aber bei C sowie bei C++ keinen performancekritischen Code, bei dem die Optimierungen des Compilers abgeschaltet sind. Dann ist es ein Versehen, Bug, oder wie man es auch immer nennen mag. Optimierungen unter C oder C++ sind was ganz anderes als die von einem JIT, indem so viele Entscheidungen wie möglich zur Kompilierzeit getroffen werden, sodass der Codehaufen auf das effizienteste oder kleinste Maß abgeschmolzen wird, je nachdem, wie smart der Compiler ist. Hinten fällt der Maschinencode heraus, Overhead zur Optimierung während der Laufzeit ist unnötig und sogar kontraproduktiv.

Ich denke genau darin dürfte der unterschied zwischen Nativer Kompilierung und JIT Sprache liegen: die Art der Optimierung.
Native Kompilate kommen bereits sehr effizient daher, da kann man In Time nichts mehr verbessern, oder nicht ohne übermässig grossen Aufwand.
KIT Sprachen dagegen Kompilieren Code so das er für die Ausfühtrung Optimiert ist, dadurch wird an anderer stelle Optimiert. JIT Sprachen können zur Laufzeit zb. if's entfernen, welche eine Bedingung nie erreichen können, was ein Pre Laufzeit Kompiler ev. nicht erkennen kann. Und können Architekturspezifische Funktionen voll ausnutzen. Dafür gibt es aber den genannten Overhead und einige Optimierungen bezüglich Speichermanagement fallen schlechter aus als wenn das in C oä. gut gemacht wurde. Und der GC braucht auch ab und an mal etwas Performance.

Die meiste Laufzeit wird in irgendwelchem Library- oder Framework-Gehörn (und darunter, eine andere Baustelle) verbraten, weshalb es also umso besser ist, wenn in der ausführbaren Datei nicht viel mehr landet, als was man wirklich braucht. Schlanke Anwendungen, die besonders zuverlässig sein und trotzdem nicht die Festplatte vollspammen sollen, will man derart statisch linken und einkondensieren lassen. Das ist genau die richtige Strategie für einen Treiberdialog. Andere können es doch auch.

Ich habe wirklich keine Ahnung was sich manche dabei denken. Aber Ich sehe das eher so das solche Probleme sprachunabhängig sind, es kommt viel mehr auf das Entwicklerteam dahinter an ob eine Anwendung nur schnell oder langsam ist.

Performance Optimierungen werden heute in der IT-Schule nicht mehr gelehrt, da die CPU's "genügend" Power haben das man sich darum nicht kümern muss. Was seid Jahren eine welle Entwickler auf die Welt loslässt, welche von schnellem Code keine Ahnung haben.

Alles durchaus beeindruckend und klug, dennoch:
*Freundlich Hüstel*.

Das wusste Ich schlicht und ergreifend nicht

Vielleicht hat man wegen der beabsichtigten Portierung mal alles auf den Prüfstand gestellt und ist zu ungefähr denselben Schlüssen gekommen, wie ich sie dargelegt habe. Auch die Verteilung, jeweils im Rahmen der Portierung, dürfte mit QT weitaus unproblematischer als mit dem .NET ausfallen.

Das weiss Ich nicht, dürfte aktuell aber ziemlich sicher so sein.

So wie es aussieht dürfte m$ mit .NET aber eine Vollständige Platformunabhängigkeit anstreben. Zumindest wenn man sieht das inzwischen fast der gesamte Code zu .NET auf github öffentlich verfügbar ist.

[Lookbehind]

...
PS: Kann ein Mod bitte die letzten 5? Posts in den OT Thread verschieben, das gehört hier nicht mehr hinein. (und bitte diese Notation entfernen)

Besser:
Einen eigenen Thread draus machen und ins Webdesign und Programmierung schieben. Finde die Diskussion nämlich durchaus interessant.

[Juli Karen]

Auf Wunsch in eigenen Thread ausgelagert - ohne Notation, Multi .

Mir fiel kein besserer Titel ein, zur Not ändern lassen

[Kellendil]

Performance Optimierungen werden heute in der IT-Schule nicht mehr gelehrt, da die CPU's "genügend" Power haben das man sich darum nicht kümern muss. Was seid Jahren eine welle Entwickler auf die Welt loslässt, welche von schnellem Code keine Ahnung haben.

Und die stattdessen vermehrt Testing, Projekt Managment (Agile), Software Design und vor allem "How to choose & glue existing libraries together and slap a GUI on the result" lernen. Was Sinn macht, weil wartbarer Code immer wichtiger wird und "schnellen Code schreiben" mittlerweile eine "Spezialisierung" innerhalb der Informatik/IT ist.

Wenn eine Firma ein Team aus 10 Leuten zusammen stellt, und sie haben 2 Moeglichgeiten: 9 Leute koennen besonders wartbaren Code schreiben, 1er besonders schnellen Code, oder andersrum (9 Leute schnellen, einer wartbar), ist klar was langfristig billiger ist: Hardware vs Maintanance => Maintenance teurer. Also wird das gelehrt, was die Wirtschaft verlangt.

[Multithread]

Wenn eine Firma ein Team aus 10 Leuten zusammen stellt, und sie haben 2 Moeglichgeiten: 9 Leute koennen besonders wartbaren Code schreiben, 1er besonders schnellen Code, oder andersrum (9 Leute schnellen, einer wartbar), ist klar was langfristig billiger ist: Hardware vs Maintanance => Maintenance teurer. Also wird das gelehrt, was die Wirtschaft verlangt.

Auch die erste möglichkeit kann ne Firma in den Ruin treiben, nämlich dann wenn die Kunden wegen der mässigen Performance abspringen.
In meinem Praktikumsbetrieb sind deswegen zwei sehr grosse Kunden abgesprungen. Damit ist dann dem Geldbeutel auch nicht gedient.

Wie du oben geschrieben hast: Gerne wird für schnelle Resultate bei der Performance geschlampt,. Wir haben selber aktuell zwei Baustellen bezüglich Performance. Sowas kann den ganzen guten ersten Eindruck der Software zertören.

Dennoch gebe Ich dir in einem Punkt recht: Man sollte zuerst warbaren Code schreiben und diesen dann Optimieren (das muss man beim schreiben aber im Hinterkopf behalten, ansonsten gibts später probleme), das ist besser als Optimierten Code zu schreiben und diesen danach zu warten.

[Kellendil]

Auch die erste möglichkeit kann ne Firma in den Ruin treiben, nämlich dann wenn die Kunden wegen der mässigen Performance abspringen.
In meinem Praktikumsbetrieb sind deswegen zwei sehr grosse Kunden abgesprungen. Damit ist dann dem Geldbeutel auch nicht gedient.

Aber lag das daran, dass euer eigener Code einfach langsam war, oder an langsamen/ungeeigneten Libs/Technologien die verwendet wurden bzw. falsche Hardware? Ich vermute, dass sowas eher der Grund sein wird (falsche Technologie benutzt) als "ineffizienter selbstgeschriebener Code". Und die richtige Technologie zu waehlen oder zumindest zu vergleichen ist auch zumindest bei mir im Studium eine Sache die gelehrt wird.

[Whiz-zarD]

Und die stattdessen vermehrt Testing, Projekt Managment (Agile), Software Design und vor allem "How to choose & glue existing libraries together and slap a GUI on the result" lernen. Was Sinn macht, weil wartbarer Code immer wichtiger wird und "schnellen Code schreiben" mittlerweile eine "Spezialisierung" innerhalb der Informatik/IT ist.

Wenn das so wäre, wäre ich froh.
Wenn ich aber so einige Startups sehe, habe ich das Gefühl, dass man eher mit Hackerbuden zu tun hat, anstatt mit professionellen Entwicklern. Aufs Testen wird gerne zu Gunsten der Agilität verzichtet und man produziert lieber Banenensoftware (Reift beim Kunden).
Sowas wie TDD kennt doch keine Sau. Höchstens nur vom Hörensagen, aber praktisch eingesetzt haben dies die wenigen. Selbst Unittests machen nur sehr wenige Firmen. Und ja, es macht heutzutage mehr Sinn, bestehende Bibliotheken zu verwenden, als ständig das Rad neuzuerfinden.

Die Firma, in der ich arbeite, verwendet ebenfalls C# als Hauptsprache und wir haben keinerlei Performance-Probleme, die durch .NET geschuldet wären, sondern eher durch die Design-Fehlentscheidungen, die man damals getroffen hatte, weil einige Entwickler damals meinten, sie wären schlauer als die Entwickler von Oracle und haben einen OR-Mapper selbstgebaut und haben sogar die Fremdschlüssel-Implementierung im OR-Mapper nachgebildet. Ja, die Validierung der Fremdschlüsseln wurde im OR-Mapper abgebildet, weil man meinte das wäre performanter, wenn der Client dies übernimmt, anstatt die Daten erst zur Datenbank zu schicken... Die Software ist ein sehr gutes Beispiel, wieso man lieber zu existierende Bibliotheken greifen sollte, anstatt das Rad neuzuerfinden. Selbst Microsoft musste sich eingestehen, dass ein OR-Mapper gar nicht mal so einfach ist und haben ihr Entity Framework komplett über den Haufen geworfen.

Ich halte es also nicht für verkehrt, bestehende Bibliotheken zu nehmen, denn hier bekommt man eine Lösung für ein Problem. Wieso sollte man so etwas nicht nutzen wollen? Das hat auch nicht unbedingt was mit schnellgeschrieben Code zu tun, sondern auch damit, dass der Code schon erprobt und getestet wurde und einen recht stabilen Status erreicht hat. Man kann sich also schon relativ sicher sein, dass der Code das macht, was man will und man kann sich um sein eigentliches Tagesgeschäft kümmern. In meinem Fall wäre es z.B. die Implementierung der Kennzahl-Berechnungsalgorithmen der Ratingagenturen. Ich möchte nicht erstmal ein OR-Mapper entwickeln, damit ich die Daten aus einer Datenbank in lesbarer Form bekomme, sondern möchte einfach einen OR-Mapper verwenden. Wozu dann also einen OR-Mapper selbst bauen? Auch möchte ich die Kennzahlen in das Excel-Template der Ratingagenturen schreiben und möchte nicht erstmal mich wochenlang damit rumschlagen, wie man nun Daten in eine Excel-Datei übertragen kann, denn das ist sogar mit dem Office Open XML SDK von Microsoft gar nicht mal so trivial. Alternativ könnte man zwar auch die COM-Schnittstelle verwenden und Excel im Hintergrund starten und per COM-Schnittstelle die Werte übertragen, aber dieser Weg wird auf einem Server nicht empfohlen. Es macht auch kein Sinn, das Office Open XML-Format selbst zuimplementieren. Das schaffen nicht mal die Entwickler von Open-/LibreOffice. In diesem Fall ist man dann sogar froh, wenn man auf Bibliotheken von Drittanbietern zurückgreifen kann, denn die vereinfachen die Lage ganz enorm.

Mag sein, dass man in den 80ern und 90ern lieber zu selbstgeschriebenen Bibliotheken tendiert hat, weil man es so schreiben kann, wie man es gerade braucht, aber die Softwareentwicklung ist heutzutage viel komplexer und schneller geworden, sodass man sich gar nicht sicher sein kann, was morgen gebraucht wird. Daher macht es in vielen Fällen keinen Sinn, eine eigene Bibliothek zu schreiben, die zwar die Anforderungen von Heute erfüllt, aber morgen schon veraltet ist oder etliche Bugs besitzt, weil man diverse Sonderfälle nicht berücksichtigt hat.

[Kellendil]

Wenn das so wäre, wäre ich froh.
Wenn ich aber so einige Startups sehe, habe ich das Gefühl, dass man eher mit Hackerbuden zu tun hat, anstatt mit professionellen Entwicklern. Aufs Testen wird gerne zu Gunsten der Agilität verzichtet und man produziert lieber Banenensoftware (Reift beim Kunden).
Sowas wie TDD kennt doch keine Sau. Höchstens nur vom Hörensagen, aber praktisch eingesetzt haben dies die wenigen. Selbst Unittests machen nur sehr wenige Firmen.

Ja, ob die Firmen/Startups das Einsetzen ist die eine Sache. Aber zumindest bei uns im Studium wird TDD gelehrt und wir haben dieses Semster ein Projektfach, in dem wir TDD einsetzen sollen. Inklusive Website-GUI-Testing. Wobei das bei uns relativ sinnlos ist, weil sich unsere Spezifikation ueber das Projekt hinweg aendern kann, je nachdem wie viel wir schaffen. Ohne feste Spezifikation/Anforderungen stelle ich mir TDD unpraktisch vor.

[Lookbehind]

Ja, ob die Firmen/Startups das Einsetzen ist die eine Sache. Aber zumindest bei uns im Studium wird TDD gelehrt und wir haben dieses Semster ein Projektfach, in dem wir TDD einsetzen sollen. Inklusive Website-GUI-Testing. Wobei das bei uns relativ sinnlos ist, weil sich unsere Spezifikation ueber das Projekt hinweg aendern kann, je nachdem wie viel wir schaffen. Ohne feste Spezifikation/Anforderungen stelle ich mir TDD unpraktisch vor.

Es hilft schon mal enorm welche zu haben. Wenn ihr eure Struktur nicht ganz blöd aufstellt, ist es auch ein vertretbarer Aufwand die Spezifikationen später zu ändern. Hauptsache ihr habt auch welche! Erlebe ich nämlich leider auch immer wieder. "Ja schreib doch mal Tests für dieses Programm hier" *Quellcode reich* "Ja, und was soll das können? Dokumentation? Spezifikation? ...?" "Ja, du hast doch den Quellcode."

[Multithread]

Aber lag das daran, dass euer eigener Code einfach langsam war, oder an langsamen/ungeeigneten Libs/Technologien die verwendet wurden bzw. falsche Hardware? Ich vermute, dass sowas eher der Grund sein wird (falsche Technologie benutzt) als "ineffizienter selbstgeschriebener Code". Und die richtige Technologie zu waehlen oder zumindest zu vergleichen ist auch zumindest bei mir im Studium eine Sache die gelehrt wird.

Nein, das Hautpproblem ist effektiv schlechter selbst geschriebener Code. die meisten Bibliotheken sind performant genug für das was Sie machen sollen.

Probleme gibt es hauptsächlich bei: DB/File abfragen und Schlaufen, welche mehr machen als sie müssten.

[magges]

Ich war dieses Jahr auf der JavaLand und habe an dem Vortrag "JVM Deepdive" teilgenommen und ich muss sagen es ist echt erstaunlich wie die Runtimes funktionieren und was sie alles optimieren, bzw. wie performant trotzdem alles ist.

Hier gibt es noch eine Niederschrift wie grob die CLR funktioniert. Ist zwar aus 2007 aber überaus interessant und empfehlenswert!