[Juli Karen]

... auch wenn es heutzutags keinen Grund mehr gibt, einen Thread nach ~400 Posts dichtzumachen

R.I.P. #85.

Und auch R.I.P. an Larry Tesler, dem Erfinder des "C&P"

[Almalexia]

Möge er in Frieden ruhen!

[foobar]

Und auch R.I.P. an Larry Tesler, dem Erfinder des "C&P"

[Phael]

Möge er in Frieden ruhen!

[Multithread]

Möge er in Frieden ruhen!

[Juli Karen]

Spät, aber immerhin, kam ich nun auch dazu, mir mal zwei, drei Testsberichte zur Radeon 5600XT durchzulesen.

Für mich als "Aufsteiger" von einer RX 290X wären um 60% mehr Leistung zwar schon recht ordentlich, aber die fehlenden 2GB VRAM, die mich mit einer RX 5700 derzeit nur ab 20 € mehr kosten würden - sowie deren zusätzliche Mehrleistung - sprechen eigentlich doch deutlich gegen diese Karte.

Lt. CB Fazit soll die RX 5700 aber bereits als Auslaufmodell gelten, weiß da einer Näheres dazu?

[Homerclon]

Lt. CB Fazit soll die RX 5700 aber bereits als Auslaufmodell gelten, weiß da einer Näheres dazu?

Das ist nur deren Vermutung. Sie schreiben allerdings auch selbst, das dies AMD verneint hat.

Im 3./4. Quartal kommt eh eine neue Generation, die laut Gerüchten auch Refreshs der aktuellen Navi-Generation bringen soll (halte ich auch nicht für unwahrscheinlich, bei Polaris waren die 2x und 3x Refreshs, und in den Treiber tauchen seit längerem bereits Navi 2x als Codenamen auf). Dann läuft die gesamte 5000er-Reihe aus.

[jabu]

Zu diesen Pionieren (wie dem kürzlich Verstorbenen):

Vor etwas mehr als 20 Jahren haben bei Microsoft (zu meinem Bedauern) die Web- und .NET-Apologeten die Macht an sich gerissen und die modernen, vom PARC adaptierten, Erkenntnisse (zunächst per geänderter Prioritätensetzung, infolgedessen durch Kulturverlust) über Bord geworfen. Die Weiter- und Fortentwicklung der modernen GUI- und Steuerelemente von Windows wurde eingestellt. Es wurden Stile drübergeklatscht und halbherzige Erweiterungen eingeführt, die sich mit den bewährten Konzepten bissen (und bis heute beißen) und damit ihren Sinn entstellen. Gute Ansätze wurden nicht weiterverfolgt, und offene Baustellen wurden nicht geschlossen, was vermutlich teilweise beabsichtigt war, um das Gewohnte (hinter dem ein seriöses Konzept steckte) gegenüber dem (konzeptuell schwachen) neuesten Hipster-Scheiß als altbacken hinzustellen, damit Letzteres heller leuchten möge. Dahinter steckte eine Strategie, doch dazu später.

Dann kamen die Mobile-Apologeten auf den Plan, womit Windows noch schlimmer vermurkst wurde. Ein angenehmer Nebeneffekt der mobilen Endgeräte war bzw. ist, dass man sich endlich eingestehen musste, dass verwalteter Code (praktisch C#/CLI/.NET) ressourcen- und leistungsmäßig für mobile Geräte ungeeignet ist (zumindest bis vor ein paar Jahren noch war), sodass C++/Native eine große Rennaissance erfuhr. Doch ein GUI-Toolkit von Microsoft, welches auch die Anforderungen ausgewachsener Desktop-Programme abdeckt, fehlt für C++ bis heute. Und der C++-Kram für die Kachel-Apps kam mehrere Jahre zu spät. Selber schuld, würde ich sagen. Ein einziges Mal CLI/.NET auf einem Einsteiger- bis Mittelklasse-Laptop zu probieren, hätte genügt, um herauszufinden, dass das für noch schwächere Hardware, z.B. die eines Phones, gar nicht geeignet ist, weder leistungsmäßig noch für die Akkulaufzeit. Wie realitätsfern muss man sein, wenn man als Entwickler nur noch vor High-End-Workstations sitzt? Heutzutage ist das schon viel besser, aber als die Thematik aktuell war, war die Hardware noch nicht so weit.

Die MFC (von Microsoft) sowie direktes Windows-API sind jeweils schlecht wartbar und im Gebrauch umständlich und fehleranfällig. Das kommerzielle Lizenzmodell von Qt kann sich für kleine Entwickler als ein gefährlicher Knebel erweisen, sodass diese schon nach dem kleinsten "Fehler" (eher dürften es normale Umstände sein, z.B. indem die Software öffentlich verfügbar gemacht wurde) bis zu ihrem Tod monatlich dreistellige Euro-Beträge zahlen müssen. Ein regulärer Ausweg wäre, den Vertrieb (einschl. Updates) einzustellen und die Software aus allen öffentlichen Kanälen zu entfernen, was enorm schwierig bis gar nicht leistbar werden könnte. Das freundliche wxWidgets bietet oftmals zu wenig. Der C++Builder von Embarcadero ist für Normalsterbliche meistens zu teuer. Microsoft schlachtete diesen Mangel an einem C++-GUI-Toolkit für Windows aus, um das .NET-Framework zu pushen. Mit einem gescheiten, plattformübergreifenden, preisgünstigen und quelloffenen C++-GUI-Toolkit wäre C#/CLI/.NET von Anfang an chancenlos gewesen.

Die Vermurksung von Windows und die CLI/.NET-Technologie stehen in einem engen Zusammenhang. Personen, Motivation (Lösung für die Belange der Betriebswirtschaft mit Knebelung an Windows), Zeiträume, das alles ist eng miteinander verzahnt. Windows sollte eine Plattform für betriebswirtschaftliche Anwendungen sein und später auch für Mobilgeräte und ein Client für die Cloud. Das Begehr wegen der Betriebswirtschaft und der Cloud werden wir wohl so schnell nicht loswerden. Der User mit seinen Anforderungen an einen ganz normalen Desktop steht offenbar irgendwo ganz hinten in der Prioritätenliste. Deswegen (und mangels Konkurrenz) sind die am PARC gewonnenen Erkenntnisse niedrig priorisiert. Man denkt bei Microsoft eben "weiter", wobei dieses Ziel gar nicht so genau definiert zu sein scheint (außer monetär) und der Weg als Ziel (was mit Benutzererfahrung und Lebensqualität zu tun hat) längst aus dem Blick verloren wurde. Das ist typisch für die Folgen menschlicher Gier. Es wird reichlich Erde verbrannt, anstatt es sich und allen anderen gut gehen zu lassen, wegen irgendwelcher abstrakter Ziele (z.B. um irgendwann mal noch viel reicher zu werden oder angeblich die Welt zu retten), deren Eintretenswahrscheinlichkeit kaum abzuschätzen ist.

Edit:
Damit will ich nicht sagen, dass ich C# schlecht fände. Ich halte C# für eine mindestens gut gelungene Sprache. Aber wenn ich dagegenhalte, welche langwierigen Update-Orgien für CLI/.NET bisher nötig waren (man bedenke auch die wegen Fehlern verbrannten Stunden), auch zu Zeiten, als das nur selten genutzt wurde und wie überfordert PCs über lange Zeit mit der Ausführung waren (und wie träge XP schon durch die bloße Installation wurde) und wie schlecht vorhersehbar die auf dem jeweiligen Zielsystem installierte .NET-Version war, dann dürfte der mit der frühen Verfügbarmachung dieser Technologie angerichtete Schaden den Nutzen überwiegen, vermutlich sogar den Gesamtnutzen bis heute, wenn man die möglichen, damit ausgebremsten, Alternativen mit einbezieht. Mir wäre viel lieber gewesen, wenn man, entlang einigermaßen gesicherter Erkenntnisse (an derer Erlangung man beständig geforscht hätte) und in kleinen sicheren Schritten Windows gutqualitativ weiterentwickelt hätte, mehr wie eine Evolution (anstatt Revolution (wo Revolution nötig ist, bitte gleich richtig)). Man hätte dabei die personellen Ressourcen behalten, um die Entwicklung der Benutzerinteraktion parallel zur Entwicklung von Schnittstellen und Frameworks weiterzubetreiben und natürlich schrittweise zu verbessern. Managed Code kam zu früh. Die Technik war unausgereift, die Verteilung über lange Zeit nicht sichergestellt, und die Hardware war nicht so weit. Heutzutage rennt der Kram ganz gut. Aber der vollzogene und längst nicht begradigte (man denke an den Bruch zwischen Forms und WPF sowie zwischen Fw und Core, wobei nur die Legacy-Variante der Technik wirklich für alles taugt (weswegen es weder WPF noch Core (auf dem Desktop) schon wirklich "gibt"), ähnlich wie bei Java (wo es FX noch nicht wirklich "gibt")) Schlingerkurs bestätigt den Wesensgehalt meiner Kritik. Es hilft nichts, verschiedene Tools zu haben, wenn das alles unterschiedlich gestrickt ist und sich nicht miteinander integriert. Der Fallback (in der Evaluierungsphase) auf die ältere, vollständigere und notfalls eben leistungsschwächere oder unelegantere Lösung ist dabei ziemlich wahrscheinlich. Ein Beispiel: Wenn Forms ebenso wie die moderne Variante (seit Vista) des Windows GDIs auf hardwarebeschleunigtes Rendering verzichten muss, hilft es genau gar nichts, wenn das WPF DirectX unterstützt, solange das WPF nicht auch alles andere, was man braucht, unterstützt. Nun soll Core auf den Desktop, unterstützt ihn aber nicht von Haus aus und bekommt deswegen das .NET-Framework übergangsweise drangefrickelt, womit doch recht wahrscheinlich wiederum nicht alles geht. Es wird aber auch rein gar nichts konsequent angegangen (wobei ich hier schon eine mögliche Absicht sehe, alte Fehler zu meiden, aber nach all den Fehlerwiederholungen ist es schwer zu glauben). Es gibt immer diese Mini-Revolutionen und dann Flickschusterei; Hauptsache, man bekommt die Leute erst mal in die gewollte Richtung manipuliert. Bei der Benutzerinteraktion ist es dasselbe in Grün. Jedesmal hofft man auf die einheitliche und wenigstens einigermaßen vollständige Lösung, nach der Transition. Und jedesmal gibt es eine Enttäuschung. Forschung und defensives, aber beständiges, Vorgehen wäre ein Ansatz, um diese Gefahr zu minimieren. Ich wünsche mir, dass die Verantwortlichen bei Microsoft (und nicht nur dort) einen imaginären Resetknopf in ihren Hirnen betätigen mögen, um ideell wieder bei besagten Pionieren und ihren Erkenntnissen anzusetzen, besser noch, bei deren Einstellung und Arbeitsweise, wodurch eben solche grundlegenden Erkenntnisse erst möglich wurden. Für zig neue Ansätze, die man mitmachen und erlernen muss (z.B. kann man mit dem Erlernen von Frameworks Lebensjahre verbrennen), aber die irgendwie nicht richtig funktionieren und dann versanden, ist das Leben zu kurz.

[Multithread]

Ich stimme dir zu, was das "Fehldesign" von C# angeht.

Aber: Ich sehe das es besser wird. Seid Sie C# Open-Source gemacht haben, hat sich an der Sprache einiges getan, gerade auch was die Plattformkompatibilität angeht.
Vor der Open-Source stellung, war nicht klar, was aus C# werden wird. Es ging nicht mehr vorwärts.

Was die Sprache selber angeht, hat diese doch einige Vorteile gegenüber C++ und Java. Ansonsten hätte Sie sich dennoch nie verbreitet.
SIlverlight z.B. (C# fürs Web/Flash ersatz) war auch ne Todgeburt.
Der Vorteil von C# ist das es vom Design her deutlich sicherer ist als Java, aber gleichzeitig viele Fehlerquellen von C++ "ausschalten" kann, bzw. stark abmildern. Das Führt nicht nur zu besserem Code, aber es macht es einfacher brauchbaren Code zu schreiben.

Die Ausführungsgeschwindigkeit von C# wurde seit den Windows XP Zeiten verbessert. Und bei .NET Core ist Sie nochmals höher (durch bessere Implementationen der C# Library Funktionen. Beispiel: Enumerator Concat neu mit n Enumeratoren, nicht nur mit 2).

WPF: Bin Ich nicht so begeistert davon. Die Idee ist gut, die Umsetzung finde Ich aber unglücklich.

Den Bruch, welchen du suchst, ist schon geschehen. Aber ob .NET Core -> .NET 5 in die richtige Richtung geht, muss Ich erst noch Zeigen.

[Homerclon]

Unfreiwilliger Erkenntnisgewinn: Ein Scythe Mugen 2 kann einen i7-4790K @ 4,4 GHz allein durch indirekte Belüftung kühlen.
Wobei ich das nicht empfehlen würde, meine CPU erreichte ~90°C unter höchstlast (weniger als mit Prime, aber nahe dran, wobei ich es nicht lange am Stück ausprobiert habe).

Nach 9 Jahren treuen Diensten, hat der Lüfter die Hufen hoch gerissen - ohne Vorankündigung.
Blöderweise hab ich nur 3Pin-Lüfter da, und mein Mainboard mag die nicht steuern. Jetzt röhrt der Lüfter grundlos durchgängig mit 100% seiner Drehzahl. Da muss baldigst Ersatz her.

[Morrich]

Was hast du denn fürn schrottiges Mainbaord, dass du dem nicht sagen kannst, dass es nen Lüfter per Spannung steuern soll?

[Homerclon]

ASRock Z97X Killer

Möglicherweise hab ich die Option auch nur übersehen. Da ich meine Gehäuselüfter an einer dedizierte Lüftersteuerung (die ist älter als das Mainboard) angeschlossen habe, war ich auf die Lüftersteuerung des Mainboards bisher nicht angewiesen gewesen.

EDIT: Das witzige ist: CPU_FAN2 ist ein 3-Pin-Anschluss, ebenso 2 der 3 Anschlüsse für die Gehäuse-Lüfter.

[Morrich]

Bei solch einem Board erwarte ich aber, dass der CPU Lüfter problemlos auch per Spannung gesteuert werden kann. Das ist ja selbst bei Billigmainboards möglich.

[Homerclon]

Hatte ich eigentlich auch erwartet, aber für die Rückgabe ist es zu spät, und Garantie ist auch längst abgelaufen.

Ich probiere morgen mal den CPU_FAN2 aus. Hatte den PC heute schon zwei mal abgebaut und offen, ein drittes mal hab ich keine Lust. Außerdem ist ganz schön Eng, so das ich dafür wieder ein Gehäuse-Lüfter ausbauen darf um an den Anschluss zu kommen.
Große Hoffnung hab ich aber nicht. Irgendwann letztes Jahr hatte ich schon mal die Gehäuselüfter ausprobiert, an den 3-Pin-Gehäuse-Anschlüsse. Die liefen aber auch dort nur mit voller Drehzahl. Dabei kann man alle Gehäuse-Lüfter sogar getrennt einstellen, nur CPU_FAN1 & 2 werden zusammen geregelt.

Hab vor kurzem aber mal ein BIOS-Update durchgeführt, in der Hoffnung auf neue Optionen (außerdem hats die Sicherheitslücke geschlossen). Es gab zwar Änderungen, aber keine Betraf die Lüfter-Einstellungen.

[Almalexia]

Was will man auch von Asrock erwarten.

[Morrich]

Ich hab auch ein ASRock Board und das bietet die entsprechenden Funktionen an.
Mit dem Hersteller hat das nichts zutun.

[Almalexia]

Ich weiß nicht. Ich würde mir kein Asrock-Board kaufen. Ich habe gute Erfahrungen mit MSI und ASUS-Boards gemacht. Ist halt eine Geschmackfrage.

[foobar]

Jeder Hersteller macht seine Fehler. Mein letztes Board war ein Asrock und es hat geschnurrt wie ein Kätzchen. Mein aktuelles MSI-Board hat das Problem, dass beim Laden der Windows-Treiber für meine Asus Xonar D2X Soundkarte der Rechner einen Reset macht, wenn man PCIe Version 4.0 im UEFI-Setup einstellt. Laut Google haben andere MSI-Boards mit PCIe 4.0 Support (aber nicht alle) das selbe Problem.

Ist irgendeine komische Inkompatibilität zwischen Treiber und Hardware. Die Linux-Treiber gehen einwandfrei und wenn man PCIe auf Version 3.0 oder niedriger stellt, laden auch die Windows-Treiber. Für die nächsten zwei, drei Jahre also vermutlich kein echtes Problem. Aber auch nicht gerade ideal.

Und das Firmware-Setup ist ein Usability-Albtraum, der seines Gleichen sucht. Selbst im Vergleich zu anderen Firmware-Setups (die alle nicht das Gelbe vom Ei sind). Zum Beispiel darf man den Schalter, der den Support für Hardware-Virtualisierung aktiviert, im Overclocking-Menü suchen. Was der da verloren hat, weiß alleine MSI. Und dann ist er mit „SVM” anstatt des bekannteren „AMD-V” bezeichnet, so dass man ihn auch noch leicht übersieht.

Ich weiß nicht, was der Interface-Designer bei MSI geraucht hat, aber ich will auch was davon.

[Homerclon]

Lüfter vom 4-Pin-Anschluss an 3-Pin-Anschluss umgestöpselt. Und erst mal ein kleinen Schreck bekommen, da der Lüfter still stand.
Dann die Lüftersteuerung von Custom auf Silent umgestellt, Neustart --> Lüfter läuft, und zwar leise (am 4-Pin hatte ich das ausprobiert, da hatte es nichts gebracht).
Am 3-Pin lässt sich wohl keine Manuelle Lüfterkurve vorgeben, bleibt die Wahl zwischen vier Modi: Silent, Standard, Performance und Full Power. Evtl. funktioniert, wenn gleichzeitig noch einer am 4-Politen Anschluss hängt. Ich denke aber nicht, das ich das ausprobieren werde.

Komisch ist nur, das man die Möglichkeit für eine manuelle Lüfterkurve auch bei den 3-Poligen Gehäuse-Lüfter-Anschlüsse hat (man kann auch auswählen nach welcher Komponente sich dann gerichtet werden soll. Grundsätzlich sollte das Mainboard es also eigentlich können.

Ein Schönheitsfehler bleibt: Am 3-Pin-Anschluss wird keine Drehzahl gemessen.
Gerade fällt mir auf: Entweder wurde am 4-Pin ein falscher Wert ausgelesen, oder der Lüfter lief nicht mit 100% sondern nur ca. 90%.


Auf "Silent" wird die CPU unter Last erwartungsgemäß etwas wärmer, bleibt aber weit von den 90°C weg. Bis jetzt wurden 70°C erreicht, als ich gestern das letzte mal geschaut hatte, war die höchste gemessene Temp 67°C. Wenn die Temperatur noch ein paar wenige Kelvin weiter steigen sollte, stört mich das auch nicht weiter. Das es ruhig bleibt, ist mir wichtiger.

[Almalexia]

Ja, das kann auch Einbildung sein aber meine Mutter hat ein Z77 Mpower mit einem 2500k und ich ein MSI X79 GD45 Plus verbaut und das läuft schon 6 Jahre rund. Mein Vater hat auch ein ASUS und das läuft und läuft...
Ich denke eher daran das dass noch Nachwirkungen davon sind als ASROCK noch eine Billigmarke war.