Das längste Thema

  • Aber selbst, wenn es irgendwie geht: Wer würde das machen und vor allem warum? Damit schränkt man sich doch nur unnötig ein.

    ich hatte das auf meinem Notebook aus dem Jahr 2006 so, nur so konnte ich damals bereits f. 64-bit Programmieren ohne 64-bit installiert zu haben ...

    Host-OS war ein WinXP und Guest-OS war ein WinXP x64 (dafür zwackte ich ½ GB RAM vom Host-OS ab)

    war nur neugierig in wie weit die KVM-VIrtualisierung reicht; heute ist das ohnehin kein Thema mehr, es geht in die andere Richtung, auf einer potenten Kiste mit einem 64-bit OS wird ein schmales OS mit 32-bit virtualisiert;

  • Ja, wobei Netcup noch weiter geht. Netcup meint meines Wissens nach wirklich dedizierte Kerne, während der andere Anbieter mit ded. vCPU einen Hyperthread meint.

    das würde ich so nicht unbedingt sehen; meine CPU zu Hause ein Core-i7-3820 hat 4 Kerne und 2 Threads je Kern; so strange es auch aussieht, aber es gibt von Intel einen Benchmark - Linpack - und dieser liefert nativ am Host knapp mehr als 50% dessen, was er in einer VM in der ich 1 CPU mit 8(!) Kernen habe ...


    was sich dem Benutzer präsentiert hat dieser z.B. im Task-Manager keinen Unterschied ob es eine CPU mit z.B. 4 Kernen ohne HT od. eine Dual-Core CPU mit HT od. 2 Dual-Core CPUs ohne HT ist/sind ...

  • was sich dem Benutzer präsentiert hat dieser z.B. im Task-Manager keinen Unterschied ob es eine CPU mit z.B. 4 Kernen ohne HT od. eine Dual-Core CPU mit HT od. 2 Dual-Core CPUs ohne HT ist/sind ...

    Das stimmt so aber nicht, im Taskmanager sieht man sehr wohl einen Unterschied ;)


    pasted-from-clipboard.png

    Und die meisten Scheduler versuchen schon, wenn sie z.B. zwei Threads (von zwei verschiedenen Programmen) haben die viel CPU brauchen, diese auf physikalisch getrennte Cores laufen zu lassen und nicht auf einem zwei logischen Cores die auf einen Core abbilden.

  • Die Ausfallquote bei diesen Systemen den anderen Anbieters ist aktuell auch sehr hoch.

    Davon hatte ich auch gelesen, aber auch dass in dem primär betroffenen RZ das Problem wohl behoben sei (und seitdem war in dem Thread dort im Forum auch nichts mehr groß los).


    Ich teste dort derzeit halt rum und sobald netcup auch eine Bestell-API hat (mit Cloud-Init) tausch ich nur den API-Client darunter aus (so meine romantische Vorstellung :D )

  • Das stimmt so aber nicht, im Taskmanager sieht man sehr wohl einen Unterschied ;)

    screenTaskmgr.png

    bei mir sieht es so aus;)

    Und die meisten Scheduler versuchen schon, wenn sie z.B. zwei Threads (von zwei verschiedenen Programmen) haben die viel CPU brauchen, diese auf physikalisch getrennte Cores laufen zu lassen und nicht auf einem zwei logischen Cores die auf einen Core abbilden.

    der von Windows zählt hier nicht dazu :D

  • Davon hatte ich auch gelesen, aber auch dass in dem primär betroffenen RZ das Problem wohl behoben sei (und seitdem war in dem Thread dort im Forum auch nichts mehr groß los).


    Ich teste dort derzeit halt rum und sobald netcup auch eine Bestell-API hat (mit Cloud-Init) tausch ich nur den API-Client darunter aus (so meine romantische Vorstellung :D )

    Das ist richtig, die API ist wirklich nicht schlecht.

  • bei mir sieht es so aus

    Konnte ja nicht wissen das wir hier von Systemen reden, die seit Jahren nicht mehr supported werden, zu der Zeit gab es glaub nicht mal Hyper-Threading (Win 2000 vermute ich mal) ^^

    der von Windows zählt hier nicht dazu

    Warum nicht? Unter Linux gibt es auch Task-Viewer die das anzeigen, außerdem findet man das recht schnell in der Konsole raus ^^ Und der Scheduler ist sich bewusst wenn Hyper-Threading vorhanden ist, das zwei logische Cores auf einen physikalischen Core abbilden. Kann ja auch sinnvoll sein zu wissen was der Hyperthread-Core ist und was nicht, falls man z.B. CPU-Pinning oder ähnliches nutzt (gibt Fälle da sind zwei physikalische Cores besser, aber auch Fälle wo zwei Hyper-Threaded Cores besser sind die auf eine physikalische CPU abbilden, Caching etc.).

  • Zitat Windows Internals 7:

    Code
    1. On a uniprocessor system, scheduling is relatively simple: The highest-priority thread that wants to run is always running. On a multiprocessor system, it is more complex. This is because Windows attempts to schedule threads on the most optimal processor for the thread, taking into account the thread’s preferred and previous processors as well as the configuration of the multiprocessor system.
  • Und unter Linux gibt es passend dazu "CONFIG_SCHED_SMT" (SMT (Hyperthreading) scheduler support) als Konfigurationsparameter für den Kernel.


    Von daher achtet jedes (halbwegs moderne) Betriebssystem schon darauf auf was für Kerne es läuft und erkennt einen Unterschied zwischen zwischen 8 physikalischen Kerne (ohne HT) und 8 logischen Kernen die nur auf 4 physikalische Kerne (dankt HT) abbilden. Und meist wird dies auch dem Nutzer direkt angezeigt bzw. man kann es abfragen ;)

  • Konnte ja nicht wissen das wir hier von Systemen reden, die seit Jahren nicht mehr supported werden, zu der Zeit gab es glaub nicht mal Hyper-Threading (Win 2000 vermute ich mal)

    nicht mehr supported ist gut; zum Zeitpunkt als ich mir den Rechner kaufte gabs den Support noch; ;)

    und nein es ist ein WinXP x64 :)


    zum Windows Scheduler hat ThomasChr es schon gesagt; und das hat die Konsequenz, daß aus Sicht des Schedulers, der Core/Thread mit der niedrigsten Auslastung der beste ist, und schon wird, wenn nichts dagegen spricht 'geschoben' mit allen Konsequenzen: man beachte hier wie die Caches organisiert sind: L1, L2, und falls vorhanden L3

    das ist auch einer der Gründe warum eine 2te CPU nur eine Leistungssteigerung von rund 60% bringt (stammt aus der Zeit, in denen es nur Single-Cores gab);

    der Nachteil den eine einzelne Multicore-CPU gegenüber mehreren Single-Core CPUs hat, wird durch den L2 bzw. L3 Cache auch nur zum Teil wieder wettgemacht;


    julian-w zum Thema physikalische und logische Kerne; es gibt CPUs - keine der x86(_64)-Architektur - die haben pro physikalischem Kern nicht nur 2 sondern 3 od. mehr logische Kerne

  • Quote

    How does Windows exploit hyperthreading?


    For Windows 95, Windows 98, and Windows Me, the answer is simple: Not at all.


    For Windows NT and Windows 2000, the answer is "It doesn't even know." These operating systems are not hyperthreading-aware because they were written before hyperthreading was invented.


    Windows XP and Windows Server 2003 are hyperthreading-aware.


    aus: https://blogs.msdn.microsoft.com/oldnewthing/20040913-00/?p=37883 vom September 2004.

  • zum Windows Scheduler hat ThomasChr es schon gesagt; und das hat die Konsequenz, daß aus Sicht des Schedulers, der Core/Thread mit der niedrigsten Auslastung der beste ist, und schon wird, wenn nichts dagegen spricht 'geschoben' mit allen Konsequenzen

    Aber gerade da wird doch erwähnt, das der Scheduler auf die Core-Konfiguration achtet: "taking into account [...] as well as the configuration of the multiprocessor system." Und vmk hat das ja noch passend ergänzt: "Windows XP and Windows Server 2003 are hyperthreading-aware."


    Und das es Rechenkerne mit anderen Konfiguration gibt wie 2 logische Cores pro physikalischem Core ist ja erst mal egal, das ist halt nur der einfachste Fall. Von daher wird der Windows Scheduler vermutlich eher einen neune CPU-lastigen Thread auf einen zu 5% belegten physikalischen Core legen, anstatt ihn auf den "HyperThread-Core" eines physikalischen Cores zu legen, der zu 100% bereits ausgelastet ist. Erst wenn alle "physikalischen Cores" zu sind, macht es Sinn die HT-Cores zu nutzen (in den meisten Fällen). Okay die Benennung ist etwas doof, aber ich denke man versteht es ^^


    und das hat die Konsequenz, daß aus Sicht des Schedulers, der Core/Thread mit der niedrigsten Auslastung der beste ist

    Nur vor Windows XP, ab dann nicht mehr ;) Bei Linux finde ich gerade die Kernel-Version nicht :/

    nicht mehr supported ist gut; zum Zeitpunkt als ich mir den Rechner kaufte gabs den Support noch;

    Security is a Journey, Not a Destination ;)

  • vmk interessanter Artikel, nur daß MS selbst nicht wußte, daß Win2000 mit dem SericePack 4 HT dennoch unterstützte;


    Win[95,98,ME] sind eigentlich nur ein Win32s 4.x:


    - der OS Unterbau ist nach wie vor ein 16-bit DOS mit CONFIG.SYS/AUTOEXEC.BAT

    wie zu Win 3.1x Zeiten wo Win32s als Erweiterung eingeführt wurde und DOS als Voraussetzung galt;


    - diese nutzen demnach auch keine zusätzlichen CPUs ...


    Microsoft bastelte mehrmals herum, der Vorläufer vom DirectX war das WinG

    und wurde auch erstmals mit Win 3.1x eingeführt;

    sämtliche Entwicklungen f. das WinG konnteste dann mit DirectX verwefen;


    und so krass es sich auch anhört, daß Windows 10 eben Windows 10 benannt wurde und nicht Windows 9 (Nachfolge von Windows 8.1)

    liegt genau in dieser seltsamen Historie


    julian-w auch bei WinXP und später, es heißt nur daß ab diesen Versionen das Windows zwar die Kenntnis¹ von HT hat,

    aber deswegen nicht zwingend intelligent scheduled ...


    ¹ es zumindest verhindert, daß er zwischen Thread A1 und Thread A2 an Stelle von Thread A1 und Thread B1 scheduled;


    hier wird nur ein CPU-intensiver Prozess mit nur einem Thread hin- und hergeschaukelt

    screenTaskmgr.png

    intelligentes Scheduling sieht anders aus;

    wie bereits erwähnt, der L1 und L2 Cache ist NICHT CPU-weit der selbe,

    und dieser muss bei jedem Core-Wechsel neu befüllt werden und das kostet ...