App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
SMT/CMT-Kernzuordnen in Windows-Betriebssystemen
- Ersteller miriquidi
- Erstellt am
Unbekannter Krieger
Grand Admiral Special
- Mitglied seit
- 04.10.2013
- Beiträge
- 4.552
- Renomée
- 99
- Mein Laptop
- HP 15-bq102ng (sackteuer u. ab Werk instabil)
- Prozessor
- FX-8320E@4,2 GHz & 2,6 GHz Northbridge (jeweils mit UV)
- Mainboard
- Asus M5A99X Evo R2.0 (eher enttäuschend ggü. ASRock E3)
- Kühlung
- Raijintek Nemesis (Lüfter mittig im sowie hinter dem Kühler; erstklassig)
- Speicher
- 4x4 GiB Hynix DDR3-1866 ECC
- Grafikprozessor
- XFX RX 570 8G (P8DFD6)@1180 & 2150 MHz@starkem, fortdauerndem UV | ASRock RX 570 8G@das Gleiche
- Display
- BenQ XL2411T ~ nach 3 RMAs und 6 Monaten wieder brauchbar
- SSD
- Crucial MX100 256 GB (ein Glückskauf) | SanDisk Ultra Plus 256 GB (ein Glückskauf)
- HDD
- WD20EZRZ u. a. (Seagate, Hitachi, WD)
- Optisches Laufwerk
- TSST SH-222AL
- Gehäuse
- Corsair Carbide 300R (ein Fehlkauf)
- Netzteil
- CoolerMaster V450S (ein Glückskauf)
- Betriebssystem
- Win8.x x64, Win7 x64
- Webbrowser
- welche mit minimalem Marktanteil & sinnvollen Konzepten (nicht Chrome-Seuche und Sieche-Fuchs)
- Verschiedenes
- frühere GPUs: , Asus RX 480 O8G@580 O8G, VTX3D 7850 1G
AM für A Main und AS für A Secondary?miriquidi schrieb:Eigentlich sind A und A* die zwei logischen Kernen des ersten physischen Kerns. Meine Bezeichnung ist aber nicht sehr gut, das muss irgendwie besser gehen.
A1 und A2 als logische Kerne des physischen Kerns A?
Windows 7 mit den meisten aktuellen Windows-Updates, die nicht als fragwürdig gelten, auf meinem FX-8320E@4,2 GHz auf Asus M5A99X Evo R2.0:Gibt's hier noch Bulldozer-Nutzer mit Windows 7 oder 8?
http://up.picr.de/28124810mn.jpg
Coreinfo bestätigte das.
Auf einem Kern lief etwas Kleines nebenher.
Win7 ohne Updates sowie Win8.x mit der überwiegenden Anzahl Updates werden folgen.
Zuletzt bearbeitet:
Kannst du bei dir mal Coreinfo durchlaufen lassen? Dann sollte es klar sein.Die Screenshots von WindHund zeigen aber eine "geordnete" Core-Reihenfolgen für den FX-8350. Eine Erklärung wäre, das AMD den Käse bei den 81xx-ern erkannt hat und bei Nachfolgern dies korrigierte.
Scheint aber so zu sein, dass man die Reihenfolge A1, A2, B1, B2, C1, ... weitgehend als Industriestandard ansehen kann.
WindHund
Grand Admiral Special
- Mitglied seit
- 30.01.2008
- Beiträge
- 12.240
- Renomée
- 538
- Standort
- Im wilden Süden (0711)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- NumberFields@home
- Lieblingsprojekt
- none, try all
- Meine Systeme
- RYZEN R9 3900XT @ ASRock Taichi X570 & ASUS RX Vega64
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 9 5950X
- Mainboard
- ASRock 570X Taichi P5.05 Certified
- Kühlung
- AlphaCool Eisblock XPX, 366x40mm Radiator 6l Brutto m³
- Speicher
- 2x 16 GiB DDR4-3600 CL26 Kingston (Dual Rank, unbuffered ECC)
- Grafikprozessor
- 1x ASRock Radeon RX 6950XT Formula OC 16GByte GDDR6 VRAM
- Display
- SAMSUNG Neo QLED QN92BA 43" up to 4K@144Hz FreeSync PP HDR10+
- SSD
- WD_Black SN850 PCI-Express 4.0 NVME
- HDD
- 3 Stück
- Optisches Laufwerk
- 1x HL-DT-ST BD-RE BH10LS30 SATA2
- Soundkarte
- HD Audio (onboard)
- Gehäuse
- SF-2000 Big Tower
- Netzteil
- Corsair RM1000X (80+ Gold)
- Tastatur
- Habe ich
- Maus
- Han I
- Betriebssystem
- Windows 10 x64 Professional (up to date!)
- Webbrowser
- @Chrome.Google & Edge Chrome
Auch eine Möglichkeit, ja.AM für A Main und AS für A Secondary?
Windows 7 mit den meisten aktuellen Windows-Updates, die nicht als fragwürdig gelten, auf meinem FX-8320E@4,2 GHz auf Asus M5A99X Evo R2.0:
http://up.picr.de/28124810mn.jpg
Coreinfo bestätigte das.
Auf einem Kern lief etwas Kleines nebenher.
Win7 ohne Updates sowie Win8.x mit der überwiegenden Anzahl Updates werden folgen.
In einem "Modul" können beide beides sein, wenn das richtige Flag gesetzt wurde.
Wie bei Memory Controller?Kannst du bei dir mal Coreinfo durchlaufen lassen? Dann sollte es klar sein.
Scheint aber so zu sein, dass man die Reihenfolge A1, A2, B1, B2, C1, ... weitgehend als Industriestandard ansehen kann.
Athlon 5350: http://abload.de/img/corepairingatlohn_yts7jsjg.jpg
WindHund
Grand Admiral Special
- Mitglied seit
- 30.01.2008
- Beiträge
- 12.240
- Renomée
- 538
- Standort
- Im wilden Süden (0711)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- NumberFields@home
- Lieblingsprojekt
- none, try all
- Meine Systeme
- RYZEN R9 3900XT @ ASRock Taichi X570 & ASUS RX Vega64
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 9 5950X
- Mainboard
- ASRock 570X Taichi P5.05 Certified
- Kühlung
- AlphaCool Eisblock XPX, 366x40mm Radiator 6l Brutto m³
- Speicher
- 2x 16 GiB DDR4-3600 CL26 Kingston (Dual Rank, unbuffered ECC)
- Grafikprozessor
- 1x ASRock Radeon RX 6950XT Formula OC 16GByte GDDR6 VRAM
- Display
- SAMSUNG Neo QLED QN92BA 43" up to 4K@144Hz FreeSync PP HDR10+
- SSD
- WD_Black SN850 PCI-Express 4.0 NVME
- HDD
- 3 Stück
- Optisches Laufwerk
- 1x HL-DT-ST BD-RE BH10LS30 SATA2
- Soundkarte
- HD Audio (onboard)
- Gehäuse
- SF-2000 Big Tower
- Netzteil
- Corsair RM1000X (80+ Gold)
- Tastatur
- Habe ich
- Maus
- Han I
- Betriebssystem
- Windows 10 x64 Professional (up to date!)
- Webbrowser
- @Chrome.Google & Edge Chrome
@Helle53
Mein Windows 7 Pro ist mit allen aktuellen Updates, es lief aber ein YT Stream im Hintergrund.
Vielen Dank für dein kleines Progrämmchen, das macht schon was her (in der kurzen Zeit) !
Nutzt dein FX-81xx schon UEFI oder noch Bios?
ISt der AGESA code vom Mainboard aktuell?
Mein Windows 7 Pro ist mit allen aktuellen Updates, es lief aber ein YT Stream im Hintergrund.
Vielen Dank für dein kleines Progrämmchen, das macht schon was her (in der kurzen Zeit) !
Nutzt dein FX-81xx schon UEFI oder noch Bios?
ISt der AGESA code vom Mainboard aktuell?
Ge0rgy
Grand Admiral Special
- Mitglied seit
- 14.07.2006
- Beiträge
- 4.322
- Renomée
- 82
- Mein Laptop
- Lenovo Thinkpad X60s
- Prozessor
- Phenom II 955 BE
- Mainboard
- DFI LanParty DK 790FXB-M3H5
- Kühlung
- Noctua NH-U12P
- Speicher
- 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
- Grafikprozessor
- Radeon 4850 1GB
- HDD
- Western Digital Caviar Black 1TB
- Netzteil
- Enermax Modu 525W
- Betriebssystem
- Linux, Vista x64
- Webbrowser
- Firefox 3.5
Sorry wenn ich mich hier einmische und ich muss zugeben ich kann die Grundfrage nur rudimentär beantworten, aber ich stelle die Gegenfrage ob dieses "festnageln" heute überhaupt noch sinnvoll ist?
Dass wir hier über CPU-Kerne und dabei noch logische und reale etc. unterscheiden ist eine rein historisch gewachsene und dem konkreten Design von Hardware geschuldete Tatsache.
Wenn man sich aber Konstrukte wie Xeon Phi, GPUs sowie APUs ansieht und dazu die sich langsam entwickelnden Trends bei der Software, wird diese art von Zuteilung über kurz oder lang obsolet.
Man hat im Prinzip nur noch einen Pool von Computing-Ressourcen und befüttert ihn. Auf ähnliche Weise funktionieren die Thread-Pools in der TPL in .Net zusammen mit async/await. Man verwaltet nicht mehr Threads mit shared state, sondern bricht das Programm in möglichst viele unabhängige Einheiten herunter die man dann vom Scheduler auf die vorhandenen Computing-Ressourcen verteilen lässt. - Am Ende muss man quasi "nur" noch die Verdrahtung übernehmen wann wer auf das Ergebnis von wem anderen warten muss und quasi wieder composite Tasks zusammenbauen.
In Ähnliche Kerben schlagen Frameworks wie Akka in Java (Actors) und auch AMD will ja mit HSA effektiv dahin.
Man hat einen Pool von (mglw. unterschiedlichen) Ressourcen und versucht die gegebene Menge an Aufgaben (Tasks) möglichst rasch abgearbeitet zu bekommen. Dabei ist der Durchsatz wichtiger als die Latenz, d.h. lieber eine Task auf eine sub-optimale Recheneinheit schieben, als dass sie garnicht bearbeitet wird, bis eine der besseren Einehiten endlich frei ist...
Das dürfte das Programmiermodell der Zukunft sein was multithreading angeht und ist wesentlich besser skalierbar (Stichworte massively multicore, Virtualisierung, Cloud etc.) als der alte Ansatz.
Vorteile dabei sind dass man bei Änderung der Anzahl an Recheneinheiten nicht die Programmierung ändern muss, nur der Pool wird größer bzw. kleiner, ebenso spielt es keien Rolle ob echter Kern, SMT kern oder durch irgendwelche Virtualisierungsmechanismen simulierte, logische Computing-Einheit.
Konkret auf aktuelle CPUs und Bestandscode bezogen kommt noch ein Weiterer Punkt hinzu. Ich glaube die Diskussion hatten wir zu Bulldozer-Zeiten hier schonmal und auch wenn das bei Bulldozer sub-optimal gelöst wurde ist das nicht unbedingt ein Naturgesetz.
Wenn ich einen 4-Kerne mit HT habe und 4 Aufgaben zu verarbeiten habe, gibt es mind. 2 Möglichkeiten:
1. Ich nutze pro "echtem" Kern eine Aufgabe, umgehe also SMT und habe gleichmäßig jeden Kern ausgelastet.
2. Ich nutze die ersten beiden Kerne + ihre SMT-Zwillinge.
Nun ist es ein implementierungsdetail wer davon schneller ist. Das hängt nämlich maßgeblich von der SMT-Effizienz, Caching-Geschichten usw. und vor allem, Stromspar- und Turbomodi ab. Im 2. Fall kann der halbe Prozessor schlafen und die beiden arbeitenden physikalischen Kerne höher takten wegen freiem Thermal Budget.
Im zweigen Fall habe ich, dadurch dass kein Kern powergated werden kann, nicht soviel Spielraum.
Wir haben also den klassischen fall von eher wenigern, höher getakteten Transistoren, kontra mehr Transistoren auf niedrigerem Takt.
Und dabei hängt die Performance nun maßgeblich von anderen Faktoren und Details der Maschine ab als von CPU-Kern-Nummern.
(Das wird im Übrigen bei Zen auch noch interessant mal mit Bulldozer und den Intels zu vergeichen..)
Das ist einer der Gründe warum der Trend beim Multithreading eher weg geht von konkreten Kernen und irgendwelchen Zuordnungen hin zu flexiblen Pooling-Artigen Modellen.
Das mag für einzelne Workunits nicht immer zum optimalen Scheduling führen, ist in der Summe, aber am Durchsatzstärksten.
Ein Apache oder IIS schickt euch ja auch keine Fehlermeldung nur weil er gerade keine phyischen CPU-Kerne mehr frei hat um euren Request zu verarbeiten.
Soviel mal als Denkanstoß.
Das Thread-Scheduling im OS ist im Übrigen auch "subject to change" sobald sich die heterogenen Gerätschaften mehr durchsetzen. Da gibts dann bestenfalls noch eine Art Klassifizierung nach "Floating Point, Floating Point Vector, Integer, Integer Vector" o.ä. und Pools aus den selbigen.
Grüße,
Meine Wenigkeit.
Dass wir hier über CPU-Kerne und dabei noch logische und reale etc. unterscheiden ist eine rein historisch gewachsene und dem konkreten Design von Hardware geschuldete Tatsache.
Wenn man sich aber Konstrukte wie Xeon Phi, GPUs sowie APUs ansieht und dazu die sich langsam entwickelnden Trends bei der Software, wird diese art von Zuteilung über kurz oder lang obsolet.
Man hat im Prinzip nur noch einen Pool von Computing-Ressourcen und befüttert ihn. Auf ähnliche Weise funktionieren die Thread-Pools in der TPL in .Net zusammen mit async/await. Man verwaltet nicht mehr Threads mit shared state, sondern bricht das Programm in möglichst viele unabhängige Einheiten herunter die man dann vom Scheduler auf die vorhandenen Computing-Ressourcen verteilen lässt. - Am Ende muss man quasi "nur" noch die Verdrahtung übernehmen wann wer auf das Ergebnis von wem anderen warten muss und quasi wieder composite Tasks zusammenbauen.
In Ähnliche Kerben schlagen Frameworks wie Akka in Java (Actors) und auch AMD will ja mit HSA effektiv dahin.
Man hat einen Pool von (mglw. unterschiedlichen) Ressourcen und versucht die gegebene Menge an Aufgaben (Tasks) möglichst rasch abgearbeitet zu bekommen. Dabei ist der Durchsatz wichtiger als die Latenz, d.h. lieber eine Task auf eine sub-optimale Recheneinheit schieben, als dass sie garnicht bearbeitet wird, bis eine der besseren Einehiten endlich frei ist...
Das dürfte das Programmiermodell der Zukunft sein was multithreading angeht und ist wesentlich besser skalierbar (Stichworte massively multicore, Virtualisierung, Cloud etc.) als der alte Ansatz.
Vorteile dabei sind dass man bei Änderung der Anzahl an Recheneinheiten nicht die Programmierung ändern muss, nur der Pool wird größer bzw. kleiner, ebenso spielt es keien Rolle ob echter Kern, SMT kern oder durch irgendwelche Virtualisierungsmechanismen simulierte, logische Computing-Einheit.
Konkret auf aktuelle CPUs und Bestandscode bezogen kommt noch ein Weiterer Punkt hinzu. Ich glaube die Diskussion hatten wir zu Bulldozer-Zeiten hier schonmal und auch wenn das bei Bulldozer sub-optimal gelöst wurde ist das nicht unbedingt ein Naturgesetz.
Wenn ich einen 4-Kerne mit HT habe und 4 Aufgaben zu verarbeiten habe, gibt es mind. 2 Möglichkeiten:
1. Ich nutze pro "echtem" Kern eine Aufgabe, umgehe also SMT und habe gleichmäßig jeden Kern ausgelastet.
2. Ich nutze die ersten beiden Kerne + ihre SMT-Zwillinge.
Nun ist es ein implementierungsdetail wer davon schneller ist. Das hängt nämlich maßgeblich von der SMT-Effizienz, Caching-Geschichten usw. und vor allem, Stromspar- und Turbomodi ab. Im 2. Fall kann der halbe Prozessor schlafen und die beiden arbeitenden physikalischen Kerne höher takten wegen freiem Thermal Budget.
Im zweigen Fall habe ich, dadurch dass kein Kern powergated werden kann, nicht soviel Spielraum.
Wir haben also den klassischen fall von eher wenigern, höher getakteten Transistoren, kontra mehr Transistoren auf niedrigerem Takt.
Und dabei hängt die Performance nun maßgeblich von anderen Faktoren und Details der Maschine ab als von CPU-Kern-Nummern.
(Das wird im Übrigen bei Zen auch noch interessant mal mit Bulldozer und den Intels zu vergeichen..)
Das ist einer der Gründe warum der Trend beim Multithreading eher weg geht von konkreten Kernen und irgendwelchen Zuordnungen hin zu flexiblen Pooling-Artigen Modellen.
Das mag für einzelne Workunits nicht immer zum optimalen Scheduling führen, ist in der Summe, aber am Durchsatzstärksten.
Ein Apache oder IIS schickt euch ja auch keine Fehlermeldung nur weil er gerade keine phyischen CPU-Kerne mehr frei hat um euren Request zu verarbeiten.
Soviel mal als Denkanstoß.
Das Thread-Scheduling im OS ist im Übrigen auch "subject to change" sobald sich die heterogenen Gerätschaften mehr durchsetzen. Da gibts dann bestenfalls noch eine Art Klassifizierung nach "Floating Point, Floating Point Vector, Integer, Integer Vector" o.ä. und Pools aus den selbigen.
Grüße,
Meine Wenigkeit.
Zuletzt bearbeitet:
sompe
Grand Admiral Special
- Mitglied seit
- 09.02.2009
- Beiträge
- 14.860
- Renomée
- 2.173
- Mein Laptop
- Dell G5 15 SE 5505 Eclipse Black
- Prozessor
- AMD Ryzen 9 3950X
- Mainboard
- MSI MPG X570 GAMING PRO CARBON WIFI
- Kühlung
- Wasserkühlung
- Speicher
- 4x 16 GB G.Skill Trident Z RGB, DDR4-3200, CL14
- Grafikprozessor
- AMD Radeon RX 6900 XT
- Display
- 1x 32" LG 32UD89-W + 1x 24" Dell Ultrasharp 2405FPW
- SSD
- Samsung SSD 980 PRO 1TB, Crucial MX500 500GB, Intel 600p 512GB, Intel 600p 1TB
- HDD
- Western Digital WD Red 2 & 3TB
- Optisches Laufwerk
- LG GGC-H20L
- Soundkarte
- onboard
- Gehäuse
- Thermaltake Armor
- Netzteil
- be quiet! Dark Power Pro 11 1000W
- Betriebssystem
- Windows 10 Professional, Windows 7 Professional 64 Bit, Ubuntu 20.04 LTS
- Webbrowser
- Firefox
Hat mal jemand einen Vergleich zwischen einem Urschleim Windows 7 und einer Version auf dem aktuellen Stand gemacht um den Einfluss des Shedulers zu untersuchen?
@helle53: Danke. Dann scheint das beim Bulldozer V1 ein (bedauerlicher) Einzelfall zu sein.
@Ge0rgy: Bringt es etwas. Ich kann das jetzt nur konkret für meine Applikation beantworten: Ein i7-Sandy Bridge Doppelkern mit aktivem HT rechnet mit 4 Threads ein wenig schneller als mit zwei Threads (die von Windows verteilt werden). Das ist jedoch sehr von der Tagesform von Windows abhängig und können durchaus mal 15 % sein.
Rechne ich mit zwei Threads und nagle sie auf die physischen Kerne fest, bringt das gegenüber 4 Threads nochmal 5,5 % mehr Geschwindigkeit. Bzw. in 3 Monaten eine Zeitersparnis von 4 Tagen. Oder anders betrachtet, bei einem "richtigen" Prozessor wie einem Xeon mit 16 Kernen bzw. 32 Threads mal eben 32 GB weniger RAM-Bedarf. Insofern würde ich sagen, ja es lohnt sich (für mich).
@Ge0rgy: Bringt es etwas. Ich kann das jetzt nur konkret für meine Applikation beantworten: Ein i7-Sandy Bridge Doppelkern mit aktivem HT rechnet mit 4 Threads ein wenig schneller als mit zwei Threads (die von Windows verteilt werden). Das ist jedoch sehr von der Tagesform von Windows abhängig und können durchaus mal 15 % sein.
Rechne ich mit zwei Threads und nagle sie auf die physischen Kerne fest, bringt das gegenüber 4 Threads nochmal 5,5 % mehr Geschwindigkeit. Bzw. in 3 Monaten eine Zeitersparnis von 4 Tagen. Oder anders betrachtet, bei einem "richtigen" Prozessor wie einem Xeon mit 16 Kernen bzw. 32 Threads mal eben 32 GB weniger RAM-Bedarf. Insofern würde ich sagen, ja es lohnt sich (für mich).
Ähnliche Themen
- Antworten
- 76
- Aufrufe
- 4K
- Antworten
- 492
- Aufrufe
- 21K
- Antworten
- 11
- Aufrufe
- 847
- Antworten
- 49
- Aufrufe
- 4K
- Antworten
- 308
- Aufrufe
- 19K