Machen mehrere Kerne wirklich Sinn ?

A

Anonymous

Guest
Ich frage das deshalb, weil ich mir in ein bis zwei Punkten nicht wirklich sicher bin, in Bezug auf Audiobearbeitung meine ich. Ich muss mir aber langsam über einen neuen Rechner wegen zu geringer Rechenleistung Gedanken machen.

Los gehts...

Ist im Audiobereich wirklich vieles parallelisierbar ? Oder muss da schon mal der ein od. andere Kern dann auf das Rechenergebniss des anderen warten, weil z.B. der Hall auf Kern4 auf das Rechenergebniss des Kompressors auf Kern3 warten muss ?

Will sagen, sind Benchmarks mit Algorithmen die hoch parallelisierbar sind wirklich representativ für unsere Audiosachen ?

----------

Folgendes kann ich leider nicht mit einem Link belegen , da ich diesen verloren habe. Aber ich denke schon ich habe das damals richtig verstanden.

Wenn ich zb. als INSERT , also in einer Spur mehrere Instanzen von Nebula2 benutzt (EQ->Comp->Hall) dann laufen die bei REAPER alle auf einem Kern. Der kann dann bis es eben nicht mehr geht ausgelastet werden. Wenn ich den Hall über Aux einbinde läuft der auf einem anderen Kern. Soweit ist ja alles ok.

Problem:

Also was ich will ist , die einzelnen Kerne bis zur Oberkante auslasten können um so wenig wie möglich an Rechenleistung zu verlieren.
Das Problem wird aber immer folgendes sein , sagen wir ich habe einen Hall der einen der vier Kerne zu 30 Prozent auslasten würde, ich habe aber auf allen anderen Kernen (also auf jedem einzelnen !!!) nur noch jeweils 25 Prozent frei, und was mache ich dann ? Wie soll ich den jetzt noch den Hall laden, obwohl ja insgesamt gesehen noch genügend Rechenleistung für drei weitere Instanzen vorhanden währe ?

Denkt euch das einfach wie früher mit den Disketten. Du hast auf 5 Disketten jeweils noch 150-200kbyte Speicherplatz frei, aber deine 300kbyte wirst du eben auf keine der 5 Disketten speichern können obwohl du insgesammt noch das Vielfache an Platz für die Datei zu Verfügung hast.

Alles klar ? ;-)

OT: Also, was ich gerne hätte wären 5-6 Gigahertz Rechenleistung auf einem Kern. Geht das noch ? Oder wird der, wie oben beschriebene, "Schwund" an verfügbarer Rechenleistung ab jetzt immer größer?

tschööö...

Illya
 
Ja, das ist sinnvoll - Selbst wenn es nur pro Thread wäre und das ist natürlich aufgrund der Architekturen heutiger Rechner auch zu erwarten, dass OS, Audioapps und Co mindestens mittelfristig dies einbeziehen und davon auch profitieren, dazu auch die allgemeine Flüssigkeit des Bedienens und dran-arbeitens.

man kann natürlich nicht alles beliebig viel in ein Rechnernetz stecken, wenn es um Realtime-Zeug wie Audio geht, aber es gibt durchaus grade hier sinnvolle Ideen, was aber natürlich von der Programmierung der PlugIns abhängt.

Benchmarks von Logic sind dabei natürlich sinniger als die von Photoshop oder irgendwelchen Spielen.

Einzelne und viele andere Apps könnten natürlich immernoch auf Einkern-Technik beruhen, jedoch sind die Dualcore und andere Prozessoren hier durchaus auch ein anderer Schritt als reine Mehrkernsysteme, die nicht so nah zusammenarbeiten.

Ich glaube jedoch nicht, dass du quasi in beide Kerne 50:50-Verteilverhältnisse kriegst, es wird sicher mal hier mal da weitergehen.

Die XY Ghz sind irgendwann schwer zu machen, wie du siehst steigen die Taktungen nicht mehr so schnell, weil es auch physikalisch Grenzen gibt und Kapazitäten bei bestimmten Bauweisen entstehen.

Die Grenze zum Lichtcomputer oder dem Quantenrechner sind dann nach oben begrenzt durch Lichtgeschwindigkeit, bei den Quanten geht noch was, steckt aber noch tief in den Kinderschuhen.

Nein, vor zu viel Schund muss man sich langfristig nicht fürchten, denn die Programmiermethoden werden natürlich schon übernommen, ältere Plugs werden da natürlich nicht immer mitgenommen oder müssen umgeschrieben werden, das gilt ja nicht nur für Audio.
 
Hi Moogulator, :D

Das mit dem "nur noch jeweils 25 Prozent frei" meinte ich natürlich nur als Beispiel, da das so einfacher/schneller nachzuvollziehen ist und man locker unangestrengt weiterlesen kann.

Ich habe auch bewusst die Speicheranbindung an die CPU weggelassen, sonst müsste ich weiter ausholen , also irgendwo bei Seymour anfangen... und würde bei heutigen Systemen enden.., das währe dann schon eine kleine
Geschichte für sich, die will ich hier aber niemandem zumuten. Dafür gibt es andere Foren. Ist aber eigentlich der wichtigste Teil.., hmm.. mal sehen. Dabei kann einem aber auch ganz schnell ganz schlecht werden, wenn man bedenkt womit wir bez. Speicheranbindung heute noch arbeiten müssen. Hauptsache Megahertz , na ja, Marketing halt.
Und auch das die CPU etliche Takte Däumchen dreht etc.
Warten wir mal ab, vieleicht will das ja ein anderer machen. ;-)

Tja, und rechnen mit Photonen, warten wir mal ab wann das kommt in Zukunft. Spannend wird es bestimmt.

Mir ging es hauptsächlich um den Schwund, also Rechenleistung die ich ja bezahlt habe , wenn ich mir einen Rechner mit Mehrkern zusammenbasteln würde. Je mehr Kerne, desto mehr Schwund, so hätte ich das wohl besser schreiben sollen, sorry.

Edit: Beim "Render" im Netzwerk hat wenigstens jede CPU ihr eigenen BUS, bzw. eigenes RAM, da kommt sich nichts in die Quere.

Illya
 
Oooch, das Forum hier ist auch dafür da, wir können auch tiefer. OS war ein Fach, was ich ansich mochte. Damals gabs aber noch keine Mehrkern Prozessoren in einem Gehäuse, naja..

Natürlich gibts es "Schwund", da allein das OS sowieso eine Verwaltung hat und bestimmte zeitkritische Sachen nicht zu weit aufgespalten werden können, ich fühle mal du kennst dich eh etwas aus, daher weisst du eh schon: Prozessortakt mal 2 ist natürlich nicht realistisch, aaaaber: Nach oben sind die Grenzen auch da, es ist inzwischen "leichter" mehrere Kerne zu bauen als schneller zu werden mit dem Takt, wie du schon sagtest, hat das natürlich auch was mit dem Bus, dem Cache und der Architektur des Chips und der Kerne miteinander zu tun, man kann es also nicht ganz pauschal sagen.
 
Nachgefragt, wieso denn Marketing in Bezug auf MHz bei Speicheranbindung ?
Ich dachte, schneller geht nicht, wegen der Latenzen bei jetziger Technik.
 
Mogulator lass uns meine "Frage" lieber vergessen, da ich in Sachen Multicore erst ab.. hmm.. NT4 od wars NT5 ??? Mich damit beschäftigt habe. Oh ja, Zeitscheiben (time slice), ne , das ist bei mir alles irgendwo tiefst im Hirn vergraben. Ich will nicht damit sagen das es nicht spannend ist, aber WIR können uns sowieso keine CPU Leisten die so groß ist wie eine Ritter Sport Schokolade, also nicht diesen kastrierten Murks. ;-)

Und am besten noch Programmierer einstellen die dann die Soft. für uns proggen he,he...

Ich sehe schon wie wir hier anfangen rumzuträumen. ;-) Außerdem müsste ich Unmengen wieder nachlesen um nicht nacher als totaler DAU darzustehen.

Ich trinke jetzt mal weiter meinen VINO TINTO.

Ach ja, meine CT-Sammlung dient mittlerweile als Kratzbaum für meine Katzen..

Illya

Edit: Das ist leider wie ich merke (trotz VINO) nicht mal eben schnell abzuhandeln. Was habe ich mir bloß dabei gedacht.. :roll:
 
Waldorfer schrieb:
Nachgefragt, wieso denn Marketing in Bezug auf MHz bei Speicheranbindung ?
Ich dachte, schneller geht nicht, wegen der Latenzen bei jetziger Technik.

Mein Gott, halbe Flasche VINO und ich bin schon breit... (ich lache nur noch)

ähhmm ja... ach so. Also bevor ich mich ausklinke..

"Hauptsache Megahertz , na ja, Marketing halt." Den darfst du gern aus dem Zusammenhang reißen, den der steht für sich. Ich meinte das in Bezug auf dieses ewige viele Kerne und mal eben die Rechenleistung der einzelnen Kerne zusammenzählen.. sorry , my fault.

Nicht böse sein lieber Waldorfer, aber trink doch auch was, ja ? (bitte,bitte) ;-) Ich habe einfach die zum Verständniss notwendige Hälfte weggelassen.. übel,übel..
 
Waldorfer schrieb:
Nachgefragt, wieso denn Marketing in Bezug auf MHz bei Speicheranbindung ?
Ich dachte, schneller geht nicht, wegen der Latenzen bei jetziger Technik.

Mit Latenz hat das nicht zu tun. Der Begriff ist zzt auch eher überstrapaziert.
 
Doch doch, es gibt auch eine Speicherlatenz. Wenn man den Speicher auslesen will, muß man ihn ja Adressieren und das dauert. An dieser Adresse wird dann (prinzipbedingt, RAM-intern) ein sehr grosser Block (eine Speicher-Reihe) gelesen., von dem die CPU aber nur einen Teil bekommt. Dabei liest die CPU auch mehr Daten ein als sie eigentlich braucht (immer in Cache-Line-Häppchen), die kommen dann gleich in den Cache. (Ist sehr wahrscheinlich, dass die gebraucht werden). Und falls der nächst Zugriff fortlaufend ist, dann muß nicht komplett umadressiert werden, das Datum wurde ja sogar schon gelesen - es muß nur noch (aus dem Reihen Puffer) zur CPU geschoben werden.
Das ist die (kosten)effektiveste Methode den Speicher praktisch schnell zu bekommen, auch wenn er nicht immer schnell ist.
 
Moogulator schrieb:
Prozessortakt mal 2 ist natürlich nicht realistisch, aaaaber: Nach oben sind die Grenzen auch da, es ist inzwischen "leichter" mehrere Kerne zu bauen als schneller zu werden mit dem Takt, wie du schon sagtest, hat das natürlich auch was mit dem Bus, dem Cache und der Architektur des Chips und der Kerne miteinander zu tun, man kann es also nicht ganz pauschal sagen.

Ja, klaro, Prozessortakt mal 2 = Marketing :D . Ich sach nur mit nem Moped auf der vier spurigen Autobahn unterwegs. Looolll..

Das steckt aber leider bei vielen reinen USERN in den Köpfen. Dieses "Quantispeed" od. wie das bei Intel/AMD heist. Das erkläre dann mal einem "normalem" Nutzer. Ich mache das nicht mehr, da mache ich lieber Musik , und wer sich in Sachen Rechnerarchitektur bilden will , der soll das auch bitte schön selber machen, und nicht MEINE Lebzeit verballern.

Was ja schon gut ist , ist das die Kerne nicht mehr in getrenten Sockeln werkeln , sondern auf einem DIE sind, das ist ja schon schneller. Ich habe da aber die Entwicklung in den letzen 3 Jahren nicht weiter verfolgt, ist zwar spannend, aber ich habe dann weniger Zeit mich um meine Musik zu kümmern etc.

Edit: Ich weiß das Multithreading in Sachen OS absolut nicht mein Ding ist, ich habe mich damals mehr auf die reine Hardware-Anbindung konzentriert, das hat mir völlig gereicht als ich das dann mit damaligen PC Technik verglichen habe (Speicheranbindung).
 
Doch doch, es gibt auch eine Speicherlatenz.

Danke für die Info ;-)

Ich bin über das Problem durch die neuen DDR3 gestolpert, wo der I/O Buffer Takt dann ja eigentlich wieder verdoppelt wird aber die Latenzen leider auch anwachsen.

Das steckt aber leider bei vielen reinen USERN in den Köpfen. Dieses "Quantispeed"

Ist ja auch klar, die Märkte und Anbieter fördern das ja auch noch, indem dann die GHz-Angabe einfach ver4facht wird.
 
Die ganzen Latenzen summieren sich halt. Und ich finde es eine Frecheit , das da von System zu System nur ca. jeder dreizehnte Takt wirklich ankommt , also in Sachen Rechenleistung. Ein Dreizehntel !!!! Das ist doch fürn Popo...

Aber ich kann mir auch nichts besseres leisten.., muss also mit dieser Technologie leben.. shit.

Edit: Das ist mein Stand der Dinge , wenn die heute schneller sind als 13 Takte bitte ich um links , bzw. um Aufklärung.
 
Naja, ich sehe die Flasche da mehr halb voll ;-)

nein im Ernst - ich hatte schon länger mit dem Gedanken gespielt, aber jetzt erst habe ich das "Gefühl", dass mir ein BEZAHLBARER Compi auch das bringt, was ich Live benötige. Also es bleibt noch genug über, trotz Windows, Sachen von denen ich nicht genug verstehe und teilweise auch nicht optimalen Algos der Software. Wobei ich da nur mutmaßen kann.....
Aber was solls. Hauptsache die Kiste ist schnell genug, wie schnell sie sein könnte ....
 
Waldorfer schrieb:
Naja, ich sehe die Flasche da mehr halb voll ;-)

nein im Ernst - ich hatte schon länger mit dem Gedanken gespielt, aber jetzt erst habe ich das "Gefühl", dass mir ein BEZAHLBARER Compi auch das bringt, was ich Live benötige. Also es bleibt noch genug über, trotz Windows, Sachen von denen ich nicht genug verstehe und teilweise auch nicht optimalen Algos der Software. Wobei ich da nur mutmaßen kann.....
Aber was solls. Hauptsache die Kiste ist schnell genug, wie schnell sie sein könnte ....

Ne, ist auch nicht wirklich schlimm, das mit der Flasche jetzt. ;-)

Ich bin der Meinung, das man mit dem arbeiten soll was verfügbar/bezahlbar ist. Jeder nach seinem Geldbeutel. Ich bin meist nur mit einem 1800Mhz AMD XP (auf 1400Mhz gedrosselt) unterwegs. Will sagen, es reicht mir auch was ich mit meinem alten System machen kann, aber manchmal juckts halt schon, wenn man weiß das bessere Technologie verfügbar währe.

Es ist ja auch mittlerweile auch alles saubillig geworden (PC-CPU), aber ich zahle halt auch nicht nur den dreizehnten Teil meiner Stromrechnung, sondern den vollen Betrag.( Bei ca. 7-9 Stunden Laufzeit am Tag)

Aber neuer Rechner muss langsam sein, weil meiner schaft bei einem Hall bei Nebual mal locker nur einen (1), aber mit einem Q6600 würde ich von dem gleichen Hall 11 Instanzen öffnen können. Das ist schon ein heftiger Unterschied.

Vieleicht meckere ich ja zuviel, aber alter Wein in neuen Schläuchen ...auch wenn er süßer ist... hmm.. mal sehen was ich mir demnächst gönne. Vieleicht ja was externes. ;-)
 
Fetz schrieb:
Doch doch, es gibt auch eine Speicherlatenz. Wenn man den Speicher auslesen will, muß man ihn ja Adressieren und das dauert. An dieser Adresse wird dann (prinzipbedingt, RAM-intern) ein sehr grosser Block (eine Speicher-Reihe) gelesen., von dem die CPU aber nur einen Teil bekommt. Dabei liest die CPU auch mehr Daten ein als sie eigentlich braucht (immer in Cache-Line-Häppchen), die kommen dann gleich in den Cache. (Ist sehr wahrscheinlich, dass die gebraucht werden). Und falls der nächst Zugriff fortlaufend ist, dann muß nicht komplett umadressiert werden, das Datum wurde ja sogar schon gelesen - es muß nur noch (aus dem Reihen Puffer) zur CPU geschoben werden.
Das ist die (kosten)effektiveste Methode den Speicher praktisch schnell zu bekommen, auch wenn er nicht immer schnell ist.

Der Begriff ist ein Anglizismus, er war mal für die Audio-Verzögerung gedacht und dafür als Fachbegriff ganz ok, hier sollte man schon etwas anders argumentieren, in der Sache gibt es natürlich einen zeitlichen Versatz mit Prozessor - Bus - Speicher. Das dürfte allgemein bekannt sein.
 
Moogulator schrieb:
Der Begriff ist ein Anglizismus, er war mal für die Audio-Verzögerung gedacht

Nein. Die Speicherlatenz heißt wirklich so. Englisch heißt das Latency - und der Begriff ist wirklich, und nicht nur dafür, üblich. Ist nämlich ein generelles Phänomen digitaler Systeme, dass die Verarbeitungsgeschwindigkeit sehr viel grösser ist als die Latenz ist.

Die zeitliche Grössenordnung der Speicherlatenz hat natürlich nichts mit der Audiolatenz zu tun, aus Anwendersicht wird die CPU davon einfach nur etwas langsamer.
 
hall lässt sich doch sehr gut parallelisieren. also ein 30%CPU belastender hall ließe sich problemlos in viele 10% Teile zerlegen usw.
Plugins kann man doch auch in threads zerteilen... ;-)

Das man die üblicherweise als ganzes laden muss heist ja nicht dass das in jedem Fall sinnvoll ist...
Man könnte ja auch ein Plugin laufen lassen, das 120% frisst.
Natürlich entsteht durch die zerstückelung in threads mehr overhead. Wenn aber die anderen CPUs kaum ausgelastet sind macht das kaum einen Unterschied.
 
komons.de schrieb:
hall lässt sich doch sehr gut parallelisieren. also ein 30%CPU belastender hall ließe sich problemlos in viele 10% Teile zerlegen usw.
Plugins kann man doch auch in threads zerteilen... ;-)
...Natürlich entsteht durch die zerstückelung in threads mehr overhead

Das ist doch mal eine gute Information, danke. Hall ist also gut parallelisierbar, nach deiner Aussage. Gilt das nur für algorithmischen Hall, oder auch für diese dynamic volterra kerneling Geschichte (Nebula) , also sowas ähnliches wie Convolution bei, SIR, Sintefex etc. (Faltungshall) ?

Wie groß wird/kann denn der Overhead werden ? also wieviel Rechenleistung verliere ich durch den Verwaltungsaufwand , wenn sich z.B. Der Hall auf die restliche zur Verfügung stehende Rechenleistung von drei Kernen aufteilt.

Nebula:
http://www.kvraudio.com/forum/viewtopic ... sc&start=0

Edit: Kann es sein, das da jeder Seq./Host - Hersteller sein eigenes Süppchen kocht? Ich hatte ja als Beispiel REAPER genannt. Kann ja auch sein das die das in zwei Monaten wieder anders machen, ich weiß das aber nicht. So nach dem Motto , viele Wege führen nach Rom.
 
Toni W. schrieb:
..., oder auch für diese dynamic volterra kerneling Geschichte (Nebula) , also sowas ähnliches wie Convolution...

Nebula ist ein Frickelalgorithmus und hat mit der mathematischen Exaktheit der Faltung nichts zu tun.

Volterra REihen *modellieren* nichlineare Systeme, für die Modellbildung gibt es aber kein (geschlossenes) Verfahren zum Ausmessen wie bei der Impulsanwort/Faltung - das ist immer Näherungweise/Empirisch.

Mit der Inkludierung zeitvarianter System kommt da noch eine Bastelebene, sowohl bei der Modellbildung als auch der Berechnung hinzu.

Die Berechnung von Voltera-Reihen lässt sich allerdings recht gut parrallelisieren, kommt also nur drauf an wie gut Nebula das macht.
 
Fetz schrieb:
Die Berechnung von Voltera-Reihen lässt sich allerdings recht gut parrallelisieren, kommt also nur drauf an wie gut Nebula das macht.

Aha, danke. Jetzt bleibt für mich nur noch die Frage des Verwaltungaufwandes bei Verteilung auf mehrere Kerne (im Allgemeinen), und steigt dieser mit der Anzahl der Kerne linear , bzw. wie sieht das aus ?

Edit: Was ich wissen will, ist wenn wir irgendwann 16 od. Mehr Kerne nutzen der Verwaltungsaufwand nicht irgendwann so hoch das wir mehr Rechenleistung verlieren als wir nutzen. ?(Sorry, ich kann das nicht anders beschreiben)
 
Toni W. schrieb:
Aha, danke. Jetzt bleibt für mich nur noch die Frage des Verwaltungaufwandes bei Verteilung auf mehrere Kerne (im Allgemeinen), und steigt dieser mit der Anzahl der Kerne linear , bzw. wie sieht das aus ?

Das kommt auf den Algorithmus und auf die Gestaltung des schedulers/ anzahl der Ebenen drauf, cache-zugriff etc an. Ich schätze, das der Aufwand linear steigt. (Ohne dass ich mich da besonders auskenne.) Zerstückelung lohnt sich auch nur, wenn der Rechenaufwand vergleichsweise groß ist zum zusätzlichen Aufwand für die Threadverwaltung. Bei 30%CPU Auslastung ist aber prinzipiell davon auszugehen, da der scheduler mit allem drum und dran für das ganze system nur ein paar Prozent frisst.
Theoretisch gibt es auf alle Fälle eine Obergrenze, ab der sich parallelisierung nicht mehr lohnt, aber bei 4 CPUs brauch man sich da keine Gedanken machen...

Man kann ja man verleichsbenchmarks anschauen von Multiprozessorsystemen, da ist der overhead im Bereich <10%.
 
Toni W. schrieb:
Edit: Was ich wissen will, ist wenn wir irgendwann 16 od. Mehr Kerne nutzen der Verwaltungsaufwand nicht irgendwann so hoch das wir mehr Rechenleistung verlieren als wir nutzen. ?(Sorry, ich kann das nicht anders beschreiben)

JA, natürlich. Dazu gibt es auch Berechnungen für theoretische Obergrenzen, ist ja auch logisch. 4 ist da im Vergleich eine sehr kleine Zahl.
Man braucht sich ja nur mal die Multicluster Rechenfarmen anzuschaunen,
da sieht man was in der Praxis veranstaltet wird.

http://de.wikipedia.org/wiki/Supercomputer

Natürlich ist das auch Architekturabhängig.
 
he,he, der Link ist mir schon bekannt. :D

Ich wollte diese Frage aber auch gern hier drin haben, damit nicht jeder der das liest denkt, viel hilft viel, sondern das das auch Konsequenzen hat. Also sorry für den Missbrauch und danke für die Hilfe.

Somit sind wir ja nun auch am Ende angelangt, habt Dank an alle hier.

Illya
 
ach und das muss zu den supercomputern noch angemerkt werden:
da werden nicht immer alle CPUs von einem User bedient. Man kann sich dort auch mal nur 300 CPUs mit entsprechendem RAM mieten und mehrere User sind gleichzeitig aktiv. Die Software, die man dort verwenden kann, ist dann allerdings direkt für die Architektur zugeschnitten/freigegeben.
 
Es gab damals (2000) auch ein "Spektrum der Wissenschaft : Dossier - Rechnerarchitekturen"

Die Infos kann man ja heute auch über das Netz bekommen, wer aber ein bischen offline schmökern will kann ja mal schauen ob er das Heft noch bekommt. Das Heft war mein Einstieg in die Thematik und es liest sich sehr gut, auch wenn man keinen Hochschulabschluss hat.(so wie ich) :D
 
Fetz schrieb:
Moogulator schrieb:
Der Begriff ist ein Anglizismus, er war mal für die Audio-Verzögerung gedacht

Nein. Die Speicherlatenz heißt wirklich so. Englisch heißt das Latency - und der Begriff ist wirklich, und nicht nur dafür, üblich. Ist nämlich ein generelles Phänomen digitaler Systeme, dass die Verarbeitungsgeschwindigkeit sehr viel grösser ist als die Latenz ist.

Die zeitliche Grössenordnung der Speicherlatenz hat natürlich nichts mit der Audiolatenz zu tun, aus Anwendersicht wird die CPU davon einfach nur etwas langsamer.

Ja, schon, aber er ist MS-mäßig "übersetzt" worden. Man würde sonst noch heute von "Verzögerung" sprechen oder nicht? Ging mir da nur um den Begriff und seine mittlerweile allgegenwärtige Benutzung. Müssen wir nicht vertiefen. Aber dein letzter Satz ist, was ich damit ausdrücken wollte und grade wegen des Begriffes "Latenz", der ist etwa so gewachsen wie "allgemeine Schutzverletzung", was wohl außer MS niemand als "deutsches Wort" begreift, wenn überhaupt.. ;-)

Mehrkenrnetze und Systeme sind für Realtime-Aufgaben nicht primär ideal gedacht und konzipiert, jedoch kann man mit einer begrenzten Zahl und geschickten Verteilalgorithmen hier durchaus etwas bewegen, am einfachsten könnte das bei DualCore sein, indem man die Busbreite quasi über 2 Prozessoren verlängert und wie "ein Register" sieht, THEORETISCH!!

in der Praxis sind dann doch noch einige abstraktionen drumrum nötig, die den Vorteil schnell wieder eindampfen können..
 
Man verzeihe mir, das ich mich hier mal ein bißchen Off Topic dranhänge...

Wie sieht das denn mit Cubase und Duo oder Quad CPU`s aus ? Nutzt Cubase beide Kerne ? Und wie ist das mit Ableton ?
 
2 Kerne klappen schon ganz gut, zumindest bei Live und Logic, Cubase müsste ich mal prüfen, denke aber man hat in der 4er auch zumindest Doppelkern berücksichtigt.

Das Problem ist eben, dass man nicht eben mal 16 oder 128 Kerne einbauen kann und alles davon profitiert, es würde aber schon was bringen, wenn ein Programm PRO PLUGIN auf Kerne verschiebt, zB ein PlugIn auf Kern1, eins auf 2, da ist die Verteilung noch nicht perfekt und darüber angeordnet wäre eine freie Verteilung der Jobs innerhalb eines Plugins, Multithreading-Programmierung also, viele Funktionen und da wäre es auch wichtig zu checken, wo die Grenze ist und wo einfach nur zu viel Verwaltung aufkommt, ich habe mich bisher nicht mit viel mehr als 4 Kernen befasst, jedoch kommt das Thema und ist ansich schon da (nicht hier bei mir, aber generell schon).

Meint: Nutzen? Ja, aber effektiv und perfekt ausgelotet? Najaaaa
 


News

Zurück
Oben