4 Threads, nicht Kerne

[rangnar]

Die Core i3 Silizium-Waffeln haben meines Wissens und der ARK-Datenbank von Intel nach, alle nur 2 Prozessor-Kerne. Manche melden aber dem dämlichen OS von heute die gelogene Anzahl von 4 Kernen, um die überlangen Röhren auslasten zu können.

Oder sind wir bei der Volksverdummung schon so weist, dass man dem belesenen Nutzer schon so viel Dummheit unterstellt, nicht mehr zwischen Thread und Kern unterscheiden zu können?

[Cesair]

Was ist denn ein "Prozessor"?

[Nephtys]

rangnar schrieb:
--------------------------------------------------------------------------------
> Die Core i3 Silizium-Waffeln haben meines Wissens und der ARK-Datenbank von
> Intel nach, alle nur 2 Prozessor-Kerne. Manche melden aber dem dämlichen OS
> von heute die gelogene Anzahl von 4 Kernen, um die überlangen Röhren
> auslasten zu können.
>
> Oder sind wir bei der Volksverdummung schon so weist, dass man dem
> belesenen Nutzer schon so viel Dummheit unterstellt, nicht mehr zwischen
> Thread und Kern unterscheiden zu können?

Hyperthreading simuliert vor OS-Ebene jeweils 2 logische Kerne pro realem Kern, kommt in der Realität auch nahe dem, was 2 echte Kerne leisten.

[beaver]

Aber auch nur, weil immer noch niemand richtig für multicores programmieren kann. Da werden dann viele cores fast gar nicht ausgelastet, und somit kann man auch 12 software-cores haben, weil erst dann die physikalischen cores ausgelastet sind.

[Morpf]

Dass dem so ist, halte ich aber mal für ein Gerücht.
Hyperthreading bedeutet im Prinzip nur, dass ich schneller Threads wechseln kann. Aber es laufen trotzdem nicht mehr Threads zur gleichen Zeit.
Hyperthreading funktioniert nur gut, wenn die Pipeline eines Kernes dazu neigt leer zu laufen (z.B. viele Verzweigungen im Programmcode) oder man auf Syscalls wartet (IO und co). Wenn man aber rechenintensive Programme hat, die nicht IO-intensiv sind, dann bringt Hyperthreading genau gar nichts. Und wenn die Programme zu IO-intensiv sind, dann wird Bandbreite schnell zum Flaschenhals.

Morpf, der Rechner mit 2 Hexacores mit Hyperthreading (12 Kerne, 24 Threads) für wissenschaftliche Berechnungen genutzt hat.

[Mixermachine]

Hyperthreading kommt genau dann zum Einsatz, wenn ein Cachemiss entsteht. Also ein Rechenblock nicht direkt in Cache L1 bis L3 aufzufinden ist (sind ja auch nur so 1 bis 12 MB Speicher).
Der RAM ist im Vergleich zum Cache ziemlich langsam. Und so wird eben erst der Block aus dem RAM nachgezogen. Noch blöder wirds, wenn erst noch was von der Festplatte gelesen werden muss.
Genau in dieser Zeit ist aber der Kern absolut nicht ausgelastet...
Hier kommt dann der zweite (virtuelle) Thread ans Werk und arbeitet eben in der "verlorenen" Zeit etwas ab was er gerade so im Cache hat.

Hyperthreading bring selten 0 %. Im Idealfall 30%.

Bitte informiert euch vorher, bevor ihr jedes Feature als Kundenverarsche abstempelt.

[Thaodan]

Nephtys schrieb:
--------------------------------------------------------------------------------
> rangnar schrieb:
> ---------------------------------------------------------------------------
> Hyperthreading simuliert vor OS-Ebene jeweils 2 logische Kerne pro realem
> Kern, kommt in der Realität auch nahe dem, was 2 echte Kerne leisten.
Das OS erkennt bzw. achtet auf Hyperthreading Kerne, deswegen gab es auch Anfangs Probleme mit Windows 7 und den Bulldozer Kernen.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[redmord]

Ich galube, es war von CPU die Rede.

[Morpf]

Ich bezog mich in meinen Ausführungen auf die Aussage, dass Hyperthreading 2 echten Kernen sehr nahe käme, was einfach mal falsch ist - selbst im Best Case. Ich schrieb nie was von "Kundenverarsche", oder? Ich schrieb, dass Hyperthreading nur unter bestimmten Bedingungen einen merklichen Vorteil bringt.

Bitte lies meine Antwort richtig, bevor du mir irgendwelche Anschuldigungen unterstellst.

PS: Ich dächte, Hyperthreading würde auch unter anderen Bedingungen zuschlagen und nicht nur bei ne Cache Miss.

[zettifour]

beaver schrieb:
--------------------------------------------------------------------------------
> Aber auch nur, weil immer noch niemand richtig für multicores programmieren
> kann. Da werden dann viele cores fast gar nicht ausgelastet, und somit kann
> man auch 12 software-cores haben, weil erst dann die physikalischen cores
> ausgelastet sind.

Es ist schon etwas anders. Mal aus OS X/iOS Sicht:

Man hat eine oder mehrere Methoden, die sich für Parallelität eignen, zB das Einlesen und Auswerten von vielen Dateien. Man erstellt eine Warteschlange (Queue) und sagt dieser Warteschlange, wieviele Tasks(!) sie gleichzeitig ausführen darf. In diese Warteschlange schiebt man dann seine Methoden/Tasks. Dann wartet man in einer Methode, bis die Warteschlange leer ist, also alle Tasks abgearbeitet sind.
Auf die Cores an sich hat man als Entwickler keinen direkten Zugang (also nicht ohne Weiteres). Das Betriebssystem verteilt die Tasks in der Warteschlange auf die vorhandenen Cores, egal ob Hyperthreaded oder nicht.
Hat man mehr Tasks als Cores ist der Rechner 100% Busy - auch nicht so toll. In Mac OS/iOS gibt es dafür GrandCentralDispatch, daß die Tasks intelligent auf die Cores verteilt. Als Entwickler ist das noch einfacher umzusetzen als wie oben beschrieben.
Mit dem obigen Beispiel vom parlallelen Einlesen vieler dateien ist es 0 Problem 100 Cores zu beschäftigen.

[Morpf]

100% Auslastung ist nicht das Problem. Im Gegenteil, man möchte möglichst alle Ressourcen voll ausschöpfen. Problematisch wäre es nur, wenn diese Auslastung dazu führt, dass das System nicht mehr schnell auf Nutzereingaben reagiert (z.B. bei Großrechnern wäre dies wiederum egal). Aber auch bei annähernd voller Auslastung des Systems kann man es schnell reagierend halten. Das Stichwort lautet preemtive Scheduling.

Zu einem Zeitpunkt jeden Teil heutiger CPUs voll auszunutzen ist in der Praxis eigentlich nicht erreichbar. Irgendwann muss man eigentlich immer auf Daten warten, die nicht in den Registern stehen. Und selbst beim Zugriff auf L1-Cache vergehen ein paar Taktzyklen ohne Arbeit zu verrichten. Noch schlimmer wirds dann bei L2, L3, RAM, oder gar HDD. Deswegen versucht man auch immer möglichst auf Speicher "nah" an der CPU zuzugreifen. Eben damit die nicht Däumchen-drehend auf Daten warten muss sondern möglichst ausgelastet ist.

[rangnar]

Mixermachine schrieb:
--------------------------------------------------------------------------------
> ...
> Hyperthreading bring selten 0 %. Im Idealfall 30%.
>
> Bitte informiert euch vorher, bevor ihr jedes Feature als Kundenverarsche
> abstempelt.

Hyperthreading bringt im Idealfall 30%, liegt also im Idealfall 70% hinter einem realen Kern, und bringt unter Umständen auch gar nichts.

Bitte informiert euch vorher, bevor ihr jedes Feature als PR-BlaBla-HyperHype hochjubelt, obwohl es Kundenverarsche ist.

[Endwickler]

rangnar schrieb:
--------------------------------------------------------------------------------
> Die Core i3 Silizium-Waffeln haben meines Wissens und der ARK-Datenbank von
> Intel nach, alle nur 2 Prozessor-Kerne. Manche melden aber dem dämlichen OS
> von heute die gelogene Anzahl von 4 Kernen, um die überlangen Röhren
> auslasten zu können.
>
> Oder sind wir bei der Volksverdummung schon so weist, dass man dem
> belesenen Nutzer schon so viel Dummheit unterstellt, nicht mehr zwischen
> Thread und Kern unterscheiden zu können?

Nun, normalerweise melden die Prozessoren korrekt, dass sie zwei Kerne haben und einige melden zusätzlich, dass sie vier Threads können. Wenn irgend eine Darstellung daraus "vier Kerne" macht, solltest du das nicht der CPU anlasten.
Volksverdummung gibt es nicht und nicht es kann wirklich nicht jeder zwischen kern und Thread unterscheiden und die meisten brauchen da auch keinen Unterschied. Wenn du es besser weißt, dann hau dir auf die Schulter, nimm dir einen Keks und freu dich. :-)

[throgh]

rangnar schrieb:
--------------------------------------------------------------------------------
> Die Core i3 Silizium-Waffeln haben meines Wissens und der ARK-Datenbank von
> Intel nach, alle nur 2 Prozessor-Kerne. Manche melden aber dem dämlichen OS
> von heute die gelogene Anzahl von 4 Kernen, um die überlangen Röhren
> auslasten zu können.
>
> Oder sind wir bei der Volksverdummung schon so weist, dass man dem
> belesenen Nutzer schon so viel Dummheit unterstellt, nicht mehr zwischen
> Thread und Kern unterscheiden zu können?

Kannst du mir dann bitte einmal verraten warum du gleich diese Diskussion mit einem Ton beginnst, der schlichtweg zu wünschen übrig lässt? Vorzugsweise mag Hyperthreading nicht viel bringen, was übrigens schon bekannt ist. Aber was möchtest du denn damit grundlegend aussagen? Dann bitte belege deine Phrasen auch mit Quellen statt hier nur schöne Schlagworte niederzuschreiben.