Ergebnisse: Effizienz

Was hierbei nicht berücksichtigt wurde ist das man bei weniger Kernen auch die Corespannung reduzieren kann. Wenn ich schon von Hand die Kerne im BIOS abschalten muss dann kann ich die Spannung auch gleich mit reduzieren. Wirklich interessant wird das Feature wenn die Prozessoren während der Laufzeit die Kerne selbstständig je nach Bedarf aktivieren oder deaktivieren und die Spannung anpassen.

"Der ALU-Test unter Sandra 2010 Pro zeigt, dass jeder zusätzliche Kern, mit wenigen Ausnahmen, ein vielfaches der Single-Core-Performance bietet. Zwei Kerne scheinen mehr als die 2fache Performance zu liefern."

Na, ich denke das 12,6 x 2 = 25,2 nahe genug an 25,45 dran ist, um lediglich von zweifacher Performance zu sprechen. Ich finde, dass die Skalierung auf allen Stufen wirklich beeindruckend ist.

"Der SHA256-Verschlüsselungstest zeigt erneut, dass zwei Kerne außerordentlich gute Performance bieten. Dies könnte an Turbo Core liegen."

Nicht erneut, jedoch hätte ich über die "Turbo-Core-Vermutung" gerne mehr gelesen. Denn in allen vorrangegangenen Benches ist nichts davon zu merken.
Wie gesagt, sehr deutliche Skalierung. Wo ist Turbo Core?
Trotzdem sind die Diagramme interessant und es ist schön, das sich jemand diese Arbeit gemacht hat.

LOL:

Wie soll eine Single-Core App auch auf mehreren Kernen skalieren...? =)
Meine Empfehlung: Nehmt ein ganzes Album mit mind. 20 Songs zum Umwandeln und startet entsprechend der Anzahl der vorhanden Kerne jeweils eine neue Instanz von Lame mit einem anderen Song. Und nehmt eine schnelle SSD oder RAMDisk, sonst bremst die Platte. Gemessen wird dann die benötigte Gesamtzeit zum Umwandeln fürs ganze Album.

In den meisten Fällen nimmt die Leistung durch mehr Kerne ja fast in Gestalt einer e-Funktion ab. Da muss sich in den nächsten Jahren aber dringend ein neuer Ansatz auftun, sonst wirds schwierig mit der Leistungssteigerung. Ähnlich wie dem GHz-Wahn vor ein paar Jahren.

Das kommt einzig und allein auf das Softwaredesign an.
Unsere VoIP server skalieren auf mind. 16 Kernen noch sauber.

Es ist nicht einfach multithreaded zu programmieren und stellt erheblich höhere Anforderungen an die Programmierer.
Auch läßt sich nicht jedes Programm für multithreading optimieren.

Das synthetische Benchmarks wie Sandra o.ä nahezu linear skalieren ist wohl kaum ein Wunder.
Programme wie z.B WinZip oder auch Lame würden sich sicherlich optimieren lassen, da finde ich es sehr schade dasss es noch nicht geschehen ist.

Tatasache ist dass nach wie vor zu wenig getan wird und die Programmierer entweder zu faul oder schlicht nicht fähig genug sind (bestehende) Programme auf concurrency hin zu optimieren.

Wenn man sich zu den obigen Zitaten die Einheiten der physikalischen Größen anschaut, dann stellt man fest; Dem THG Team würde ein Auffrischungskurs Physik Klasse 6 gut tun. Die Sachkompetenz der THG Tester wird in Frage gestellt, wenn man die Deutungen der Messergebnisse erstmal richtig stellen muss um den Test ein Ergebniss zu entlocken.

//offtopic

(Trotzdem) danke an das Team für diesen Test. So zeigt er deutlich, dass eine CPU die mit verschiedenen Programmen gefüttert wird, nicht dringend mehr als 2 Kerne braucht. Nur dem geneigten Anwender, der eine Anwendung ausgiebig anwendet, die mit 6 Kernen skaliert, empfiehlt sich ein 6-Kerner.

In meinem Fall läuft ein Athlon K8 X2 @3GHz. Die wirkliche Spaßbremse ist die Festplatte, die sollte mal mit einer SSD getauscht werden, aber nicht der K8 X2 in einen K10 X4/6.

Bei meinem X3 ist die Auslastung z.Z. auch eher auf 2 Kerne beschränkt, weshalb es ein flotter X2 auch getan hätte (Und: Besser.)

Die gängigen Multi-Thread-Linux-Programme, die ich nutze (Clam-Antivirus, DeVeDe, etc.) sind für 2 Kerne optimiert, und hier zählt auch die Taktsau. - Sobald die volle Takrate noch "festgestellt" wird (geht über ein Applet), wird es dann noch effektiver. - Der 3te Kern kriegt dann und wann mal einen Auschlag, oder die Kerne wechseln sich untereinander ab (einer darf immer nicht mitspielen).

Bei Multitasking sieht es schon wieder anders aus.

Unverständlich ist die konsequente Weigerung von "Winzip", mehr Kerne zu nutzen. "iTune" und "Lahm" ähhhh... "Lame" sind auch so Kanditaten. Merkwürdig: Gängige, teils kostenpflichtige Programme, an denen der Fortschritt vorbeigegangen zu sein scheint.

Und ausgerechnet die sprichwörtliche "Handbremse" gibt ordentlich Gummi...

Wie ich schon sagte, das ganze steht und fällt mit fähigen Programmierern.
Multithreaded zu programmieren ist deutlich schwieriger und mehr Aufwand.

WinZip kann man sicherlich nicht "mal eben" optimieren ich würde sogar soweit gehen zu sagen dass es zu einem großen Teil eine Neuentwicklung wird, jedenfalls der Core-Componenten, Teile des Pack/Entpack Algorythmus.

Die 2-4 Kern CPUs + HT gibt es aber auch schon eine ganze Weile.

Die Konkurrenten RAR und 7zip haben sich keine Zacke aus der Krone gebrochen.

Besonders gut zeckt RAR unter MP-Systemen mit 64BIT-OS

Angesichts von 30 W die man mit einem Core i5 erreichen kann, liegt dort die falsche Messlatte an. Die hohe Single-Thread Leistung bei knapp 4 GHz Takt löst dann zum Teil auch das leidige Problem schlecht optimierter Software.

Wieviele Programme sind denn schon so schlecht optimiert? WinZip. Nimmste Winrar und das Problem ist gelöst Alle Programme bei denen man die gewonnene Zeit auch spürt sind optimiert. Außer natürlich ITunes WinZip und uralt Codecs.

Stimme zu. - So schwer kann und darf das nicht sein mit der Optimierung.

WinZip leisten sich ein klares No Go, und das gehört abgestraft.

"Stimme zu. - So schwer kann und darf das nicht sein mit der Optimierung.
WinZip leisten sich ein klares No Go, und das gehört abgestraft."

Das stimmt nicht. Ich hatte mich vor einem Jahr mal mit einem WinRAR-Entwickler (per E-Mail) unterhalten. Er hat mir gesagt das war ein ganz schöner Akt.

Am besten man äußert sich nicht über Dinge von denen man keine Ahnung hat .

Es ist ein böser Akt, das kann ich als Entwickler nur bestätigen. Und oft genug muss man das Verhältnis zwischen Aufwand und Ergebnis sorgsam wirtschaftlich abwägen. Wobei die Komprimierung eigentlich ein recht dankbares Objekt darstellt, während sich manch andere Aufgabe nicht oder nur schwer umsetzen lässt.

Aber:
Wer von seinen Kunden Geld für die Produkte verlangt, sollte so viel Anstand und Einsicht besitzen, dies auch mit Qualität zu entgelten. Von einem Packprogramm sollte man es eigentlich erwarten dürfen, bei einem Editor ist es hingegen sinnlos.

Da hast du dich glaube ich in den meisten Fällen verguckt und nicht nachgerechnet.
Dass bei 5 aktiven Kernen die benötigte Zeit nicht halbiert wird, wenn man noch einen Kern aktiviert, bei einem aktiven Kern der dann einen zweiten zur Seite gestellt bekommt aber schon, sollte eigentlich klar sein.
Die skalieren sogar sehr gut, das liegt in den meisten Fällen bei 90%.

So lange das Programm die CPU nicht großartig mit dem RAM kommunizieren laesst. Dann wird die Effizienz staerker abfallen.

Synthethische Urteile a priori, ja, es gibt sie immer noch, ... Scherzkeks ...

Genügend Beispiele von Games, Anwendungen und OS, wo die Mehrkern-Unterstützung und Skalierung anscheinend kein Problem dargestellt hat.

Man muss halt wollen und engagierte Leute gut bezahlen (oder nicht), und dann klappt das.

Jemand hat was über 'ne Email gesagt juckt hier nicht die Bohne, weil WinRar es macht, und WinZip nicht.

Zur Urteilsbegründung siehe oben.

Allerdings muss - Multicore Optimierung hin oder her - eine Prognose erlaubt sein, wann der Geschwindigkeitsvorteil durch Ausplitten eines Programmes in einzelne Threads und der damit erhöhte rechnerische Verwaltungsselbstaufwand der CPU sowie die zwangsläufig zunehmenden Fehler in der Sprungvorhersage den Performance Benefit wieder auffressen. Dies ist bei Datenbankanwendungen eher später, bei anderen Programmen eher früher der Fall. Wie im gigaherz Wahn lässt sich auch eine Parallelisierung nicht bis in die Unendlichkeit fortsetzen.