PureBoard

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?

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.

Quake vier z.B wird es auf Multicoreprozessoren bringen. Die Entwickler haben das Spiel so programiert, dass ein Kern die Physik berechnet und der andere den Rest.

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.

Wie funktioniert das jetzt eigentlich? Wie kann jedem Prozessorkern seine Arbeit zuweisen?

Threads werden dann vom Betriebssystem nach bedarf auf die Kerne
verteilt. Als Programmierer kann man glaub aber auch sagen, ob ein
Thread auf Kern a oder b laufen soll ... aber wie genau das war hab ich
wieder vergessen.

MFG PMV

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.

Also doch reales Multithreading.

Ich denke wenn man ein kleines 2D-Spiel programmiert, wo Berechnung und Darstellung in getrennten Threads verarbeitet werden könnte sich sowas schon lohnen.

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.

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.