Erzherzog schrieb:
War aber generell eine blöde Zeit, bis Software gut mit 2 oder mehr Cores umgehen konnte vergingen Jahre.
Oh, mit einem zweiten Kern konnte damals fast jede Software von Haus aus sogar schon umgehen, weil man oft das UserInterface in einen eigenen Thread ausgelagert hat, damit die UI noch reagiert, wenn das Proramm arbeitet.
Damals, wie auch heute, gilt bei der Software, die man als Anwender verwendet, dass der Anwender hier quasi die Geschwindigkeit bestimmt.
Erzherzog schrieb:
Gerade wenn man ein niedrig getaktetes Modell hatte (was bei den meisten OEMs der Fall war) hielten sich die Vorteile gegenüber einem Core echt in Grenzen.
Kam damals auf die Software an und was man verwendete. Wenn eine Software wirklich einen Kern blockierte, war ein zweiter Kern oft Gold wert, weil das System bedienbar bleib. Für die einzelne Software wiederum kann das stimmen, da sie langsamer lief.
Luxmanl525 schrieb:
Tatsächlich stimmt es aber, daß Anwendersoftware 2 Kerne weitgehend nicht spürbar zu Nutzen wußten.
Selbst heute gibt es noch sehr viel Anwendersoftware, die 2 Kerne nicht wirklich spürbar nutzen, weil die Anwendersoftware nicht ununterbrochen arbeitet, sondern darauf warten, dass bestimmte Events in der UI ausgelöst werden und dann die damit verknüpften Anweisungen auszuführen.
Heute ist es durchaus einfach die Programme in viele Teilaufgaben zu erledigen, nur werden diese Teilaufgaben nicht ständig ausgeführt, sonder nur, wenn sie ausgeführt werden muss.
Heute braucht man in der Regel mehr als 2 Kerne in fast allen Gerätenklassen mit Anwendersoftware, eher, weil man eine vielzahl an Background-Tasks hat, die ausgeführt werden wollen, um diese alle "schnell" auszuführen, müsste ein Kern heute da immer unter "dauerlast" stehen, was den Verbrauch auch hochtreibt. Bei 4 oder mehr Kernen verteilt man die Aufgaben auf alle Kerne und diese können bei niedrigen Taktraten bleiben.