Was bringt ein Dualprozessorsystem?

Von: , Frage gestellt am Fr, 25. Feb 2000

Man kommt ja immer günstiger an Dualmainboards ran und zwei PII-CPUs kosten auch nicht mehr die Welt...
Aber was bingt es mir als normalsterblicher User ohne NT?
Läuft da alles ein bißchen schneller?
Lohnt sich die Investition?

18 Antworten zu dieser Frage

  1. Antwort von nach 16 Stunden hilfreich
    Re: Was bringt ein Dualprozessorsystem?

    Hallo ecki,

    Ohne NT/Win2000 oder LINUX überhaupt nichts.
    Falls NT oder LINUX muß die Verwendete
    Software auch für Mehrprozessorbetrieb
    geeignet sein.Also kommt es darauf an
    was du mit dem Rechner machen willst.
    Für Spiele unter Win95/98 wäre es reine
    Verschwendung. Außer Quake gibt es glaube ich kein Game,daß zwei Prozessoren unter-
    stützen würde.Außerdem würde Win95/98 bei
    zwei Prozessoren zwar ohne Probleme laufen
    aber nur mit einem Prozessor.

    Hoffe etwas geholfen zu haben.

    Gruß Norbert [Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

  2. Antwort von nach einem Tag hilfreich
    Re: Was bringt ein Dualprozessorsystem?

    Mit Win98/95: NIX !!!
    Mit Win 2000: Mußt du wissen meiner Ansicht nach aber auch herzlich wenig.
    Du mußt wissen, dass zwei P3-500 noch lange nict die Leistung vom einem Gigaherz rüberbringen.

    • Antwort von nach 4 Tagen hilfreich
      Re^2: Was bringt ein Dualprozessorsystem?

      Verbreite hier keinen Blödsinn !!

      Es kommt drauf an, was für Rechenoperationen ausgeführt werden !
      Unter NT ist ein P2B-DS mit 2 PII 233 mit 66Mhz Busfreq. 4 mal schneller als ein PIII 500MHz auf Asus Board mit 100MHz Bus !!!! Also, stelle nächstes mal lieber dem fragenden die Rückfrage, was er will! Und sage ihm schlicht und einfach: Unter win95/98 macht es keinen Sinn (siehe andere Antwort...)

      Gruß
      Axel

      • Antwort von nach 4 Tagen hilfreich
        Re^3: Was bringt ein Dualprozessorsystem?

        Verbreite hier keinen Blödsinn !!
        dito! Es kommt drauf an, was für
        Rechenoperationen ausgeführt werden !
        was sollen das denn für welche sein??? Unter NT ist ein P2B-DS mit 2 PII 233 mit
        66Mhz Busfreq. 4 mal schneller als ein
        PIII 500MHz auf Asus Board mit 100MHz Bus
        mal ganz einfach ohne die Verwaltungsverluste des Dual-Systems zu betrachten, 233*2=466 < 500 MHz,
        P3 schneller P2 - es sei denn, Du benutzt 16-bit Programme zum rechnen - dann allerdings selbst Schuld!!! !!!! Also, stelle nächstes mal lieber dem
        fragenden die Rückfrage, was er will!
        Warum? es hat alles gestimmt, was er geschrieben hat!
        Sollte ein test bei Dir wie beschrieben abgelaufen sein, würde ich eher auf einen Konfigurationsfehler tippen als aufs Tempo des Dual-Systems.

        Micha

        • Antwort von nach 4 Tagen hilfreich
          Re^4: Was bringt ein Dualprozessorsystem?

          also:

          es ist ein 32-bit Programm und was ich lediglich sagen wollte:

          es kommt auf die Rechenoperationen an, die ausgeführt werden, und die DS-Mainboard-Struktur verwaltet den Prozessorcache um ein vielfaches besser und schneller, probier`s einfach mal aus und rechne nicht 2*233<500 - das ist mir leider zu trivial und klappt hier nicht !

          gruß
          axel

          • Antwort von nach 4 Tagen hilfreich
            Wie soll das gehen?

            also nun wird der Blödsinn Hochgradig!!!
            beim P2/P3 verwaltet das Board nicht den Cache, sondern der Chip selbst. Das Board bekommt damit ja gar nichts zu tun. Wäre nett, wenn Du mal die Testbedingungen nennen könnstet - ich wäre ja lernfähig. Aber ich habe nicht die zeit, sinnlos zu probieren. Gib also bitte Deine Testbedingung an, ich werde es testen!(obwohl ich nicht sehr überzeugt bin vom Erfolg)

            Micha

            • Antwort von nach 5 Tagen hilfreich
              Re: Wie soll das gehen?

              Also gut!

              1. Ich möchte hier wirklich nicht arrogant wirken, ganz im ernst nicht !

              2. Ich programmiere hier unter Visual c++, allerdings ohne Verwendung der MFC ("nur" windows-api zur visualisierung) und simuliere metallische Gefüge und mikrorissentstehung, -wachstum und -zusammenwachsen im Durchschnitt an ca. 12000 Körnern unter zyklische mechanischer Belastung. Diese Simulationen mit diversen physikalischen Modellen zur Berechnung der Simulation ist sehr aufwendig.

              Nun habe ich das (sowohl release als auch debug) Modul auf unterschiedlichen Rechnern laufen lassen. Auf dem doch mittlerweile 2 Jahre alten Dual System von Asus habe ich wirklich diese Geschwindigkeitsdifferenzen zu neueren Systemen festgestellt. Es ist ein echtes 32-bit Programm. Also, ich hoffe auf Eure Hilfe: woran liegt es? Ist es nicht auch so, dass NT die Cache-Verwaltung übernimmt? Also kommt es doch wahrscheinlich auf die Kombination von Hard- UND Software an. Dasselbe bemerke ich bei Berechnungen mit ANSYS FEM (Finite-Elemente)und Mathematica. Das SETI schneller läuft, liegt sicherlich daran, dass es ein 16-bit Programm ist.

              Ganz im ernst: mein statement klang gestern ein wenig agressiv, lag an meiner Tagesstimmung. Ich hoffe, Ihr könnt mir bei der Klärung dieser Frage helfen ;-)

              Gruß
              Axel

              P.S. RAM ist auf allen Rechnern genügend vorhanden und ok, das Dual-System hat SCSI, die anderen nicht, aber es wird auch nicht auf die Festplatten zugegriffen.

            • Antwort von nach 5 Tagen hilfreich
              Re^2: Wie soll das gehen?

              Nun ja, lässt sich dann ja recht schwer nachvollziehen. Komisch ist es schon. Das der Celeron "aufgibt", ist ja zu verstehen - der hat ja so gut wie keinen Cache, wenn das Programm diesen exorbitant nutzt, fehlt dann natürlich was.
              Ansonsten wäre ich recht ratlos. Ich kann mir wirklich nur vorstellen, das der P3-500-PC irgendein Problem hat, denn technisch ist es nicht zu erklären. Es sei denn, das Programm ist auf ein Doppelsystem optimiert. Dann versucht es möglicherweise bei den Einprozessorsystemen 2 Treads parallel abzuarbeiten und der Cache muss ständig die Anforderungen des "falschen" Treads beantworten und wechselt deshalb fortlaufend sinnlos seinen Inhalt.
              Aber unabhängig davon - Deine Entschuldigung sei gnädig angenommen ;) - Du musst zugeben, selbst wenn wir uns auf Deine These einigen, ist das ein so extrem seltener Fall, das die Betrachtung mit der ursprünglichen Frage kaum korrespondiert. Es ging, wie ich das verstanden habe, um die Vor/Nachteile und den Sinn von Doppelprozessorsystemen. Und da ist es in der weit überwiegenden Zahl der Fälle eben wirklich so, das das Doppelsystem bei den heutigen Preisen schneller Prozessoren nicht sehr sinnvoll ist. Wenn der "Frager" ganz gezielte Antworten auf ein bestimmtes Problem hätte haben wollen, hätte er das Problem wohl genauer beschrieben.
              Also dann,
              bis zum nächsten Problem...

              Micha
              *derhofftdasdeinelauneheutebestensist*

            • Antwort von nach 5 Tagen hilfreich
              In der Tat gebe ich zu...

              ....dass es ein recht seltenes Phänomen ist. Das Programm ist nicht für Dualsysteme optimiert, es sei denn, V-C++ macht das unter NT von selbst - wäre mir aber neu!

              Aber nochmal zurück zu meinen Vermutungen:

              Liegt es nicht evtl. auch konkret am Betriebssystem und der mainboardstruktur, so dass die Prozessorgeschwindigkeit (MHz) nur einen Teil des ganzen ausmacht? Wie erklärt es sich sonst, dass ältere UNIX-Kisten von HP (Workstation) mit wesentlich weniger Taktfrequenz bei Rechenoperationen um ein vielfaches schneller sind? Klar, dort werden Prozesse parallel abgearbeitet, aber wie sieht es denn nun wirklich bei einem guten Dual-board unter NT aus ? Ich weiss es wirklich nicht, aber ich glaube, dass man da leider nicht so richtig "drin" steckt und daher machte ich gestern die provokante Bemerkung, dass 2*233<500 vielleicht ein wenig zu "trivial" ist.

              Gruß, Axel, heute mit besserer Laune



Keine passende Antwort gefunden? Jetzt eigene Frage stellen!