1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Intel Core i7-5960X im Test: Die…
  6. Thema

Mehr Kerne

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Mehr Kerne

    Autor: Auf 'ne Cola 30.08.14 - 10:40

    gerade Datenträgerbereinigung laufen lassen, sind natürlich bei 4 Kernen auf 50% CPU Last begrenzt, weils nur zwei Threads sind.

  2. Re: Mehr Kerne

    Autor: redmord 30.08.14 - 11:04

    Bei Win8.x noch der Fall?

  3. Re: Mehr Kerne

    Autor: JouMxyzptlk 30.08.14 - 11:33

    Auf 'ne Cola schrieb:
    --------------------------------------------------------------------------------
    > Selbst bei meinem I7 habe ich jetzt HT deaktiviert, weil mehr als 4 Kerne
    > einfach Mist sind und nur kontraproduktiv.

    Bitte Belege und Beweise bringen.
    Als ich bei meinem i7-2600K das HT deaktiviert hatte um zu probieren ob ich doch über 4.8 GHz komme hat das nichts gebracht. Video encoden dauerte fast exakt doppelt so lange (was mich überraschte). Auch das restliche System war merklich träger.

  4. Re: Mehr Kerne

    Autor: mazaboorm popo 30.08.14 - 11:53

    Auf 'ne Cola schrieb:
    --------------------------------------------------------------------------------
    > Selbst bei meinem I7 habe ich jetzt HT deaktiviert, weil mehr als 4 Kerne
    > einfach Mist sind und nur kontraproduktiv.


    das ist doch quatsch, ab win 7 ist das system so schlau singel Thread Anwendungen auf die "echten" Kerne zu legen und der rest wird dann auf den virtuellen berechnet.
    Wenn ein Programm multi cpu tauglich ist dann hat es auch einen vorteil von den virtuellen cpu´s da diese nur die Recheneinheiten darstellen die gerade ungenutzt sind.

  5. Re: Mehr Kerne

    Autor: Auf 'ne Cola 30.08.14 - 11:58

    Wieso wird mein System bei einer sta nur zu 12,5% belastet?

  6. Re: Mehr Kerne

    Autor: dukki 30.08.14 - 12:05

    Auf 'ne Cola schrieb:
    --------------------------------------------------------------------------------
    > Wieso wird mein System bei einer sta nur zu 12,5% belastet?


    Weil dir dein taskmanager die "ht cores" als echte cores anzeigt. Prozentrechnung und so.

    Nicht auf ht optimierte Software kann jedoch bei eingeschalteten ht einige Performance Probleme herbeiführen. Dies liegt dann an ht und nicht an den Kernen. Du schaltest mit ht ja keine deaktivierten Kerne frei. Damit können nur mehrere Prozesse parallel durch einen physikalischen Kern berechnet werden (salop beschrieben)

    Bestes beispiel: mikroruckler bei battlefield 3 wenn bei Intel CPUs ht aktiviert ist.

    Ist dann aber eher ein Henne ei Problem

    Ht =/ echte physikalische kerne



    1 mal bearbeitet, zuletzt am 30.08.14 12:10 durch dukki.

  7. Re: Mehr Kerne

    Autor: Auf 'ne Cola 30.08.14 - 12:19

    es ist aber schon so, dass die Anzeige vom TM stimmt, dass nur 12,5% benutzt werden?
    Wenn ja sehe ich tdm keinen Vorteil darin: Jede (mit bekannte) Anwendung, die mehr Leistung als die gegebenen 12,5% gut brauchen könnte limitiert bei den 12,5%*x.
    Da aus den 12,5% ohne HT ja 25% werden, ist es doch von Vorteil HT auszuschalten um dann doppelt so viel Leistung zu bekommen?!

  8. Re: Mehr Kerne

    Autor: Poison Nuke 30.08.14 - 16:14

    Windows weiß nicht, ob die HT Kerne echt oder virtuell sind... für Windows sind es einfach 8 Kerne.
    Die CPU regelt das ganze dann intern für sich. Die 12,5% mit HT sind IDENTISCH schnell wie 25% ohne HT bei einer Single-Thread Anwendung.
    Das ist simple Prozentrechnung.

    Solange insgesamt nur 4 Threads laufen würden, würde man auch nie einen Unterschied merken, auch wenn bei aktiven HT gerade mal 50% angezeigt werden. Dafür hat man mit eingeschaltetem HT aber dann eben unter Umständen noch mehr Reserven, weil einige Threads wirklich auf einem Kern doppelt ausgeführt werden können.
    Denn was ist HT? Ressourcen von einem Kern werden von verschiedenen Prozessen genutzt, wodurch bei optimaler Ausnutzung effektiv wirklich doppelt so viele Prozesse laufen können. Aber die einzelnen Prozesse sind dadurch nicht schneller oder langsamer.

    Kurzum: in von mir gefühlt 95% der Fälle bringt es nur Vorteile, HT aktiv zu lassen. Weil eben freie Ressourcen besser verteilt werden können. Es gibt nur wenige Ausnahmen wo die CPU eben Probleme bei der Aufteilung hat (z.B. Mikroruckler bei bestimmten Spielen)

    Greetz

    Poison Nuke

  9. Re: Mehr Kerne

    Autor: MarkusXXX 30.08.14 - 16:32

    Galde schrieb:
    --------------------------------------------------------------------------------
    > Da aber tatsächlich nur Betriebssystem und Grafiktreiber Mehrkerntauglich
    > sind und der Rest alles sich auf Kern 1 "tummelt" macht es aktuell recht
    > wenig Sinn. Zumindest sind dies meine eigenen Erfahrungen.

    Bei meinem Windows 7 64-Bit verteilt Windows die Prozesse munter reiherum. Auch Prozesse mit einem einzelnen Thread werden oftmals auf 4 Kerne verteilt. Dadurch wird der zwar nicht schneller, aber es ist keineswegs so, dass die nur auf 1. Kern laufen und ich die manuell umverteilen müsste.

  10. Re: Mehr Kerne

    Autor: nie (Golem.de) 30.08.14 - 16:36

    Doch, das hat sich schon mit Windows 7 durch die Funktion des SMT Parking geändert: Zuerst werden die physikalischen Kerne belastet:

    https://www.golem.de/1003/73762-8.html

    Man kann das im Task-Manager, Process Explorer etc. daran sehen, dass immer zuerst Core 0, 2, 4 etc... belastet werden, wenn eine Anwendung nicht alle zur Verfügung stehenden Threads nutzt.

    Nico Ernst
    Redaktion Golem.de

  11. Re: Mehr Kerne

    Autor: Cerdo 30.08.14 - 17:12

    JouMxyzptlk schrieb:
    --------------------------------------------------------------------------------
    > Sharra schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Mal von 3D-Anwendungen, Videobearbeitung und ähnlichem abgesehen, lohnen
    > > sich so viele Kerne für den Normalanwender/Zocker? Oder sind 4 Kerne mit
    > > höherem Takt sinnvoller?
    >
    > Letzteres ist sinnvoller, mehr GHz statt mehr cores.

    Das war mal richtig, bis vor etwa zehn Jahren. Seit dem bedeuten höhere Taktraten vor allem höheren Stromverbrauch, da die "frequency wall" erreicht ist.
    Deswegen hat sich die Taktfrequenz seitdem aus ca. 3,5 GHz eingependelt. Würde man den Chip höher Takten wäre die Verlustleistung größer und man hätte einen minimal schnelleren, aber signifikant heißeren Kern.

    Schau dir mal das Amdahlsche Gesetz an, das erklärt, warum parallel arbeitende Prozessoren besser sind: https://de.wikipedia.org/wiki/Amdahlsches_Gesetz

    In fünf Jahren wird es deshalb Standard-Prozessoren mit 32 Kernen und mehr geben. Mehr als 3,8 GHz wird aber keiner haben, normal sind wohl eher bis zu 3,4 GHz, da der Energieverbrauch (und die Hitzeentwicklung) dann viel niedriger ist.

  12. Re: Mehr Kerne

    Autor: Cerdo 30.08.14 - 17:19

    Auf 'ne Cola schrieb:
    --------------------------------------------------------------------------------
    > " Gegenüber klassischen Multiprozessorsystemen ist Hyper-Threading bei der
    > reinen Leistung im Nachteil, da beide logischen Prozessoren sich die
    > Ressourcen teilen müssen und dabei in Konflikt geraten können."
    Das Problem ist nicht das Hyper-Threading an sich, sondern, dass die meisten Programmier es einfach nicht beherrschen. Die haben das programmieren noch gelernt, als "Forken" die einzige Möglichkeit war, einen "parallelen" Prozess zu starten.

    Auch heute noch lernen viele Informatiker erst parallel zu programmieren, wenn sie im Master ein passendes Modul wählen. "Programmier" lernen das oft nur im Selbststudium.

  13. Re: Mehr Kerne

    Autor: Satan 30.08.14 - 17:40

    HyperThreading sinnvoll zu nutzen, ist aber - anders als bei "normalen" Kernen - unglaublich schwierig. Wenn ich zwei Threads habe, die beide auf demselben Kern laufen und dasselbe tun (bzw. zumindest dieselben Ressourcen auslasten), skaliert Hyperthreading mit Pech eben gar nicht - wenn ich einen Compute-intensiven Thread und einen speicherlimitierten Thread auf einem Kern laufen lasse, skaliert das mit Glück genau so wie zwei echte Kerne.

    Gibt ja zu P4-Zeiten sogar den Trick, auf dem zweiten Thread nur nen Prefetcher für die Daten des ersten Threads laufen zu lassen, wobei das heute unnötig sein dürfte.

    > Auch heute noch lernen viele Informatiker erst parallel zu programmieren, wenn
    > sie im Master ein passendes Modul wählen. "Programmier" lernen das oft nur im
    > Selbststudium.
    Bei uns gabs ne Einführung in die Nutzung von pthreads im zweiten Semester. Allerdings wurde das Thema Skalierung und Effizienz einfach mal komplett außen vor gelassen und sich eher darauf beschränkt, Probleme wie Race Conditions und Deadlocks zu lösen...

  14. Re: Mehr Kerne

    Autor: Cerdo 30.08.14 - 17:54

    Satan schrieb:
    --------------------------------------------------------------------------------
    > HyperThreading sinnvoll zu nutzen, ist aber - anders als bei "normalen"
    > Kernen - unglaublich schwierig. Wenn ich zwei Threads habe, die beide auf
    > demselben Kern laufen und dasselbe tun (bzw. zumindest dieselben Ressourcen
    > auslasten), skaliert Hyperthreading mit Pech eben gar nicht - wenn ich
    > einen Compute-intensiven Thread und einen speicherlimitierten Thread auf
    > einem Kern laufen lasse, skaliert das mit Glück genau so wie zwei echte
    > Kerne.

    Klar, parallele Prozesse lohnen sich erst bei rechenintensiven Anwendungen. Die sind auch nicht für alles geeignet. Aber wenn der Aufwand für das Erzeugen und Verwalten der Parallelität im Verhältnis klein genug ist, dann lohnt sich das schon.

  15. Re: Mehr Kerne

    Autor: Poison Nuke 30.08.14 - 17:59

    > > sie im Master ein passendes Modul wählen. "Programmier" lernen das oft
    > nur im
    > > Selbststudium.
    > Bei uns gabs ne Einführung in die Nutzung von pthreads im zweiten Semester.
    > Allerdings wurde das Thema Skalierung und Effizienz einfach mal komplett
    > außen vor gelassen und sich eher darauf beschränkt, Probleme wie Race
    > Conditions und Deadlocks zu lösen...

    immerhin gabs das bei euch schon, bei uns haben wir von sowas bisher noch nicht im geringsten was gehört in den ersten Semestern.

    Greetz

    Poison Nuke

  16. Re: Mehr Kerne

    Autor: Satan 30.08.14 - 18:15

    Davon rede ich nicht, ich rede eher davon, dass Code, der zwar wunderbar mit echten Kernen skaliert, bei Verwendung von HyperThreading nicht zwangsläufig schneller oder mit Pech sogar langsamer ist als auf einem einzelnen Kern ohne HT. Je effizienter dein Code die einzelnen Kerne auslastet, umso eher ist HT eher ein Klotz am Bein als sonst was.

  17. Re: Mehr Kerne

    Autor: Daepilin 30.08.14 - 19:44

    Da sich hier ja die Informatiker austauschen: Bei mir kam Parallelisierung im rahmen der Rechnernetze Vorlesung im 6. Bachelorsemester dran.

    Vorher in der OOP(c++, aber quasi ohne c11, Vorlesung war vor 1,5 jahren) Vorlesung wurde mal erwähnt, dass es threads gibt und in prozessinfo wurde beschrieben welche Mechanismen es gibt einen Prozessor parallel auszulasten.

    Selbstständig parallel programmieren ging nicht darüber hinaus n paar simple MPI Programme zu schreiben...

  18. Re: Mehr Kerne

    Autor: iRofl 30.08.14 - 19:59

    Sharra schrieb:
    --------------------------------------------------------------------------------
    > Bei Spielen ist eben die Frage, welche nutzen wirklich viele Kerne auch
    > voll aus.

    Bei Spielen wie immer: absolut 0 Mehrwert - http://www.gamestar.de/hardware/prozessoren/intel-core-i7-5960x/test/intel_core_i7_5960x,856,3059355.html
    Aber ist auch bei den meisten Programmen so. Was eine Überraschung.

  19. Re: Mehr Kerne

    Autor: Satan 31.08.14 - 01:03

    Naja, Spiele nutzen auch fast nie mehr als einen oder zwei Kerne, da sollte das wenig verwundern. Aber bei normalen Anwendungen, bei denen auch tatsächlich mal die Gefahr besteht, dass es mal etwas länger dauert, ist mir außer Gimp schon ewig nichts mehr untergekommen, was nicht ordentlich parallelisiert wäre.

  20. Re: Mehr Kerne

    Autor: Poison Nuke 31.08.14 - 11:25

    Photoshop, Lightroom, z.T. auch After Effects und Premiere Pro. Noch ein paar weitere Beispiele?
    Also die Liste mit Programmen, die rechenintensiv sind und sich gut parallelisieren lassen würden, es aber nicht sind, lässt sich fast ewig fortsetzen.

    Greetz

    Poison Nuke

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Mecklenburgische VERSICHERUNGSGRUPPE, Süd-/Ostdeutschland (Home-Office)
  2. Schleich GmbH, München
  3. Bundesamt für Sicherheit in der Informationstechnik, Bonn
  4. Forschungszentrum Jülich GmbH, Erlangen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Mobile-Angebote
  1. 499,90€
  2. 326,74€
  3. 206,10€ (mit Rabattcode "PFIFFIGER" - Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Geforce RTX 3060 Ti im Test: Die wäre toll, wenn verfügbar-Grafikkarte
Geforce RTX 3060 Ti im Test
Die "wäre toll, wenn verfügbar"-Grafikkarte

Mit der Geforce RTX 3060 Ti bringt Nvidia die Ampere-Technik in das 400-Euro-Segment. Dort ist die Radeon RX 5700 XT chancenlos.
Ein Test von Marc Sauter

  1. Supercomputer-Beschleuniger Nvidia verdoppelt Videospeicher des A100
  2. Nvidia Geforce RTX 3080 Ti kommt im Januar 2021 für 1.000 US-Dollar
  3. Ampere-Grafikkarten Specs der RTX 3080 Ti und RTX 3060 Ti

Made in USA: Deutsche Huawei-Gegner schweigen zu Juniper-Hintertüren
Made in USA
Deutsche Huawei-Gegner schweigen zu Juniper-Hintertüren

Zu unbequemen Fragen schweigen die Transatlantiker Manuel Höferlin, Falko Mohrs, Metin Hakverdi, Norbert Röttgen und Friedrich Merz. Das wirkt unredlich.
Eine Recherche von Achim Sawall

  1. Sandworm Hacker nutzen alte Exim-Sicherheitslücke aus

Macbook Air mit Apple Silicon im Test: Das beste Macbook braucht kein Intel
Macbook Air mit Apple Silicon im Test
Das beste Macbook braucht kein Intel

Was passiert, wenn Apple ein altbewährtes Chassis mit einem extrem potenten ARM-Chip verbindet? Es entsteht eines der besten Notebooks.
Ein Test von Oliver Nickel

  1. Apple Macbook Air (2020) im Test Weg mit der defekten Tastatur!
  2. Retina-Display Fleckige Bildschirme auch bei einigen Macbook Air
  3. iFixit Teardown Neue Tastatur macht das Macbook Air dicker