Der E6420 ist draußen. Kostet ca. 180 € und hat 2*4 MB Cache.
http://www.compuland.de/product_info.ph ... d=geizhals
Was meint ihr? Lieber den Prozzi kaufen oder den E6600 mit 2*2,4 GHz, der 70 € mehr kostet?
Core 2 Duo Preise sinken enorm!!
Grafikkarten machen keine Physik. Als es die ersten Physikbeschleuniger gab sahen die Grafikkartenhersteller Konkurenz heranreifen. Konkurenz möchte man natürlich nicht, weswegen Ati und nVidia schnell ein paar pseudolösungen zusammenbastelten.
Der Haken an der sache ist, dass damit nur für das spiel irrelevante Physik berechnet werden kann, weil die bandbreiten nicht ausreichen um ausreichend schnell von und zum GPU Speicher zu transferieren.
Physik die sich auf den Spielverlauf auswirken kann (zb Hindernisse auf einer Rennstrecke) muß weiter entweder die CPU oder ein Physikbeschleuniger berechnen, die Grafikkarte ist dafür nutzlos.
Auch wäre es mal an der zeit mehr CPU leistung in dinge wie KI zu investieren.
Abgesehen von Spielen können auch richtige Anwendungen von mehr Kernen Profitieren vor allem überall da, wo sich ein Problem gut parallelisieren läßt. Rendering Programme profitieren zb stark, wenn die entsprechende Software auch multithreaded Programmiert ist.
Leider ist es sehr viel schwieriger Multithreaded zu Programmieren, weswegen viele Anwendungen das noch nicht nutzen, da erst jetzt der breite Markt echte Mehrprozessorsysteme hat.
Aber selbst wenn die Anwendungen alleine nicht davon profitieren hat das zumindest den Vorteil, das eine Aufwändige Anwendung den Rechner nicht Blockiert... einen Film umkodieren und nebenbei ein Spiel spielen geht zb.
Der Haken an der sache ist, dass damit nur für das spiel irrelevante Physik berechnet werden kann, weil die bandbreiten nicht ausreichen um ausreichend schnell von und zum GPU Speicher zu transferieren.
Physik die sich auf den Spielverlauf auswirken kann (zb Hindernisse auf einer Rennstrecke) muß weiter entweder die CPU oder ein Physikbeschleuniger berechnen, die Grafikkarte ist dafür nutzlos.
Auch wäre es mal an der zeit mehr CPU leistung in dinge wie KI zu investieren.
Abgesehen von Spielen können auch richtige Anwendungen von mehr Kernen Profitieren vor allem überall da, wo sich ein Problem gut parallelisieren läßt. Rendering Programme profitieren zb stark, wenn die entsprechende Software auch multithreaded Programmiert ist.
Leider ist es sehr viel schwieriger Multithreaded zu Programmieren, weswegen viele Anwendungen das noch nicht nutzen, da erst jetzt der breite Markt echte Mehrprozessorsysteme hat.
Aber selbst wenn die Anwendungen alleine nicht davon profitieren hat das zumindest den Vorteil, das eine Aufwändige Anwendung den Rechner nicht Blockiert... einen Film umkodieren und nebenbei ein Spiel spielen geht zb.
-
dllfreak2001
- Beiträge: 2925
- Registriert: 07.09.2004 23:44
- Wohnort: Bayern
Wobei bei Q4 sowieso kaum Physik zu sehen ist.
Mich würde interessieren, wenn ich in PB nen Programm mit den Standart Befehlen für die Threads in eben solche aufteile. Wird das OS die Threads dann auf die Kerne aufteilen oder sind das nur ein virtuelle Threads die garnichts damit zutun haben.
Mich würde interessieren, wenn ich in PB nen Programm mit den Standart Befehlen für die Threads in eben solche aufteile. Wird das OS die Threads dann auf die Kerne aufteilen oder sind das nur ein virtuelle Threads die garnichts damit zutun haben.
I´a dllfreak2001
In PureBasic kann man AFAIK nicht sagen, welcher Thread auf welcher CPU Laufen soll, aber das ist eh nicht so wichtig.
Threads werden vom Betriebsystem auf die Kerne verteilt. Optimalerweise erzeugt man genauso viele Threads wie CPUs zur verfügung stehen.
Dann läuft dieser Programmteil tatsächlich auf verschiedenen CPUs parallel.
Multithreaded programmieren hat aber viele Tücken, weswegen man da mehr aufpassen muß. Auch ist das Auffinden eines durch fehlerhafte Synchronisation verursachten Fehlers unter umständen sehr sehr schwierig.
Threads werden vom Betriebsystem auf die Kerne verteilt. Optimalerweise erzeugt man genauso viele Threads wie CPUs zur verfügung stehen.
Dann läuft dieser Programmteil tatsächlich auf verschiedenen CPUs parallel.
Multithreaded programmieren hat aber viele Tücken, weswegen man da mehr aufpassen muß. Auch ist das Auffinden eines durch fehlerhafte Synchronisation verursachten Fehlers unter umständen sehr sehr schwierig.
-
dllfreak2001
- Beiträge: 2925
- Registriert: 07.09.2004 23:44
- Wohnort: Bayern
Da kann man natürlich eine Menge schöner sachen machen. Einen Raycaster könnte man zb tatsächlich fast um die anzahl der CPUs beschleunigen.
Auch für echtzeit Raytracing ist das sehr interessant, weil das auch ein hervorragend parallelisierbares problem ist.
Bei einem reinen 2D Spiel würde ich das aber nur machen, wenn das ganze wirklich in einem fühlbarer mehr an geschwindigkeit resultiert (oder um ein schönes übungsprojekt zu machen), denn das Debuggen mit multithreading sollte man wirklich nicht unterschätzen!
Mit multithreading bringt man eine ordentliche portion nichtdeterminismus in den programmablauf, da muß man dann unbedingt drauf achtgeben.
Mein rat: wer es nicht brauch oder die Ambition hat sich damit auskennen zu wollen läßt besser die Finger davon.
Auf jeden Fall dazu erst infos sammeln und ein bischen lesen, sonst gibt es böse überraschungen.
Auch für echtzeit Raytracing ist das sehr interessant, weil das auch ein hervorragend parallelisierbares problem ist.
Bei einem reinen 2D Spiel würde ich das aber nur machen, wenn das ganze wirklich in einem fühlbarer mehr an geschwindigkeit resultiert (oder um ein schönes übungsprojekt zu machen), denn das Debuggen mit multithreading sollte man wirklich nicht unterschätzen!
Mit multithreading bringt man eine ordentliche portion nichtdeterminismus in den programmablauf, da muß man dann unbedingt drauf achtgeben.
Mein rat: wer es nicht brauch oder die Ambition hat sich damit auskennen zu wollen läßt besser die Finger davon.
Auf jeden Fall dazu erst infos sammeln und ein bischen lesen, sonst gibt es böse überraschungen.
Man kann aber nachträglich per API Windows sagen, auf welchen
Prozessoren/Kernen der Thread laufen darf. Ich habe das damals
für einen alten Threadmanager (Der übrigens sehr gut funktioniert
hat!) diese Funktion raus gesucht. Wurde damals aber ausgebuht,
da man solche Sachen dann doch dem System überlassen sollte.
Prozessoren/Kernen der Thread laufen darf. Ich habe das damals
für einen alten Threadmanager (Der übrigens sehr gut funktioniert
hat!) diese Funktion raus gesucht. Wurde damals aber ausgebuht,
da man solche Sachen dann doch dem System überlassen sollte.
