Assemblercode - Noch optimierbar?

  • Ich habe das ganze mal mittels PThreads und C realisiert. Kompiliert habe ich es unter Debian 8 mit gcc, da Windows aber ebenfalls POSIX-Threads unterstützt, sollte sich das auch mit VC++ oder so für Windows kompilieren lassen.

    Es ist zu beachten, dass durch meine Realisierung des Threadings nur gerade Threadanzahlen möglich sind. So spare ich mir das alternierende Vorzeichen in der Hauptschleife. Mein Lösungsweg kurz dargestellt am Beispiel von 4 Threads:
    Leibniz-Reihe: 1 - 1/3 + 1/5 - 1/7 + 1/9 - 1/11 + 1/13 - 1/15...
    Thread 1: 1 + 1/9 +...
    Thread 2: 1/3 + 1/11 + ...
    Thread 3: 1/5 + 1/13 + ...
    Thread 4: 1/7 + 1/15 + ...
    Ergebnis: (Thread 1 + Thread 3) - (Thread 2 + Thread 4)
    In Worten: Ich erzeuge Teilsummen bei gleicher Schrittgröße durch unterschiedliche Startwerte. Um das wechselnde Vorzeichen zu beachten, wird am Ende die Summe aller geraden Threads von der Summe der ungeraden Threads subtrahiert. (Mein Programm arbeitet direkt mit Brüchen, die im Zähler 4 stehen haben, um die Multiplikation am Ende zu sparen.)

    Ansonsten... Der C-Code an sich ist total unoptimiert. Es ging hier wirklich nur ums Threading. Außerdem ist die ein oder andere Programmiersünde im Quellcode enthalten. :D

  • chesstiger,

    Kompiliert habe ich es unter Debian 8 mit gcc, da Windows aber ebenfalls POSIX-Threads unterstützt, sollte sich das auch mit VC++ oder so für Windows kompilieren lassen.

    hat mich jetzt 4 Stunden gekostet, deinen Code lauffähig zu bekommen :D
    Ich verwende MINGW Developer Studio (die neueste Version ist von 2008), welches ich per MINGW-GET-SETUP auf die neueste MINGW-Version geupdatet habe.
    Danach folgte per MINGW Installation Manager die Installation des mingw-libthreadgc (NICHT libthreadgce !!!) - paketes.

    Nach 2 hieben auf F8 (Build and execute) wurde dein Code anstandslos compiliert, allerdings meckerte die EXE, dass sie nicht lauffähig ist, da die Datei pthreadgc-3.dll fehlt. Diese Datei aus den Tiefen des MINGW in das Verzeichnis der EXE kopiert und alles lief....Die DLL stellt die POSIX-Kompatibilität zur Windows-API bereit, also die "Windows-API Thread Funktionen"

    Jetzt versuche ich mal, inwieweit ich das hinbekomme, Zeiten ausgeben zu lassen, denn das ist ja das interessante dabei 8o
    ....to be continued

    //EDIT1
    oha, schon nach einigen Sekunden habe ich es als C-Anfänger hinbekommen, die Laufzeit zu ermitteln....schön, wenn man bereits aus alten Projekten die Zeilen kopieren kann :rolleyes:

    Der erzeugte C-Code ist imho sauschnell! Mein ASM-Code ist gerade mal doppelt so schnell, was daran liegt, dass zwar die EXAKTEN SSE-Befehle verwendet werden wie in meinem Code, aber nicht skalar, d.h. der Compiler ist nicht in der Lage, die vorhandene Registerbreite von 2 doubles voll auszunutzen, es wird nur eines benutzt....
    Aber da werde ich mich dahinterklemmen, imho habe ich etwas darüber gelesen.
    float2, float3 und float4 (und andere) Datentypen gibt es ja, ggf auch ein double2?! Dann könnte der Compiler die Register "richtig" füttern und der erzeugte Code wäre in etwa so schnell wie der ASM-Code!

    Das macht übrigens der Compiler aus dem loop:
    asm_pi.JPG

  • Tja, irgendwann musste es mal soweit kommen....
    Andy programmiert C :Face:

    Aber wenn schon, denn schon 8o
    Anbei die nach C portierte ASM-Version (wer kann DAS von sich behaupten, als Anfänger hingedröselt zu haben :party: ) mit 4 SSE/SIMD-Schleifenbefehlen, natürlich skalar, d.h. die 128-Bit-Register werden in 2x double (64Bit) aufgeteilt und dann wird jeweils der 1/positiv und 1/negativ zusammengezählt (die erg-variable) und positiv++4 und negativ--4 berechnet, und die Schleife braucht gegenüber der "einfachen" Version nur noch halb so lange...

    //edit2 Quellcode "schön" gemacht^^

    Laufzeit: auf die Millisekunde so schnell wie mein ASM-Code :klatschen: wzbw 8)

    //EDIT
    bissl im code rumgespielt und festgestellt, die "einfachen" Operatoren funktionieren mit den _m128d Variablen auch! Die Schleife wird also zu

    Code
    for(int i = 0; i < LOOPSEACH/2; i++) {
    		d = a;            //immer 1.0 1.0
    		d = d / c;        //_mm_div_pd(d,c);     // 1/c1   1/-c2
    		c = c + b;        //_mm_add_pd(c,b);     // c1=c1+4   c2=c2-4		
    		erg = erg+d;      //_mm_add_pd(erg,d); // erg = erg + (1/c1 + 1/-c2)
    	 }

    //EDIT3
    der vom Compiler erstellte Schleifenblock...FEEEETTTT!!!

  • Für diejenigen, welche einen Prozessor haben welcher AVX unterstützt, hier der Code:

    diesen Code mit den Flags -mavx -O3 hier eingetragen http://godbolt.org , sieht man, was der GCC daraus macht....sehr schick, der "inner loop" besteht aus den schon zuvor beschriebenen 5 Zeilen:

    Code
    .L2    sub     eax, 1
            vdivpd  ymm2, ymm4, ymm0
            vaddpd  ymm0, ymm0, ymm3
            vaddpd  ymm1, ymm1, ymm2
            jne     .L2

    diesmal werden 4 DOUBLE gleichzeitig berechnet, daher nur 1/4 der Schleifendurchläufe!

    Gegenüber im vorhergehenden Post#43 gezeigten Code wurden nur die "langen" (256Bit) AVX-Variablentypen und Intrinsics im C-Code angepasst!
    Das ist dermaßen einfach, da frag ich mich ernsthaft, warum diese Techniken/Verfahren nicht permanent eingesetzt werden...

    Auf einem AMD FX-6300 ist der AVX-Code leider nicht doppelt so schnell, sondern nur gleich schnell wie der SSE-Code, fu** AMD! Da wurde bei der Implementierung geschlampt! Könnte jemand mit INTEL-Prozessor mal die Laufzeit der beiden Programme testen?
    AVX-SSE.zip
    Ich habe jetzt keine Abfrage programmiert, ob der Prozessor AVX unterstützt, wenn nicht, crashed die exe. :Glaskugel:

    Wer Interesse an einer unkomplizierten C++-Umgebung hat, in welcher die oben beschriebenen Codes problemlos laufen, dem empfehle ich das MinGW-Developer-Studio hier http://vaultec.mbnet.fi/mingwstudio.php
    Dort aber UNBEDINGT den Installer mit dem GCC4 runterladen!

  • Intel Core i5 4300U:

    Code
    C:\Temp>SSE.exe
    ret1= 6.064393047313  ret2= -5.278994884167   summe= 3.14159265258555
    SSE Duration mSec 2593.268000
    
    
    C:\Temp>AVX.exe
    ret1= 3.465683017203  ret2= -2.761371315559  ret3= 2.598710030113  ret4= -2.517623568609  summe= 3.14159265259144
    AVX Duration mSec 2763.371000

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Oha!
    Danke erstmal für die Tests!
    Meine Ergebnisse sind mit einem FX6300@3.5GHz (Bulldozer) wie bei euch recht identisch, ca.1300ms... Im Vergleich doch recht schnell...

    @chesstiger, ja, das gefällt mir ganz und garnicht... :huh:
    Google befragen mit "avx slower than sse" zeigt, dass nicht nur ich damit ein Problem habe. Wobei man fairerweise sagen muss, dass bei vielen dieser Aussagen/Fragen gezeigt wird, wie man durch Umstellen des Codes die Performance signifikant verbessern kann. Die Compiler brauchen also massiv Hilfe seitens des Entwicklers!

    Angeblich sollen die "neueren" INTEL-Prozessoren (Skylake, Kaby Lake) etwas besser bei AVX abschneiden, also abwarten...
    Wie es aussieht, verwenden sowohl AMD als auch INTEL "nur" die 128-Bit breiten Register und "mappen" die 256- bzw. 512 Bit breiten AVX-Register. Heisst also, dass bei AVX bspw. beim Addieren nicht 4 Doubles gleichzeitig addiert werden, sondern "nacheinander" 2x2 per SSE... :S
    //EDIT Dazu kommt noch, dass das DIV genau wie ein SQRT bei AVX "intern" sowieso nur als SSE ausgeführt wird, daher also kein Wunder, dass die Laufzeiten identisch sind!

    Was man aber auch nicht verschweigen sollte ist, dass die Berechnung von PI im vorliegenden Programm nur von 2 Befehlen ausgeführt wird, Division und Addition in einer extrem kurzen Schleife. Die Prozessoren haben keinerlei Möglichkeit, ihre Pipelines optimal zu füllen, der aufwendige und dadurch langsame DIV bricht denen in jedem Schleifendurchlauf das Genick.

    In "realer" Software mit Speicher/Cache-zugriffen gibt es je nach Speicheranbindung sicherlich Unterschiede zugunsten AVX. Auch die Befehle wie bspw. FMA bringen dann sicher etwas Performance.

  • Hi zusammen,

    anbei Vergleich von Laufzeiten für einen AMD Ryzen5 (ohne X!) ohne Übertakten....(Aldi-PC Medion P56000 für runtergesetzt 400€ )

    Auch kein Unterschied zwischen AVX und SSE, naja, hätte mich ehrlich gesagt auch gewundert^^

    Aber im direkten Vergleich zu den sonst so schnellen Intels (bspw. hier) ist das Faktor 2.5 schneller....

    Das Multithreading sieht auch gut aus, 6 Cores mit HT, beim Script von hier mit 1000000000 Durchläufen kommen folgende Ergebnisse raus

    Spoiler anzeigen

    Threads: 1 Time: 664.4ms PI: 3.141592652586

    Threads: 2 Time: 337.1ms PI: 3.141592652591

    Threads: 3 Time: 226.2ms PI: 3.141592652598

    Threads: 4 Time: 182.8ms PI: 3.141592652593

    Threads: 5 Time: 191.3ms PI: 3.141592652591

    Threads: 6 Time: 175.0ms PI: 3.141592652588

    Threads: 7 Time: 159.2ms PI: 3.141592652589

    Threads: 8 Time: 145.4ms PI: 3.141592652586

    Threads: 9 Time: 132.4ms PI: 3.141592652587

    Threads: 10 Time: 120.8ms PI: 3.141592652590

    Threads: 11 Time: 122.5ms PI: 3.141592652589

    Threads: 12 Time: 116.7ms PI: 3.141592652588

    Threads: 13 Time: 122.2ms PI: 3.141592652590

    Threads: 14 Time: 127.4ms PI: 3.141592652590

    Threads: 15 Time: 120.6ms PI: 3.141592652591

    Threads: 16 Time: 115.2ms PI: 3.141592652590

    Threads: 17 Time: 116.9ms PI: 3.141592652589

    Threads: 18 Time: 120.1ms PI: 3.141592652589

    Threads: 19 Time: 122.5ms PI: 3.141592652590

    Threads: 20 Time: 123.8ms PI: 3.141592652589

    Threads: 21 Time: 116.5ms PI: 3.141592652590

    Threads: 22 Time: 123.7ms PI: 3.141592652590

    Threads: 23 Time: 118.5ms PI: 3.141592652590

    Threads: 24 Time: 117.9ms PI: 3.141592652589


    also mit Multithread fast Faktor 5 schneller als Singlecore. Würde meine Annahme bestätigen, dass sich Windows immer einen Thread reserviert.

    Fehlen nur noch die Programme, die diesen Prozessor komplett ausnutzen:Face:

  • Hi zusammen,

    habe soeben etwas herausgefunden, was mich an der Konzeption von Multithreading "etwas" (ziemlich) zweifeln lässt. Kann natürlich am "neuen" Ryzen liegen...oder an Windows, Diskussion dazu bzw. tiefergehende Infos (falls jemand welche hat) sind ausdrücklich erwünscht^^

    Ich habe, um den Ryzen auszuloten, das Programm HWiNFO64 runtergeladen und mir dort die Anzeige der "Sensors" auf den Desktop gelegt. Beim Ryzen 5 1600 werden demnach 12 Threads (6 Cores a 2 Threads) angezeigt. Bei "Standardprogrammen", welche definitiv nur einen bis maximal 2 Threads beanspruchen, verteilt Windows die Last quer über alle Threads, da der Ryzen bei "kalten" Cores diese bis zu 500Mhz übertakten kann. Im Taskmanager dümpelt die Last bei voll rödelndem Excel oder diversen Spielen oder Prime95 mit einem Thread bspw. bei 8-10%. Soweit normal. Bei HWiNFO sieht man sehr schön, wie Windows das Core-hopping betreibt, also fleissig die Last von einem Core auf den nächsten schiebt, die anderen haben dann halt weniger bis nichts zu tun.

    Jetzt wollte ich aber mal alle Kerne glühen sehen und habe mich auf mein Script in diesem Thema hier besonnen.

    Script ausgeführt, alles paletti, Zeiten s.o.

    Jetzt wollte ich die Laufzeit erhöhen um bei HWiNFO zu sehen was denn auf den Cores so passiert und wurde "etwas" (ziemlich) überrascht!

    Nach sukzessiver Erhöhung von $n (Anzahl Durchläufe in Zeile 91 des Scripts) stellte ich fest, dass bei Ausführung von einem bzw. zwei Threads die Zeiten nur ca. 1/4 bis 1/3 vom 3., 4., 5., ...24. Thread waren! Wie kann das sein? Bisher waren doch bei höherer Anzahl benutzter Kerne die Zeiten immer niedriger geworden?!

    Nach einigen Tests, wobei ich im Taskmanager und auch auf HWiNFO die Cores zu 100% ausgelastet sah, habe ich $n auf die größte mögliche 32Bit-Zahl, also 0xFFFFFFFF gesetzt. Mit diesem Ergebnis:

    Spoiler anzeigen

    @@ Debug(91) : $n = -1

    Threads: 1 Time: 5739.9ms PI: 3.141592653468

    Threads: 2 Time: 5758.2ms PI: 3.141592653533

    Threads: 3 Time: 5834.6ms PI: 3.141592653558

    Threads: 4 Time: 5957.7ms PI: 3.141592653557

    Threads: 5 Time: 6324.2ms PI: 3.141592653580

    Threads: 6 Time: 7159.6ms PI: 3.141592653570

    Threads: 7 Time: 7946.1ms PI: 3.141592653573

    Threads: 8 Time: 8774.5ms PI: 3.141592653573

    Threads: 9 Time: 9370.6ms PI: 3.141592653571

    Threads: 10 Time: 9920.8ms PI: 3.141592653585

    Threads: 11 Time: 10863.7ms PI: 3.141592653576

    Threads: 12 Time: 11574.2ms PI: 3.141592653582

    Statt mit steigender Anzahl Threads schneller zu werden, benötigt das Programm bei Aufteilung auf 12Threads (also je 1/12 Last auf alle der 12 verfügbaren Cores/Threads) doppelt so lange, als wenn man "nur" einen einzigen Thread laufen lässt....

    Dafuq. Genau dafür braucht man Multithreading NICHT!

    Schuld ist imho Windows(10 home), welches natürlich intensives Core-hopping betreibt, und das mit komplett ausgelasteten Kernen:Face:. Selbst wenn ich jetzt per SetProcessAffinityMask() (oder im Taskmanager) AutoIt nur 3 Cores statt 6 zur Verfügung stelle, verschlimmert sich das Problem nur....der Windows Scheduler wechselt fleissig alle paar Millisekunden den Core, und je mehr er davon hat, desto aufwendiger wird die Verwaltung....bis letztendlich bei der ganzen Verwalterei keine Rechenzeit für das Programm übrig bleibt....:theke:.

    Irgendetwas läuft gewaltig schief, aber was?:Glaskugel:

    Ideen? Infos?

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (23. Januar 2018 um 22:51)

  • Nach diesem Ergebnis würde mich und vermutlich auch andere brennend interessieren ob es unter den diversen

    Linuxen gleich beschissen aussieht.

    Ich bin dabei mir einen neuen Rechner zu planen und habe dabei mit einem ThreadRipper von AMD aus der mittleren

    Klasse geliebäugelt.

    Aber das wäre ja dann reinste Geldverschwendung wenn genau das was den Prozessor ausmacht, nämlich

    rigorosen Gebrauch von Mutlithreading zu machen und der Prozessor genau in dem Bereich vom System

    bei seiner grandiosen Arbeit behindert wird.

    Das erklärt aber auch warum Intel CPU's bei vielen Benchmarks so stark sind, weil eben alles Single-Threaded

    optimiert ist.(CPUs und Betriebs-System)

    Irgendwie ist das armseelig von Microsoft, die ersten Quadcore-CPUs habe ich vor fast 15 Jahren gesehen

    und bis heute ist Windows nicht im Stande die Multicore-CPU vernünftig zu nutzen und anzusteuern.

    Würdest und könntest du so einen Test auch für Linux(Ubuntu Mint Arch oder andere) durchführen mit hoffentlich

    besserem Ergebnis.

    Ich werde wohl ab dem nächsten Rechner auf Linux wechseln müssen, denn Windows 10 ist einfach ein nicht

    entschuldbarer schlechter Witz von Microsoft und dort eben gerne mit einem AMD Ryzen ThreadRipper.

    Dann fehlt nur noch eine Autoit-TRE Version und sonst eben GoLang und das als Google-Hasser.

    Ps:Autoit-ThreadRipperEdition

    Schönen Freitag Tuxedo

  • Sorry alpines aber bei diversen Benchmark Ergebnissen wird ganz sicher auf Teufel komm raus beschissen(sprich optimiert),

    wer da was optimiert hat weiss ich nicht ,aber ich denke es sind sowohl die Benchmark Software optimiert, aber auch

    der Prozessor Hersteller könnte seine Prozesoren daraufhin optimieren, daß sie bei bestimmten Benchmarks besser

    abschneiden.

  • der Prozessor Hersteller könnte seine Prozesoren daraufhin optimieren, daß sie bei bestimmten Benchmarks besser

    abschneiden.

    Der Prozessorhersteller hat doch, so wie ich Andy verstanden habe, nichts falsch gemacht. Die Last die auf den Kernen verteilt wird wird ganz allein von Windows entschieden.

    Wieso sollte ein Chiphersteller seine Technik für Benchmarks optimieren, wenn diese (oder sogar das Betriebssystem) nicht die volle Kapazität der CPU testen können.

  • Nach diesem Ergebnis würde mich und vermutlich auch andere brennend interessieren ob es unter den diversen

    Linuxen gleich beschissen aussieht.

    Weil mir das Thema keine Ruhe gelassen hat, habe ich mehr oder weniger intensiv recherchiert.

    So wie es aussieht, ist das ein Windows- und weniger ein Linux-Problem! Allerdings gibt es seit November schon einen Fix, welcher bei einigen Multicore-Spielen die FPS um bis zu 15% gesteigert hat.

    Weiterhin gibt es Programme zum rumspielen mit den Windows-Einstellungen, bspw. Mercury oder Lasso.

    Damit kann man u.a. SMT (Simultaneous Multithreading) ausschalten, hat also nur "echte" Cores und kein (Intel-) Hyperthreading.

    Für den Otto-Normalo Computerklimperer ist das sowieso alles nur theoretisch, der freut sich wie ein Schneekönig über seine "fette" CPU und Grafikkarte und benutzt dann die Programme der Softwarehersteller, welche natürlich um der Problematik wissen und somit Softwaretechnisch ALLES dafür tun, dass die Programme "geschmeidig" laufen. Die wären ja ehrlich gesagt auch bescheuert, wenn sie einen Haufen Arbeit in die Entwicklung von Multithreading-Software investieren würden und dann irgendein Spinner auf die Idee käme, das Programm in gleicher Geschwindigkeit auf einem Singlecore auszuführen!

    DAS wird unterbunden, indem den verfügbaren Threads nur "kurze" (wie im ursprünglichen AutoIt-Script gezeigt) Zeitscheiben zur Verfügung gestellt werden. Man achtet also seitens Software(ersteller) peinlich genau darauf, Multithreading nur dann einzusetzen, wenn es einen messbaren Vorteil bringt, also bei einfachen und "kurzen" bzw. gut parallelisierbaren Algorithmen.....

    Aber genau DIE wären ja per OpenCL bzw. CUDA wesentlich schneller auf einer GPU umzusetzen:rofl: Abgesehen von Algorithmen, welche besser auf einer CPU skalieren, aber das sind imho die großen Ausnahmen.

    Will sagen, einem "Otto"-Normalo reicht ein hochge(über)takteter billigst-Dual/Quadcore für seine "Standard"-Programme.

    Abgesehen von Anwendungen, die auf die Verwendung möglichst vieler Kerne ausgelegt sind, macht ein Mehrkernprozessor heutzutage keinen Sinn!

    Weiterhin hatte ich Kontakt mit einigen Leuten, welche intensiv sog. "Number-Crunching" betreiben. Solange der Algorithmus die Verwendung von OpenCL oder CUDA auf Grafikkarten einschränkt (denn da können die besten CPU´s keinen Blumenpott gewinnen) und somit auf CPU´s "gecruncht" wird, überlässt keiner der Programmierer dem BS (egal welchem) das Kommando über die Threads! Will heißen, der Programmierer ermittelt zuerst die Anzahl der verfügbaren Cores, erstellt dann die entsprechende Anzahl Threads und ordnet diese dann explizit (wie schon oben angesprochen per SetProcessAffinityMask() ) den einzelnen Kernen zu. Wenn man das exzessiv betreibt und bspw. einem Quadcore die 4 Kerne VOLL auslastet....dann....genau, bleibt dem BS keine "Zeit" bzw. Rechenpower. So etwas nennt man dann "einfrieren", da zuckt dann nicht mal mehr der Mauszeiger (der sowieso bei dieser Art Rechnerei niemals sichtbar ist, Console ftw :rock:). Ergo startet man die Berechnung und muss halt warten, bis das Ergebnis erreicht wird!

    Jedenfalls hat mich das auf die Idee gebracht, die einzelnen Threads im AutoIt-Script an die (n-1, ein Kern soll für Windows bleiben) verwendbaren Kerne explizit zu binden, also das Core-hopping einzuschränken. Dann werden bei einem Dualcore somit nur ein Kern, bei einem Quadcore nur drei Kerne usw. benutzt, und zwar exclusiv. Damit müsste dann, WENN es das BS überhaupt zulässt(!), die zu erwartende Laufzeitverbesserung eintreten.

    Das erklärt aber auch warum Intel CPU's bei vielen Benchmarks so stark sind, weil eben alles Single-Threaded

    optimiert ist.(CPUs und Betriebs-System)

    hehe, genau DAS ist das Problem. Die Software könnte seit Jahrzehnten wesentlich schneller sein, wenn die Programmierer bzw. die Compilerhersteller die Funktionen der CPU´s auch nur annähernd ausnutzen würden. Aber ich denke, da hackt die eine Krähe der anderen kein Auge aus. Hardware wird sowieso für die Anwendungen produziert, die Geld in die Kassen spülen, also Militär und Überwachung. Und die Software für genau diese Anwendungen wird von Spezialisten erstellt, welche jedes kleine Quentchen Performance aus der Hardware rausholen (können). Und ich glaube nicht, dass bei diesen Anwendungen ein "Standard"-Windows(Server) oder Linux verwendet wird.

    Ich werde wohl ab dem nächsten Rechner auf Linux wechseln müssen, denn Windows 10 ist einfach ein nicht

    entschuldbarer schlechter Witz von Microsoft und dort eben gerne mit einem AMD Ryzen ThreadRipper.

    Dann fehlt nur noch eine Autoit-TRE Version und sonst eben GoLang und das als Google-Hasser.

    Alternativ schau dich mal im Lager der Anbieter von Rechenleistung um. Wo ist denn das Problem, für 500€ einen PC zu kaufen, dort Software zu schreiben und diese dann bspw. auf Amazon- oder Google- oder wasweissich-Rechenzentren mit x-tausenden von Kernen/Threads laufen zu lassen. Selbst wenn diese Dienstleistung ein paar Euros im Monat/Jahr kosten sollte, kommst du da WESENTLICH billiger weg wie mit einem aktuellen Multicore-Prozessor. Wobei die Threadripper schon vergleichsweise günstig sind. Aber kannst du diese vielen Kerne überhaupt "sinnvoll" ausnutzen?!

    Aber Recht hast du, um Windows beim exzessiven Core-hopping zuzuschauen, ist das Geld zu schade....:theke:

  • Dankeschön für die detailierte Darstellung, das Thema ist ja wesentlich komplexer als ich mir dachte.

    Aber Aufgrund deiner Erläuterungen werde ich wohl oder übel umdenken und statt eines Threadrippers

    mich nach einem im Singlecorebetrieb möglichst flotten 4 Kerner umsehen(falls man sowas Altes noch kiregt) oder den Publikumsliebling Ryzen 5 1600 nehmen.

    Meine Anforderungen sind nicht die höchsten, zum Zocken brauche ich es nicht unbedingt, aber Filme encoden(HD-Material)

    braucht doch einiges an Leistung oder auch Spectral-Wave-Editing ist auch sehr Leistungshungrig.

    Danke für die Infos

    Tuxedo

  • Die Last die auf den Kernen verteilt wird wird ganz allein von Windows entschieden.

    Eben, und imho sollte (muss) das ein modernes BS auch so machen!

    Wieso sollte ein Chiphersteller seine Technik für Benchmarks optimieren, wenn diese (oder sogar das Betriebssystem) nicht die volle Kapazität der CPU testen können.

    Das wurde "früher" gerne gemacht, kam aber raus und sorgte für schlechte Publicity^^.

    Man sollte aber im Hinterkopf behalten, dass es SO GUT WIE KEINE Software auf dem Markt gibt, welche das von mir im Script gezeigte Szenario, also volle Last über eine (in Prozessorzeit) unendlich lange Zeit, vollführt!

    Über ein Bild, völlig egal in welcher Auflösung, jagd man einen völlig egal wie programmierten Filter. Das dauert auf einem Singlecore wegen mir einige Sekunden, bei einem Multicore ist das dann Faktor x schneller. Punkt. Niemand, aber auch niemand (Otto-Normalo-PC-User) braucht heutzutage die brachiale Leistung eines Core i5/i7/Ryzen. Gebraucht wird von diesen Usern ein brachial hoher Takt für Single-Core-Leistung, und genau DAS ist ein RIESEN Unterschied!

    Während ich diesen Text schreibe, liegt mein Prozessor zwischen jedem Tastenanschlag 99,999% aller Takte im C6, also TIEFSCHLAF! Da juckt es Windows überhaupt nicht, zwischen den aktuell 185 Prozessen und ca. 2000 Threads hin- und herzuschalten. Aber wehe EINER dieser Prozesse verlangt nach (voller) Leistung, dann müssen die anderen "warten". Jeder PC-User, egal mit welchem High-tech-Prozessor kennt die Trägheit des BS, wenn bsw. "fette" Windows-Updates im Hintergrund installiert werden.

    und statt eines Threadrippers

    mich nach einem im Singlecorebetrieb möglichst flotten 4 Kerner umsehen(falls man sowas Altes noch kiregt) oder den Publikumsliebling Ryzen 5 1600 nehmen.

    Tja, imho ist der Threadripper der ideale Prozessor für eine Workstation mit entsprechender Software. Und da übersteigt der Preis der Software die Hardware idR um ein Vielfaches!

    Meine Anforderungen sind nicht die höchsten, zum Zocken brauche ich es nicht unbedingt, aber Filme encoden(HD-Material)

    braucht doch einiges an Leistung oder auch Spectral-Wave-Editing ist auch sehr Leistungshungrig.

    Wenn du die Möglichkeit hast, schau mal ob du für die Software auf dem jeweiligen Prozessor entsprechend Benchmarks bekommst. Fürs "reine" Zocken ist das so oder so völlig unerheblich^^

    Filme encoden(HD-Material) oder auch Spectral-Wave-Editing könnten je nach Programmierung von (je mehr desto besser) "vielen" Cores profitieren.

    Versuch macht kluch:thumbup:

    Btw., der Ryzen 5 1600X hat beides, gute Singlecore- als auch sehr gute Multicore-Performance. Out of the Box. Wenn du übertaktest, dann ist der 1600 ca. 10%billiger und letztendlich genau so schnell wie der 1600X.

    Also wie immer....:Glaskugel:die Glaskugel wirds schon richten:rofl: