Warum sind alle so scharf auf Dualcore CPUs

[beos]

Grüß Euch,

mal abgesehen davon, das sich auf SMP Maschinen angenehm arbeiten läßt
und eine wenige Anwendung aus dem Video und 3D Rendering Bereich schneller
arbeiten bringen uns doch Dualcores gar nichts.....

Ich finde die technische Seite der Entwicklung sehr interessant - aber einen
Nutzen (ähnlich 64 Bit) sehe ich nicht.....

Was meint Ihr?

Tschüß Beos

[BlackBirdSR]

Grüß Euch,

mal abgesehen davon, das sich auf SMP Maschinen angenehm arbeiten läßt
und eine wenige Anwendung aus dem Video und 3D Rendering Bereich schneller
arbeiten bringen uns doch Dualcores gar nichts.....

Ich finde die technische Seite der Entwicklung sehr interessant - aber einen
Nutzen (ähnlich 64 Bit) sehe ich nicht.....

Was meint Ihr?

Tschüß Beos

Für den Desktop wird es die erst ein paar Monate nach dem Release der ersten DualCore CPU geben. Selbst dann gibt es kaum Software, und der Takt wird wohl langsamer sein.

Nutzen sehe ich jetzt auch keinen. Aber ich bin nunmal total gespannt auf die erziehlte Performance, die Probleme und Möglichkeiten, sowie das Ergebnis zwischen AMD und Intel.
Und am Ende ist es einfach die Zukunft. Wie auch 64Bit.
Ich denke es wird nicht lange dauern, und fast jede CPU wird mit mehreren Kernen auf dem Chip antanzen.

[beos]

Technisch interessant ist es auf alle Fälle - aber ein komischer Ansatz
für mehr Performance - schließlich lassen sich nicht sehr viele
Probleme der Informatik so leicht paralleliesieren......
d.h es müßte erst mal ein neuer mathematischer Ansatz gefunden werden um
Probleme zu parallelisieren und SMP tauglich zu machen.....

[BlackBirdSR]

Technisch interessant ist es auf alle Fälle - aber ein komischer Ansatz
für mehr Performance - schließlich lassen sich nicht sehr viele
Probleme der Informatik so leicht paralleliesieren......
d.h es müßte erst mal ein neuer mathematischer Ansatz gefunden werden um
Probleme zu parallelisieren und SMP tauglich zu machen.....

Du triffst den nagel genau auf den Kopf.
Es lässt sich nicht mehr viel mehr parallelisieren. D.h es bringt nichts mehr, noch mehr ALUs, nocht mehr FPUs einzubauen.
Was bleibt ist mehr Cache oder mehr Takt.
Das mit dem Takt geht ja nun nicht mehr so toll.

Die Lösung liegt darin, mehrere Kerne zu verbauen, die dafür eventuell nicht so komplex und hoch getaktet sind.
Dann kann man im schlimmsten Fall immernoch 2 unabhängige Aufgaben erledigen, da muss kein Code parallelisiert werden.

[Coda]

Es lässt sich nicht mehr viel mehr parallelisieren...
..., solange der Programmierer nicht mitdenkt.

[Demirug]

Ist ein Henne-EI Problem. Solange es keine Dualcore CPUs gab hat eben auch kaum einer seine Software auf die Verwendung von mehr als einer Prozessoreinheit ausgelegt.

Ich weiss von mindestens einer Engine (OK eigentlich zwei ;) ) die Multicore CPU aktiv unterstützt. Stehe da aber bis etwas dem 29.9 unter einer NDA.

[beos]

Hmmm,

wenn man mal schaut, wie wenig Programme eine effiziente SMP Unterstützung
haben....denken wohl fast alle Programmierer nicht mit - oder es ist einfach
unmöglich

[Demirug]

Hmmm,

wenn man mal schaut, wie wenig Programme eine effiziente SMP Unterstützung
haben....denken wohl fast alle Programmierer nicht mit - oder es ist einfach
unmöglich

Es gibt dinge die kann man einfach nicht durch SMP schneller machen. Das sind aber eher die Ausnahmen. SMP Unterstüzung ist aber wesentlich aufwendiger zu programmieren und daher überlegen es sich die meisten Entwickler genau ob sich dieser Mehraufwand lohnt wenn das Programm am Ende mehrheitlich sowieso nur auf nicht SMP Systemen läuft.

[Endorphine]

Selbst wenn einzelne Anwendungen ihre Arbeit kaum in unabhängige Threads parallelisieren können, dann läuft es eben wie mit SMT -- der Gewinn stellt sich auch im Multitasking ein. :)

[betasilie]

Grüß Euch,

mal abgesehen davon, das sich auf SMP Maschinen angenehm arbeiten läßt
und eine wenige Anwendung aus dem Video und 3D Rendering Bereich schneller
arbeiten bringen uns doch Dualcores gar nichts.....

Ich finde die technische Seite der Entwicklung sehr interessant - aber einen
Nutzen (ähnlich 64 Bit) sehe ich nicht.....

Was meint Ihr?

Tschüß Beos
full ack.

Kann das auch nicht nachvollziehen.

[Demirug]

Selbst wenn einzelne Anwendungen ihre Arbeit kaum in unabhängige Threads parallelisieren können, dann läuft es eben wie mit SMT -- der Gewinn stellt sich auch im Multitasking ein. :)

Ja, dann muss man aber immer ein paar rechenintensive Sache gleichzeitig laufen lassen um das System so richtig unter Last zu halten.

Meist wollen wir aber eine Sache schneller erledigt haben.

[Ikon]

Ist doch nur das übliche Spielchen - die Hersteller denken sich etwas aus und reden uns Kunden dann das Bedürfnis ein es kaufen zu müssen - mit dem Zweck uns das Geld aus der Tasche zu ziehen.

Natürlich ist die technische Umsetzung interessant, aber welcher Heimnutzer braucht DualCore oder SMP schon?

[Coda]

.NET 2005 unterstützt OpenMP. Damit dürfte die Sache deutlich einfacher werden.

[mapel110]

Mehr Leistung ist immer interessant, auch wenn sie nur im Multitasking spürbar wird.
Kommt dann nurnoch auf den Mehrpreis an, den man dafür zahlen muss.
Den doppelten Preis(darauf sollte eigentlich ein doppelter Core hinauslaufen) wird sicher kaum jemand bereit sein zu zahlen.
Könnte also für die CPU-Hersteller IMO eher ein Verlustgeschäft werden.

[ShadowXX]

Mehr Leistung ist immer interessant, auch wenn sie nur im Multitasking spürbar wird.
Kommt dann nurnoch auf den Mehrpreis an, den man dafür zahlen muss.
Den doppelten Preis(darauf sollte eigentlich ein doppelter Core hinauslaufen) wird sicher kaum jemand bereit sein zu zahlen.
Könnte also für die CPU-Hersteller IMO eher ein Verlustgeschäft werden.

Juppss....genau der Meinung bin ich auch....der Preis wird das entscheidene sein.

Wenn ein Dual-A64 (oder auch Intel) nur wenig mehr kostet als die Single-Variante, würde ich zum Dual-Core greifen...sonst würde ich eher den Single nehmen, da ich zuhause kaum von DualCore profitieren kann (zumindest nicht so stark wie in der Firma, wo ich ohen Dual-Core CPUs kaum arbeiten könnte)

Allerdings habe ich auch die Befürchtung, das sowohl AMD als auch Intel uns dieses CPUs zum fast doppelten Preis unterjubeln wollen....das wird der Home-User-Desktop-Markt aber hoffentlich nicht mitmachen...

(Wobei ich da allerdings schon die die Marketingabteilungen aller beteiligten (also AMD,Intel und die diversen vertreiber von PCs) sich die Hände reiben sehe....."Doppelte Performance, Dank doppelter Prozessorpower" usw. werden die Headlines sein....dann immer mit kleinen Sternchen versehen, bei denen dann im kleinstgedruckten steht "nur mit extrem ausgewählten Anwendungen, die vielleicht irgendwann mal rauskommen werden".)

[Gast]

Allerdings habe ich auch die Befürchtung, das sowohl AMD als auch Intel uns dieses CPUs zum fast doppelten Preis unterjubeln wollen....das wird der Home-User-Desktop-Markt aber hoffentlich nicht mitmachen...


Der doppelte Preis ist recht unwahrscheinlich, da ja nicht 2 Prozessoren verkauft werden, sondern lediglich ein Prozessor mit 2 Kernen. Das heißt, das viele Teile auch weiterhin nur einfach vorhanden sein werden (wie zum Beispiel der Cache). Des weiteren fallen nur die einfachen Kosten für das Packaging an und die Pakete für den Versand nach Malaysia werden auch nicht teurer... Defacto werden die CPUs sicher teurer (wie jede neue Entwicklung) aber im normal üblichen Rahmen. Schließlich wollen die ihre Dinger ja auch verkaufen...

Interessanter dürfte eher sein, in welchem Verhältnis die Preise festgelegt werden. Zu den Multi-Prozessor-fähigen Prozessoren um Preisrahmen um 1-2000 US-Dollar? Dann besteht nämlich sogar die Möglichkeit, dass die Dual-Cores günstiger werden, weil du ja im Prinzip 2 Prozessoren zum Preis von einem bekommst... :)

[BlackBirdSR]

Der doppelte Preis ist recht unwahrscheinlich, da ja nicht 2 Prozessoren verkauft werden, sondern lediglich ein Prozessor mit 2 Kernen. Das heißt, das viele Teile auch weiterhin nur einfach vorhanden sein werden (wie zum Beispiel der Cache). Des weiteren fallen nur die einfachen Kosten für das Packaging an und die Pakete für den Versand nach Malaysia werden auch nicht teurer... Defacto werden die CPUs sicher teurer (wie jede neue Entwicklung) aber im normal üblichen Rahmen. Schließlich wollen die ihre Dinger ja auch verkaufen...

Interessanter dürfte eher sein, in welchem Verhältnis die Preise festgelegt werden. Zu den Multi-Prozessor-fähigen Prozessoren um Preisrahmen um 1-2000 US-Dollar? Dann besteht nämlich sogar die Möglichkeit, dass die Dual-Cores günstiger werden, weil du ja im Prinzip 2 Prozessoren zum Preis von einem bekommst... :)

gerade der Cache ist ja doppelt vorhanden ;)
Die CPU an sich wird wohl so groß wie ein jetziger Opteron.
AMD kann und wird also ordentlich Aufpreis verlangen, solange DualCore CPUs noch neu sind.

[StefanV]

AMD kann und wird also ordentlich Aufpreis verlangen, solange DualCore CPUs noch neu sind.
Siehs mal etwas anders ;)

AMD kann und wird also ordentlich Aufpreis verlangen, solange die Ausbeute DualCore CPUs noch nicht so gut ist.

Das ist gängige Praxis bei AMD, einfach den Preis für das, was sie eh nicht liefern können, sehr hoch ansetzen.

Bestes Beispiel: K6-2 zu K6-3...

[beos]

Ich denke mal, dass der Preis ziemlich hoch sein wird (im Gegensatz im Nutzen) - der der Preis orientiert sich ja meinst nicht an der Produktionskosten, sondern wie viel die Markting Strategen denken, dass die Leute ausgeben würden.......

z.B. Firewire und USB2 Geräte.......denke mal nicht dass der Firewire Bridge
Chip viel teuer in der Herstellung ist als ein USB2 Chip.......trotzdem ist alles
auf dem Firewire steht viel teuerer wie USB2 Gerät....

So wird das bestimmt auch mit den Dualcore's werden -

[StefanV]

z.B. Firewire und USB2 Geräte.......denke mal nicht dass der Firewire Bridge
Chip viel teuer in der Herstellung ist als ein USB2 Chip.......trotzdem ist alles
auf dem Firewire steht viel teuerer wie USB2 Gerät....

So wird das bestimmt auch mit den Dualcore's werden -
Doch, Firewire ist in der Herstellung teurer als USB ;)

Das liegt aber daran, daß IEE1394 a bisserl mehr 'intelligenz' benötigt, grob gesagt ists vergleichbar mit IDE vs SCSI (wobei es auch mal 'günstige' SCSI Platten gab, als die Apfel Rechner noch keinen IDE Port hatten).

[CrazyIvan]

Ich quote mich mal schnell selber, da dies auch in diesen Thread gut reinpasst:

Es wird keine 10 Jahre mehr dauern, dann sind streaming clients, xbox, Arbeits-PC und Spiele-PC passe. Dann wird der geneigte Anwender einen(!) Rechner bei sich zu Hause im Keller stehen haben, der gleichzeitig Rechen- sowie Speicherkapazität für alle im Haus genutzten Clients zur Verfügung stellt. D.h. auf diesem wird gleichzeitig Spiel, Photoshop o.ä., Video De-/Encoding und die Steuerung der Hausklima- und Alarmanlage laufen. Was man dann als Client oder Terminal sieht, sind nur noch Monitor plus Benutzerschnittstellen zu diesem Rechner.
Der springende Punkt ist aber der. Damit sowas in Zukunft möglich wird, muss es heute irgendwann eingeführt werden. Dazu gehören Features wie SMT, SMP, 64-bit Adressraum und anderes. In der Vergangenheit waren dies eben die Einführung von 16 und 32bit, 3d-Hardwarebeschleuniger, Videobeschleunigung bei Grafikkarten, schnelle Schnittstellen wie Gigabit Ethernet, USB 2.0, FireWire und tausende andere.

Gerade durch Vanderpool beziehungsweise AMDs Derivat sehe ich einen großen Bedarf an MultiCores.

[Muh-sagt-die-Kuh]

Es wird keine 10 Jahre mehr dauern, dann sind streaming clients, xbox, Arbeits-PC und Spiele-PC passe. Dann wird der geneigte Anwender einen(!) Rechner bei sich zu Hause im Keller stehen haben, der gleichzeitig Rechen- sowie Speicherkapazität für alle im Haus genutzten Clients zur Verfügung stellt. D.h. auf diesem wird gleichzeitig Spiel, Photoshop o.ä., Video De-/Encoding und die Steuerung der Hausklima- und Alarmanlage laufen. Was man dann als Client oder Terminal sieht, sind nur noch Monitor plus Benutzerschnittstellen zu diesem Rechner.
Der springende Punkt ist aber der. Damit sowas in Zukunft möglich wird, muss es heute irgendwann eingeführt werden. Dazu gehören Features wie SMT, SMP, 64-bit Adressraum und anderes. In der Vergangenheit waren dies eben die Einführung von 16 und 32bit, 3d-Hardwarebeschleuniger, Videobeschleunigung bei Grafikkarten, schnelle Schnittstellen wie Gigabit Ethernet, USB 2.0, FireWire und tausende andere.

Gerade durch Vanderpool beziehungsweise AMDs Derivat sehe ich einen großen Bedarf an MultiCores.Terminal / Server Architekturen sind nun wirklich nichts neues.

[CrazyIvan]

Ich hoffe, Du meinst das, was mir als Client/Server Architektur bekannt ist?!
Die dortigen Clients sind auch einzelne Rechner. Ich rede aber von einem einzigen Rechenwerk, welches nur durch vielerlei Nutzerschnittstellen nach außen hin sichtbar ist.

[StefanV]

Sowas gibts AFAIK auch schon.

Bzw gab es früher mal...

[Muh-sagt-die-Kuh]

Ich hoffe, Du meinst das, was mir als Client/Server Architektur bekannt ist?!
Die dortigen Clients sind auch einzelne Rechner. Ich rede aber von einem einzigen Rechenwerk, welches nur durch vielerlei Nutzerschnittstellen nach außen hin sichtbar ist.Nein, ich meine genau das was ich sage, und das ist genau das was du beschreibst: Terminal / Server

Ein Terminal (manchmal auch als "Thin-Client" (http://wwws.sun.com/sunray/sunray1/index.html) bezeichnet) hat eine Maus, eine Tastatur und einen Bildschirm, und eben die Hardware, die nötig ist um das Bild darzustellen und Eingabe / Ausgabedaten über das Netzwerk an den Server zu übermitteln. Das ganze gab es schon, bevor PCs überhaupt in Mode kamen...

[mrdigital]

Hatten wir auch in der Uni in den Rechenpools, kleine Boxen (keine PCs !, die waren so groß wie ne Zigarrenschachtel) in denen nur ein X Server lief und irgendwo im Keller war die dicke SUN die all diese X Terminals beschickt hat. Diese Technik ist also wirklich nicht neu ;)

[BlackBirdSR]

Hatten wir auch in der Uni in den Rechenpools, kleine Boxen (keine PCs !, die waren so groß wie ne Zigarrenschachtel) in denen nur ein X Server lief und irgendwo im Keller war die dicke SUN die all diese X Terminals beschickt hat. Diese Technik ist also wirklich nicht neu ;)

Uh, erinnere mich nicht daran *g*

20 Workstations an einer US2, und dann versuche mal Netscape zu starten und einen Transistor zu zeichnen... :|

hätte nie gedacht, dass ich einmal 3 Minuten warten muss, bevor eine Linie von Punkt A nach Punkt B auf dem Bildschirm erscheint :mad:

[icemanemp]

Bei Vanderpool laufen doch 2 unabhängig Betriebssystem oder mehr...

Terminal-Server Architektur, sind doch alle Benutzer nur einem einem Betriebssystem angemeldet...

Was ist gegen Dualcore auszusetzen... wenn man bedenkt, das heutige Produktionsprozesse nicht mehr zulassen... dann bringt es auch nix durch Takterhöhung die Verarbeitungsleistung in der "Länge" (seriell) zu verkürzen, sondern durch superskalaren Aufbau, Befehlspipelining, SMT und SMP (on-chip) mehr in der selben Zeit zu verarbeiten (parallel). Mit "Multichip on die" kann man doch endlich richtig 2 Programm mit voller Last betreiben, nicht wie bei SMT, das nur eine kleinere Verbesserung bringt...

In der Einführungsphase von Intel und AMD kann das alles aber auch nach hinten losgehen, da wenn die Hersteller denken, das sie durch Dualcore den Takt der einzelnen Cores drastisch senken, nur um auf ihr Quantispeed oder Modellnummer zu kommen, dann wird die Leistung bei "normalen" Anwendungen wieder fallen. Natürlich ist dann die Schreierei vieler gross...

Es hat auch scheinbar keiner den Einsatz von optimierten Compilern gedacht. Hier : http://www.tecchannel.de/hardware/1359/index.html geht es zwar um superskalare Architekturen, aber Dualcore bedeutet ja auhc doppelte Anzahl FPUs, ALUs usw...

Aber egal ich freu mich auf die Zukunft ;) ...

[BlackBirdSR]

BEs hat auch scheinbar keiner den Einsatz von optimierten Compilern gedacht. Hier : http://www.tecchannel.de/hardware/1359/index.html geht es zwar um superskalare Architekturen, aber Dualcore bedeutet ja auhc doppelte Anzahl FPUs, ALUs usw...


Du kannst aber einen Thread nicht auf 2 CPUs verteilen. Also bleibt es wie bisher bei der gleichen Anzahl an Ausführungseinheiten.

[ShadowXX]

Bei Vanderpool laufen doch 2 unabhängig Betriebssystem oder mehr...

Terminal-Server Architektur, sind doch alle Benutzer nur einem einem Betriebssystem angemeldet...

Was ist gegen Dualcore auszusetzen... wenn man bedenkt, das heutige Produktionsprozesse nicht mehr zulassen... dann bringt es auch nix durch Takterhöhung die Verarbeitungsleistung in der "Länge" (seriell) zu verkürzen, sondern durch superskalaren Aufbau, Befehlspipelining, SMT und SMP (on-chip) mehr in der selben Zeit zu verarbeiten (parallel). Mit "Multichip on die" kann man doch endlich richtig 2 Programm mit voller Last betreiben, nicht wie bei SMT, das nur eine kleinere Verbesserung bringt...

In der Einführungsphase von Intel und AMD kann das alles aber auch nach hinten losgehen, da wenn die Hersteller denken, das sie durch Dualcore den Takt der einzelnen Cores drastisch senken, nur um auf ihr Quantispeed oder Modellnummer zu kommen, dann wird die Leistung bei "normalen" Anwendungen wieder fallen. Natürlich ist dann die Schreierei vieler gross...

Es hat auch scheinbar keiner den Einsatz von optimierten Compilern gedacht. Hier : http://www.tecchannel.de/hardware/1359/index.html geht es zwar um superskalare Architekturen, aber Dualcore bedeutet ja auhc doppelte Anzahl FPUs, ALUs usw...

Aber egal ich freu mich auf die Zukunft ;) ...


Gegen DualCore ist nix auszusetzen...auch im Heimbereich nicht.

Nur sehe ich den Schuss von AMD und Intel nach hinten losgehen, wenn es zum Start dieses CPUs nicht genug SW gibt, um zu zeigen was es bringt.
Speziell wenn die CPUs dann auch noch sehr teuer sind...

(Ganz von dem abgesehen, was du erwähnt hast...)

Ich bin gespannt wann der erste der beiden nach misslungenen DualCore-Start wieder anfängt zurückzurudern.....(was wohl aber nicht passieren wird).

Ich gehe davon aus, das wir uns daran gewöhnen werden müssen, das es noch einige Jahre dauern wird, bis es wieder richtige Geschwindigkeitssteigerungen geben wird (nämlich bis dahin, wo die SW anfängt DualCores auch auszunutzen).

Gaming CPUs werden die DualCores innerhalb der nächsten Jahre wohl nicht gerade sein...es würde mich nicht wirklich Wundern, wenn alle "fast nur Gamer" erst mal die nächsten 2 bis 3 Jahre bei Ihren "alten" CPUs bleiben werden...

Für Vanderpool sehe ich allerdings im Heimbereich nicht wirklich einen Anwendungsbedarf...aber vielleicht fällt mir momentan nur nix vernünftiges dafür ein (ausser dedizierten Server auf OS 1 und Games auf OS 2...das geht aber im Prinzip auch schon mit 2 CPUs bzw. DualCore, dafür brauchte ich Vanderpool nicht...)

[zeckensack]

Ich glaube eher weniger, dass die Prozessorhersteller "scharf" auf Dualcores sind. Sie müssen es einfach versuchen, um die Performance weiter erhöhen zu können.

Auch eine "normale" CPU kann Threaden bis der Arzt kommt. Sie kann nicht mehr als einen Thread gleichzeitig ausführen, für nicht-Server-Anwendungen ist das aber nicht wirklich relevant. Die Thread-Scheduler in den diversen Betriebssystemen schalten schnell genug um, um die Illusion der Gleichzeitigkeit aufrecht zu erhalten.

Wenn ich die Wahl hätte zwischen einem K8 mit 4GHz Takt oder einem Dualcore-K8 mit 2GHz Takt, und ansonsten gleichen Rahmenbedingungen (Speicherdurchsatz, Caches) so würde ich klar ersteren vorziehen.
1)er hätte genau so viel Multithreading-Wumms wie das Dualcore-Gerät
2)er könnte zusätzlich auch seine volle Leistung in einem einzigen Thread bringen. Eine Dual-Core-CPU kann das nicht!

Das ganze scheitert dann aber natürlich an der kurzfristigen Machbarkeit. Und nur deswegen werden IMO Dualcores für Desktop-Systeme überhaupt in Betracht gezogen.

[PhoenixFG]

Mal eine bescheidene Frage. Ich hoffe, der Blick in die Kristallkugel bleibt erspart. Werden bei Dual-Core-CPUs die einzelnen Cores via PowerNow , SpeedStep oder wie auch immer ein Hersteller das Feature bis dahin nennt, abschalt- bzw. drosselbar sein?

Mir ist inzw. eigentlich diese Stromsparerei mit all ihren Vorteilen wichtiger als bloße CPU-Power.

MfG

[Ikon]

@PhoenixFG
Obwohl die DualCore-CPUs wohl durchaus gängige Energiespartechniken unterstützen werden (einzig CnQ könnte IMO problematisch werden) sind sie schon konzeptionell nichts für Stromsparer. DualCore ist vom Ansatz der "ausreichenden Leistung" meilenweit entfernt und auch die Effizienz sinkt in praktisch jeder Hinsicht.

VIAs C7 und Intels Shelton sind in diesem Segment die Zukunft.

[Gast]

Ich weiss von mindestens einer Engine (OK eigentlich zwei ;) ) die Multicore CPU aktiv unterstützt. Stehe da aber bis etwas dem 29.9 unter einer NDA.

Croteam, oder doch Valve?

[Demirug]

Croteam, oder doch Valve?

Von diesen beiden habe ich keine klare Aussage zu diesem Thema.

[justanick]

Bei Dual Core könnten sich interressante Stromsparmöglichkeiten bieten:cool:. Der 1 Core läuft mit voller Taktfrequenz und der Zweite im nur mit 800/1000Mhz und gesenkter Spannung, falls sowas überhaupt möglich ist:rolleyes:. Auch das Abschalten des Zweiten Core wie es der Pentium M mit Teilen des L2 Caches macht wären denkbar.

[ShadowXX]

Bei Dual Core könnten sich interressante Stromsparmöglichkeiten bieten:cool:. Der 1 Core läuft mit voller Taktfrequenz und der Zweite im nur mit 800/1000Mhz und gesenkter Spannung, falls sowas überhaupt möglich ist:rolleyes:. Auch das Abschalten des Zweiten Core wie es der Pentium M mit Teilen des L2 Caches macht wären denkbar.

Oder man kauft sich gleich nur eine CPU mit nur einem Core....wofür soll ich Geld für DualCore ausgeben, wenn der eine Core immer aus ist....

[justanick]

Oder man kauft sich gleich nur eine CPU mit nur einem Core....wofür soll ich Geld für DualCore ausgeben, wenn der eine Core immer aus ist....Nur bei geringer Last würde runtergetaktet oder ganz deaktiviert.:wink:
Außerdem hält man so die Die recht groß und kann so besser kühlen.:smile:

[incurable]

Außerdem hält man so die Die recht groß und kann so besser kühlen.:smile:
Also die Argumentation erschließt sich mir nicht, was interessiert es den Hotspot in der ALU von CPU0, dass 7mm rechts von ihm ein Stück Silizium verweilt, dass ob dynamischer Abschaltung hübsch kühl gehalten wird?

[Mike]

Mal ein Gedankengang, den ich grade hatte:
Sind Dualcores nicht vielleicht sogar (langfristig) gut, um Strom zu sparen?
Vergleichen wir einen Singlecore @ 2GHz mit einem Dualcore @ 1GHz, diese würden ungefähr die gleiche Leistung haben(abzüglich des overhead, bleibt die Frage, wie groß dieser ist), vorausgesetzt, das gutes Multithreading möglich ist.

Allerdings müsste man den Dualcore doch eigentlich mit niedrigerer Spannung laufen lassen können, oder?

Dieses würde ja dazu führen, das der Dualcore weniger Strom benötigen würde.

Die Frage wäre, inwieweit sich die Spannung senken lässt bzw. wieviel Mehrtakt der Dualcore braucht um den Overhead ausgleichen zu können.
Desweiteren wären natürlich nach wie vor Aufgaben, die sicht nicht wirklich gut parallelisieren lassen, ein Problem..

[Gast]

Mal ein Gedankengang, den ich grade hatte:
Sind Dualcores nicht vielleicht sogar (langfristig) gut, um Strom zu sparen?
Vergleichen wir einen Singlecore @ 2GHz mit einem Dualcore @ 1GHz, diese würden ungefähr die gleiche Leistung haben(abzüglich des overhead, bleibt die Frage, wie groß dieser ist), vorausgesetzt, das gutes Multithreading möglich ist.

Allerdings müsste man den Dualcore doch eigentlich mit niedrigerer Spannung laufen lassen können, oder?

Dieses würde ja dazu führen, das der Dualcore weniger Strom benötigen würde.

Die Frage wäre, inwieweit sich die Spannung senken lässt bzw. wieviel Mehrtakt der Dualcore braucht um den Overhead ausgleichen zu können.
Desweiteren wären natürlich nach wie vor Aufgaben, die sicht nicht wirklich gut parallelisieren lassen, ein Problem..

Deine Überlegung scheitert schon an deiner Ausgangslage. Wenn du von den aktuellen Begebenheiten ausgehst, werden 2x1GHz niemals die gleiche Leistung wie 1x2GHz erreichen. Der Grund liegt einfach daran, dass die Anwendungen nicht für mehrere Cores ausgelegt sind. Folge: Starte 3Dmurks auf einem 2x1ghz dual-core system und auf einem 2ghz-single-core system und errate, wo du das (deutlich) höhere ergebnis bekommen wirst.

anderes sieht die sache vielleicht irgendwann mal aus, wenn 2 cores als voraussetzung für software gelten und die 2ghz-maschine praktisch 2 prozessoren "simulieren" muss (eventuell vergleichbar mit intels hyperthreading). Tjoa, aber bis dahin dauert es wohl noch ein ganzes weilchen, mindestens jedoch bis 2006, wenn MS sein nächstes windows präsentiert, das eventuell die vorteile von dual-cores richtig zu nutzen weiß. aber bis dahin, gibts dann vielleicht auch schon quad-cores ;)

[justanick]

Also die Argumentation erschließt sich mir nicht, was interessiert es den Hotspot in der ALU von CPU0, dass 7mm rechts von ihm ein Stück Silizium verweilt, dass ob dynamischer Abschaltung hübsch kühl gehalten wird?P4's im M0 Stepping(Also P4 EE) ließen sich besser kühlen als gewöhnliche Northwoods -> Dual Core lässt sich leichter kühlen, zumindestens wenn ein Core deaktiviert ist oder wenn beide mit 1,6Ghz statt einer mit 2,4Ghz und den entsprechenden Spannungen laufen, wie Mike schon anmerkte.

[Mike]

Deine Überlegung scheitert schon an deiner Ausgangslage. Wenn du von den aktuellen Begebenheiten ausgehst, werden 2x1GHz niemals die gleiche Leistung wie 1x2GHz erreichen. Der Grund liegt einfach daran, dass die Anwendungen nicht für mehrere Cores ausgelegt sind. Folge: Starte 3Dmurks auf einem 2x1ghz dual-core system und auf einem 2ghz-single-core system und errate, wo du das (deutlich) höhere ergebnis bekommen wirst.
Deswegen schrieb ich auch "vorausgesetzt, das gutes Multithreading möglich ist", womit ich meine, dass A: die Aufgabe, die das Progamm erledigt, sich gut parallelisieren lässt, und B: dass das Programm dann natürlich auch diese Parallelisierung über mehrere Threads unterstützt.

Außerdem schrieb ich auch von dem Problemfall der Aufgaben, wo dies nicht gut möglich ist.
Inwieweit das auf Spiele zutrifft, kann ich dir nicht genau sagen.
Laut Demirug befinden sich ja Spiele/Engines damit in Entwicklung, mal sehen wie das aussehen wird. :)

[Lilebror]

Deine Überlegung scheitert schon an deiner Ausgangslage. Wenn du von den aktuellen Begebenheiten ausgehst, werden 2x1GHz niemals die gleiche Leistung wie 1x2GHz erreichen. Der Grund liegt einfach daran, dass die Anwendungen nicht für mehrere Cores ausgelegt sind. Folge: Starte 3Dmurks auf einem 2x1ghz dual-core system und auf einem 2ghz-single-core system und errate, wo du das (deutlich) höhere ergebnis bekommen wirst.

anderes sieht die sache vielleicht irgendwann mal aus, wenn 2 cores als voraussetzung für software gelten und die 2ghz-maschine praktisch 2 prozessoren "simulieren" muss (eventuell vergleichbar mit intels hyperthreading). Tjoa, aber bis dahin dauert es wohl noch ein ganzes weilchen, mindestens jedoch bis 2006, wenn MS sein nächstes windows präsentiert, das eventuell die vorteile von dual-cores richtig zu nutzen weiß. aber bis dahin, gibts dann vielleicht auch schon quad-cores ;)

Also das man mit dem Neuen Dual Opteron eindeutig stromsparen kann steht fest. Denn laut PC Gameshardware hat AMD ja schon einige im server bereich zum Test laufen, zwar braucht der Prozi genauso viel leistung wie ein jetztiger Athlon 64 (so um die Hundert wat), enthält aber zwei in etwea gleichstarke Cores die zumindest von dem Stromverbrauch/Leistungs verhältnis wesentlich efizienter arbeiten.
Die Software wird sich auf Dualcores einrichten müssen, ob das grundsätzlich möglich ist , weiß ich auch nich sicher ist aber das zumindest Teile eines Spiels oder einer software Paralel bearbeitet werden können.

mfg: Lilebror

[Gast]

Also das man mit dem Neuen Dual Opteron eindeutig stromsparen kann steht fest. Denn laut PC Gameshardware hat AMD ja schon einige im server bereich zum Test laufen, zwar braucht der Prozi genauso viel leistung wie ein jetztiger Athlon 64 (so um die Hundert wat), enthält aber zwei in etwea gleichstarke Cores die zumindest von dem Stromverbrauch/Leistungs verhältnis wesentlich efizienter arbeiten.
Die Software wird sich auf Dualcores einrichten müssen, ob das grundsätzlich möglich ist , weiß ich auch nich sicher ist aber das zumindest Teile eines Spiels oder einer software Paralel bearbeitet werden können.

mfg: Lilebror


Sorry, aber auf die Aussage von PC Games (Hardware) geb ich nicht viel... Und dass ein Dual-Core Opteron nicht mehr braucht als ein normaler, hat grundsätzlich Null Aussage. Faktisch nutzbar wird diese Aussage nämlich erst, wenn klar ist, mit welchen Spezifikationen der Dual-Core da gelaufen ist... Ich denke da zum Beispiel an die ersten 64-Bit Prozessoren von AMD, die auch schon "lauffähig" waren ... allerdings mit 800 MHz... bis die dinger tatsächlich auf dem Markt waren, war ein Jahr rum ;) Und einen Dual-Core mit 2x500 MHz zu betreiben, der weniger braucht als ein FX-53 oder Opteron 148 ist weiß Gott keine Kunst. Schau dir die aktuellen mobilen Prozessoren an. Die brauchen zwar auch bloß 50 Prozent der Leistung von den Desktop-Chips, sind aber auch meist langsamer getaktet ...

Spannend wirds erst, wenn du bei gleichem Takt nur noch die halbe Leistung Umsetzen darfst, und das ist schließlich der Punkt, den AMD (irgendwann mal) erreichen will. Und da bin ich wirlich gespannt, wie sie 2,4 GHz Chips mit 50 Watt Hinbekommen, um insgesamt auf die 100 Watt zu kommen, die offiziell anvisiert werden ;D

[Lilebror]

Sorry, aber auf die Aussage von PC Games (Hardware) geb ich nicht viel... Und dass ein Dual-Core Opteron nicht mehr braucht als ein normaler, hat grundsätzlich Null Aussage. Faktisch nutzbar wird diese Aussage nämlich erst, wenn klar ist, mit welchen Spezifikationen der Dual-Core da gelaufen ist... Ich denke da zum Beispiel an die ersten 64-Bit Prozessoren von AMD, die auch schon "lauffähig" waren ... allerdings mit 800 MHz... bis die dinger tatsächlich auf dem Markt waren, war ein Jahr rum ;) Und einen Dual-Core mit 2x500 MHz zu betreiben, der weniger braucht als ein FX-53 oder Opteron 148 ist weiß Gott keine Kunst. Schau dir die aktuellen mobilen Prozessoren an. Die brauchen zwar auch bloß 50 Prozent der Leistung von den Desktop-Chips, sind aber auch meist langsamer getaktet ...

Spannend wirds erst, wenn du bei gleichem Takt nur noch die halbe Leistung Umsetzen darfst, und das ist schließlich der Punkt, den AMD (irgendwann mal) erreichen will. Und da bin ich wirlich gespannt, wie sie 2,4 GHz Chips mit 50 Watt Hinbekommen, um insgesamt auf die 100 Watt zu kommen, die offiziell anvisiert werden ;D

Naja gut muss ja zugeben das du da schon recht hast! Was ja hauptsächlich das Problem der hohen verlustleistung ist sind die Leckströme (ströme im prozessor die eigentlich nicht fließen sollen). Also mit den produktionen der Prozessoren in 90 nm und weniger wird das aber garantiert kommen.
Naja ich bin auf jedenfall gespannt wie viel Leistung sie brauchen und Leistung sie in ersten Spielebenchmarks erziehlen.
Zu der Frage warum alle so hinter SMP hinterher sind : ganz einfach welcher PC hobby schrauber und zocker oder gar overclocker wünscht sich nicht 2 Prozessoren in seinem PC zu haben, also ich hätte sie gerne , wenn ichs geld hätte, hätte ich die auch. Wenn es jetzt dazu in spielen noch nutzen erziehlen würde dann würde ich das geld zusammen kratzen, egal wie ;D .
Alleine der Gedanke , ich will beispielsweise einen Deticated Server sagen wir für BF Vietnam machen mit 64 Bots und dann geh ich in meinen eigenen server rein der von der 1 Core berechnet wird und spiele dann mit der 2. , mhhhhhhhhhh wäre das schön. :D

[smoe82]

Es laufen doch schon verdammt viele Sachen gleichzeitig. Während ihr zum Beispiel ein Maultiplayerspiel macht, läuft im Hintergrund der Netzwerktreiber, evtl. ne Firewall, das Betriebssystem selbst, Virenscanner und so weiter.

Daß SMP schwerer zu programmieren ist, bleibt eine ewige Mär. Erstens erzeugt SMP nur einmalig Overhead. Das heißt, je größer mein Programm wird, desto eher lohnt es sich. Zweitens gibt es in vielen Sprachen (z.B. C++) ne ganze Menge Möglichkeiten SMP zu nutzen, auch schon in Bibliotheken gefaßt. Drittens kann man sogar sehr leicht die einfachsten Sachen parallelisieren. Fast jede Shooter-KI läuft schneller, wenn man jedem Gegner einen eigenen Thread zuweist. Das mag sich heute noch nicht lohnen. Aber sobald die KIs mehrere Handlungszweige aufweisen, beschleunigt SMP merklich.

Ein gutes Beispiel ist auch das codieren von Filmen. Ein Two-Pass-Verfahren auf 2 Threads, während der erste einfach 10 Sekunden Vorlauf hat, gibt es als Modul für einige Software schon heute. (ich glaube es soll beim nächsten DVDx auch kommen)

Oder wie wäre es mit einer Suche nach unbekannten Variablen im mathematischen Bereich? Da läßt sich auch noch viel machen...



SMP und das daraus folgende echte Multitasking sind eine wirklich sinnvolle Entwicklung. Es müssen nur mehr Programmierer auf den Zug aufspringen. Besonders die Programmierer der Betriebssysteme.

[Ikon]

Ich pfücke mir mal dieses Beispiel heraus:

Ein gutes Beispiel ist auch das codieren von Filmen. Ein Two-Pass-Verfahren auf 2 Threads, während der erste einfach 10 Sekunden Vorlauf hat, gibt es als Modul für einige Software schon heute. (ich glaube es soll beim nächsten DVDx auch kommen)

Wo liegt der Sinn darin? Ein sinnvoller Skalierungsfaktor für die Quantisierung lässt sich doch nur bestimmen wenn man bereits die Statistiken des (kompletten) ersten Durchlaufs hat.

[smoe82]

Ich pfücke mir mal dieses Beispiel heraus:



Wo liegt der Sinn darin? Ein sinnvoller Skalierungsfaktor für die Quantisierung lässt sich doch nur bestimmen wenn man bereits die Statistiken des (kompletten) ersten Durchlaufs hat.


Nein nicht ganz. Je nachdem, wie oft ein neuer Quantisierungsschlüssel beziehungsweise ein Schlüsselbild berechnet wird. Wenn der erste Thread ein Schlüsselbild nimmt (worauf dann die nächsten 100 basieren, was 4 Sekunden ausmacht) und die Unterschiede von Bild zu Bild berechnet, kann er nach den 100 Bildern eine Statistik für diesen Abschnitt an den 2ten Thread übergeben, welcher sich dann mit der optimalen Quantisierung beschäftigt. Ist halt abhängig davon, wie oft das Schlüsselbild erneuert wird. (in der Regel alle 25 Bilder)

So wie Du das meinst, ergibt das den gleichen Effekt. Denn der zweite Durchlauf kann auch immer nur für eine Schlüsselszene die Quantierung festlegen. Über den ganzen Film gesehen ist das Nonsens.

Das ist bei VBR immer so. Du kannst im Encoder auch einstellen, wie oft ein neues Schlüsselbild erzeugt wird. Wie stark der maximale Bitratenunterschied sein darf, wie viele Bilder darauf folgen und so weiter.

Einen Schlüssel für den gesamten film gibts nur bei VCD (CBR) und da wäre Two-pass Schwachsinn!

[Ikon]

@smoe82
Ich denke, du hast mich nicht richtig verstanden. Ich bezweifle nicht dass es technisch möglich ist, wohl aber ob es sinnvoll ist. Der einzige Vorteil eines zweiten Durchgangs ist ja das Erreichen einer bestimmten Dateigröße des finalen Streams.

(Ich nutze folgendes zur Verdeutlichung obwohl ich annehme dass du es bereits weißt.)

Der erste Pass spuckt (üblicherweise) Statistiken aus, die dem Nutzer sagen wie groß der Stream bei minimaler oder zumindest sehr geringer Kompression wird. Im zweiten Durchlauf werden dann alle Quantisierer anhand eines Skalierungsfaktors, der sich aus der gewünschten Dateigröße ergibt, erhöht bzw. in seltensten Fällen auch gesenkt.

Der Skalierungsfaktor kann aber eben erst bestimmt werden, wenn der erste Durchlauf abgeschlossen ist.

Ich verstehe nicht so ganz, was du mit "optimale Quantisierung" meinst.

[smoe82]

@smoe82
Ich denke, du hast mich nicht richtig verstanden. Ich bezweifle nicht dass es technisch möglich ist, wohl aber ob es sinnvoll ist. Der einzige Vorteil eines zweiten Durchgangs ist ja das Erreichen einer bestimmten Dateigröße des finalen Streams.

(Ich nutze folgendes zur Verdeutlichung obwohl ich annehme dass du es bereits weißt.)

Der erste Pass spuckt (üblicherweise) Statistiken aus, die dem Nutzer sagen wie groß der Stream bei minimaler oder zumindest sehr geringer Kompression wird. Im zweiten Durchlauf werden dann alle Quantisierer anhand eines Skalierungsfaktors, der sich aus der gewünschten Dateigröße ergibt, erhöht bzw. in seltensten Fällen auch gesenkt.

Der Skalierungsfaktor kann aber eben erst bestimmt werden, wenn der erste Durchlauf abgeschlossen ist.

Ich verstehe nicht so ganz, was du mit "optimale Quantisierung" meinst.

Eben nicht. Im ersten Durchgang wird "geschaut", wie der Stream aufgebaut ist. Sind viele starke Bildwechsel drin, oder ist das Bild eher smooth? Wie groß sind die Farbunterschiede? Und so weiter.

Im zweiten Durchgang wird anhand dieser Statistiken ermittelt, ob es sich "lohnt" eher eine hohe Bitrate zu nehmen, oder ob eine niedrige ausreicht.

Der Nachteil bei CBR (constant bitrate) ist ja, daß es für schnelle Szenen nicht ausreicht und für langsame manchmal einfach zuviel ist.

VBR kann die Bitrate ändern, braucht dazu aber immer den Bezug zum Schlüsselbild, beziehungsweise es muß ein neues Schlüsselbild angelegt werden.

Im One-Pass-Verfahren ist die Codierung schon "viel weiter", und kann somit die Bitrate entweder nur langsam anpassen (was sich durch Ruckler bemerkbar macht) oder eben erst ab dem nächsten Schlüsselbild (was einen plötzlichen Qualitätsunterschied hervorbringt).

Bei einem Two-Pass-Verfahren werden nicht nur Statistiken ermittelt, sondern auch die Schlüsselbilder mit den dazugehörigen Bitraten-Empfehlungen. Je nach "Sprunghaftigkeit" des Inhalts werden mehr oder weniger oft neue Schlüssel erzeugt. Der zweite Durchgang generiert nur noch die restlichen Bilder anhand des Schlüsselbildes.


Du hast insofern recht, daß man mit diesem Verfahren eine genaue Größe der Zieldatei festlegen kann. Allerdings geschieht dies erst im Zweiten Durchgang. Da der erste Pass nicht die Bitrate festlegt, sondern nur eine "Empfehlung" gibt. Anhand dieser und der Statistik läßt sich recht genau ermitteln, wie hoch die Bitrate im Durchschnitt anzusetzen ist.


"Optimale Quantisierung" ist ungünstig gewählt. "optimale Bitrate" wäre besser gewesen. Du hast recht: Die Quantisierung hängt von der Bitrate ab, und wird erst im zweiten Pass genau festgelegt.


MfG Smoe


Zusammengefügt von mirp (2004-09-28 um 10:22 Uhr).

[Lilebror]

k.p. Aber jetzt noch mal zu Spielen ich kenne mich nich besonders mit Programmiereung aus ich bin so mehr mit der Hardware als EWlektroniker vertraut.
Ist es denn nich möglich in spielen zb. Physikalischegegbenheiten die ich verursache zum beispiel eine Tonne umschmeißen der, sagen wir, 1. CPU
und etwas was die KI verursacht, der 2. zuzuteilen?
Oder jeweils Schatten und KI berechenung der einen und Physik restlichen Kram der 2 zuzuweisen. Da könnte man doch extreme Leistungsunterscheide mit Erziehlen, man denke an Doom 3 welches ja extrem viel Cpu Leistund für die Schatten berechnung braucht.

[Lilebror]

k.p. Aber jetzt noch mal zu Spielen ich kenne mich nich besonders mit Programmiereung aus ich bin so mehr mit der Hardware als EWlektroniker vertraut.
Ist es denn nich möglich in spielen zb. Physikalischegegbenheiten die ich verursache zum beispiel eine Tonne umschmeißen der, sagen wir, 1. CPU
und etwas was die KI verursacht, der 2. zuzuteilen?
Oder jeweils Schatten und KI berechenung der einen und Physik restlichen Kram der 2 zuzuweisen. Da könnte man doch extreme Leistungsunterscheide mit Erziehlen, man denke an Doom 3 welches ja extrem viel Cpu Leistund für die Schatten berechnung braucht.

! Leistungsgewinne meinte ich !

[Muh-sagt-die-Kuh]

Ein gutes Beispiel ist auch das codieren von Filmen. Ein Two-Pass-Verfahren auf 2 Threads, während der erste einfach 10 Sekunden Vorlauf hat, gibt es als Modul für einige Software schon heute. (ich glaube es soll beim nächsten DVDx auch kommen).Arbeiten heutige Encoder nicht eher so, dass jedem Thread ein Teil eines Frames zugewiesen wird? Bei 2 Threads z.B. Thread 1 obere Bildhälfte, Thread 2 untere Bildhälfte. Gibt es Geschwindigkeitsvergleiche von beiden Vorgehensweisen?

[smoe82]

Arbeiten heutige Encoder nicht eher so, dass jedem Thread ein Teil eines Frames zugewiesen wird? Bei 2 Threads z.B. Thread 1 obere Bildhälfte, Thread 2 untere Bildhälfte. Gibt es Geschwindigkeitsvergleiche von beiden Vorgehensweisen?


Nein. Du meinst das RENDERN von 3D-Bildern. Beim Codieren von Filmen ist das so einfach nicht möglich, da das Bild in seiner Information schon zusammenhängt. Die Codierung eines unteren Bildabschnittes ist stark von den Inhalten des oberen Abschnittes abhängig.

Es besteht auch eine fundamentale Abhängigkeit zu vorhergehenden Bildern, weswegen man nicht jedes zweite Bild von der zweiten CPU berechnen lassen kann.

[smoe82]

! Leistungsgewinne meinte ich !


Natürlich. Genau in diese Richtung gehen ja sämtliche Ansätze der SMP-Programmierung in Spielen. Es gibt aber noch viel mehr Sachen, die berechnet werden. Wo befindet sich welcher Spieler auf dem Feld? Was machen evtl. Fahrzeuge, Flugzeuge etc.? Unabhängige Vorgänge (z.B. ein Vogel fliegt vorbei) und Netzwerklast bei MP-Spielen. Die Möglichkeiten sind nahezu unbegrenzt. Und je mehr wir uns einer realeren virtuellen Welt nähern, desto mehr müssen wir parallelisieren. Alles was zur Zeit gemacht wird ist nichts anderes, wie Multitasking in Windows: dieser Thread 3/10 Sekunden, dann dieser 5/10 Sekunden (oder auch 1/2 ;) ) und dann dieser noch mal 2/10 Sekunden.

Also eine Abarbeitung nacheinander. Das kann nicht ewig so weiter gehen.

[Ikon]

Eben nicht. Im ersten Durchgang wird "geschaut", wie der Stream aufgebaut ist. Sind viele starke Bildwechsel drin, oder ist das Bild eher smooth? Wie groß sind die Farbunterschiede? Und so weiter.

Im zweiten Durchgang wird anhand dieser Statistiken ermittelt, ob es sich "lohnt" eher eine hohe Bitrate zu nehmen, oder ob eine niedrige ausreicht.

So kompliziert ist es nicht wirklich.
Der erste "First Pass" ist einfach nur ein Durchgang mit fixem Quantisierer wie auch im SinglePass-Verfahren, natürlich wird der generierte Stream selbst nicht abgespeichert sondern nur eine Statistikdatei. Für I-/P-Frames wird hier üblicherweise ein Quantisierer von 2 gewählt, der Quantisierer der B-Frames wird anhand der eingegeben Skalierungsformel gewählt (meist 3-4).

Der zweite Durchlauf ist wieder dasselbe, nur dass hier die Quantisierer entsprechend der gewünschten Stream-Größe skaliert wird und der Stream selbst natürlich auch abspeichert wird.

Mehr ist es nicht.

Der Nachteil bei CBR (constant bitrate) ist ja, daß es für schnelle Szenen nicht ausreicht und für langsame manchmal einfach zuviel ist.

Einfach gesagt, ja, wobei "schnell" einen relativ hohen und "langsam" einen geringen Platzbedarf meint.

VBR kann die Bitrate ändern, braucht dazu aber immer den Bezug zum Schlüsselbild, beziehungsweise es muß ein neues Schlüsselbild angelegt werden.

Das ergibt wenig Sinn, ALLE Frames in einem MPEG4-Stream benötigen den Bezug zu einem I-Frame sofern sie nicht selbst welche sind.

Im One-Pass-Verfahren ist die Codierung schon "viel weiter", und kann somit die Bitrate entweder nur langsam anpassen (was sich durch Ruckler bemerkbar macht) oder eben erst ab dem nächsten Schlüsselbild (was einen plötzlichen Qualitätsunterschied hervorbringt).

1) Ruckler (also ausgelasse Frames) treten definitiv nicht auf, bestenfalls eine kurzzeitige Verschlechterung der Qualität aufgrund übermäßiger Kompression.

2) Ich glaube du denkst dass die Quantisierungsformel nur am Anfang bzw. Ende eines GOPs verändert werden kann -> dem ist nicht so. Im finalen Stream gibt es soetwas wie Quantisierer nicht mal mehr.

Bei einem Two-Pass-Verfahren werden nicht nur Statistiken ermittelt, sondern auch die Schlüsselbilder mit den dazugehörigen Bitraten-Empfehlungen. Je nach "Sprunghaftigkeit" des Inhalts werden mehr oder weniger oft neue Schlüssel erzeugt. Der zweite Durchgang generiert nur noch die restlichen Bilder anhand des Schlüsselbildes.

Siehe ganz oben, abgesehen davon ist es falsch, dass der erste Durchgang schon die finalen I-Frames abspeichert, schließlich werden diese im zweiten Durchgang u.U. ebenfalls höher/niedriger quantisiert.

Du hast insofern recht, daß man mit diesem Verfahren eine genaue Größe der Zieldatei festlegen kann.

Nicht nur insofern :)
Die Entwickler von z.B. XviD betonen selbst immer wieder, dass TwoPass NUR den Vorteil einer festlegbaren Dateigröße gegenüber SinglePass besitzt.

Allerdings geschieht dies erst im Zweiten Durchgang. Da der erste Pass nicht die Bitrate festlegt, sondern nur eine "Empfehlung" gibt. Anhand dieser und der Statistik läßt sich recht genau ermitteln, wie hoch die Bitrate im Durchschnitt anzusetzen ist.

Der Encoder selbst legt ja gar keine direkte Bitrate fest, er kennt nur Quantisierer. Wenn du im Panel eine Bitrate eingibst, manifestiert sich diese lediglich im Skalierungsfaktor für die (fixen) Quantisierer des ersten Durchgangs.

Beispiel:

Stream-Größe FirstPass: 1000MB
Gewünschte Dateigröße: 666MB
-> Nötiger durchschnittlicher I-/P-Quantisierer: 3 (Skalierungsfaktor: 1,5 wenn der erste Durchgang von Quant 2 ausging)

[Lilebror]

Natürlich. Genau in diese Richtung gehen ja sämtliche Ansätze der SMP-Programmierung in Spielen. Es gibt aber noch viel mehr Sachen, die berechnet werden. Wo befindet sich welcher Spieler auf dem Feld? Was machen evtl. Fahrzeuge, Flugzeuge etc.? Unabhängige Vorgänge (z.B. ein Vogel fliegt vorbei) und Netzwerklast bei MP-Spielen. Die Möglichkeiten sind nahezu unbegrenzt. Und je mehr wir uns einer realeren virtuellen Welt nähern, desto mehr müssen wir parallelisieren. Alles was zur Zeit gemacht wird ist nichts anderes, wie Multitasking in Windows: dieser Thread 3/10 Sekunden, dann dieser 5/10 Sekunden (oder auch 1/2 ;) ) und dann dieser noch mal 2/10 Sekunden.

Also eine Abarbeitung nacheinander. Das kann nicht ewig so weiter gehen.

Na also hat SMP durchaus einen Sinn! Ich halte da sowieso viel von ! Was will ich mit einem einzigen kern der aber ständig von mehren Programmen ausgebremst wird zum beispiel durch Firewall oder ähnliches betribssystem etc. Ich hatte zum beispiel einen Fall da wäre mir ein 2ter Prozzi sehr lieb gewesen , hatt NFS U Laufenb aber es ruckelte , habe ich dann irgendwann mal ganz entnerft alle unnötigen Programme im Hintergrund ausgeschaltet wie Antivir, Fraps und son kram und auf einmal lief es wie geschmeirt kein einziger ruckler mehr! Also ich spreche mich ein deutig für Dualcore Prozzis aus und läuft ja alles sowie so drauf hinaus Laut CT forscht jeder Prozzi Hersteller auf mehrere Kerne hin und das nicht nur auf 2 sondern mehr.

Naja ich freu mich auf erste ergebnisse von Programmen die es unterstützen ! ! Ich spare insgeheim jetzt schon für einen solchen Prozessor ;D

[smoe82]

So kompliziert ist es nicht wirklich.
Der erste "First Pass" ist einfach nur ein Durchgang mit fixem Quantisierer wie auch im SinglePass-Verfahren, natürlich wird der generierte Stream selbst nicht abgespeichert sondern nur eine Statistikdatei. Für I-/P-Frames wird hier üblicherweise ein Quantisierer von 2 gewählt, der Quantisierer der B-Frames wird anhand der eingegeben Skalierungsformel gewählt (meist 3-4).

Der zweite Durchlauf ist wieder dasselbe, nur dass hier die Quantisierer entsprechend der gewünschten Stream-Größe skaliert wird und der Stream selbst natürlich auch abspeichert wird.

Mehr ist es nicht.



Einfach gesagt, ja, wobei "schnell" einen relativ hohen und "langsam" einen geringen Platzbedarf meint.



Das ergibt wenig Sinn, ALLE Frames in einem MPEG4-Stream benötigen den Bezug zu einem I-Frame sofern sie nicht selbst welche sind.



1) Ruckler (also ausgelasse Frames) treten definitiv nicht auf, bestenfalls eine kurzzeitige Verschlechterung der Qualität aufgrund übermäßiger Kompression.

2) Ich glaube du denkst dass die Quantisierungsformel nur am Anfang bzw. Ende eines GOPs verändert werden kann -> dem ist nicht so. Im finalen Stream gibt es soetwas wie Quantisierer nicht mal mehr.



Siehe ganz oben, abgesehen davon ist es falsch, dass der erste Durchgang schon die finalen I-Frames abspeichert, schließlich werden diese im zweiten Durchgang u.U. ebenfalls höher/niedriger quantisiert.



Nicht nur insofern :)
Die Entwickler von z.B. XviD betonen selbst immer wieder, dass TwoPass NUR den Vorteil einer festlegbaren Dateigröße gegenüber SinglePass besitzt.



Der Encoder selbst legt ja gar keine direkte Bitrate fest, er kennt nur Quantisierer. Wenn du im Panel eine Bitrate eingibst, manifestiert sich diese lediglich im Skalierungsfaktor für die (fixen) Quantisierer des ersten Durchgangs.

Beispiel:

Stream-Größe FirstPass: 1000MB
Gewünschte Dateigröße: 666MB
-> Nötiger durchschnittlicher I-/P-Quantisierer: 3 (Skalierungsfaktor: 1,5 wenn der erste Durchgang von Quant 2 ausging)


Danke für die vielen Infos. Ich kanns natürlich auch nur so weitergeben, wie ich es kenne. Man lernt halt nie aus... ;)

[Ikon]

Was will ich mit einem einzigen kern der aber ständig von mehren Programmen ausgebremst wird zum beispiel durch Firewall oder ähnliches betribssystem etc.

Gegenfrage: was nützt ein zweiter Core der die meiste Zeit idelt (was ja selbst Single-Cores schon die meiste Zeit tun)? Das ist maßlos ineffizient.

Ich hatte zum beispiel einen Fall da wäre mir ein 2ter Prozzi sehr lieb gewesen , hatt NFS U Laufenb aber es ruckelte , habe ich dann irgendwann mal ganz entnerft alle unnötigen Programme im Hintergrund ausgeschaltet wie Antivir, Fraps und son kram und auf einmal lief es wie geschmeirt kein einziger ruckler mehr!

Du sagst es selbst: nach Beendigung unnützer Hintergrundprogramme lief das Spiel zufriedenstellend.
Ein zweiter Core soll also lediglich dazu dienen, deine anfängliche Unfähigkeit im Bezug auf Resourcenzuweisung/-priorisierung zu kompensieren?

[smoe82]

Na also hat SMP durchaus einen Sinn! Ich halte da sowieso viel von ! Was will ich mit einem einzigen kern der aber ständig von mehren Programmen ausgebremst wird zum beispiel durch Firewall oder ähnliches betribssystem etc. Ich hatte zum beispiel einen Fall da wäre mir ein 2ter Prozzi sehr lieb gewesen , hatt NFS U Laufenb aber es ruckelte , habe ich dann irgendwann mal ganz entnerft alle unnötigen Programme im Hintergrund ausgeschaltet wie Antivir, Fraps und son kram und auf einmal lief es wie geschmeirt kein einziger ruckler mehr! Also ich spreche mich ein deutig für Dualcore Prozzis aus und läuft ja alles sowie so drauf hinaus Laut CT forscht jeder Prozzi Hersteller auf mehrere Kerne hin und das nicht nur auf 2 sondern mehr.

Naja ich freu mich auf erste ergebnisse von Programmen die es unterstützen ! ! Ich spare insgeheim jetzt schon für einen solchen Prozessor ;D


Ich selbst habe einen HT-Pentium4 und bin sehr zufrieden. Man kann den effekt schön beobachten, wenn man den Taskmanager aufmacht und die Prozessorzeit der einzelnen Threads betrachtet. Jedesmal, wenn die Last meines Virenprogrammes steigt, erledigt das der zweite Thread. Das läßt sich super beobachten, wenn man über Ethernet etwas saugt und diese Dateien gleich komprimiert z.b. mit RAR. In dem Fall läuft mein Netzwektreiber mit etwa 3 Prozent CPU-Auslastung bei 100MBit, mein Virenscanner (McShield) mit etwa 5% und RAR mit etwa 50 Prozent. Dabei bezeichnen die 50% bei RAR eigentlich 100% CPU-auslastung. Allerdings auf dem ersten Thread. Wenn jetzt eine neue Last, wie McShield dazukommt, dann wird hardwareseitig vom ersten Thread Leistung "abgezwackt", ohne timeslotting zu verursachen. RAR wird nicht unterbrochen; für RAR ist es eben so, als wenn statt 3Ghz plötzlich nur noch 2,9Ghz drin sind.

Das ist echt perfekt und hat auf jeden Fall Zukunft!

[Lilebror]

Ich selbst habe einen HT-Pentium4 und bin sehr zufrieden. Man kann den effekt schön beobachten, wenn man den Taskmanager aufmacht und die Prozessorzeit der einzelnen Threads betrachtet. Jedesmal, wenn die Last meines Virenprogrammes steigt, erledigt das der zweite Thread. Das läßt sich super beobachten, wenn man über Ethernet etwas saugt und diese Dateien gleich komprimiert z.b. mit RAR. In dem Fall läuft mein Netzwektreiber mit etwa 3 Prozent CPU-Auslastung bei 100MBit, mein Virenscanner (McShield) mit etwa 5% und RAR mit etwa 50 Prozent. Dabei bezeichnen die 50% bei RAR eigentlich 100% CPU-auslastung. Allerdings auf dem ersten Thread. Wenn jetzt eine neue Last, wie McShield dazukommt, dann wird hardwareseitig vom ersten Thread Leistung "abgezwackt", ohne timeslotting zu verursachen. RAR wird nicht unterbrochen; für RAR ist es eben so, als wenn statt 3Ghz plötzlich nur noch 2,9Ghz drin sind.

Das ist echt perfekt und hat auf jeden Fall Zukunft!


Ohh nda komm ich aber mal wieder ins schwärmen und Träumen das ist nähmlich das was mich an AMD stört, sowas lässt sich selbst durch nen super schnellen AMD 64 . . . . nich ersetzen. Son misst wollte mir früher immmer nen P4 Kaufen und dann kam der xp 2400 ja da hab ich dem dann genommen. Wie ist das jetzt eigentlich ist in den neuen P4 bzw. prescott jetzt auch die 64bit funktion mit eingebaut so das ich das, das dann in zukunft nutzen kann ? Ich überlege mir nähmlich einen neunen Prozzi zu kaufen und bevor ich jetzt wieder nen neuen Thread auf mache frage ich am besten gleich hier oder ?!

Ach ja die neuen haben aber alle auch HT oder ?! ;D

Hab mal so ein vergleichs Video von Tom's Hardware gesehen 3,6 Ghz (ein 3er aufgetaktet aber ohne HT) gegen einen 3er mit HT und dann gleichzeitig auf beiden Rechnern die gleichen Anwendungen nacheinander gestarten und der HT lag um einiges Vorne mindestens 30 %.

Naja wäre dankbar für ne Antwort ! !

[smoe82]

Ohh nda komm ich aber mal wieder ins schwärmen und Träumen das ist nähmlich das was mich an AMD stört, sowas lässt sich selbst durch nen super schnellen AMD 64 . . . . nich ersetzen. Son misst wollte mir früher immmer nen P4 Kaufen und dann kam der xp 2400 ja da hab ich dem dann genommen. Wie ist das jetzt eigentlich ist in den neuen P4 bzw. prescott jetzt auch die 64bit funktion mit eingebaut so das ich das, das dann in zukunft nutzen kann ? Ich überlege mir nähmlich einen neunen Prozzi zu kaufen und bevor ich jetzt wieder nen neuen Thread auf mache frage ich am besten gleich hier oder ?!

Ach ja die neuen haben aber alle auch HT oder ?! ;D

Hab mal so ein vergleichs Video von Tom's Hardware gesehen 3,6 Ghz (ein 3er aufgetaktet aber ohne HT) gegen einen 3er mit HT und dann gleichzeitig auf beiden Rechnern die gleichen Anwendungen nacheinander gestarten und der HT lag um einiges Vorne mindestens 30 %.

Naja wäre dankbar für ne Antwort ! !

Alle P4 ab 2,8 Ghz haben auf jeden Fall HT. Beim Prescott würde ich noch warten bis sich die Produktion normalisiert hat und mit dem nächsten Stepping auch weniger Stromhunger drin ist. Wenn Du Glück hast, hat er dann auch schon 64 Bit Erweiterung. Allerdings sehe ich (als Programmierer) keinerlei Bedarf dafür. Denn erstens reichen 4 GB (2GB effektiv) addressierbarer RAM noch völlig aus und zweitens ist die schnelle Verarbeitung auf 64Bit-Zahlen oder Wörter beschränkt. Das bläst nicht nur den Code auf, sondern bringt meistens auch gar nichts.

[Lilebror]

Alle P4 ab 2,8 Ghz haben auf jeden Fall HT. Beim Prescott würde ich noch warten bis sich die Produktion normalisiert hat und mit dem nächsten Stepping auch weniger Stromhunger drin ist. Wenn Du Glück hast, hat er dann auch schon 64 Bit Erweiterung. Allerdings sehe ich (als Programmierer) keinerlei Bedarf dafür. Denn erstens reichen 4 GB (2GB effektiv) addressierbarer RAM noch völlig aus und zweitens ist die schnelle Verarbeitung auf 64Bit-Zahlen oder Wörter beschränkt. Das bläst nicht nur den Code auf, sondern bringt meistens auch gar nichts.

Achso dann is gut mhh naja muss sowieso noch was warten werde mir warscheinlich nichts mehr an meinem Rechner aufrüsten sondern direkt einen komplett neuen kaufen und dann mal sehen was da für ein Prozzi rein kommt.

Danke für die Antwort.

mfg : Lilebror

[Ikon]

Ich weiß leider auch nicht genau wie das mit 16Bit und den 32/64Bit x86 Prozessoren aussieht, ob diese nun 16Bit Code auch "ohne Geschwindigkeitsverlust" "in Hatdware" ausführen können (bzw ab welcher CPU das nicht mehr so ist) ...

Ich erinnere an die 16Bit-Schwäche des Pentium Pro (P6) die erst mit dem Pentium II einigermaßen ausgebügelt werden konnte.

[BlackBirdSR]

Hier bitte weiter mit DualCore und Multithreading.
Danke

Der Rest hat einen eigenen Thread bekommen
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=172733