Neuer DAW Rechner Intel 2014.08.30

  • Ersteller Loop_Breaker
  • Erstellt am
korrekt
schon wegen der latenz für die bufferberechnung ist singlethreading power wichtiger als parallelprocessing weil dort die timings knapper sind als dass die aufgeteilte last die kerne komplett auslastet - letzteres wäre sowieso schon lange der buffer underrun tod der samples.

ist aber projektabhängig ob ich erst an das singlethread limit komme, oder ob ich da keinen flaschenhals habe und die schiere pluginanzahl auf verschiedenen parallelisierbaren spuren alle cores ausreizen KANN
 
korrekt
schon wegen der latenz für die bufferberechnung ist singlethreading power wichtiger als parallelprocessing ...

Könnt ihr das bitte näher erläutern was es mit der Pufferberechnung auf sich hat? (interessiert mich brennend)
 
naja das was die daw und die plugins halt machen müssen
audio samples mit hilfe von algorithmen berechnen(z.b. synth,sampler) / verändern(z.b. input des interfaces, wav in der daw...) und das auf basis von mehr oder weniger großen buffern in verschiedenen bereichen der software

das sind viele buffer und die wollen alle so klein wie möglich bleiben (sonst ist die latenz groß), damit der interfacetreiber für die ausgabe der neu berechneten samples im ausgabebuffer noch rechtzeitig -vor abschicken an die hardware- übertragen kann, da es ansonsten audio aussetzer gibt (knachser, kleine loops)

im groben kann ich den signallauf an einem beispiel erklären wenn ich eine gitarre am interface einstecke und über ein VST plugin (z.b. amplitube) den sound machen will und das ganze wieder über die kopfhörer hören möchte:

input am interface -> preamp -> A/D wandler (kleine latenz, aber kein samplebuffer)
A/D wandler -> interface hardware (z.B. mit DSP für effektberechnung usw..) dort gibt es den ersten buffer, der die kommunikation zwischen interface und rechner bus buffern soll - falls es kein pci/pcie bus ist, kann noch ein weiterer hardware/softwarelayer dazu kommen, der protokollbedingt einen weiteren buffer dazwischenstellt (USB/Firewire..)

das ist bis jetzt nur hardware und hat eigentlich nichts mit der cpu auslastung zu tun
der buffer im interface ist höchstens dann zu klein, wenn der systembus derart belastet werden würde, daß die daten mit einer größeren verzögerung, als die buffergröße ausgelegt wurde, abgenommen oder geschrieben werden würden.

nun gibt es den ersten softwarebuffer im treiber (genau den, der am interfacetreiber in form von samples eingestellt werden kann) der die eingangsdaten und ausgangsdaten aller interface kanäle an die applikationen (z.b. in form von asio - was den betriebssystem audioteil umgeht) und betriebssystem (z.b. WDM) bereitstellt

da der treiber in einer höheren priorität läuft, als die DAW, wird der treiber selbst nur dann ausgebremst, wenn andere min gleichwertig eingestufte treiber die ausführung beeinträchtigen. dann kann dieser treiberbuffer seinserseits nicht mehr rechtzeitig an die hardware synchronisiert/übergeben werden. logischerweise wird der zeitpunkt des buffer-austausch von treiber zu interface (bufferswitch) vom interface aus getriggert, da es die clock für die samples beinhaltet.
bei jedem bufferswitch wird also das, was die daw über den asiotreiber auf den buffer geschrieben hat, an das interface weitergegeben und gleichzeitig die eingänge des interfaces auf die buffer der eingangskanäle - den bekommt dann die daw.

wenn nun also das input signal der gitarre im asio buffer des treibers nach einem bufferswitch anliegt, kann die daw ihn auslesen -> es wird hierbei der asiotreiber die bufferswitch funktion (callback) der daw aufrufen, die dann ihrerseits die eingangsbuffer und ausgangsbuffer ausliest/beschreibt
und genau hier ist der haken bei knachsern -> es muss der buffer vor dem nächsten bufferswitch, der von der interfaceclock angetriggert wird, von der daw beschrieben bzw ausgelesen werden.
ist die daw z.b. zu spät beim schreiben, wird der buffer einfach an das interface zum D/A wandeln abgegeben und zwar so wie er ist (es kann unterschiedlich implementiert sein, ob das nun ausgenullte buffer sind oder das drin bleibt, was beim letzten bufferswitch übertragen wurde)

bis hierhin war es im prinzip die kette hardware input -> A/D -> treiber -> asio bufferswitch -> treiber -> D/A

was nun die daw mit den buffern anfängt, liegt natürlich voll und ganz in ihrem ermessen :)
die einfachste bufferswitch funktion wäre: "lege inputbuffer auf outputbuffer"
damit wäre der kleinste minimalste aufwand getrieben, was eine audioengine mit hilfe des asiotreibers machen kann. im prinzip nur eingänge auf ausgänge routen.

beim alltagsbetrieb mit er daw ist das natürlich viel komplexer.. da gibt es evtl nochmal einen buffer, dann einen plugin-latenz ausgleich (in den meisten daws) - was im prinzip wieder in buffer pro routing darstellt - die aber alle unterschiedlich lang sind ( da sie von den pluginlatenzen abhängig sind)

es gibt also noch plugins mit latenzen -> also buffer, die allerdings weniger dazu da sind, um timings und datenübertragungen zu gewärleisten, sondern weil die internen algorithmen mehrere samples "sehen" müssen, um korrekt zu rechnen. beispiel: limiter mit lookahead -> es wird künstlich über einen kleinen samplebuffer die zeit verschoben, damit der limiter "vorher" reagieren kann, bevor es klippt und somit sanft reagiert.

um jetzt beim beispiel "amplitube als VST" zu bleiben sieht das je nach daw ungefär so aus:
hardware input -> A/D -> treiber -> asio bufferswitch -> mixer kanal routings -> insert effekte routing -> VST plugin eingangsbuffer(normal gleichgroß wie ASIO Buffer) -> eventueller VST plugin interner eingangsbuffer (=pluginlatenz) -> plugin algorithmus/logik (multithreading machbar) -> plugin interner ausgangsbuffer -> DAW mixer routing -> sonstige insert effekte, send routings usw -> summing -> asio bufferswich -> treiber -> D/A

der VST plugin buffer ist deshalb gleichgroß wie der asio buffer, weil die daten im prinzip in einem rutsch von Asio buffer durch das plugin durch, wieder zurück und wieder auf den asiobuffer geschrieben werden können - falls nirgends weitere pluginlatenzen oder pluginlatenz-ausgleich stattfindet, kann dies ohne weitere latenz innerhalb der daw [zwischen den bufferswitches] passieren

verkürzt gesagt, nimmt die daw also eingangs-samples über den asiobuffer entgegen (gesamte bufferlänge auf einmal), berechnet alles (schickt es durch plugins usw) und legt das ergebnis auf die ausgänge auf den asiobuffer - das passiert getriggert vom treiber, der wiederum vom interface getriggert wird.

genau diese kette kann nun daw intern über multithreading auf mehrere threads aufgeteilt werden - dadurch können wiederum die threads auf verschiedene kerne (sofern vorhanden) gelegt werden (bestimmt mitunter das OS, kann aber auch die DAW oder Plugins programmiertechnisch gesteuert werden)

in wie weit nun genau dieser signalpfad zwischen buffer übergabe parallelisiert werden kann, liegt ganz einfach an der struktur des routings
wenn ich nur einen kanal habe, der wie im beispiel von input - > vst -> output geroutet ist, kann ich ihn nicht parallelisierren, da ich nichts berechnen kann, was noch nicht da ist.
wenn ich aber zwei inputs habe und die auf getrennte kanäle verarbeite, wäre dies schon über zwei threads parallel abzuarbeiten.

das war aber nur grob beschrieben - in wirklichkeit gibt es ziemlich viel synchronisationspunkte, wo sich die daten der verschiedenen threads "treffen" - genau dort kann immer nur ein thread gleichzeitig drauf zugreifen und somit gibt es in der praxis einen overhead, durch multithreading
erst entsteht. dieser wird auch größer, umso mehr threads sich um "gemeinsam genutzte speicherbereiche" kümmern müssen - man muss nur mal überlegen, daß es nicht nur die audioengine gibt wovon ich die ganze zeit rede, sondern auch eine GUI, die mehr oder weniger in echtzeit diese daten anzeigen soll bzw beeinflussen. genau hier entstehen auch synchronisationspunkte, die wiederum die audioengine mehr oder weniger ausbremsen -> je nach implementierung und priorisierung. wenn man also träge "laggy" VU meter sieht, die dem audiosignal hinterhereilen, dann ist ganz einfach der thread für die gui niedriger priorisiert als der audiothread, der wichtiger ist.

sprich - die multithreading geschichte ist sozusagen eine wissenschaft für sich (selbst für entwickler) - da man es hocheffizient implementieren muss, damit es nicht zum flaschenhals durch sich selbst wird (overhead > nutzen multithreading)

um jetzt wieder auf die erde zurückzukommen (ich bin ja ziemlich ins detail gegangen und abgeschweift)
wenn der eine signalpfad, der zwingendermaßen über einen thread laufen MUSS, zuviel rechnzeit benötigt, bis er die asiobuffer wieder mit daten beschrieben hat, wird es aussetzer geben - und da kann kein anderer thread (und somit kern) helfen, die berechnung schneller durchzuführen.

wenn ich also grundsätzlich zu langsame kerne habe, aber viele, dann limitiert mir die singlethreadleistung die "länge/berechnungsdauer" meines (eines) signalpfades

sobald ich also nur einen einzigen kanal, der nicht parallelisierbar ist, in meinem routing habe, der für einen core zuviel ist, dann wird es zu einem buffer aussetzer kommen - egal ob der rest der kerne noch freiraum hätte.

anderstrum können mehrere kanäle parallel auf einem kern berechnet werden (wenn es zeitlich reicht) - das macht die daw sowieso und das betriebssystem unterstützt dies von natur aus schon. sonst könnte man ja nur soviel programme laufen lassen wie man kerne hat -> das nennt man multitasking -> das OS teilt im prinzip die threds selbstständig auf die kerne auf, und gibt ihnen immer wieder zeit zum rechnen und hält sie danach an -> es läuft also immer nur ein thread (oder 2 im falle HT) auf einem kern gleichzeitig

innerhalb der plugins kann wie geschrieben auch multithreading passieren -> skaliert aber auch nicht 100% pauschal.
auch hier gelten die limits "was nicht da ist - kann nicht berechnet werden"

und somit ist meiner meinung nach (für mich) ein potenter mehrkern proz mit großer singlethreadleistung besser als ein proz mit doppelt soviel kernen aber ein Ghz weniger, weil genau das eine felhende Ghz in dem einen nicht-parallelisierbaren-routing die buffer-underrun grenze nach unten verschiebt.
aber eigentlich anwendungsfall abhängig :)


hier noch ne kleine ältere lektüre von RME http://www.rme-audio.de/techinfo/lola_lomo.htm
 
danke buffi für diese wertvolle information
 
ich würde beim board lieber das hier nehmen:
http://geizhals.de/gigabyte-ga-x99-ud4-a1155326.html

MSI halten meiner erfahrung nach nicht lange & die gigabyte ultra durable sind hervorragend.
das bessere P/L gibts wohl mit dem i7-4790K, da board & speicher günstiger & mehr auswahl.
 
SEHR SEHR LANGER TEXT :D
und somit ist meiner meinung nach (für mich) ein potenter mehrkern proz mit großer singlethreadleistung besser als ein proz mit doppelt soviel kernen aber ein Ghz weniger, weil genau das eine felhende Ghz in dem einen nicht-parallelisierbaren-routing die buffer-underrun grenze nach unten verschiebt.
aber eigentlich anwendungsfall abhängig :)



Stimme dir voll und ganz zu. Mit einer der Gründe, wieso ein iPhone trotz Dual-Core CPU schneller ist, als ein Android mit nem Quadcore (abgesehen vom OS).

Sorry fürs Offtopic.

B2T:

Ich habe mir fast alles in diesem Thread durchgelesen und frage mich, wofür ihr soooo viel Leistung braucht? Was genau macht ihr mit Eurer DAW? :O

Um die 1000€ CPU von Intel auszulasten, müsste man doch massig Spuren + Inserts haben?

Ich selbst arbeite derzeit mit dem iMac 27" Late 2013 (i5, keine Ahnung welche Gen.) und habe eigentlich keine Probleme. Nur wenn ein Projekt irsinnig groß wird und ich nebenbei Archive entpacke, kommt es beim ersten Abspielen zu einer Unterbrechung.

Was mache ich denn anders? Ich habe auch ca. 5 Inserts pro Kanal. Manchmal mehr, manchmal weniger. Auch wenn ich um die 50 Spuren habe, funktioniert noch alles.

Vielleicht gibt es ja noch etwas, was ich gar nicht kenne? :-D
 
Also ich würde da in diesem Falle ein Board mit dem 2011er Sockel ohne -3 nehmen dann kann man die alte MAudio Delta 1010LT weiterbenutzen.Ja die Gigabytesboards hatte ich für DAWs im Einsatz ist ein sehr Gute Wahl.
 
buffi Super DANKE!!!
mit so einer Hammer Erklärung hab ich echt nicht gerechnet:)

Weißt du zufällig ob windows auch einfluss auf VST Plugins hat (wenn sich nicht hinter einer Bridge laufen) oder kennt Windows nur den Cubase Task und weist diesen dann Rechenzeit zu und Cubase "verteilt" sie dann an die Plugins?

Ich hab mir das MultifaceII zugelegt weil ich bei meinen jetztigen System einen deutlichen performance unterschied zum FF UCX gemerkt habe (wo ich aber anscheinend der einzige bin) und deshlab auf die schnellern wandler und coolerer DSP verzichtet, und habe mir gedacht FW und USB ist PCIe-Karten deshalb unterlegen weil die daten für firewire und USB von Prozessor verpackt werden müssen und dann erst weitergereicht werden und dass das halt soviel Stabilität/Leistung frisst...

Jetzt habe ich gelesen das die Prozessoren für'n X99 Chipsatz PCIe Lanes (oder wie das heißt) haben und das is irgendwie so rüber gekommen als ob das nur für die 16xPCI Karten gilt, nutzt dann meiner RME- 1xPCIe Karte auch diese besagten PCIe Lanes (ich hoffe das heißt so // Direktanbindung an den Prozessor quasi).

Und USB3 soll ja auch irgendwie direkt an diesen Prozessoren dran liegen, gilt das aber auch für USB2?


Bei mir beginnt es meistens zu klippen weil ich zu viele Kanäle habe. Bin mir schon länger der Tatsache bewusst das man nur genug plugins in Serie hängen muss um das System zu überfordern. Hab mir schon ein DualXeonSystem überlegt, was aber eine viel höhere DPC-Latency (was ist das eigentlich) hat als ein Singelsockelsystem und somit ist der Traum zerplatzt. Aber Intel hat meine Gebete erhört und für mich extra ein 8Kern System für einen Sockel entwickelt^^(ich bin schon ziemlich verblendet von diesen 5960x...) Derzeit hat meine DAW einen Q6600@4GHz und die "Singlecore-Leistung" reicht mir "eigentlich" aus um mal das Lied soweit zu gestallte das ich es als Audio exportieren kann (hab da eher die Probleme das die Plugins latenzen verursachen), aber ich will dann immer eine Spur mehr... und dann is wieder vorbei mit der Freude (Arbeite Hauptsächlich mit VSTi und VSTs).


2 Dinge sind für meine Kaufentscheidung wesentlich:

1.) Angenommen man lastet mit einen Kanal nur einen CPU Kern "fast" aus, und dupliziere den Kanal 7x müsste ich unter theoretisch angenommen idealen Bedingungen nicht den ASIO-Puffer raufdrehn...?

2.) DDR4, (auf die hab ich eigentlich gewartet und dann wollt ich's mir mal so richtig gut gehen lassen...[Der eine Kauft sich Chrom-Felgen fürs Auto der andere einen 5960x^^])) sind die nicht in einen halben Jahr um die hälfte billiger (wär ja jetzt nicht so schlimm) aber nicht auch spürbar schneller?



Edit: Mein q6600 lief in Wirklichkeit nur mit den Standarttakt von ca. 2,4GHZ weil die Einstellungen zu extrem waren. Leider wurde die "BIOS Meldung" durch das Bootlogo verdeckt...
 
danke :)
aber wie gesagt für mich ist die bauchtendenz bisher eher richtung 4ghz quadcore ist besser als 3,5ghz 6core.. auch deshalb weil ich mit meiner maschine nicht nur audio mache sondern halt auch zocke ;)


Weißt du zufällig ob windows auch einfluss auf VST Plugins hat (wenn sich nicht hinter einer Bridge laufen) oder kennt Windows nur den Cubase Task und weist diesen dann Rechenzeit zu und Cubase "verteilt" sie dann an die Plugins?

wenn sie nicht als eigener prozess laufen (was du meinst) dann ist das plugin direkt von cubase geladen (normales prozedere mit DLL's)
dementsprechend werden funktionen in der dll im kontext von den threads, die sie aufrufen, ausgeführt.
das heist wiederum, cubase kann selbst entscheiden was für eine prio und kernzuweisung der thread bekommt - und ob es ein dedizierter thread ist oder ein allgemeiner, der alles seriell abarbeitet.
cubase kann sogar weiter gehen und die dll mit der eigenen bridge laden - d.h. es wird ein extra prozess gespawned (threads kann man nur im eigenen adressraum erzeugen -> cubase x64 kann somit nur x64 threads erzeugen - deshalb muss im falle eines 32bit plugins eine extra 32bit exe gestartet werden, die wiederum das plugin lädt)
in dem fall gibt es zusätzlichen overhead - weniger dadurch, daß es eine übesetzung gibt, sondern dadurch, daß die beiden threads (die von cubase und die der bridge) ja irgendwie kommunizieren müssen - und das tun zwei unterschiedliche threads nunmal nicht einfach so.. deshalb wird wohl (reine vermutung) ein gemeinsamer adress space genutzt, wo die VST buffer dann ausgetauscht werden (incl den ganzen VST steuerprotokollen)
und genau da muss synchronisiert werden, weil die zwei threads eben multithreading fähig sind und sonst den speicherbereich "ungeordnet" schreiben/lesen -> gibt sonst datenmüll und crash

um die frage zu beantworten -> es kommt drauf an, wie cubase das plugin lädt bzw funktionen ausführt (mit welchem thread)

bei cubase bin ich mir SEHR sicher, daß es sehr viele threads gibt, die das alles machen :) auch mit unterschiedlichen prios und einer ganz ausgefuchsten synchronisierung usw.. schon wegen asioguard ist die ganze engine sehr komlex und wird so einfach nicht erklärbar sein, wei sie funkioniert.


r firewire und USB von Prozessor verpackt werden müssen und dann erst weitergereicht werden und dass das halt soviel Stabilität/Leistung frisst...

ja im falle firewire und usb gibts da extra treiber, die natürlich wieder ihre zeit zum berechnen brauchen - dazu kommen evtl noch zusätzliche interrupts dafür, die das gesamtsystem "stören"

bei meinem FF UFX habe ich mit latencymon geschaut, ob USB oder Firewire mehr auslastung im treiber verursacht hatte - bei mir war letztendlich USB schneller o_O seitdem lass ichs auf USB rennen ;) (ja ich hab ne gute TI FW karte)

klar gehen deshalb mit den reinen bus-anbindungen des rechners weniger buffer/wege/interrupts/treiber und deshalb sind nochmal ein paar prozentchen leistung machbar, wodurch sich noch schärfere buffersizes ergeben - aber genauso sind es schnelligkeit von ram, gesamtsystem "agilität" - d.h. je weniger onboard sachen auf den bussen "mitlabern" desto weniger hat der rechner zu tun und wird weniger gestört.. desweiteren halte ich "gamer" chipsätze für die besseren DAW chipsätze, da ich schon mehrmals DPC latencychecks gemacht hatte mit serversysteme (einsockel), die schöne dicke xeons hatten.. die waren IMMER irgendwie sehr träge - obwohl sie eigentlich dann trotzdem schnell genug sind in benchmarks.. das meine ich mit agilität -> ram schnelligkeit, ram controller, caches, proz geschw., proz architektur, chipsatz gedöns was noch mitspielen will

das deckt sich mit deiner beobachtung:
Hab mir schon ein DualXeonSystem überlegt, was aber eine viel höhere DPC-Latency (was ist das eigentlich)

am besten so ein richtig übles gamer system mit dem dicksten proz und geilsten ram und gut is (natürlich noch das OS tunen und entschlacken, unnötiges auf dem mainboard abschalten, mainboard tools garnicht erst installieren usw)

wie sich das neue system mit den 6 und 8 core prozzis schlägt wird sich zeigen - benchmarks von cinebench gehen rein auslastungstechnisch in richtung DAW - weil floating point berechnung und multithreading fähigkeit.. also eigentlich genau richtig um zu entscheiden, ob ein proz das richtige für die DAW ist.. aber wie gesagt kommt es auf die anwendung drauf an, ob ich 3,5 Ghz x8 habe oder 4x 4ghz - eben auf die routings im projekt.. theoretisch würde schon alles für mehr kerne sprechen aber da gibts noch viele begleiterscheinungen die dazu kommen und da muss man einfach einen DAW benchmark machen und schauen bis zu welcher belastung die buffer noch rechtzeitig bedient werden.

cinebench teilt das bild in X teile auf und jeder thread kann für sich werkeln ohne schnelle feingranulare synchronisation, die da einen overhead veranlasst

in der daw sieht das komplexer aus und aus meinem gefühl heraus wird das eben höher ausfallen und deshalb mit steigender parallelität auch zu steigenden nebeneffekten durch multithreading synchronisation kommen wodurch die grenze zusätzlich nochmal fällt (zu den fehlenden 500mhz eines cores dazu)

generell kann man aber sagen, daß neue architekturen eher kein schuss in den ofen sind (bei intel zumindest) und jedesmal einen kleinen schub an geschwindigkeit pro ghz dazu gewinnen - rein durch den geänderten / optimierten / erweiterten aufbau des prozessors und anbauteile (chipsatz)

von daher würde ich einen kommenden 6kerner natürlich dem alten 4kern haswell den ich jetzt z.b. noch habe klar vorziehen - aber der dinger ist halt auch schweineteuer :) evtl würd ich sogar den 8kerner nehmen und nochmal gehörig an der ghz schraube drehen damit ich da gleichviel singlethread leistung habe wie mit einem 6core

das wäre dann ne geile kiste :)





Und USB3 soll ja auch irgendwie direkt an diesen Prozessoren dran liegen, gilt das aber auch für USB2?

durch geänderte hardwareanbindungen der USB schnittstellen ändert sich nicht die tatsache, das das OS einen treiber dafür braucht (das protokoll hat sich ja nicht geändert) von daher würde ich aus dem bauch heraus sagen, es wird evtl performancemäßig besser - aber der treiber muss trotzdem werkeln und fällt nicht einfach weg.

Derzeit hat meine DAW einen Q6600@4GHz

der ist wirklich lahmarschig :)

ich hatte den auch mal.. auf 3,5ghz laufen - war im vergleich zum 960iger i7 deutlich langsamer (i7 auf standard takt)
nach dem 960iger (der jetzt mein zweitrechner ist im schlafzimmer) hab ich den 4770K geholt was jetzt meine hauptkiste ist - die rockt schon :) läuft auch auf 4Ghz mit normaler Lukü - hab auch den schnellen 2400er ram spendiert.. ram ist ja bekanntlich ein großer flaschenhals

aber ob ich jetzt von dieser plattform schon auf die neue wechsel glaube ich nicht - eher überspringe ich noch ein oder zwei - weil es reicht einfach was das ding leistet :)

in deinem fall würde ich echt überlegen, auf die neuste plattform zu steigen - ist aber ne reine budget angelegenheit - weil die DDR4 preise sehr hoch sind im vergleich zu hochgezüchteten DDR3 gamer riegel


siehe http://www.pcgameshardware.de/RAM-Hardware-154108/News/DDR4-vs-DDR3-Preisunterschied-1134456/


ich würde da den preisknick prozessor kaufen - also eher den 6kerner weil der 8er mit seinem obligatorischen 1000€ ist eher keine so rationale idee :p aber der ram.. wenn der wirklich in der praxis doppelt so schnell werden kann würde ich klar zum DDR4 greifen und den aufpreis hinblättern

1.) Angenommen man lastet mit einen Kanal nur einen CPU Kern "fast" aus, und dupliziere den Kanal 7x müsste ich unter theoretisch angenommen idealen Bedingungen nicht den ASIO-Puffer raufdrehn...?

theoretisch würde ich sagen, kommt der overhead dazu und macht die rechnung zu nichte - aber mit viel glück wenn noch bisschen platz nach oben ist, kann es reichen - ich glaubs nicht.

wollt ich's mir mal so richtig gut gehen lassen

ich an deiner stelle würde nen gutes gamerboard kaufen (kein workstation gedöns)
sowas wie http://www.gigabyte.de/products/product-page.aspx?pid=5129#ov oder was von ausus.. ist geschmacksache ;) aber MSI würde ich auch nicht empfehlen

den 5930K draufpacken und min 8gb speicher rein hauen

dann vielleicht noch so ne neue M2.5 SSD draufschnallen und das system ist aufgegeilt :)
 
ich an deiner stelle würde nen gutes gamerboard kaufen (kein workstation gedöns)
sowas wie http://www.gigabyte.de/products/product-page.aspx?pid=5129#ov oder was von ausus.. ist geschmacksache zwinker aber MSI würde ich auch nicht empfehlen

den 5930K draufpacken und min 8gb speicher rein hauen

Dann solltest du aber durchrechnen wie viele Lanes du brauchst und falls es reicht den 5820K dem 5930K voziehen. Meines Wissens nach sind die Lanes und der Standarttakt der einzige Unterschied und der Taktunterschied ist ja dank offenem Multiplikator egal/anpassbar.

Edit: Der 5930K ergibt meiner Meinung nach nur für Multi-GPU Systeme sinn, zumindest kann ich mir kein anderes Szenario denken, in dem die Lanes des 5820 nicht reichen. Es sei denn, du belegst alle Slots mit SAS-Controllern und machst ein Riesen SSD RAID :D


Ich bin übrigens auch noch am hadern ob ich mir den 4790K, den 5820K oder den 5960K gönne :D
Anwendungsszenarien: Cubase, After Effects, Premiere, Cinema 4D, Gaming, Code-Kompilierung, VMs, extremes Multitasking. Dafür ergibt der 5960 wenn man das Geld hat auf jedenfall sinn. Für Cubase alleine würde für mich nur der 6-Kerner infrage kommen, da man diesen höher übertakten kann und wie ja schon treffend angemerkt wurde: Singlecoreperformance ist wichtiger als Multicoreperformance
 
man kommt mit dem höher getakteten aber schon nochmal höher denke ich - das war der grund wieso ich den vorschlug.. die lanes sind freilich nicht der grund - ausser man zockt BF4 mit vier x16 grakas
 
hab auch den schnellen 2400er ram spendiert.. ram ist ja bekanntlich ein großer flaschenhals

Hast du hierzu ein Test zu Hand? Als ich mich das letzte mal mit RAM beschäftigt habe, hieß es noch die RAM-Geschwindigkeit sei zu vernachlässigen. Der Test hatte glaube ich aber den Schwerpunkt auf Gaming gelegt. Wenn RAM wirklich wichtig ist für Cubase müsste ein Haswell-E System ein Haswell System bei gleichem Takt und gleicher Kernzahl ja dank Quad Channel schlagen.
 
als entwickler weiß man sowas halt :p da braucht es keine tests

habe aber trotzdem mal schnell gegoogled und dashier gefunden:

"The increased memory bandwidth available with the Overclocked FSB having the most profound effect with not only the inital test but also the Save / Re-open results These results would suggest that memory performance has a far greater impact on overall D.A.W performance than first believed, and is clearly showing that it is directly impacting the ASIO driver / buffer implementation of the respective audio devices, some more than others. Question is, Why ?"

http://www.dawbench.com/blofelds3.htm

auch hier nochmal gut zu sehen, wie sich ram speed durchschlägt:

http://www.adkproaudio.com/benchmarks.cfm

". Little or no improvement is found with Quad core vs dual core.
A faster GHZ dual core will out do a slower quad core for samples playback. DDR3 1600 is better than DDR2 800."

auch hier wieder das thema core skalierung

die hängt von dem ab, was man berechnen lässt (und die benchmarks sind eher nicht REAL WORLD) - aber selbst dort sieht man schon, daß die doppelte anzahl kerne eben nicht doppelt skaliert - und das von daw zu daw unterschiedlich (klar -weil thread synchronisation eben unterschiedlich komplex und effizient implementiert ist)

hier paar schöne benchs die da was zeigen:

http://www.dawbench.com/dawbenchdsp-x-scaling.htm (4 to 8 core)

auf dem letzten screenies sieht man auch schön wie so eine alte sonar daw mit bugs einen core überlastet und sozusagen genau das simuliert, was ich meine mit singlecore problematik - allerdings durch einen bug und nicht durch das -nicht parallelisierbare- single-processing eines routings

die benchs sind halt ziemlich gut auf multithreading ausgelegt (was sie ja auch sollen, da die daw getestet wird und nicht unterschiedliches verhalten bei unterschiedlich vielen cores)
deshalb sind die ergebnisse erstmal klar für mehr cores.

aber wenn man genau hinschaut, nachdenkt, das auf real-world projekte umsetzt, kriegt man da die rosarote brille wieder abgenommen :)

hier noch ein bisschen benchmark der neuen proz
http://www.golem.de/news/intel-core...innt-mit-octacore-und-ddr4-1408-108893-5.html
 
Das "DDR3 1600 is better than DDR2 800" denke ich war zu erwarten, bzw. hoffe dies ist der Fall man erwartet ja im Technikbereich das es mit der Zeit besser und nicht schlechter wird. Aber trotzdem gibts auch wieder Rückschritte, siehe Rambus RAM usw..

Wäre interessant zu wissen wie das genau mit dem Einfluss der RAM im Audiobereich ist. Habe leider nicht alles verstanden auf den von dir verlinkten Seiten. Was ist das Fazit ?

RAM Takt hat definitiv einen allgemeinen Einfluss aber gem. div. Tests lohnt sich halt der Preisaufschlag für Normaluser nicht, nun ist die Frage lohnt er sich für DAW User.

Zusätzlich gibt es bei den RAM noch verschiedene Latency bzw. Timings z.B. CL7-7-7, CL9-9-9 usw..., die mit tieferen Werten sind meist auch teurer, hier stellt sich die gleiche Frage.
 
Wäre interessant zu wissen wie das genau mit dem Einfluss der RAM im Audiobereich ist. Habe leider nicht alles verstanden auf den von dir verlinkten Seiten. Was ist das Fazit ?

ich habe da auch kaum daw benches bezüglich unterschiedlicher ram speeds gefunden..

in wie weit man 3Dmark oder sisoft sandra mit daw last bei ram einfluss vergleichen kann, kann ich nicht sagen. die ergebnisse in diesem bench sind schon sehr unterschiedlich: http://www.legitreviews.com/ddr3-memory-performance-analysis-on-intel-x79_1779

ich würde sagen, daß ramlastige plugins sich eher durch den ram speed beeinflussen lassen, als algorithmen, die sehr gut den L2 cache ausnutzen und kaum mit dem restlichen ram arbeiten müssen..
da wäre mal ein versuch mit großen sample libs mit veränderten ram speeds vs rechenlastige plugins mit veränderten ram speeds ganz angebracht.. vielleicht hat ja jemand die muße dies zu tun :)
 
Es ist sowas von schwierig bis unmöglich immer das beste zu kaufen. Deshalb mache ich es ganz einfach. Meine Kollegen/Freunde kaufen immer wieder mal einen neuen PC (Gamer) und dies meist in dem Preisbereich der auch für mich in Frage kommt. Somit warte ich bis diese zwei bis drei Monate in Betrieb sind und falls die keine Probleme haben kaufe dann genau die selben Komponenten. Dadurch spare ich viel Zeit und habe jemanden mit gleichem System für Tests falls es Probleme gibt.
 
ist ja nicht ganz so von der welt :) in meinem alten rechner hab ich ne wakü
im neuen mit dem 4770K nur ne riesige lukü - hab ihn auf 4ghz laufen ohne vcore anhebung
hab die cpu auch nicht geköpft und der kühler wird kaum laut bei last..
ich muss sagen, das system ist bis auf die graka SEHR leise.. kaum warnehmbar
wenn die halt mal hoch dreht in games, dann ist sie das einzige was ich höre
 

Oft gelesene Themen

Zurück
Oben