32bit vs 64bit

Das Problem ist oft das es eben nicht immer simpel geht. Übrigens was hier steht ist eigentlich schon simpel und jeder Spezi würde wohl bei jedem 2. Satz die Nase rümpfen. Warum soll nicht auch ein Musikerforum den Anspruch haben trotzdem halbwegs fachlich korrekt zu sein?

Manchmal muss man sich auch die Mühe machen und sich ein wenig damit beschäftigen. Von Nix wird Nix. Das geht nur bei RTL.
 
Die meisten verstehen ja auch nicht, das 64 Bit Cubase nicht heist das die Audiodateien in 64Bit FP berechnet werden.

Cubase 6 arbeitet intern bei VST 2 Plugins immer noch mit 32Bit FP .
Es wurde mit VST 3 jedoch die Möglichkeit geschaffen auch intern mit 64Bit FP zu arbeiten.
Jeder sollte sich aber mal klarmachen, das man mit 32 FP (Fliesskomma) eine Dynamik von über 1000dB hat!
Einige denken immer noch das es 32Bit Festkomma -> 192dB sind (16Bit 96dB Dynamik).
 
Jungens!!! Kommt mal wieder runter.

Ich hab zwar von dem ganzen Kram auch keine Ahnung, aber das macht ja nichts. Kann ja mal meinen Senf dazu posten. Ich finde, dass PCs mit grösseren Zahlen schneller sind als PCs mit kleineren Zahlen. Sonst würden das die Hersteller ja nicht verkaufen. Steht auch laufend in der Werbung. 1GHz mehr ist schneller, zwei Kerne sind schneller als 1 Kern. Ausserdem ist 64bit > 32bit und damit ist 64bit auch schneller.

Dann kam irgendwann jemand daher und behauptete allen Ernstes, seine 2.2 GHz CPU von gestern sei schneller als meine 3.4GHz von vor zwei Jahren. Ganz schnell hab ich ihm nen Vogel gezeigt - was für ein Spinner. Tststs.

Zu den Fakten:
1) Ihr alle, die ihr hier so verzweifelt diskutiert, lasst leider ein paar Sachen ausser Acht, die damit die zweifelsfreie Entscheidung, was schneller sei: 64bit oder 32bit, unmöglich machen. Bei vielen Plugins ist es nun mal so, dass die Codebasis für 32bit-Systeme optimiert war. Wenn ich das jetzt schnell mal auf 64bit umschreibe, kann das später je nach meinem programmiertechnischen (Un)-vermögen langsamer, schneller oder eben sogar fast gleich schnell laufen.

2) Rechenauflösung und Systemarchitektur sind zwei völlig verschiedene Dinge. Ich kann auch mit 256 bit Genauigkeit auf 32-bit Systemen rechnen. Alles eine Frage des Algorithmus.

3) Zu den Taktfetischisten: Erklärt mir mal mit eurer Logik, warum eine moderne 2.4 GHz CPU auf einem Core schneller als ein P4 mit 3.6 GHz ist! Das ist er nämlich in der Tat in einigen Anwendungsbereichen! Das ich mit einem Takt soundso viele Daten transportieren KANN, heisst nicht, dass es tatsächlich so abläuft oder SINN macht.

4) Auf dem gleichen PC-System, einmal mit frischem Win7 32bit, ein zweites Mal mit frischem Win7 64bit, auf dem ich ausser Cubase mehrere kommerzielle und Freeware-Plugins in der passenden Architektur ohne Bridge benutzt habe, sind die 64bit Plugins im Durchschnitt 10% langsamer. UND: es gab Ausnahmen, die auf dem 64bit-System schneller waren.
 
Grundsätzlich sind mMn derartige Diskussionen in Foren ohnedies sinnlos, denn man kann sich ( wie tgud es gut tut :D ) nur auf eigene Erfahrungen in der eigenen Umgebung wirklich verlassen.

Es wird i.a. weder sonderlich tiefschürfend, noch nachvollziehbar, noch für die meisten Leser nachvollziehbar... von den allermeisten Posts könnte man in einem direkten Gespräch so gut wie bei jeder Zeile nachhaken, techn, fachlich, philosophisch u praktisch betrachtet. Manches ist schlichter Unsinn. Mir persönlich ist es meistens zu mühsam, da wirklich ins Detail zu gehen ( wtff ? ) ...

Andererseits leben Foren u.a. von derartigen Diskussionen, den daraus entstehenden Mythen

NiceDay

lg
Andi
 
Jungens!!! Kommt mal wieder runter.

Ich hab zwar von dem ganzen Kram auch keine Ahnung, aber....

Genau das ist das Problem. Übrigens nicht nur von dir. Kompliziert werden Dinge häufig gerade deswegen, weil man Halbwissen oder Nichtwissen vermischt und dadurch das Ganze nach und nach undurchdringlich wird. Dann kommt immer das Totschlagargument: Mir ist das zu hoch - ich will es simpel. Ja liebe Leute: Ein klein wenig Selbstständigkeit kann man doch voraussetzen oder?

Würde man die Zeit in der man ständig Halbwissen transportiert einfach mal daran setzen die Dinge richtig zu verstehen, wäre das Resultat erstaunlich einfach und verständlich. Der Weg dahin ist manchmal vielleicht mühsam und langweilig - aber: Was will ich denn mit einer Frage erreichen? Wenn man nur beantwortet haben will was man eh schon kennt braucht es die Frage nicht.

Im Gegensatz zu anthe finde ich schon dass sich eine theoretische Betrachtung lohnt. Es ist ja gerade wichtig zu verstehen warum ein Ergebnis so vorliegt wie es vorliegt und nicht nur dass man es hat. Eine Beobachtung zu interpretieren ohne Hintergrundwissen nennt man übrigens auch nicht Interpretation sondern Raten. Für das erste gibt es in der Schule meist eine gute Note, für das zweite einen Ratefuchs.
 
@ jojoon

Erklärt mir mal mit eurer Logik, warum eine moderne 2.4 GHz CPU auf einem Core schneller als ein P4 mit 3.6 GHz ist!
Naja.
Also mit solchen Anwandlungen wirds auch keine Klärungen geben.
Das ist die gleiche Argumentation, mit der seinerzeit die PowerPC-Fetischisten den PC-Freaks das fürchten lehren wollten und davor die Motorola-Freaks gegen die Schlipsträger von IBM und deren CPU-Architektur argumentiert haben.

So wischiwaschi wie Deine Frage wird auch die Antwort ausfallen, und ist damit dann auch genauso wenig wert - ist halt wischiwaschi.
Oder willst du vielleicht selber erklären, warum das, was Du behauptest, so ist, wie es zu sein scheint?
Bin gespannt....... :D
 
@doktorbeil: Du hast die Ironie in meinem vorherigen post nicht verstanden!

Ich bin Programmierer im Bereich der digitalen Bild- und Signalverarbeitung. Ich habe genug Ahnung um dir zu sagen, dass die Geschwindigkeitsunterschiede zwischen 32bit und 64bit-Systemen nicht durch einfache Betrachtung der Busarchitektur und Zählen von CPU-Zyklen abgeleitet werden können. Frag die Entwickler lieber ab und zu mal, ob sie nicht mal wieder ein Code-refactoring machen wollen. Das bringt oft mehr. Jetzt können wir anfangen über Heaps und Stacks und Registerbefehle philosophieren, haben damit aber mit Sicherheit die meisten Recording.de-user abgehängt.

Fazit: eine tiefergehende theoretische Betrachtung lohnt sich hier nicht, weil die Zeit dafür besser zum Musik machen aufgehoben ist. Erstens macht Erfahrung klüger und zweitens wird der Wandel zu 64bit-Audioworkstations gerade vollzogen. Ob man will oder nicht, kommt man bei Neuanschaffungen, die zukunftstauglich sein sollen, nicht mehr um 64bit herum. Warum also der heisse Dampf? Ich nehme leichte Performanceeinbussen für ein System mit der Möglichkeit mehr Speicher zu adressieren in Kauf. Und meine ASIO-Latenzen haben beim Wechsel zu Win7/64 nicht gelitten.
 
Und meine ASIO-Latenzen haben beim Wechsel zu Win7/64 nicht gelitten.

Ist bei mir auch so. Deshalb verstehe ich auch die Argumente derer nicht, die meinen, auf 64Bit sei die Ausführungsgeschwindigkeit deutlich langsamer. Auch die Belastung der CPU ist nicht wirklich höher. Aber ich werde demnächst mal ein paar kleine Benchmarks mit umfangreicheren Projekten starten.
 
Zu den Taktfetischisten: Erklärt mir mal mit eurer Logik, warum eine moderne 2.4 GHz CPU auf einem Core schneller als ein P4 mit 3.6 GHz ist! Das ist er nämlich in der Tat in einigen Anwendungsbereichen! Das ich mit einem Takt soundso viele Daten transportieren KANN, heisst nicht, dass es tatsächlich so abläuft oder SINN macht.

siehe http://de.wikipedia.org/wiki/Floating_Point_Operations_Per_Second

"Die Anzahl der Gleitkommaoperationen ist nicht notwendigerweise direkt zur Taktgeschwindigkeit des Prozessors proportional, da – je nach Implementierung – Gleitkommaoperationen unterschiedlich viele Taktzyklen benötigen."

wenn du es noch genauer wissen willst musst du dir z.b. die intel specs angucken wieviel takte welche befehle brauchen
dann musst du dich mit der softwareimplementierung (und evtl compiler optimisations) auseinander setzen und gucken ob da gleichheit für verschiedene architekturen vorherrscht und nicht auf zusätzliche befehlssätze zugegriffen wird..

dann hast du deine frage selbst beantwortet - oder es reicht dir halt der satz aus wikipedia der eigentlich alles beschreibt.

man beachte auch die Gflops tabelle weiter unten - da ist der 4 core i7 halt nicht "nur" 4 mal schneller als der P4 ;)

das ist natürlich nur ein beispiel für die FP berechnung - integer is wieder eine andere baustelle
bis auf protools (alt) wird ja in modernen daws FP berechnet - so auch wie in meiner daw - ich hab meine live-daw-engine übrigends nur mit 32bit programmiert - das reicht mir aus ;)

//edit
was ich gerade gefunden hab:
http://pvs.uni-muenster.de/pvs/lehre/SS11/mgpp/folien/mgpp-uebung2.pdf

ist sehr hilfreich um das zu verstehen wieso verschiedene architekturen verschieden schnell berechnen
 
@ jojoon

Sorry die Ironie aus deinem Beitrag hab ich nicht wirklich herauslesen können. Das kann ich ehrlich gesagt auch auf den zweiten Blick nicht. Ist aber auch egal.

Es geht nicht darum zu beweisen welch akademischer Grad hinter einem steckt - noch soll hier eine Diskussion damit enden dass man sich mit aus Wikipedia abgeschriebenen Fremdwörtern überbietet. Was tatsächlich wahr ist kann im Dunst der Anonymität des Internets sowieso keiner nachprüfen und schützt zudem auch vor Falschaussagen nicht. Ergo: Es ist vollkommen egal wer sich hinter einem Schreiber verbirgt. Ich finde es zudem auch irgendwie seltsam dass, wenn irgendwann die eigene Argumentationskraft nicht mehr reicht, plötzlich ein angeblicher Bildungsstand zur Rechtfertigung zweckentfremdet wird. Mir wäre das jedenfalls eher peinlich. Nun ja - soll jeder für sich selbst entscheiden.
 
man beachte auch die Gflops tabelle weiter unten - da ist der 4 core i7 halt nicht "nur" 4 mal schneller als der P4
Besonders interessant finde ich den Vergleich von Pentium 4, 3,2 GHz zum IItanium, 1,6 GHz: Gleiche Höchstleistung, aber doppelte Durchschnittsleistung beim Itanium - und das bei halber Taktfrequenz........

Da erkennt man nur zu deutlich, dass einfache Zahlenvergleiche kaum wirklich Sinn machen.
 
[ref=[URL]https://recording.de/Community/Forum/Sequencer/Cubase_und_Nuendo/158703/Post_1669820.html#105]doktorbeil[/URL] schrieb in #105: [/r.

Im Gegensatz zu anthe finde ich schon dass sich eine theoretische Betrachtung lohnt. Es ist ja gerade wichtig zu verstehen warum ein Ergebnis so vorliegt wie es vorliegt und nicht nur dass man es hat. Eine Beobachtung zu interpretieren ohne Hintergrundwissen nennt man übrigens auch nichttu Interpretation sondern Raten. Für das erste gibt es in der Schule meist eine gute Note, für das zweite einen Ratefuchs.


Wie meistens redet man schriftlich anonym im Inet nur allzu leicht aneinander vorbei. Das einzig Sinnvolle, dass Du einem reinen User erklaeren kannst ist, dass die allermeisten Dinge nicht so einfach sind, wie sie oft scheinen. Die theoretische Betrachtung wovon denn? Hat jetzt was genau ergeben? Selbst Du als Fachkundiger, aber dennoch nicht in diesem Bereich Arbeitender? bzw Erfahrung habender kannst keine wirklich 100% Aussage zur Frage X geben, oder? Ich selbst bedaure so gut wie jeden Mist, den ich so ablasse, kurz nach dem Absenden des Posts, weil so gut wie alles so o so auagelegt werden kann... B*Baeume balancieren ist ein Kinderspiel dagegen. ...
 
@doktorbeil:

Ich finde es zudem auch irgendwie seltsam dass, wenn irgendwann die eigene Argumentationskraft nicht mehr reicht, plötzlich ein angeblicher Bildungsstand zur Rechtfertigung zweckentfremdet wird.

Das sollte dir nur helfen den ersten Teil meines Posts (das vor "Zu den Fakten:") als Ironie wahrzunehmen.

Was tatsächlich wahr ist kann im Dunst der Anonymität des Internets sowieso keiner nachprüfen und schützt zudem auch vor Falschaussagen nicht. Ergo: Es ist vollkommen egal wer sich hinter einem Schreiber verbirgt.

Interessante Sichtweise mit dramatischer Konsequenz. Was von dem, was du im Internet zu lesen bekommst, glaubst du denn dann? Nichts? Warum ziehst du es dann als Wissensquelle heran?
Und nebenbei, würde ich dir meinen Realnamen, Adresse und Lebenslauf zusenden, würdest du meine Aussagen dann als vertrauenserweckender erachten ? Und viel wichtiger:

Aber ja, im Internet ist es ja leicht etwas abzutun, weil man anderer Meinung ist. Da geht man auch leicht über einen Kommentar zu Bildungshintergrund/Expertise hinweg, den man im realen Leben vielleicht doch ernster nehmen muss/sollte, um nicht einen unnötigen Gesichtsverlust zu riskieren.

Wenn du die Möglichkeit hast in EINEM Taktzyklus ZWEI 32bittige Daten mit EINEM 64bittigen Datenwort zu transportieren braucht es doch dann nur die Hälfte an Zeit im Vergleich zu ZWEI notwendigen 32bittigen Datenwörtern welche die Daten in ZWEI Taktzyklen transportieren würden. Die Zykluszeit ist ja konstant weil dein Prozessor sowohl im 32bittigen wie auch im 64bittigen System den gleichen Takt hat.

Da du ja auch einen Anspruch auf darauf stellst, Wissen zu verbreiten, stelle ich dir mal diese Tabelle (ja, auch aus dem Internet) zur freien Interpretation der Rechenzeit von 64bit und 32bit Systemen zurVerfügung:
http://www.iinuu.eu/en/it-guru/windows-7-32-vs-64-bit-performance-benchmark

Wiewohl ich darauf hinweisen muss, dass auch diese Testumgebung nicht wohldefiniert ist und somit nur eine Tendenz aufzeigt. Es kommt eben IMMER auf die Implementation des Programmcodes an.
 
Ich habe gerade mal einen Vergleich von Cubase auf einem Intel Mac Core2Duo mit 2.8 GHz und 8 GB RAM gemacht.


Der Cubase Song besteht aus nativen 64 Bit Instrumenten (1x HalionSonic SE, 7x Retrologue, 1x Padshop, 1x GrooveAgentOne und 8 Audiospuren mit nativen 64-Bit Effekten (EQ, Dynamics, Hall, Delay, DeEsser, PitchCorrect und VariAudio-Echtzeit).

Cubase 32 Bit: RAM Auslastung: 800 MB (gemittelt)
Cubase 64 Bit: RAM Auslastung: 840 MB (gemittelt) + 220 MB RAM für die BridgeApp, die immer aktiv ist.

Die ASIO-Auslastung (Wiedergabe über die Mac-interne Soundkate bei einer Latenz von 512 Samples) an gleicher Stelle "abfotografiert:


cubit.png
 
Na tsching, wenn du dafür nicht von den Steinis ge"steinigt" wirst, weiss ich es auch nicht... ;-)

Aber finde es höchst interessant, das es beim Mac nicht anders ist wie beim PC....
 
@ jojoon

Fazit: eine tiefergehende theoretische Betrachtung lohnt sich hier nicht, weil die Zeit dafür besser zum Musik machen aufgehoben ist.
Würde mich dann aber schonmal interessieren, wieso Du dann hier im Thread auftrittst? Ich mein, nichts gegen die Informationen und das Wissen, was Du vermittelst.

Aber wieso machst du das dann eigentlich, wenn doch
tiefergehende theoretische Betrachtung lohnt sich hier nicht, weil die Zeit dafür besser zum Musik machen aufgehoben ist.
??, zumal Deine penetrante Attitüde, von oben herab der Welt zu erklären, was sie tun soll, nicht dafür spricht, dass Du selber zu Deinem Fazit stehst.
 
@ Beatback

das es beim Mac nicht anders ist wie beim PC....
Warum sollte es?
Die beiden sind sich doch technisch gesehen mittlerweile so unähnlich ja gerade mal nicht...... :D
 
Na tsching, wenn du dafür nicht von den Steinis ge"steinigt" wirst weiss ich es auch nicht... ;-)
Das wissen die doch selber, dass das so ist. Interessant ist übrigens die RAM-Auslastung eines kompletten Songs. selbst, wenn ich noch Samplelibraries hinzufüge, komme ich oft niemals über 2 GB Gesamt-RAM-Auslastung. Also ist die besten Empfehlung im Moment: Cubase 32 Bit in einer 64-Bit-Betriebsystemumgebung (dann kann jedes Programm nämlich bis zu 4GB RAM nutzen).
 
Die beiden sind sich doch technisch gesehen mittlerweile so unähnlich ja gerade mal nicht...... Lachen
Schon klar, aber der Programmcode könnte ja doch recht unterschiedlich sein, da es zwei unterschiedliche Teams (PC/MAC) gibt.
 
Das wissen die doch selber, dass das so ist. Interessant ist übrigens die RAM-Auslastung eines kompletten Songs. selbst, wenn ich noch Samplelibraries hinzufüge, komme ich oft niemals über 2 GB Gesamt-RAM-Auslastung. Also ist die besten Empfehlung im Moment: Cubase 32 Bit in einer 64-Bit-Betriebsystemumgebung (dann kann jedes Programm nämlich bis zu 4GB RAM nutzen).
Gut, das auch mal von dir als Cubaseexperten zu hören.
Ich bin aber schon in die Bredouille gekommen und brauchte bei einem Orchesterarrangement 6GB Ram (Cubase.exe und der Auxhost.exe von JBridge).
In dem Fall hatte ich dann mit jBridge Kontakt 5, die HSO und Addictive Drums für die Cubase 6 32Bit gebridged.

Mit jBridge hast du dann jedes Plugin als eine Extraanwendung mit der Auxhost.exe laufen.
D.h. jede Kontak/Halion/AD Instanz kann für sich 4GB vom Ram beanspruchen.
Du kannst sogar die 64 Bit Version von Kontakt 5 für die 32Bit Cubase Bridgen und damit dann den vollen Ram pro VSTi Instanz ausnutzen.

Bei einem umfangreichen Orchesterarrangement bekommt man einen I7 ganz schnell in die Knie.
 

Ähnliche Themen

moonbooter
    • Danke
  • Artikel
Antworten
4
Aufrufe
2K
A
moonbooter
    • Danke
  • Artikel
Testberichte Test: Eventide H9 Max
Antworten
2
Aufrufe
1K
BassExplorer
B
moonbooter
    • Danke
  • Artikel
Antworten
2
Aufrufe
3K
joit
J
RECORDING-Redaktion
  • Artikel
Antworten
4
Aufrufe
3K

Zurück
Oben