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?
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]
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.
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
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
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
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
und rechne nicht 2*233
Also gut!
-
Ich möchte hier wirklich nicht arrogant wirken, ganz im ernst nicht !
-
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.
Noch was
Ist nicht auch die gesamte Struktur des Mainboards anders?
und die 3.
mir ist noch was eingefallen.
ein Studienarbeiter hat einen celeron 450. eine berechnung, die hier 12 min dauerte war bei ihm in 1h noch nicht fertig.
das c+±programm ist außerdem sehr optimiert, was den source code anbelangt.
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*
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
Klamüser,klamüser…
ich mal Deine vermutungen.
Liegt es nicht evtl. auch konkret am
Betriebssystem und der mainboardstruktur,
Betriebssystem: definitiv nicht, denn das kann ja höchstens Leistung verteilen und steuert keinesfalls den internen Prozessorcache
Mainboardstruktur: eventuell, wenn, dann aber so, das das P3 Board grottenschlecht ist - vermute ich bei der genannten Firma aber eher nicht.
so dass die Prozessorgeschwindigkeit
(MHz) nur einen Teil des ganzen ausmacht?
stimmt, aber je mehr richtiges Rechnen, desto mehr ist die Prozessorgeschwindigkeit entscheidendes Kriterium
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
…es erklärt sich an der von Dir genannten Parallelabarbeitung und daran, das die entsprechenden Prozessoren manche Operationen in einem Takt ausführen können, bei denen sich PC-Prozis mehrere Takte Zeit lassen.
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
Mal zu Klärung für alle
Hallo,
ein Dual-System bringt Dir gar nichts, selbst wenn du NT nutzt, nicht viel.
- win9x läuft, aber es wird nur eine CPU angesprochen ----> Verschwendung
- NT, Win2000 nutzem beide CPUs, aber:
das allein bringt fast gar nichts, denn auch die restliche Software müsste Multiprocessorfähig sein, und das ist sie im Normaluserbereich bis auf wenige Ausnahmen nicht. Unter NT würden nur die Systemdienste etwas schneller laufen, und das ist das geld nicht wert.
Falls das jemand nicht glaubt:
bei normaler software sind alle Alghoritmen ohne Abfrage der CPU-Anzahl geschrieben, es wird also alles auf dem erten verfügbaren Processor gerechnet, der 2. wird gar nicht registriert.
bei Multiprocessor-Software muss jeder Alghor. erst die Anzahl der verfügbaren CPUs abfragen und dann die zu berechnenden Probleme aufteilen und rekursiv zusmammenführen. Solche Software ist für den Normaluser (bis auf wenige Ausnahmen) nicht verfügbar und auch nicht bezahlbar)
Also das Geld lieber in ein ordentliches Single-Board und einen guten Processor stecken.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
bei mir steht gerade einer auf der Leitung…
ich mein, danke für die Belehrung. Aber das stand alles so schon mal da…wieso also Klärung???
Micha
…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!
also das reine number-crunching sollte single threaded ablaufen, solange du es nicht anders implementiert hast. bei benutzung von _richtig_ aufwendigen bibliotheksfunktionen, vorzugsweise aus irgendwelchen naturwissenschaftlichen klassenbibliotheken waere es schon vorstellbar, dass die intern multithreaded arbeiten. aehnliches koennte fuer bei aufwendigen grafikberechnungen parallel zur eigentlich applikation gelten, wer weiss, vielleicht hat irgendein heller kopf bei m$ das so implementiert.
aber amdahls law kannst du nicht austricksen: zwei prozessoren einer bestimmten leistung werden beim gleichen programm immer _maximal_ so schnell sein, wie einer mit der doppelten, normalerweise eher langsamer. wobei ich hier mal bewusst theoretisch von prozessoren bestimmter leistung spreche, bei praktischen systemen wie du sie schilderst, gibt es halt neben dem prozessor noch ne menge anderer rahmenbedingungen. wie ist denn der speicher der beiden fraglichen maschinen, oder falls du _wirklich_ grosse datenmengen hast, die platten performance, oder bei viel grafik, die der display-hardware?
Liegt es nicht evtl. auch konkret am
Betriebssystem und der mainboardstruktur,
so dass die Prozessorgeschwindigkeit
(MHz) nur einen Teil des ganzen ausmacht?
ey, konkret ja, alter
natuerlich sollte man bei solchen vergleichen auch das gleiche os betrachten und wenn’s genauer sein soll, am besten das gleiche system (dual board mit 1 oder 2 prozessoren). und prozessorgeschwindigkeit und taktfrequenz sind mitnichten aequivalent…
Wie erklärt es sich sonst, dass ältere
UNIX-Kisten von HP (Workstation) mit
wesentlich weniger Taktfrequenz bei
Rechenoperationen um ein vielfaches
schneller sind?
man kann bei verschiedenen cpus mitnichten durch einen vergleich der taktfrequenz auf die leistungsfaehigkeit schliessen. da gibt es noch ein _paar_ andere faktoren…
und bei hp (parisc architektur) gilt sowieso: scheissegal, wie gross der chip wird, was er kostet und ob wir ihn mit ln2 kuehlen muessen 
, hauptsache schnell. nur so als beispiel, die pa8500 familie hat 1.5
_megabytes_ first level cache, im x86 sektor sind so um die 64k ueblich…
joachim
Ist nicht auch die gesamte Struktur des
Mainboards anders?
So, mein PC war kaputt. Ich war jetzt etwas überaschr, was sich hier so alles um meinen harmlosen Beitrag rumgestritten wurde.
Jedenfalls kann ich nur an meiner Meinung festhalten und würde gerne auch nochmal deine Testbedingungen nachbauen. Muß irgendwie seltsam abgelaufen sein.
Wenn ich jetzt die Fehler aus deinen Beiträge betrachte, würde ich an deiner Stelle die Aufforderung von wegen Sch**ße verbreiten nochmal überdenken.
Gruß juz
Falls…
Du alles nachgelesen haben solltest, ist doch jetzt alles klar, oder? Dennoch sind wir letztendlich nicht sehr viel weiter, ist mir aber letztendlich auch egal, da mich hier nur die resultierenden Rechenzeiten interessieren und ich hatte eigentlich auch nicht vor, mainboards zu entwickeln. Und: mein „…sch***e verbreiten“ habe ich natürlich längst revidiert. So bleibt nur zu hoffen, dass mir das keiner nachträgt (Du hoffentlich auch nicht).
Gruß und schönen Tag
Axel