Dual-Core vs. Single-Core --- war "Produktpolitik der Hersteller" [Archiv]

paul.muad.dib

2006-01-15, 17:27:28

Diskussion ausgeglieder aus:

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=272441

Auch das trifft nicht zu, denn ihr denkt in der falschen Dimension. Vielleicht sollte ich das mal ausführlicher erklären. Nehmen wir einen 3,2 GHz SingleCore und einen 3,2 GHz DualCore. Wenn nur ein Core benutzt wird, ist die Leistung identisch. Nun stehen dem DualCore Prozessor aber mehr Ressourcen zur Verfügung, die er für andere Bereiche nutzen könnte.

richtig

Nehmen wir nun an, das der zweite Core von einem Spiel unterstützt wird und zwar ohne eine konkrete Aufgabe zu erhalten; er berechnet also fast das gleiche wie der erste Core.

Genau das ist nicht möglich. Man kann nicht einfach sagen, dass ein spiel einen 2. Kern unterstützem soll. Es muss ein zweites Programm gestartet werden, was Berechnungen für das Spiel ausführt und daher eine definierte Aufgabe haben muss. Es ist nicht möglich, ein Spiel einfach so zu schreiben, dass ein Teil des Programmcodes auf dem einen Kern und ein Teil auf dem anderen ausgeführt wird.

Jetzt kommt aber der Entwickler ins Spiel: Er könnte die brachliegende Leistung für andere Bereiche nutzen, die auf heutigen SingleCore CPUs nicht möglich wären. Beispielweise für wesentlich genauere KI-Aktionen (das wäre "eine Leistungssteigerung im Sinne eines besseren Spiels (welches auf heutigen CPUs nicht möglich wäre)" Je mehr Rechenleistung der KI zur Verfügung steht, desto genauer/schneller kann sie arbeiten und reagieren.

richtig, aber

Die zur Verfügung stehende Mehrleistung kann nur schwer im vollen Umfang genutzt werden. Daher ist dieser Weg teurer, als die Leistungssteigerungen, die in der Vergangenheit erreihct wurden. Er ist nur deshalb nötig gewordenen, weil auf herkömmlichem Wege momentan nicht mehr viel herausgeholt werden kann.

Für heutige Spiele, die ruckeln bringt das rein gar nichts.

Gast

2006-01-15, 17:49:58

Es ist nicht möglich, ein Spiel einfach so zu schreiben, dass ein Teil des Programmcodes auf dem einen Kern und ein Teil auf dem anderen ausgeführt wird.

Nun, ein Spiel besteht sowieso immer aus dutzenden verschiedenen Elementen. Das wäre nicht das Problem.
Möglich ist es sicher, denn man könnte die Programmfunktionen auf die Cores aufteilen und die Ergebnisse später wieder zusammenfügen. Daher werden auch nicht 100% mehr Leistung zustande kommen, aber ca. 80% mehr sind realistisch.

Oder bei Spielen wo das keinen Sinn macht, könnte man die Leistung für eine Verbesserung der KI oder Effekte einsetzen.

So gesehen, besteht eigentlich immer eine Möglichkeit, die Leistung zu nutzen.

Außerdem sollte nicht vergessen werden, das währenddessen immernoch ein Betriebssystem im Hintergrund läuft, welches auch etwas Leistung abhaben möchte. Hier würde DualCore schon etwas bringen, da ein Core allein für das Betriebssystem reserviert werden könnte - das geht auch schon heute.

Botcruscher

2006-01-15, 18:05:06

Meine perönliche Meinung:

Ich hab nicht vor das Henne-Ei-Problem mit meinem Geld für die Hersteller zu lösen. Oder kurz DC ja, aber erst wenn man ihn für <150€ bekommt und gut ocen kann.

Daher werden auch nicht 100% mehr Leistung zustande kommen, aber ca. 80% mehr sind realistisch.

Hängt davon ab wie gut sich alles parralelisieren läst. Selbst 50% halte ich aber für zu optimistisch.
Gerade bei Simulationen wird man woll sehr wenig erreichen.

paul.muad.dib

2006-01-15, 18:07:01

aber ca. 80% mehr sind realistisch.

Sagt wer? In einem Encoding Benchmark, wo überdurchschnittlich hohe Leistungszuwächse möglich sind, ist der 3,2 Ghz DC gerade mal 50% schneller als der 3,2 Ghz Single Core.

http://www.computerbase.de/artikel/hardware/prozessoren/2005/test_intel_dual-core_benchmarks/16/#abschnitt_windows_media_encoder

So gesehen, besteht eigentlich immer eine Möglichkeit, die Leistung zu nutzen.

Nein, bei einem sehr rechenintensiven Thread, der sich nicht aufteilen lässt, geht das nicht.

Außerdem sollte nicht vergessen werden, das währenddessen immernoch ein Betriebssystem im Hintergrund läuft, welches auch etwas Leistung abhaben möchte. Hier würde DualCore schon etwas bringen, da ein Core allein für das Betriebssystem reserviert werden könnte - das geht auch schon heute.

Ein Betriebssystem, auf dem Spiele in nennenswertem Umfang von Dc profitieren würden, wäre ein schlechtes Betriebssystem. Wenn ich mir momentan die CPU-Auslastung anschaue, schwankt sie zwischen 1-5 %, allerdings bei per c&q reduziertem Prozessortakt. interessant wird der Aspekt nur, wenn mehr oder weniger rechintensive Programme im Hintergrund laufen. Das ist dann aber eben eher mehr Komfort als wirkliche Mehrleistung, da ich die entsprechnenden Programe auch stoppen könnte.

Damit wir uns nicht missverstehen. Ich lehne DC nicht grundsätzlich ab. Würden aber eine Taktverdopplung und eine Kernverdopplung zu Wahl stehen, dann wäre die Taktverdopplung immer die bessere Alternative. Dies ist aber eben heute leider nicht mehr möglich.

Gandharva

2006-01-15, 18:09:23

Nun, ein Spiel besteht sowieso immer aus dutzenden verschiedenen Elementen. Das wäre nicht das Problem.
Möglich ist es sicher, denn man könnte die Programmfunktionen auf die Cores aufteilen und die Ergebnisse später wieder zusammenfügen. Daher werden auch nicht 100% mehr Leistung zustande kommen, aber ca. 80% mehr sind realistisch.

Oder bei Spielen wo das keinen Sinn macht, könnte man die Leistung für eine Verbesserung der KI oder Effekte einsetzen.

So gesehen, besteht eigentlich immer eine Möglichkeit, die Leistung zu nutzen.Du stellst dir das alles viel zu einfach vor! Weils grade sehr gut passt wie ich finde: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3880400#post3880400

Gast

2006-01-15, 18:21:14

Sagt wer? In einem Encoding Benchmark, wo überdurchschnittlich hohe Leistungszuwächse möglich sind, ist der 3,2 Ghz DC gerade mal 50% schneller als der 3,2 Ghz Single Core.

Genau da könnte ich aber auch ein anderes Ergebniss liefern:
http://www.tomshardware.com/2005/12/28/intels_65_nm_process_breathes_fire_into_double_core_extreme_edition/page19.html

Man vergleiche mal P4 EE 955 3,46 GHz (1:16 min) und P4 EE 3,46 GHz (2:06). Das ist schon ein erheblicher Unterschied...

Je nach Anwendung ist es mehr oder weniger, wobei ich sagen würde, das es in vielen Fällen auf noch nicht ausgereifte DualCore Unterstützung zurückzuführen ist.
Erinnert sich noch jemand an FlaskMPEG und dem P4? Erst als FlaskMPEG optimiert wurde (SSE), konnte der P4 sich gegen die Konkurrenz behaupten.

Nein, bei einem sehr rechenintensiven Thread, der sich nicht aufteilen lässt, geht das nicht.

Wieviele rechenintensive Threads, die sich nicht aufteilen lassen, kennst du? Die Frage ist erstgemeint. ;)

Gast

2006-01-15, 18:23:20

Du stellst dir das alles viel zu einfach vor!

Ich stelle es mir nicht zu einfach vor; denn ich weiß wie es funktionieren könnte, wenn es anständig umgesetzt wäre...

Deswegen halte ich DualCore für keine Verzweiflungstat der Hersteller...

Coda

2006-01-15, 18:38:00

Doch er hat recht. Die Nebenläufigkeit ist oft nicht gegeben, deshalb lässt sich viel Programmcode gar nicht parallelisieren.

Auch die Compiler können das nicht wirklich gut. Der von Intel kann zwar etwas Multithreading einführen, das bringt aber kaum 10%.

Gast

2006-01-15, 18:41:09

Ihr redet aber immer nur von jetzt und heute. Das steht hier aber gar nicht zur Debatte.
Wartet doch mal ab, bis erstmal auf DualCore optimiert wurde.

Das fing beim Treiber an (NVIDIA) und hört sicherlich nicht beim Compiler auf... wir sind noch in der Anfangsphase!

Coda

2006-01-15, 18:48:57

Sag ich ja gar nichts dagegen, aber es liegt an den Programmierern. Und Nebenläufigkeit ist nun wirklich nicht das einfachste Gebiet der Informatik.

Der 80er nVIDIA-Treiber stürzt bei mir auch häufig mit Bluescreens ab, vermutlich wegen irgendwelchen Race-Conditions beim Speichermanagement.

IVN

2006-01-15, 18:57:03

Genau da könnte ich aber auch ein anderes Ergebniss liefern:
http://www.tomshardware.com/2005/12/28/intels_65_nm_process_breathes_fire_into_double_core_extreme_edition/page19.html

Man vergleiche mal P4 EE 955 3,46 GHz (1:16 min) und P4 EE 3,46 GHz (2:06). Das ist schon ein erheblicher Unterschied...

Je nach Anwendung ist es mehr oder weniger, wobei ich sagen würde, das es in vielen Fällen auf noch nicht ausgereifte DualCore Unterstützung zurückzuführen ist.
Erinnert sich noch jemand an FlaskMPEG und dem P4? Erst als FlaskMPEG optimiert wurde (SSE), konnte der P4 sich gegen die Konkurrenz behaupten.

Wieviele rechenintensive Threads, die sich nicht aufteilen lassen, kennst du? Die Frage ist erstgemeint. ;)
Schlechter Vergleich.Der EE3.46 ist ein Gallatin (also ein Northwood mit 2MB L3 Cache).Da ist nicht nur ein DC vs. SC,sonder auch ein Core to Core Vergleich gegeben.

Gast

2006-01-15, 19:04:02

Schlechter Vergleich.

Ich habe den bewusst so gewählt.
Schließlich bieten neue Cores nicht nur andere Taktraten, sondern auch neue Features.

Da man nun davon ausgehen kann, das DualCore den SingleCore früher oder später vollständig verdrängen wird, ist der Vergleich sowieso hinfällig, denn irgendwann gibt es nunmal keine SingleCore Varianten mehr, die auf dem aktuellsten Stand sind...

Es sollte lediglich zeigen, das locker 50% und mehr Steigerungen möglich sein, irgendwo hatte ich auch mal einen Benchmark mit fast 80% Unterschied gesehen; weiß nur nicht mehr wo.

Gast

2006-01-15, 19:05:46

Zumal ich da beim besten willen keinen großen Unterschied sehe.

Wenn der sogar noch L3 Cache hat und ein Northwood ist, dann wird er eine sehr hohe pro-MHz Leistung haben. ;-)

IVN

2006-01-15, 19:08:29

Ich habe den bewusst so gewählt.
Schließlich bieten neue Cores nicht nur andere Taktraten, sondern auch neue Features.

Da man nun davon ausgehen kann, das DualCore den SingleCore früher oder später vollständig verdrängen wird, ist der Vergleich sowieso hinfällig, denn irgendwann gibt es nunmal keine SingleCore Varianten mehr, die auf dem aktuellsten Stand sind...

Es sollte lediglich zeigen, das locker 50% und mehr Steigerungen möglich sein, irgendwo hatte ich auch mal einen Benchmark mit fast 80% Unterschied gesehen; weiß nur nicht mehr wo.
Lol,wieso vergleichst du dann keinen P4 mit 2GHz gegen einen A64 X2 mit 2GHz?? :uhammer2:
Ein Presy SC gegen eine Presy DC beim gleichen Takt ist fair,aber das..... :crazy:

Gast

2006-01-15, 19:11:22

Lol,wieso vergleichst du dann keinen P4 mit 2GHz gegen einen A64 X2 mit 2GHz?? :uhammer2:

Weil das schwachsinn ist? Zwei verschiedene Hersteller, zwei Architekturen und außerdem hat es nichts mit dem Thema zu tun.

Es ging mir überhaupt niemals darum, irgendetwas zu vergleichen. Es ging mir nur darum, die DualCore Vorteile aufzuzeigen und sie sind mehr als deutlich.

IVN

2006-01-15, 19:12:30

Zumal ich da beim besten willen keinen großen Unterschied sehe.

Wenn der sogar noch L3 Cache hat und ein Northwood ist, dann wird er eine sehr hohe pro-MHz Leistung haben. ;-)
Tja,ein Northwood mit ~25Mio. Transis Logikanteil pro Core,und ein Presy mit ~80Mio.

IVN

2006-01-15, 19:15:47

Weil das schwachsinn ist? Zwei verschiedene Hersteller, zwei Architekturen und außerdem hat es nichts mit dem Thema zu tun.

Es ging mir überhaupt niemals darum, irgendetwas zu vergleichen. Es ging mir nur darum, die DualCore Vorteile aufzuzeigen und sie sind mehr als deutlich.
Man kann sie aber auch nicht mit 2 verschiedene Architekturen des selben Herstellers auzeigen.

Gast

2006-01-15, 19:16:59

Tja,ein Northwood mit ~25Mio. Transis Logikanteil pro Core,und ein Presy mit ~80Mio.

Ändert nichts daran, das die Unterschiede minimal sind. Anfangs war der Prescott sogar langsamer als der NW, was er dann mit mehr Cache und höheren Taktraten ausgebügelt hat.

Die Unterschiede sind immer noch minimal, es kann durchaus sein, das der NW vor einem gleichgetakten Prescott liegt.

Vergleiche gibts hier zuhauf: http://www.tomshardware.de/cpu/20051103/cpu-charts-62.html

Der Vergleich ist sowieso hinfällig, denn wie ich schon sagte, es wird früher oder später keine gleichgetakteten SingleCores mehr geben, also spielt das auch keine Rolle.

Gast

2006-01-15, 19:19:39

Die >50% Unterschied kommen - das sollte jeder erkennen - einzig und allein durch den zweiten Kern zustande, was schon sehr beachtlich ist.

Darum gings mir, um nichts anderes.

WEGA

2006-01-15, 19:42:29

ich kauf mir aller frühestens DC, wenn er billiger ist als 2 einzelne CPUs.

Gast

2006-01-15, 19:48:04

ich kauf mir aller frühestens DC, wenn er billiger ist als 2 einzelne CPUs.

Dann müsstest du ihn jetzt kaufen. ;-)

Der neue DC Presler (2x3 GHz) ist z.B. schon für 323€ zu haben, während die normalen Varianten immer noch mit ca. 167€ zur Buche schlagen.

WEGA

2006-01-15, 19:56:38

Dann müsstest du ihn jetzt kaufen. ;-)

Der neue DC Presler (2x3 GHz) ist z.B. schon für 323€ zu haben, während die normalen Varianten immer noch mit ca. 167€ zur Buche schlagen.

ich rede doch von amd. nie im leben kauf ich mir nen p4 mit flaschenhals. außerdem sagte ich "aller frühestens". d.h. noch lange nicht, dass ich es tue, wenn es soweit ist ;)

Demirug

2006-01-15, 20:01:01

Spasstiger

2006-01-15, 20:11:49

Ein Athlon 64 X2 3800+ erreicht bei Spielen, die von Dual-Core-Optimierungen profitieren (sei es vom Grafiktreiber oder vom Spiel aus), eine Performance, die mit einer teureren Single-Core-CPU mithalten kann. Und in letzter Zeit werden es vor allem dank der Optimierung im Grafiktreiber immer mehr Spiele, die deutliche Vorteile aus zwei Kerne ziehen können.
Hinzu kommt eine Vorteil von bis zu 100% in Anwendungen, die leicht parallelisierbar sind, wie Encoding und der subjektive Vorteil des direkteren Ansprechverhaltens des Rechners generell.

Wer 300 Euro für eine CPU ausgeben würde, sollte imo gleich in einen Dual-Core investieren. Übertakten kann man die zudem auch. ;)

paul.muad.dib

2006-01-15, 21:37:22

[QUOTE=Gast]Genau da könnte ich aber auch ein anderes Ergebniss liefern:
http://www.tomshardware.com/2005/12/28/intels_65_nm_process_breathes_fire_into_double_core_extreme_edition/page19.html

Man vergleiche mal P4 EE 955 3,46 GHz (1:16 min) und P4 EE 3,46 GHz (2:06). Das ist schon ein erheblicher Unterschied...[\Quote]

Du vergleichst hier einen Northwood mit einem Pressler, dazwischen liegen 2 1/2 Prozessorgenerationen. Der Northwwod war zwar anfangs bei Spielen etwas schneller, im encoding lag aber gleich der Prescott vorne. Unter anderem besitzt dieser SSE3 und weitere Optimierungen.
Interessanter wäre hier ein Vergleich zw. Cedar Mill und Pressler mit gleicher Taktfrequenz.

krypt

2006-01-15, 22:37:28

Bei der Multitcore Programmierung trennt sich mal wieder die Spreu vom Weizen. Das ist wie jedesmal wenn eine neue Technologie auf dem Vormarsch ist. Am Anfang beherrschen sie nur die Experten doch dann werden die Tools immer besser und immer mehr Entwickler können sie nutzen. Defakto gibt es derzeit kaum Tools um die Multicore Entwicklung zu vereinfachen man muss fast alles von Hand machen. Das ist so ähnlich wie damals als man bei den Singlecores noch alles mit Assembler machen musste und ein Makro-Assembler das einzige Hilfsmittel war. Es ist aber durchaus möglich das dabei einige der alten Hasen die nicht bereit sind sich anzupassen auf der Strecke bleiben.

wie schlecht, dass auslagern von ablaeufen auf threads keine technologie ist.
(man kann es auch paralellisierung oder sonstwie nennen)

dieses forum ist imho nicht der geeignete platz, fur solch softwaretechnische diskussionen, wie an so mancher anwort hier festzustellen ist.

anhang: gut durchdachtes softwaredesign + implemetation wird noch immer von menschen und nicht von tools gemacht

Demirug

2006-01-15, 23:04:41

wie schlecht, dass auslagern von ablaeufen auf threads keine technologie ist.
(man kann es auch paralellisierung oder sonstwie nennen)

dieses forum ist imho nicht der geeignete platz, fur solch softwaretechnische diskussionen, wie an so mancher anwort hier festzustellen ist.

anhang: gut durchdachtes softwaredesign + implemetation wird noch immer von menschen und nicht von tools gemacht

Das streite ich ja gar nicht ab. Die Tools sind ja nur dazu da diesen Prozess zu vereinfachen.

In diesem Zusammenhang sind WWF, Concurrency and Coordination Runtime (CCR) und Dryad sehr interessante Projekte.

krypt

2006-01-15, 23:23:44

Demirug

2006-01-15, 23:57:08

Ich arbeite als Softwareentwickler sowohl im Bereich der Industrie wie auch der Spiele Entwicklung. Die Erfahrung mit der Industriesoftware macht sich jetzt bezahlt weil man dort schon seit Jahren auf Multi CPU Systeme setzten konnte. Bei einer Anlage im 7 bis 8 stelligen Bereich kommt es auf die paar Euros für ein paar zusätzliche CPUs nicht so sehr an. Entsprechen konnte ich da viel Erfahrung sammeln. Ein Teil dieser Erkenntnisse habe ich dann auch auf die Game Engine übertragen an der ich arbeite. Gerade Spiele lassen sich sehr gut auf viele CPUs verteilen das es dort viele eigenständige Elemente gibt. So kann zum Beispiel jeder NPC auf einen eigenen Core laufen. ähnliches gilt für die meisten Scripte die man benutzt. Das Hauptproblem dabei ist allerdings die gemeinsame Datenbasis. Aber dafür gibt es einen einfachen Trick den ich schon vor Jahren in der Automatisierungstechnik gelernt habe: „Sample Hold Calculate Update“. Zuerst aktualisiert (Sample) man die gesamte Datenbasis. Das kann auch schon von mehren Cores erfolgen. Dann friert man sie ein (Hold) und dann erst wird gerechnet (Calculate). Erst wenn alle Berechnungen abgeschlossen sind wird zurück geschrieben. (Update). Das Verfahren ist absolute Narren sicher. Das Problem ist nur das es keine fertigen Tools gibt die eine „normale“ Funktion automatisch in die Phasen zerlegt. An diesem Problem arbeite ich unter anderem geraden.

paul.muad.dib

2006-01-16, 01:01:41

Wieviel Performancegewinn wäre dein deiner Meinugn nach realistisch? Wieviel Leistung kostet das "hold"?

2006-01-16, 01:09:45

nun, ich bin einfacher anwendungsentwickler unter java, c++, kein spieleentwickler. jedoch kann ich aus erfahrung sagen, dass die meisten prozesse linear nacheinander ablaufen, augrund ihrer unaufloesbaren abhaengigkeit untereinander.

bist du (spiele)softwareentwickler und koenntest mal n konkretes beispiel anfuehren ?

genau das ist das problem. am einfachsten, bei spielen, lassen sich solche dinge wie z.b.:

- ai
- physik
- grafik

trennen.

ich habe neulich mal mit java und der (gfx engine) http://www.jmonkeyengine.com/ und der (physik engine) http://www.ode.org/ herumgespielt. ich wollte ein simples 3d autorennen basteln. das kann man schon auf min. 2 thread parallelisieren, jedoch hatte ich ein paar probleme (ich leider nicht sehr java erfahren!) eine gewisse fps konstanz in das game zu bringen, sobal der sich der gc aktivierte, hatte das programm gewisse aussetzer (neuere vm's weden das wohl lösen, da sie nicht mehr das java programm anhalten). also im groben kann man schon parallelisieren, nur wenn man die granularität eben zu fein macht, kann der nutzen durch synchonisationen / locks etc. arg blockiert werden. ein guter profiler ist da wirklich sehr hilfreich. server applikation (z.b. appache...) lassen sich dagegen viel einfacher parallelisiern, z.b. könnte jede verbindung einen thread / process bekommen...

p.s. hat hier jemand erfahrung mit multi-threaded opengl rendering? unter dx8/9 hab ich das schon zufriedenstellend hinbekommen, aber unter opengl sehe ich da schwierigkeiten, ausser ich lege alle aufrufe in ne große liste und arbeite sie nach meinen vorstellungen ab...

ich bastel an etwas ähnlichem wie fraps, nur muss meine anwendung under dx8/dx9/opengl immer min. 25 fps haben, egal was das game macht....

thomas

Demirug

2006-01-16, 08:09:09

Wieviel Performancegewinn wäre dein deiner Meinugn nach realistisch? Wieviel Leistung kostet das "hold"?

Das ganze skaliert sehr gut. Die genaue Steigerung hängt aber stark vom Einzelfall ab.

Das "Hold" selbst kostet gar keine Leistung weil es nur ein logischer Schritt ist. Der Leistungsverlust entsteht durch das Zwischenspeichern der Änderungen.

HellHorse

2006-01-16, 09:37:32

Auch die Compiler können das nicht wirklich gut.
Sobald man sich von Nebeneffekten verabschiedet (pur funktional, resp. single-assignment) geht das erstaunlich gut. Es ist wirklich verblüffend, was in dieser Richtung schon alles gemacht wurde. Bloss solange Spieleentwickler C++ als das höchste der Gefühle (d.h. mindestens 10 Jahre) betrachten, wird daraus wohl nichts.

Demirug

2006-01-16, 09:48:32

Sobald man sich von Nebeneffekten verabschiedet (pur funktional, resp. single-assignment) geht das erstaunlich gut. Es ist wirklich verblüffend, was in dieser Richtung schon alles gemacht wurde. Bloss solange Spieleentwickler C++ als das höchste der Gefühle (d.h. mindestens 10 Jahre) betrachten, wird daraus wohl nichts.

Von Konsolen Entwicklern werden ja heute immer noch gefordert das sie Assembler beherschen. Wie gesagt die CCR gefällt mir von Ansatz her schon recht gut. Man muss sich aber schon umstellen wenn man damit arbeiten will.

Für Spiele halte ich derzeit den oben beschriebenen Ansatz allerdings für besser. Das einzige Problem mit dem ich dabei noch Kämpfe ist die Automatisierung des verzögerten Writebacks so das man darauf beim schreiben der Scripte nicht selbst achten muß.

Gast

2006-01-16, 10:24:55

Ich bring mal meine praktische Erfahrung in diese theoretische Diskussion ein.
Ich bin vor kurzem von einem A64 3000+ auf einen Opteron 165 @ 2400MHz umgestiegen. Ich kann jetzt meinen Virenscanner im OnAccess Mode im Hintergrund laufen lassen, ohne daß das System auch nur ein bischen ausgebremst wird. Ich mache viel mit Video- und Bildbearbeitung. Auch hier ist das Arbeiten unter Windows viel angenehmer. Das System reagiert sofort auf meine Eingaben, egal welche Software im Hintergrund läuft. Das Encoden mit CCE ist ebenfalls deutlich schneller.
Da ich auf meine Daten beruflich angewiesen bin, mach ich regelmäßig Backups mit Acronis True Image. Ich war selbst überrascht, daß dieses Programm einen zweiten Core zu 100% ausnutzen kann. Meine 10Gig Windows Partition kann ich jetzt in unter 2 Minuten sichern!!! Das Ziel-Image wird dabei auf knapp 5Gig komprimiert.
Jeder muss für sich entscheiden, ob sich das Geld für einen DualCore lohnt. Für mich hat es sich gelohnt und meiner Meinung nach schafft es kein noch so übertakteter SingleCore Prozessor, Windows so reaktionsfreudig und flüssig bedienbar zu machen.

HOT@Unterricht

2006-01-16, 11:20:02

IVN,

Jetzt häng dich net so daran auf, dass es ein Gallatin ist. Ein Gallatin 2M hat deutlich mehr Power als ein Pressi 2M bei gleichem Takt.
Das liegt vor allem daran, dass der Gallatin eine kürzere Pipe hat und einen fast doppelt so schnellen L2 Cache. Wieviele Transen jetzt letztendlich Logik sind, ist eine vollkommen irrelevante Information. Wichtig ist, dass an der Architektur kaum etwas geändert wurde.

Gast

2006-01-16, 11:22:39

IVN

2006-01-16, 11:28:32

Gast

2006-01-16, 11:30:07

Ja,Gallatin ist schneller(aber nicht ueberall).Meinst du aber nicht das man ein Apfel mit Aepfeln und eine Birne mit Birnen vergleichen sollte?

Das mag schon sein, aber bei einem generell schnellerem Core sollte ein Vergleich erlaubt sein.
Es gibt fast keine Bereiche in denen der Pressi Vorteile hat - erst recht keine Spiele.

IVN

2006-01-16, 11:40:27

Das mag schon sein, aber bei einem generell schnellerem Core sollte ein Vergleich erlaubt sein.
Es gibt fast keine Bereiche in denen der Pressi Vorteile hat - erst recht keine Spiele.
Es ist egal ob er schneller oder langsamer ist,es ist und bleibt eine andere CPU.

dilated

2006-01-16, 12:31:11

wer redet noch vom p4??? hab ich was verpasst?

Monger

2006-01-16, 13:39:50

Das ganze skaliert sehr gut. Die genaue Steigerung hängt aber stark vom Einzelfall ab.

Das "Hold" selbst kostet gar keine Leistung weil es nur ein logischer Schritt ist. Der Leistungsverlust entsteht durch das Zwischenspeichern der Änderungen.

... was aber unter Umständen gewaltig sein kann, oder? Ich meine: in deinem Fall gibt es doch nur eine Datenbasis, und die wird angehalten sobald irgendein Unterprozess versucht sich zu ändern?!?

Ich hab keine echte Erfahrung mit dem Thema, aber ich hatte mal ne Vorlesung Simulationstechnik - wo die Synchronität ja ein besonderes Problem darstellt, weil man da oft genug sogar auf völlig verschiedenen PCs verteilt rechnet.

Die Lösungen dafür aber waren haarig, vorallem wenn das System erweiterbar bleiben sollte. Wie in der Datenbank wurde da ständig ziemlich optimistisch geschätzt - und dann halt bei Bedarf teilweise oder sogar komplett ein Rollback gemacht. Vorallem wurde der Raum in sehr, SEHR viele Unterräume aufgebrochen, was den Kommunikationsaufwand einerseits reduziert, andererseits aber extrem verkompliziert hat.

Ich denke, dass Parallelität ein wirklich ernsthaftes Problem ist. Der Computer ist nunmal darauf ausgelegt, einen definierten Zustand nach dem anderen anzunehmen. Durch die Parallelität gerät das alles ins schwimmen.

Ich bin mal gespannt wo die Entwicklung hingeht. Ein zusätzlicher Kern mag ja noch gehen, aber wenn wir mal 16 oder 32 Cores haben, wird alleine das Management der ganzen Cores eine Herausforderung. Hoffentlich gibt es bis dann entsprechende Frameworks.

Demirug

2006-01-16, 15:07:19

... was aber unter Umständen gewaltig sein kann, oder? Ich meine: in deinem Fall gibt es doch nur eine Datenbasis, und die wird angehalten sobald irgendein Unterprozess versucht sich zu ändern?!?

Ich hab keine echte Erfahrung mit dem Thema, aber ich hatte mal ne Vorlesung Simulationstechnik - wo die Synchronität ja ein besonderes Problem darstellt, weil man da oft genug sogar auf völlig verschiedenen PCs verteilt rechnet.

Die Lösungen dafür aber waren haarig, vorallem wenn das System erweiterbar bleiben sollte. Wie in der Datenbank wurde da ständig ziemlich optimistisch geschätzt - und dann halt bei Bedarf teilweise oder sogar komplett ein Rollback gemacht. Vorallem wurde der Raum in sehr, SEHR viele Unterräume aufgebrochen, was den Kommunikationsaufwand einerseits reduziert, andererseits aber extrem verkompliziert hat.

Ich denke, dass Parallelität ein wirklich ernsthaftes Problem ist. Der Computer ist nunmal darauf ausgelegt, einen definierten Zustand nach dem anderen anzunehmen. Durch die Parallelität gerät das alles ins schwimmen.

Ich bin mal gespannt wo die Entwicklung hingeht. Ein zusätzlicher Kern mag ja noch gehen, aber wenn wir mal 16 oder 32 Cores haben, wird alleine das Management der ganzen Cores eine Herausforderung. Hoffentlich gibt es bis dann entsprechende Frameworks.

Der Hold ist Teil des Gameloops und wie geschrieben nur eine logische Vereinbarung das ab diesem Zeitpunkt jede Funktion nur noch lesend auf die globalen Daten zugreift. Jede Funktion hat natürlich noch einen lokale Datenbasis. Sobald der Hold aufgehoben ist werden die lokalen Daten wieder in die globalen eingepflegt und der nächste Zyklus gestartet.

Das ganze skaliert solange man ausreichend Teilaufgaben hat über eine sehr große Anzahl von Cores. Um dabei bei den Spielen zu bleiben. Jedes Script für eine Tür, Lampe oder was es sonst noch so alles gibt ist dabei eine solche Teilaufgabe.

Das Problem dabei ist nun folgendens. Ein Script für eine Lampe die mit einem Taster gesteuert wird sieht zum Beispiel wie folgt aus.

if (Taster && !Merker)
{
Lampe = !Lampe
Merker = true;
}

if (!Taster)
{
Merker = false;
}

In einer HOLD Architektur wäre das nicht erlaubt. Dort müsste das Script wie folgt aussehen.

LOCKED:

LampeSave = Lampe
MerkerSave = Merker;

if (Taster && !Merker)
{
LampeSave = !Lampe
MerkerSave = true;
}

if (!Taster)
{
MerkerSave = false;
}

UNLOCKED:
Merker = MekerSave;
Lampe = LampeSave;

Ziel muss es nun sein den den passenden Code für die HOLD Architektur automatisch zu erzeugen oder dafür zu Sorgen das bei der Ausführung automatisch Schattenkopien erzeugt und wieder zurück spiegelt.

HellHorse

2006-01-16, 16:53:41

Von Konsolen Entwicklern werden ja heute immer noch gefordert das sie Assembler beherschen.
Bei dem das Sony unter Tools versteht ist das ja auch begründet. Bloss muss man sich dann nicht über die Konsequenzen wurdern.

HellHorse

2006-01-16, 16:59:52

Ziel muss es nun sein den den passenden Code für die HOLD Architektur automatisch zu erzeugen oder dafür zu Sorgen das bei der Ausführung automatisch Schattenkopien erzeugt und wieder zurück spiegelt.
Source-to-source Transformation? Solange es nur so wie das Beispiel ist, ist es ja nicht so schwer.

Piffan

2006-01-16, 18:45:55

Der Hold ist Teil des Gameloops und wie geschrieben nur eine logische Vereinbarung das ab diesem Zeitpunkt jede Funktion nur noch lesend auf die globalen Daten zugreift. Jede Funktion hat natürlich noch einen lokale Datenbasis. Sobald der Hold aufgehoben ist werden die lokalen Daten wieder in die globalen eingepflegt und der nächste Zyklus gestartet.

Das ganze skaliert solange man ausreichend Teilaufgaben hat über eine sehr große Anzahl von Cores. Um dabei bei den Spielen zu bleiben. Jedes Script für eine Tür, Lampe oder was es sonst noch so alles gibt ist dabei eine solche Teilaufgabe.

Das Problem dabei ist nun folgendens. Ein Script für eine Lampe die mit einem Taster gesteuert wird sieht zum Beispiel wie folgt aus.

if (Taster && !Merker)
{
Lampe = !Lampe
Merker = true;
}

if (!Taster)
{
Merker = false;
}

In einer HOLD Architektur wäre das nicht erlaubt. Dort müsste das Script wie folgt aussehen.

LOCKED:

LampeSave = Lampe
MerkerSave = Merker;

if (Taster && !Merker)
{
LampeSave = !Lampe
MerkerSave = true;
}

if (!Taster)
{
MerkerSave = false;
}

UNLOCKED:
Merker = MekerSave;
Lampe = LampeSave;

Ziel muss es nun sein den den passenden Code für die HOLD Architektur automatisch zu erzeugen oder dafür zu Sorgen das bei der Ausführung automatisch Schattenkopien erzeugt und wieder zurück spiegelt.

Verstehe ich das richtig, dass ein Programm theoretisch in der Lage wäre, "klassischen" Code so umzustricken, dass er auf einem Multicore- System läuft; und dass ohne manuelle Fummelei, vollautomatisch sozusagen?

Das würde doch sicher enormes Leben in die Open-Source-Bewegung bringen?

Senior Sanchez

2006-01-16, 18:48:45

Verstehe ich das richtig, dass ein Programm theoretisch in der Lage wäre, "klassischen" Code so umzustricken, dass er auf einem Multicore- System läuft; und dass ohne manuelle Fummelei, vollautomatisch sozusagen?

Das würde doch sicher enormes Leben in die Open-Source-Bewegung bringen?

Das gibt es doch schon, nur etwas beschränkt im Funktionsumfang ;) OpenMP sei hier genannt, das hauptsächlich Schleifen parallelisiert.

Demirug

2006-01-16, 20:51:59

Source-to-source Transformation? Solange es nur so wie das Beispiel ist, ist es ja nicht so schwer.

Das Beispiel war auch sehr einfach. Kritisch wird es wenn Objekt übergreifend oder noch schlimmer mit Kollektionen gearbeitet wird.

Demirug

2006-01-16, 20:56:28

Das gibt es doch schon, nur etwas beschränkt im Funktionsumfang ;) OpenMP sei hier genannt, das hauptsächlich Schleifen parallelisiert.

Bei OpenMP muss aber immer noch der Entwickler sagen welche schleifen wie verteilt werden sollen. Ist also nichts anderes als ein paar neue Anweisungen zu einer besetehenden Sprache hinzuzufügen.

@Piffan. So einfach ist das leider nicht. Das von mir erwähnte Verfahren funktioniert bei den meisten Anwendungen überhaupt nicht. Die automatische verteilung von beliebigem Code auf mehrer Prozessoren ist eine der großen ungelössten Herausforderungen.

Senior Sanchez

2006-01-16, 21:11:12

Bei OpenMP muss aber immer noch der Entwickler sagen welche schleifen wie verteilt werden sollen. Ist also nichts anderes als ein paar neue Anweisungen zu einer besetehenden Sprache hinzuzufügen.

Hmm, laut wikipedia bzw. dem Heise-Artikel den ich neulich über die neuen C++ Compiler von MS und Intel gelesen habe, meine ich mich zu erinnern, dass es auch ohne diese Eingriffe des Entwicklers geht.

Wobei ich mir das auch nicht so recht vorstellen kann, weil was ist wenn ein Wert auf dem Wert des vorigen Iterationsschrittes aufbaut? Das kann ja dann nicht parallel laufen, aber gerade so eine Analyse des Codes und der Abhängigkeiten dürfte irgendwie nich ganz so einfach sein.

Demirug

2006-01-16, 21:44:15

Hmm, laut wikipedia bzw. dem Heise-Artikel den ich neulich über die neuen C++ Compiler von MS und Intel gelesen habe, meine ich mich zu erinnern, dass es auch ohne diese Eingriffe des Entwicklers geht.

Wobei ich mir das auch nicht so recht vorstellen kann, weil was ist wenn ein Wert auf dem Wert des vorigen Iterationsschrittes aufbaut? Das kann ja dann nicht parallel laufen, aber gerade so eine Analyse des Codes und der Abhängigkeiten dürfte irgendwie nich ganz so einfach sein.

Man muss eine ganze Menge pragmas in den Code einfügen:

http://www.openmp.org/drupal/mp-documents/spec25.pdf <- mit einigen Beispielen.

Was dann automatisch geht ist das aufteilen auf die Threads wenn die entsprechenden Pragmas eingefügt wurden.

HellHorse

2006-02-02, 12:33:45

Passt vielen Orten rein, ich poste es mal hier:
Tim Sweeny über "The Next Mainstream Programming Languages"
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
Recht interessant da er auch pur funktionale Sprachen befürwortet. Aber Smalltalk hat Integers seit den 70ern korrekt und Sachen wie Sisal parallelisieren die 90% seiner Loops seit Ewigkeiten. Und wenn nichts ausser throw eine Exception generieren soll, was passiert dann bei 1 / 0?

Monger

2006-02-02, 14:47:49

Passt vielen Orten rein, ich poste es mal hier:
Tim Sweeny über "The Next Mainstream Programming Languages"
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

Sehr spannend, aber was ist mit "Lazy Evaluation" gemeint? Das habe ich nicht verstanden.

Und wenn nichts ausser throw eine Exception generieren soll, was passiert dann bei 1 / 0?
Da müsste man halt den Divisionsoperator so überladen, dass er ein "throw" macht, sobald er beim Nenner eine Null erkennt.

Die Idee ist nicht doof. Ich habe mich sowieso gefragt, warum in Java es überhaupt Basisdatentypen gibt. Die könnte man doch genauso als finale Typen definieren, wie es afaik C# macht.

HellHorse

2006-02-02, 21:31:53

Sehr spannend, aber was ist mit "Lazy Evaluation" gemeint? Das habe ich nicht verstanden.
Dass Ausdrücke erst ausgewerted werden, wenn ihr Wert benötigt wird.
http://en.wikipedia.org/wiki/Lazy_evaluation

Die Idee ist nicht doof. Ich habe mich sowieso gefragt, warum in Java es überhaupt Basisdatentypen gibt.
Das weiss niemand wirklich.

Die könnte man doch genauso als finale Typen definieren, wie es afaik C# macht.
C# macht doch das gleiche wie Java, auto(un)boxing. Das ist so doof, dafür kennt die deutsche Sprache kaum genug Worte.