Dual Core

Don06

groovemaster schrieb:

Und welche Grafikkarte hat er? Spiele sind idR nicht so CPU lastig, die Grafikkarte ist dort entscheidender.
Ich kenne zwar Gothic 3 nicht, habe aber gelesen, dass das Spiel zudem sehr speicherintensiv sein soll.
2 GB RAM bringen dort wohl einen spürbaren Vorteil gegenüber einem GB.

Ja da hast du Recht allerdings war das glaub ich so
GF7600(?) vs. GF6800
2GB RAM vs. 1GB RAM

Das Erste, was man also als Flaschenhals ausmachen könnte, wäre dann ja wohl die CPU.
Allerdings kenne ich mich da auch nicht so mit aus.

Gruß
Don06

LeGaN

Don06 schrieb:

GF7600(?) vs. GF6800
2GB RAM vs. 1GB RAM

Das Erste, was man also als Flaschenhals ausmachen könnte, wäre dann ja wohl die CPU.

Kommt aufs Spiel an, ich würde da fast eher auf die 1GB RAM tippen

Gregor

Andreas XXL schrieb:

Es ist doch so, dass "normale" Programme, die nicht irgend welchen hochparallelisierbaren Mathe schnickschnack berechnen durchschnittlich sowieso maximal nur zu 40% parralelisierbar sind.

Gibt es so ne Faustregel? Mag sein. Die Frage ist dann aber, was ein "normales Programm" ist. Ein Computerspiel?

BTW: Ich habe auch mal gehört, dass mit solchen theoretischen Überlegungen 2,4 Kerne das Optimum darstellen sollen.

Don06

@ LeGan: Ähhm, es ging darum, dass es auf dem besseren Rechner schlechter lief.
Nur die GHz Zahl des besseren Rechners war geringer, dafür aber Dual-Core.

Naja, egal.
Gruß
Don06

LeGaN

Don06 schrieb:

@ LeGan: Ähhm, es ging darum, dass es auf dem besseren Rechner schlechter lief.
Nur die GHz Zahl des besseren Rechners war geringer, dafür aber Dual-Core.

Naja, egal.
Gruß
Don06

Achso, hatte es so verstanden, dass bei 1GB RAM schlechter lief *oops*

Grüßle
Jan

Jester

Gregor schrieb:

Andreas XXL schrieb:

Es ist doch so, dass "normale" Programme, die nicht irgend welchen hochparallelisierbaren Mathe schnickschnack berechnen durchschnittlich sowieso maximal nur zu 40% parralelisierbar sind.

Gibt es so ne Faustregel? Mag sein.

Vielleicht auch 40-90 Regel? 90 Prozent aller Entwickler können nur 40% parallelisieren?

hustbaer

Andreas XXL schrieb:

Es ist doch so, dass "normale" Programme, die nicht irgend welchen hochparallelisierbaren Mathe schnickschnack berechnen durchschnittlich sowieso maximal nur zu 40% parralelisierbar sind.

IMHO ist diese Faustregel Blödsinn. Es gibt einfach Dinge die können kaum von mehreren Threads in Hardware profitieren (GUIs z.B.), andere Dinge können wieder recht einfach fast beliebig parallelisiert werden, wie z.B. 3D Rendering, das Compilieren mehrerer Dateien, das Entpacken von Archiven, Audio-/Video-Bearbeitung, ...

Dass viele Programme es derzeit noch nicht unterstützen ist eine andere Geschichte, und liegt u.A. wohl daran dass es sich bis vor kurzem auch nicht wirklich rentiert hat. Wer hatte vor z.B. 2 Jahren denn schon ein Dual Core System?

groovemaster

Gregor schrieb:

Ich traue der Meldung da nicht so ganz. Irgendwie kommt es mir so vor, als ob die da die Codenamen völlig durcheinandergebracht haben. Mir ist nach dem Artikel da nicht klar, um welche Prozessoren es eigentlich geht.

Mit den Xeon Bezeichnungen kenne ich mich ehrlich gesagt überhaupt nicht aus. Die Rede ist aber von Kentsfield und Conroe, welche die Core 2 Architektur besitzen. Das sind also die ganz normalen x86 CPUs (Quad- und Dualcore).

rüdiger

Persönlich glaube ich, dass das Problem ist, was man sich zur Zeit unter Threads vorstellt: Shared-State-Threads wie sie die meisten Betriebssysteme zur Verfügung stellen, sind äußerst schwer zu programmieren und es richtig hinzubekommen ist fast ein Ding der Unmöglichkeit. Es ist imho sinnvoller, wenn man Threads voneinander trennt und nur über Nachrichten kommunizieren lässt (ala Erlang, MPI oder fork).

Aber ich denke es braucht ohnehin noch Zeit, bis die meisten Programme für SMP ausgestattet sind, da es schwer ist diese Techniken in bestehenden Code zu integrieren und die wenigsten Projekte werden ja von Anfang an geschrieben.

Aber von Multicore/SMP etc. profitiert man ja eh, da man idr ja mehr als einen Prozess laufen hat...

hustbaer

rüdiger schrieb:

Persönlich glaube ich, dass das Problem ist, was man sich zur Zeit unter Threads vorstellt: Shared-State-Threads wie sie die meisten Betriebssysteme zur Verfügung stellen, sind äußerst schwer zu programmieren und es richtig hinzubekommen ist fast ein Ding der Unmöglichkeit.

Nur wenn man versucht schlau zu sein. Wenn man sich dagegen an bestimmte Richtlinien hält ist es eigentlich relativ einfach. Die PTHREADS Richtlinien bzw. das offizielle PTHREADS Speichermodell ist zwar übertrieben restriktiv, dafür kann aber auch garnix passieren wenn man sich daran hält.

darthdespotism

Andreas XXL schrieb:

Und zu der Behauptung "Spiel xyz unterstützt Mehrkernprozessoren"
Die brauchen doch nur sowas simples wie die Soundausgabe auf nen zweiten Thread ausgelagert zu haben und die Aussage stimmt. Nur das der 2. thread dann möglicherweise nur 1% der Berechnungen übernimmt.
Aber gelogen haben se dann nicht

Da Sound meist sowieso asynchron abgearbeitet wird hast du diese "Parallelisierung" sowieso

Ich denk mal gerade beim Compilieren und Rendern dürfte man den 2. Kern, entsprechende Einstellungen vorausgesetzt, durchaus merken und nicht zu wenig

Blue-Tiger

Gregor schrieb:

BTW: Ich habe auch mal gehört, dass mit solchen theoretischen Überlegungen 2,4 Kerne das Optimum darstellen sollen.

Hast du dafuer zufaellig eine Quelle?

Gregor

Blue-Tiger schrieb:

Gregor schrieb:

BTW: Ich habe auch mal gehört, dass mit solchen theoretischen Überlegungen 2,4 Kerne das Optimum darstellen sollen.

Hast du dafuer zufaellig eine Quelle?

Ne. Aber das wurde manchmal auf Hardwareseiten gesagt, als es abzusehen war, dass mehrere Kerne in einen Prozessor kommen.

rüdiger

hustbaer schrieb:

rüdiger schrieb:

Persönlich glaube ich, dass das Problem ist, was man sich zur Zeit unter Threads vorstellt: Shared-State-Threads wie sie die meisten Betriebssysteme zur Verfügung stellen, sind äußerst schwer zu programmieren und es richtig hinzubekommen ist fast ein Ding der Unmöglichkeit.

Nur wenn man versucht schlau zu sein. Wenn man sich dagegen an bestimmte Richtlinien hält ist es eigentlich relativ einfach. Die PTHREADS Richtlinien bzw. das offizielle PTHREADS Speichermodell ist zwar übertrieben restriktiv, dafür kann aber auch garnix passieren wenn man sich daran hält.

ist folgender Code Threadsafe und hält er sich an deine Richtlinien?

SharedObject *getSharedObject() {
  static SharedObject *sharedObject;
  if(!sharedObject) {
    LOCK;
    if(!sharedObject) {
      sharedObject = new sharedObject;
    }
    UNLOCK;
  }
  return sharedObject;
}

hustbaer

rüdiger schrieb:

hustbaer schrieb:

rüdiger schrieb:

Persönlich glaube ich, dass das Problem ist, was man sich zur Zeit unter Threads vorstellt: Shared-State-Threads wie sie die meisten Betriebssysteme zur Verfügung stellen, sind äußerst schwer zu programmieren und es richtig hinzubekommen ist fast ein Ding der Unmöglichkeit.

Nur wenn man versucht schlau zu sein. Wenn man sich dagegen an bestimmte Richtlinien hält ist es eigentlich relativ einfach. Die PTHREADS Richtlinien bzw. das offizielle PTHREADS Speichermodell ist zwar übertrieben restriktiv, dafür kann aber auch garnix passieren wenn man sich daran hält.

ist folgender Code Threadsafe und hält er sich an deine Richtlinien?
SharedObject *getSharedObject() {
  static SharedObject *sharedObject;
  if(!sharedObject) {
    LOCK;
    if(!sharedObject) {
      sharedObject = new sharedObject;
    }
    UNLOCK;
  }
  return sharedObject;
}

2x nein.

http://www.c-plusplus.net/forum/viewtopic-var-p-is-1254099.html#1254099

Ok, ich widerspreche mir hier z.T. selbst, auf der einen Seite sag' ich Multithreading ist die Hölle, auf der anderen sag' ich es ist nicht so schwer. Das liegt einfach daran dass mein Hirn mir sage "es ist nicht so schwer", die Erfahrung sagt mir allerdings "es ist die Hölle", weil ich immer wieder so viele Leute so viele Dinge diesbezüglich falsch machen sehe.

machs halt so

static SharedObject *sharedObject;

SharedObject synchronized getSharedObject() {
    if(!sharedObject) {
      sharedObject = new sharedObject;
    }
    return sharedObject;
}

oben noch das * weg

rüdiger

hustbaer schrieb:

Ok, ich widerspreche mir hier z.T. selbst, auf der einen Seite sag' ich Multithreading ist die Hölle, auf der anderen sag' ich es ist nicht so schwer. Das liegt einfach daran dass mein Hirn mir sage "es ist nicht so schwer", die Erfahrung sagt mir allerdings "es ist die Hölle", weil ich immer wieder so viele Leute so viele Dinge diesbezüglich falsch machen sehe.

Wie gesagt, das was es schwer macht ist zum größten Teil das "Shared State"-Prinzip. Schau dir zB mal Erlang an.

mit *