Laden...

Transition von x86 auf Arm

Erstellt von P.St. vor einem Jahr Letzter Beitrag vor 9 Monaten 1.174 Views
P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor einem Jahr
Transition von x86 auf Arm

Hi,

dass Microsoft auch für das .NET Framework den nativen Support für Arm64 anbietet könnte der Beginn einer neuen Ära sein. Ich hoffe, dass demnächst (zumindest auf dem Laptop-Markt) alle x86-Systeme ersetzt werden (so wie es aktuell Apple macht mit "Apple Silicon"), unserer Umwelt zuliebe. Wichtig ist dabei, dass möglichst viel Software auch für Arm gebaut wird, damit sie nicht emuliert werden muss - was natürlich Performance-Einbußen mit sich ziehen würde.

Meine aktuelle Software (noch auf .NET Framework 4.0) werde ich auf die aktuelle Version 4.8.1 migrieren, damit ich auch native Arm-Builds anbieten kann. Ich habe mir dazu gerade ein gebrauchtes Samsung Galaxy Book Go mit Snapdragon CPU und Windows 11 für 200€ gekauft (in Zukunft wird es dann vermutlich ein MacBook mit Windows 11 Arm und Parallels).

T
2.219 Beiträge seit 2008
vor einem Jahr

x86 wird so schnell nicht verschwinden und auch durch .NET Support für Arm64 wird sich daran nicht viel ändern.
Solange Unternehmen auf uralte Software setzen, die es nur für x86 gibt, wird man auch weiterhin x86 verwenden müssen.

Aber der Support ist denoch was feines.
Vermutlich aber auch zwigend nötig, wenn Microsoft zukünftig mehr als ARM setzen will.
Leider ist dies Hardware an sich von Microsoft Top aber mangels Software Support ist es immer noch eine Nische.
Daran hat sich in den letzten 10 Jahren nicht viel geändert, hier gibt es einfach das Henne Ei Problem zwischen Hard- und Software.

Nachtrag:
Dazu passend auch der Heise Artikel.

Pflegenotstand

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

6.911 Beiträge seit 2009
vor einem Jahr

Hallo P.St. ,

alle x86-Systeme ersetzt werden ..., unserer Umwelt zuliebe

Kannst du diese Aussage begründen?
Ich finde "x86 ~ nicht gut für die Umwelt" etwas vereinfacht.

werde ich auf die aktuelle Version 4.8.1 migrieren

Falls schon migriert wird, so schau dir auch .NET 7 bzw. Erste Preview von .NET 8 an.
Dort ist die Unterstützung für Arm(64) wesentlich besser. Da es insgesamt, also auch für x86, Verbesserungen zu .NET Framework (4.x) gab sollte das der Umwelt auch zu liebe kommen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
2.219 Beiträge seit 2008
vor einem Jahr

Das Umwelt Argument ist im Endeffekt ein Effizienz Argument.
Bei ARM ist eben die Leistung pro Watt besser.
Gerade bei den Apple CPUs mit ARM zeigt sich, wie effizient die Kerne sind bei geringem Energiebedarf.
Insgesamt ist ARM hier definitiv sparsamer.

Ob eine Ersetzung aller x86 Maschinen durch ARM die Umwelt wirklich entlastet, halte ich für einen Trugschluss.
Vorher wäre es vermutlich hilfreicher Fahr- und Flugzeuge sowie Schiffe abzuschaffen, die noch Brennstoffen (Benzin, Diesel, Kerosin) benötigen.
Ebenfalls müsste man den gesamten Industriesektor umbauen um kein CO2 mehr zu produzieren.
Das dürfte wesentlich hilfreicher für die Umwelt sein.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

F
10.010 Beiträge seit 2004
vor einem Jahr

Was viele Leute beim M1/M2 vergessen ist, das die Effizientsteigerung bei Apple nicht nur an Arm liegt.
Der SOCK beinhaltet z.b. nicht nur den Memorycontroller sondern den Speicher selber auch.
Das macht einen großen unterschied bei der Geschwindigkeit um beim Energieverbrauch.

Sehen wir ja an den Caches, wenn du den gesamten Speicher mit der Geschwindigkeit eines Secondlevel Cache ansprechen kannst ist das ein enormer Vorteil

16.807 Beiträge seit 2008
vor einem Jahr

Bei ARM ist eben die Leistung pro Watt besser.

Das is ne schwierige Aussage, genauso ist "ARM ist besser für die Umwelt" halt totaler Käse. Beide Plattformen haben ihre Vor- und Nachteile; auch in Sachen Leistung und Effizienz.
Ja, das Power per Watt ist ein Thema, aber auch hier "kommt es eben drauf an".

ARM Prozessoren haben vor allem die Fähigkeit langsamer oder sogar komplett aus zu sein (Clockless Core Design) zu sein, dadurch benötigen sie weniger Basisenergie (durch weniger Volt).
Das ist halt das, was sie in Laptops so super praktisch machen; wo es einfach sehr viel Idle Time im Alltag gibt.
Vor allem die letzten 10 Jahren haben x86 CPUs immense Schritte nach Vorn in Sachen Effizienz gemacht und die Differenz der beiden Plattformen wird eher geringer als größer.

Im Endeffekt endet es auf:

  • ARM CPUs haben ihre Vorteile in gewissen Anwendungsfällen
  • x86 CPUs haben ihre Vorteile in gewissen Anwendungsfällen
  • Custom Design Chips haben ihre Vorteile in gewissen Anwendungsfällen (Microsoft zB mit eigenem Ampera Chip in Azure, bzw. FPGA für Networking und AI)

alle x86-Systeme ersetzt werden (so wie es aktuell Apple macht mit "Apple Silicon"), unserer Umwelt zuliebe.

.. ist eher auch eine Aussage, die mit der Realität nicht ganz so viel zutun hat.

6.911 Beiträge seit 2009
vor einem Jahr

Hallo T-Virus ,

Insgesamt ist ARM hier definitiv sparsamer.

Auf Grundlage von was? Bzw. welcher Benchmark liegt dieser Aussage zugrunde?

So allgemeine Aussagen sind für mich schlichtweg nicht treffend, ich bin fast bereit zu schreiben "falsch".
Es hängt doch sehr wohl auch von der zu betrachtetenden Workload ab und wenn so eine Aussage getroffen wird, so sollte diese Workload ev. zusammen mit Quellen auch angegeben werden. So ist das Argument wertlos.

  • ARM CPUs haben ihre Vorteile in gewissen Anwendungsfällen
  • x86 CPUs haben ihre Vorteile in gewissen Anwendungsfällen
  • Custom Design Chips haben ihre Vorteile in gewissen Anwendungsfällen (Microsoft zB mit eigenem Ampera Chip in Azure, bzw. FPGA für Networking und AI)

Sehe ich auch so und nicht (vereinfacht) "Arm = gut, x86 = schlecht".

In Bezug auf .NET finde ich es super, dass Arm genauso berücksichtigt und optimiert wird wie für x86. Das lässt jedoch auch keine Aussage über die Effizient / Umwelteinfluss von Arm <-> x86 zu, denn im Bereich Software hängt es v.a. davon ab wie effizient der Code arbeitet und hier spielt auch die O-Notation und geeignete Datenstrukturen eine große Rolle. Einen Einblick gibt hier Sustainable Code.

Da du den Bogen auf CO2 und Verkehr / Industrie gespannt hast, sollte das auch nicht "zuerst Verkehr / Industrie, dann CPU / SW" sein, sonder idealerweise "jeder optimiert sich, denn auch kleine Beiträge bewirken in Summe etwas" sein.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
2.219 Beiträge seit 2008
vor einem Jahr

@gfoidl
Bei ARM beziehe ich mich mehr auf die Sparsamkeit im Leerlauf als auf die Performance.
Dort liegt halt die Stärke von ARM.
Und die meisten Systeme, gerade mobile Geräte aber auch Laptops o.ä. können hier gut Energie sparen.
Diese haben dann auch einen geringeren Energieverbrauch, müssen aber u.U. auch bei der Performance in bestimmten Bereichen gegenüber x86 federn lassen.
Dies muss aber nicht mal ein Nachteil sein, wenn der Zweck der CPU am Ende vollkommen erfüllt wird.
Eben wenn es darum geht einen geringen Energieverbrauch mit ausreichender Leistung zu bieten.

Ich beziehe mich hier also nicht auf einen direkten Leistungsvergleich zwischen ARM und x86.
Das kann schon aus mehreren Gründen ein Problem werden (CISC vs. RISC) sowie Hardware De-/Encoder direkt in der CPU vs. Software Emulationen.

Bei dem Umweltthema muss man halt auch beachten, dass die Hardware zum ersetzen auch erstmal gebaut werden muss.
Hier müssen also auch erstmal wieder unmengen an Resourcen und Energie aufgebracht werden, weshalb man nicht einfach von Heute auf Morgen alles ersetzen kann.
Dazu kommt eben auch wieder das Problem der Software, die auch erstmal angepasst werden muss.
Viele Firmen arbeiten nicht ohne Grund noch mit Legacy Hard- und Software.
Nicht jedes Programm ist z.B. in einer .NET Sprache oder Java geschrieben.
Auch die nativen x86 Programme muss man erstmal für die jeweiligen Platform portieren.

Und am Ende muss die CPU auch den Anforderungen entsprechen.
Was nützt eine ARM CPU wenn diese nicht die gleichen Anforderungen wie eine x86 CPU entspricht.
Ob das am Ende einzelne Hardware Funktionen, die Anzahl der Kerne oder die Taktraten der Kerne sind sei erstmal dahin gestellt.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

6.911 Beiträge seit 2009
vor einem Jahr

Hallo T-Virus,

Bei ARM beziehe ich mich mehr auf die Sparsamkeit im Leerlauf als auf die Performance.

Dann schreib das doch gleich 😉
Bisher war die Argumentation nicht sehr schlüssig, eher lose Aussagen.

Mir gehts nicht um die eine od. andere Seite (x86 od. Arm), da ich je nach Anwendungsfalls die ein od. andere Technologie passender halte, sondern darum dass die getätigten Aussagen auch entsprechend arguemntiert werden (das gilt nicht nur für dich).

Bei dem Umweltthema muss man halt auch beachten, dass die Hardware zum ersetzen auch erstmal gebaut werden muss.

Da stimme ich zu.
Vom eigentlichen Thema "Transition von x86 auf Arm" rutschen wir schon ein wenig ab, aber in "Smalltalk" ist das nicht so streng...
Beim Umweltthema könnte auch schon viel getan werden, wenn viel unnötiges Streaming, Social-Media stark reduziert werden würde. Da geht es oft nur um "Müll" den eh keinem interessiert, aber TB an Daten produziert werden.

Auch wenn ich jetzt selbst vom Thema abgewichen bin und die Tür für eine weitere Diskussion geöffnet habe, sollten wir versuchen beim Haupt-Thema Arm <-> x86 zu bleiben.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
2.219 Beiträge seit 2008
vor einem Jahr

Ja das stimmt.
Ich arbeite primär auch nur mit x86 habe aber privat immer hin meinen Home Server auf ein Raspberry Pie 4 umgestellt.
Da ich aber nur IO basierte Dienste am laufen habe ala Torrents und Samba ist dort auch keine dicke CPU nötig.

Mich erstaunt auch was sich in den letzten Jahren bei x86 noch getan hat.
Z.B. hat AMD mit den Ryzen CPUs im Chiplet Format gezeigt, dass x86 auch lange noch nicht am Ende angekommen ist.
Dort kann man immer noch einiges weiterentwickeln und verbessern, was angesichts des Alters von x86 sehr erfreulich ist.
Ich bin deshalb auch gespannt wie die Reise weitergeht.

Auch ARM entwickelt sich Schrittweise weiter, was auch nicht zu unterschätzen ist.
Aber insgesamt erwarte ich nicht, dass ale Systeme irgendwann einfach auf eine Platform migrieren.
Dafür sind die Anwendungsfälle häufig zu unterschiedlich und auch die Ziele der jeweilien Platform unterschiedlich, weshalb ich in Zukunft auch weiterhin mit eine Vielzahl von unterschiedlichen Architekturen rechne.

Z.B. ist mit RISC-V in den letzten Jahren eine neue Architektur mit offenen Befehlssatz erschienen.
Hier mangelt es zwar noch an Hardware aber auch hier kann es z.B. zukünftig zu einem Duell zwischen ARM und RISC-V kommen.
Aber bis dahin werden wenn überhaupt noch einige Jahre ins Land ziehen.

Um beim Thema zu bleiben:
Ein Wechsel von x86 zu ARM kann möglich und sinnvoll sein.
Wenn die Anforderung passt, wie z.B. bei meinem einfachen Fall mit dem Home Server, dann geht dies auch kinderleicht.
Aber dies ist eher mehr ein glücklicher Fall als der Normalzustand.
Hier gibt es eben viele Anforderungen, die einen Wechsel auch erschweren oder gar unmöglich machen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor einem Jahr

Are Arm processors more efficient than x86 processors?

ChatGPT:
Arm processors are generally more power-efficient than x86 processors, but whether they are more efficient overall depends on the specific use case.

Arm processors are designed to be more power-efficient than x86 processors, which are used in most desktop and laptop computers. Arm processors are commonly used in smartphones, tablets, and other mobile devices where power efficiency is important.

One reason Arm processors are more power-efficient is that they use a different instruction set architecture (ISA) than x86 processors. Arm processors use a Reduced Instruction Set Computing (RISC) architecture, which requires fewer instructions to perform a given task compared to the Complex Instruction Set Computing (CISC) architecture used by x86 processors. This reduces the amount of power needed to execute instructions.

Another reason Arm processors are more power-efficient is that they are typically designed for lower clock speeds and use less power as a result. This means that they consume less power overall compared to x86 processors, which are designed to run at higher clock speeds and consume more power.

However, x86 processors are generally better at handling complex workloads, such as those found in desktop and server applications. They also have a larger software ecosystem, with many applications and tools designed specifically for x86 architecture.

In summary, Arm processors are more power-efficient than x86 processors and are commonly used in mobile and embedded devices. However, x86 processors are generally better at handling complex workloads and have a larger software ecosystem. The choice of processor architecture depends on the specific use case and performance requirements.

Mit Visual Studio 2022 lassen sich auch auf einem x86 Rechner native Arm64 builds erstellen, sofern man das Projekt auf .Net Framework 4.8.1 migriert. Das habe ich nun ausprobiert und es hat problemlos funktioniert. Ich musste natürlich auch die verwendeten DLLs auf die neue .Net Version migrieren und als Arm64 bauen. Das war aber kein Problem da ich den Quellcode habe. Auf meinem Galaxy Book Go läuft der native Build deutlich performanter als der emulierte x86 build. Mit .Net Core würde es vermutlich performanter laufen. Ich weiß nicht wie hoch der Migrationsaufwand ist. Werde ich mir mal anschauen.

Auf dem Arm Windows erkennt man eine native Exe daran, dass der Button "Change emulation settings" (Rechte Maustaste auf exe-Datei->Reiter "Compatibility") ausgegraut ist. Auch eine Arm32 Exe muss auf einem Arm64 Windows emuliert werden.

Jetzt noch native msi-Pakete erstellen. Das soll mit Wix 3.14 (Dev Version) möglich sein.

Ich bin schon gespannt auf Laptops mit dem neuen Prozessor Snapdragon 8cx Gen4. Da könnte ein Nachfolger für mein altes T480s dabei sein..

16.807 Beiträge seit 2008
vor einem Jahr

Hast die generierte ChatGPT Antwort denn selbst mal durch gelesen oder nur hier rein kopiert?
Steht ja vereinfacht drin wo die Vor- oder und Nachteile von Arm und x86 liegen, und dass deine Aussage, dass Arm quasi im Alleingang die Welt rettet, vollkommener Humbug ist.

Und jetzt natives Arm mit emulierten x86 vergleichen? Puh…

T
2.219 Beiträge seit 2008
vor einem Jahr

Die Antwort von ChatGPT sagt im Grunde das gleiche wie schon hier geschrieben wurde.
Auch dort steht im letzten Absatz, dass abhängig vom Workload/Anforderungen x86 die bessere Wahl sein kann.

Auch ein Vergleich von emulierter und nativer Software ist kaum sinnvoll.
Gerade da ARM einige Hardware Befehle per Software emulieren muss, kann hier ein deutlicher Performance Unterschied bemerkbar sein.
Dies liegt schon in der Natur der Sache.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor einem Jahr

...und dass deine Aussage, dass Arm quasi im Alleingang die Welt rettet, vollkommener Humbug ist.

Was bist du denn für ein Spaßvogel? So einen Schwachsinn habe ich niemals behauptet

16.807 Beiträge seit 2008
vor einem Jahr

Ich hoffe, dass demnächst (zumindest auf dem Laptop-Markt) alle x86-Systeme ersetzt werden (so wie es aktuell Apple macht mit "Apple Silicon"), unserer Umwelt zuliebe.

Dazu der reine Hinweis: "weil Apple ja so bekannt für Umweltschutz" ist: Apple macht das Sicherlich nicht aus Umweltgründen, sondern um Unabhängigkeit von Intel zu bekommen.
ARM (durch Lizenzierung) ist der einzige Weg für Apple.

ARM hat was mit Effizienz in ganz gewissen Szenarien zutun, nicht mit Umweltschutz.

P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor einem Jahr

Auch ein Vergleich von emulierter und nativer Software ist kaum sinnvoll.
Gerade da ARM einige Hardware Befehle per Software emulieren muss, kann hier ein deutlicher Performance Unterschied bemerkbar sein.
Dies liegt schon in der Natur der Sache.

Ja, das ist mir klar. Mir hat der Vergleich mit der emulierten Exe deutlich gezeigt, dass es Sinn macht, Software auch als Arm build anzubieten. Es hätte ja auch sein können, dass der Performance-Unterschied so gering ist, dass man keinen Unterschied merkt.

6.911 Beiträge seit 2009
vor einem Jahr

Hallo P.St. ,

das Projekt auf .Net Framework 4.8.1 migriert

Warum nicht .NET 6 (LTS) od. .NET 7 (STS)?
Da wird Arm auch besser unterstützt als bei .NET Framework 4.8.1. Wenn schon migriert wird, so schau dir doch die neueste Version von .NET (aktuell 7, .NET 8 gibts als Preview) an. Zusätzlich bietet der JIT und die Libraries dort mehr Optimierungen für Arm an, so dass zusätzlich der Code effizienter abgearbeitet wird.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
2.219 Beiträge seit 2008
vor einem Jahr

Bei .NET 8 ginge dann auch AOT Kompilierung, was ggf. auch interessant sein dürfte.
Insgesamt würde ich den Schritt zu .NET 6+ mehr in Betracht ziehen als zu 4.8.1
Gerade da die Entwicklung bei .NET nicht mehr im Framework statt findet, musst du eben damit rechnen abgehangen zu werden.
Und auf Backports o.ä. solltest du auch nicht hoffen.
Wenn du auch keine Abhängigkeiten hast, du einen Wechsel verhindern, dann sollte das deine Richtung sein.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor einem Jahr

Das hört sich alles sehr interessant an. Laut dem Tool "upgrade-assistant" müssen vor der Migration nach .Net 7 noch Anpassungen vorgenommen werden. Sieht aber alles machbar aus. Das werde ich mir für mein Freizeitprojekt auf jeden Fall mal anschauen.

T
2.219 Beiträge seit 2008
vor einem Jahr

Kannst dann gerne mal einen Zwischenstand gebene, wenn du soweit bist.
Wäre bestimmt auch nicht verkehrt ein paar Erfahrungswerte dabei zu bekommen.
Ich habe mir im Dezember auch zwei Raspberry Pies ergattert und will dort auch mit .NET 6+ etwas rumspielen.
Sobald mein Glasfaseranschluss läuft und mein Netzwerk zu Hause umgestellt ist, gehe ich das als nächstes Projekt mal an.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor einem Jahr

Ich habe mein (WinForms-) Projekt nun teilweise unter .NET 7 zum Laufen gebracht. Das sind meine Erfahrungen soweit:

  • Die Klasse "ContextMenu" ist nicht mehr verfügbar
  • Referenz auf System.Web ist nicht mehr erlaubt
  • Fast alle UI-Elemente sehen etwas anders aus (Größe, Position) bzw. werden in einem Fall (PropertyGrid) viel zu klein dargestellt
  • Es gibt ein Problem bei der Verwendung der Klasse "MemoryMappedFiles", das ich mir noch näher anschauen muss
  • Die Performancesteigerung (Programmstart und zur Laufzeit) bei Arm64 in meinem Fall ca. 10%

Die Performance hat mich etwas enttäuscht, da hatte ich mir mehr erhofft. Hoffentlich bringt die AOT Kompilierung noch was. So wie ich das verstanden habe werden aktuell jedoch nur Konsolenanwendungen unterstützt.

Weiterhin ist mir aufgefallen, dass der Build mit Target .NET Framework 4.8.1 unter x86 auch auf Windows Systemen läuft, die z.B. nur das .NET Framework 4.0 installiert haben. Das liegt wohl daran, dass ich keine Funktionen verwende, die es nur in höheren Versionen des .NET Frameworks gibt.

Ich denke nun, dass für eine deutliche Performance-Steigerung ein umfassendes Code Refactoring nötig ist.

16.807 Beiträge seit 2008
vor einem Jahr

Die Performance hat mich etwas enttäuscht, da hatte ich mir mehr erhofft.

Nicht übel nehmen, aber das liegt nicht an .NET 7, sondern sehr wahrscheinlich an Dir / Deinem Quellcode. Performance ist generell sehr vom Skill der Entwicklung abhängig (nicht nur das Wissen, sondern auch das Anwenden).
Die Runtime kann durchaus optimieren, aber keine Programmierfehler/Effizienzfehler ausgleichen.

Die neue .NET Welt ist nicht nur 10% performanter, sondern eher um den Faktor 10 - und noch viel mehr.
https://devblogs.microsoft.com/dotnet/migration-of-bings-workflow-engine-to-net-5/
https://devblogs.microsoft.com/dotnet/bing-ads-campaign-platform-journey-to-dotnet-6/
https://github.com/BenjaminAbt/SustainableCode

Selbst wenn man sich in der neuen .NET Welt befindet; die Weiterentwicklung und die Investition in die Performance ist immens.
Wir hier im Forum haben von .NET 5 auf .NET 6 den größten Sprung gemerkt (vor allem dank des Skills von gfoidl): guess at what point we moved traffic from #dotnet 5 to #dotnet 6?
=> Performance Improvements in .NET 6

Ich denke nun, dass für eine deutliche Performance-Steigerung ein umfassendes Code Refactoring nötig ist.

Absolut korrekt.

Die Klasse "ContextMenu" ist nicht mehr verfügbar

Und das ist gut so. ContextMenu ist einer der ältesten Controls, die schon über 15 Jahre abgekündigt sind.
Das Replacement seit >15 Jahren ist ContextMenuStrip - da hast offensichtlich sehr alte Leichen im Keller, was dann wiederum die Performance-Issue Theorie von mir / Dein Refactoring Hinweis bestätigen würde.
Announcing .NET Core 3.1 - .NET Blog

Referenz auf System.Web ist nicht mehr erlaubt

Auch das ist absolut gut so.

Das liegt wohl daran, dass ich keine Funktionen verwende, die es nur in höheren Versionen des .NET Frameworks gibt.

Nein, das liegt daran wie die .NET Framework Runtime zB mit Inplace Updates funktioniert.

P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor einem Jahr

Danke für die Infos! Der Quellcode speziell bei den UI Abhängigkeiten (z.B. Magic - The User Interface Library for .NET - Article) ist schon uralt. Sorry, das hatte ich vergessen zu erwähnen. Ist ja dann klar dass meine Erfahrungen hier für die wenigsten relevant sein dürften.

P
P.St. Themenstarter:in
30 Beiträge seit 2017
vor 9 Monaten

So, seit ein paar Monaten bin ich umgestiegen auf ein älteres Macbook, jedoch schon mit M1 CPU, und bin total zufrieden. Windows 11 on ARM läuft wunderbar in Parallels (nach ein paar wenigen Feinjustierungen). Der Lüfter geht so gut wie nie an, das Gehäuse wird nicht heiß. So macht es Spaß, mit VIsual Studio zu arbeiten. Für meine Entwicklungsumgebung habe ich x86 nun beerdigt.