lass mich raten, auf nem Quadcore kann ich 4x schneller kodieren als auf nem Single-Core? lol
allo schrieb:
--------------------------------------------------------------------------------
> lass mich raten, auf nem Quadcore kann ich 4x schneller kodieren als auf
> nem Single-Core? lol
Die Novität besteht darin, dass man auf einer X-Core-CPU mehr!!! als X mal schneller codieren kann. Also mit einer 2-Core-CPU mehr als 2 mal schneller als mit 1 Core.
zeig mir mal bitte ein multi-cpu system das besser als (bzw. überhaupt) linear skaliert! ;)
die aktuellen mainframes von IBM skalieren "nahe" linear, aber eben doch etwas schlechter.
eib quadcore bringt demnach nur "mehr als 3 mal so schnell" weil er eben schlechter als linear skaliert :)
GPL-Hasser Nr. 927519478203 schrieb:
--------------------------------------------------------------------------------
> allo schrieb:
> ---------------------------------------------------------------------------
> -----
> > lass mich raten, auf nem Quadcore kann ich 4x schneller kodieren als auf
> > nem Single-Core? lol
>
> Die Novität besteht darin, dass man auf einer X-Core-CPU mehr!!! als X mal
> schneller codieren kann. Also mit einer 2-Core-CPU mehr als 2 mal schneller
> als mit 1 Core.
Besser formuliert:
Also mit einer 2-Core-CPU schneller als mit einem Encoder, der beide Kerne nutzt, auf derselben 2-Core-CPU.
Gar nicht so einfach, diesen Sachverhalt zu beschreiben. ;)
allo schrieb:
--------------------------------------------------------------------------------
> lass mich raten, auf nem Quadcore kann ich 4x schneller kodieren als auf
> nem Single-Core? lol
den inhalt einer meldung sollte man schon erfassen können, wenn man sich zu wort meldet.
ssssssssssssssssss schrieb:
--------------------------------------------------------------------------------
> zeig mir mal bitte ein multi-cpu system das besser als (bzw. überhaupt)
> linear skaliert! ;)
Ja, aber darum geht es nicht. Fiber Pool optimiert eben noch ein bisschen mehr, damit es gegenüber normalen Encodern noch schneller geht.
Ich kann das leider nicht so gut erklären. ;)
;)
> Ja, aber darum geht es nicht.
Ja eben doch!
> Fiber Pool optimiert eben noch ein bisschen mehr, damit es gegenüber normalen Encodern noch schneller geht.
Nein!
4 * 87% =348%, das Maximum sind wie gesagt 400%
Kleine Nachhilfe in Marketingsprache:
"3,5 mal schneller als" = "3,5 mal so schnell wie"
Marketingdeutsch schrieb:
--------------------------------------------------------------------------------
> > Ja, aber darum geht es nicht.
> Ja eben doch!
> > Fiber Pool optimiert eben noch ein bisschen mehr, damit es gegenüber
> normalen Encodern noch schneller geht.
> Nein!
http://blog.thinkmeta.de/2009/07/multicore-mp3-encoder-zwischenversion-released/
hier steht nix, das ist nur einbildung
ssssssssssssssssss schrieb:
-------------------------------------------------------------------> zeig mir mal bitte ein multi-cpu system das besser als (bzw. überhaupt)
> linear skaliert! ;)
Wie gut ein System skalieren kann hängt neben der Hardware im wesentlichen von der gestellten Aufgabe ab.
Es sind durchaus Konstellationen vorstellbar, wo ein System mit 4 CPUs eine bestimmte Aufgabe in weniger als einem Viertel der Zeit eines 1-CPU-Systems fertigstellt. Im Endeffekt ist das immer eine Frage, inwieweit die Aufgabe parallelisierbar sind, wie hoch der nicht parallelisierbare Overhead ist und inwieweit sich parallel laufende Prozesse auf einer CPU gegenseitig stören können, weil sie sich bestimmte Ressourcen gegenseitig abgraben (z.B. 4 speicherintensive Prozesse, die jeweils auf einen für sie exklusiven RAM-Bereich zugreifen, der der Größe des CPU-Cache entspricht).
blog.thinkmeta.de schrieb:
"Je mehr Dateien zu konvertieren sind, umso weniger fällt das I/O ins Gewicht, weil bereits während der Konvertierung einer Datei schon die nächsten Dateien in den Speicher geladen werden."
Auauauau!
Für Read Ahead braucht es nun wirklich keine multithreaded Applikation, da reicht ein klassisches Multitasking-Betriebssystem.
So kommt man natürlich auf "unmöglich" gute Werte.
Nein, das ist prinzipiell unmöglich - außer man verweigert dem 1-CPU-System Hilfen (wie z.B. File caching), die das 4-CPU-System erhält. Unter gleichen Voraussetzungen kann ein n-CPU-System immer nur x*n-fach schneller sein als ein 1-CPU-System, wobei 0<=x<1 ist.
Bloedsinn. Der Code ist ein voellig anderer, wenn man das 1x- mit dem 4x-System vergleicht. Man stelle sich einfach nur nicht optimierten Code auf dem Singlecore und hochoptimierten, parallelisierten Code auf dem Quadcore vor - klar, dass der Quad hier mehr als 4x schneller waere... Deine Aussage wuerde nur gelten, wenn ein und derselbe (mutithreaded) Code sowohl auf Single- als auch auf dem Quadcore zum Vergleich laufen wuerde. Man kann einfach nicht Aepfel mit Birnen vergleichen.
Warum vergleichst du dann Äpfel mit Birnen?
Hochoptimierter Code hier, nichtoptimierter Code da - was soll der Vergleich?
Lies nochmal nach, ich habe geschrieben "...unter gleichen Voraussetzungen..." - sollte eigentlich logisch sein, oder?
Kurze Hilfe:
Ein Problem wird auf einer Single-Core-CPU gerechnet mit 2mb Cache. Das Problem hat ein Working Set von 7mb.
Wenn man nun das gleiche Probleme auf einem Quad-Core zum laufen bringt (d.h. man setzt voraus das es paralellisierbar ist auf 4 Cores und nur einen minimalen sequentiellen Anteil hat) passt das working set komplett in den cache (wir haben z.B. 4 mal 2mb Cache = 8mb Cache).
Dadurch wird ein superlinearer (d.h. z.B. 5-facher Speedup bei 4 Cores) Speedup erreicht ohne modifikation des Problems.
Der Verwaltungs-Overhead ist auch Messbar , aber man kann somit trotzdem z.T. deutlich über linearem Speedup liegen. Googlelt einfach mal "superlinearer speedup" und ihr findet einige Informationen dazu.
"... da reicht ein klassisches Multitasking-Betriebssystem."
na da sind wir ja bei winblöd genau richtig, oder meintest du preämptives mt
Morpf schrieb:
--------------------------------------------------------------------------------
> blog.thinkmeta.de schrieb:
> "Je mehr Dateien zu konvertieren sind, umso weniger fällt das I/O ins
> Gewicht, weil bereits während der Konvertierung einer Datei schon die
> nächsten Dateien in den Speicher geladen werden."
>
> Auauauau!
> Für Read Ahead braucht es nun wirklich keine multithreaded Applikation, da
> reicht ein klassisches Multitasking-Betriebssystem.
>
> So kommt man natürlich auf "unmöglich" gute Werte.
Du solltest den Artikel mal genauer lesen und zu verstehen begreifen. Der Speedup kommt nicht nur durch weniger IO zustande.
Trauminsel Bielefeld schrieb:
--------------------------------------------------------------------------------
> Morpf schrieb:
> ---------------------------------------------------------------------------
> -----
> > blog.thinkmeta.de schrieb:
> > "Je mehr Dateien zu konvertieren sind, umso weniger fällt das I/O ins
> > Gewicht, weil bereits während der Konvertierung einer Datei schon die
> > nächsten Dateien in den Speicher geladen werden."
> >
> > Auauauau!
> > Für Read Ahead braucht es nun wirklich keine multithreaded Applikation,
> da
> > reicht ein klassisches Multitasking-Betriebssystem.
> >
> > So kommt man natürlich auf "unmöglich" gute Werte.
>
> Du solltest den Artikel mal genauer lesen und zu verstehen begreifen. Der
> Speedup kommt nicht nur durch weniger IO zustande.
Ach ja? Dann laß uns doch an deiner unendlichen Weisheit teilhaben.
Morpf schrieb:
--------------------------------------------------------------------------------
> Trauminsel Bielefeld schrieb:
> ---------------------------------------------------------------------------
> -----
> > Morpf schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > blog.thinkmeta.de schrieb:
> > > "Je mehr Dateien zu konvertieren sind, umso weniger fällt das I/O ins
> > > Gewicht, weil bereits während der Konvertierung einer Datei schon die
> > > nächsten Dateien in den Speicher geladen werden."
> > >
> > > Auauauau!
> > > Für Read Ahead braucht es nun wirklich keine multithreaded
> Applikation,
> > da
> > > reicht ein klassisches Multitasking-Betriebssystem.
> > >
> > > So kommt man natürlich auf "unmöglich" gute Werte.
> >
> > Du solltest den Artikel mal genauer lesen und zu verstehen begreifen.
> Der
> > Speedup kommt nicht nur durch weniger IO zustande.
>
> Ach ja? Dann laß uns doch an deiner unendlichen Weisheit teilhaben.
Wer ist "uns"? Ich rede mit Dir. Du bist der einzige hier, der ein bisschen begriffsstutzig ist.
Lies die Seite mal ganz durch. Dann weißt Du alles dazu und musst Dich hier nicht mehr lächerlich machen.
Kommentare: 173 | letzter Beitrag 27.05. 23:42
Kommentare: 94 | letzter Beitrag 26.05. 19:45
Kommentare: 79 | letzter Beitrag 27.05. 22:43
Kommentare: 71 | letzter Beitrag 27.05. 22:20
Kommentare: 63 | letzter Beitrag 00:03 Uhr
E-Mail an news@golem.de
Der japanische Spieldesigner Goichi Suda - Fans sagen schlicht "Suda 51" - ist für schräge Actionspiele bekannt. Sein nächstes Werk schickt ein scheinbar braves Schulmädchen in den Kampf gegen Zombies.
Weitgehend unbemerkt hat der US-Händler Tigerdirect die ersten Chromebox-Systeme von Google ausgeliefert. Für 330 US-Dollar bekommt der Nutzer recht gute Hardware in Nettop-Form, die sehr viel leistungsfähiger ist als die des Chromebook mit ChromeOS.
Der neue Chef der Piratenpartei steht im Verteidigungsministerium unter Druck. Elektronische Kommunikation für seine Partei ist ihm in der Dienstzeit untersagt. "Es gibt Leute im Ministerium, die darauf warten, dass ich Fehler mache", sagte Schlömer.
Renesas ist nach Elpida der zweite schwer angeschlagene japanische Chiphersteller. Renesas, das Hitachi, Mitsubishi Electric und NEC gehört, macht Verlust und will seine größte Fabrik verkaufen.
RIM soll in den kommenden Tagen erneut einen massiven Stellenabbau ankündigen. "Ich habe herausgefunden, welche Teile ich in meinem Puzzle nicht mehr benötige", sagte Firmenchef Thorsten Heins.
Ein britisches Blog will erfahren haben, dass Facebook den norwegischen Browserhersteller Opera Software kaufen will. Beide Unternehmen wollen sich dazu nicht äußern.