Wird AMD permanent gegenüber Intel in Reviews benachteiligt? Bitte ersten post lesen

Status
Für weitere Antworten geschlossen.
Ja schlapp in einigen punkten bezüglich recording gebe ich dir recht aber ich weiß ja nicht was du o. ihr unter ner guten soundkarte versteht.
Siehe z.b diese hier

http://www.musikland-online.de/onlineshop_harcom3020211823_RME-HDSP-9652-Hammerfall.html

null% cpu last und hardware gegossener Asio2.0 treiber so ziemlich das schnellste was es gibt mit ner fetten wd raptor im rücken und corsair DDD3 2133Mhz hmmm und nem
q9650 geht schon was.

ach undertaker was schlapp sagen will ist wenn du digitale-beats mit selbst eingespielten instrumenten arrangierst wirst du merken was latenzen sind und da zählt jede nanosek. weniger. Am besten die latenz ist gleich null aber leider nicht machbar,
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Und ich will nur darlegen, dass genau solche Latenzen durch die Berechnungen und damit in Abhängigkeit der CPU-Power entstehen, nicht aber durch Ramlatenzen ;) Denn nocheinmal, die bewegen sich in ganz anderen Größenordnungen - ob nun 50 oder 60ns Zugriffszeit bestehen ist so ziemlich irrelevant, wenn beispielsweise 100MHz mehr CPU-Power schon 1ms (=1000000ns) weniger erzeugen würden ;)
 
@undertaker das mag für ein normales user/gamer- system zutreffend sein.
Aber ein profi studiorechner kennt die latenz über den cache bzw der cpu nicht.
Da sind beim mastern oder bearbeiten von echtzeiteffekten die leistung der cpu zwar wieder gefragt aber nicht beim recording. Da ist es eher der speicher und die festplatte wie schnell die zugreifen können.
Weil die signale direkt in der mpu verarbeitet werden und diese soundkarten sind auch schon mal mit eigenem ram ausgestattet.

hier eine andere variante der karte
http://rme-audio.de/old/hammer/d9636.htm
 
Zuletzt bearbeitet:
Nun, dann hoffen wir doch mal das auch ein C2Q Besitzer das gleiche laufen lässt :) Wie man sieht ist das eine reine Frage der Priorisierung, Cinema4D kann z.B. auch einzeln schon alle 4 Kerne praktisch komplett auslasten, führt aber dennoch zu keinem Einbruch bei WiC - was bedeutet, das der Scheduler hier dem Spiel die höchste Priorität zuweist und danach die restlichen Ressourcen an C4D verteilt. Die Einbrüche bei Nero sind verständlich, Slowdowns durch Festplattenzugriffe werden für mich immer ein Grund bleiben, zumindest bei Spielen wie Onlineshootern auf solcherlei Hintergrundanwendungen generell zu verzichten.
Nein, es ist keine "reine Frage der Priorisierung" sondern eher eine Frage der Verteilung. Es reicht eigentlich 2 Kerne dem Game und 2 dem "LastTeil" zu zuweisen.
Dies hat aber nichts mit "Priorität" zu tun!
Die schlechten Werte von WiC kann ich mir nur mit der Demo (nachladen) an sich erklären. ETQW, UT3; BF2 usw machen diesbezüglich keine Probleme im Onlinemodus.
Und wie ich schnmal sagte, mit dem Phenom gehts, mit dem Q6600 ging es nicht.

Ich habe 4 * 500GB Platten im System (je 16MB Cache) und selbst dies hat dem Q6600 nicht geholfen.
 
Das ist eine deutlich schlechtere Lösung, da du so unter Umständen massiv Leistung verschenkst - gerade bei neueren Spielen, wo weitere Kerne häufig für Spezialaufgaben wie Partikeleffekte genutzt werden, wirst du speziell an fordernden Stellen deutlich weniger FPS haben, während bei einem Weg über die Priorisierung hier kurzzeitig Leistung vom Encoder oder Renderer im Hintergrund abgezweigt werden kann - kommt dies nur ab und an vor, werden die kaum länger rechnen müssen, deine min-fps aber weitaus besser sein.

Das dein beschriebenes Problem keines der CPU, sondern deiner spezifischen Einstellungen sein muss zeigen andere Nutzer.
 
Das ist eine deutlich schlechtere Lösung, da du so unter Umständen massiv Leistung verschenkst - gerade bei neueren Spielen, wo weitere Kerne häufig für Spezialaufgaben wie Partikeleffekte genutzt werden, wirst du speziell an fordernden Stellen deutlich weniger FPS haben, während bei einem Weg über die Priorisierung hier kurzzeitig Leistung vom Encoder oder Renderer im Hintergrund abgezweigt werden kann - kommt dies nur ab und an vor, werden die kaum länger rechnen müssen, deine min-fps aber weitaus besser sein.

Das dein beschriebenes Problem keines der CPU, sondern deiner spezifischen Einstellungen sein muss zeigen andere Nutzer.
Welche Nutzer zeigen das denn zum Beispiel. Und hast du nun auch mal Tests mit handfesten Fakten, um die hier beschriebenen Usererfahrungen widerlegen zu können?
 
Also wenn ihr wollt kann ich gern mal meinen fast 2 Jahre alten Q6600 gegen einen neuen 9950 antreten lassen.
Zum Spielen ist meine Grafikkarte aber eher ungeeignet.
 
Wird nicht viel bringen mit der Graka. Es gilt ja folgende Aussage nachzuvollziehen:

schlapp schrieb:
Wenn man einen 4Kerner auch als 4Kerner einsetzt, also zB Ut3 mit realen Settings! (also NICHT 1024*768 oder so) spielt UND dabei die anderen 2Kerne (die selbst bei UT3 kaum vorteile bringen) mit zB Raytracer auslastet (auch den Memory Controller!), dann hat ein Intel Quad keine chance gegen nen Phenom.
Ich hatte selbst einen Q6600 und habe ihne gegen einen Phenom aus genau dem grund ausgetauscht. (Eigentlich war unter diesen Bedingungen an spielen nicht mehr zu denken. *ruckel* *ruckel*)
 
Gibt ne Betaversion der Demo: Klick

Ich kann mir schon vorstellen, das der Intelquad da ab und zu in die Knie geht. Denk dran, da geht alles über den FSB. Die Kerne kommunizeren über den FSB, der Speicher wird über den FSB angesprochen und die Kommunikation mit der Grafikkarte und den restlichen Komponenten geht über den FSB.
 
Okay und was soll ich dazu verwenden (falls ich das Spiel auf der Quadro zum laufen bringe)
Cinema4D und 3DSmax hätt ich schon installiert die anderen installierten Renderer gehen eher auf die Karte als auf die CPU.
Oder doch was anderes?
 
C4D wäre ganz gut. Das das sofern die GPU reicht problemlos klappen wird kann ich dir aber auch jetzt schon sagen, denn das geht sogar schon mit einem C2D - nur hat hier eben jede Anwendung nur die Hälfte der Ressourcen zur Verfügung, was die Gesammtleistung halbiert aber dennoch ein ruckfreies Spiel ermöglicht :) Und das unabhängig davon, ob man Kerne fest zuweist oder nicht :)
 
Zuletzt bearbeitet:
Nur Geduld, bin eh schon am Demo laden...
Also wenn's geht probier ich mal folgendes:
1) Spiel und Cinema gleichzeitig ohne das ich dem System was vorschreibe.
2)priorität vom Cinema auf niedrig.
3)jeweils 2 Kerne pro Anwendung zuweisen.

Ist das ausreichend für euch?
Mit so schönen FPS Balken kann ich euch leider nicht dienen.
Will ja mein Arbeitsgerät nicht zu sehr mit unnötigem Schrott zumüllen.
 
Hmm Undertaker 1 hat immernoch nicht verstanden, das es nicht darum geht bei einem Dualcore 2 Kerne mit dem Rendern zu belasten und dann flüssig spielen zu wollen. :rolleyes:

Am besten du schaust dir mal an, welche FPS(am besten mit Fraps) du ohne zusätzlich Anwendung hast. Dann suchst du dir ein schönes Projekt zum Rendern raus(nicht den Standardbenchmark) und lässt das so ablaufen wie du es schon vorgeschlagen hast. Wichtig ist, dass das Rendern die Kerne richtig auslastet und wie schlapp bereits schrieb ordentlich Zugriffe auf den RAM verursacht.

Interessant wäre es, ob es einen Unterschied gibt wenn du Kern 0+1 und Kern 2+3 bzw. Kern 1+2 und Kern 0+3 den Anwendungen zuweist
 
Ich hätte da noch eine Frage:
hat das Spiel irgendwie ein Fps Limit?
Ich komm nie über 32Fps.
Auch nicht wenn ich die Auflösung auf 1680x1050 runter stelle.
Oder liegt das am Treiber für die Quadro?
 
C4D wäre ganz gut. Das das sofern die GPU reicht problemlos klappen wird kann ich dir aber auch jetzt schon sagen, denn das geht sogar schon mit einem C2D - nur hat hier eben jede Anwendung nur die Hälfte der Ressourcen zur Verfügung, was die Gesammtleistung halbiert aber dennoch ein ruckfreies Spiel ermöglicht :) Und das unabhängig davon, ob man Kerne fest zuweist oder nicht :)

Sorry, aber man kann mit dir nicht Diskutieren. Es bringt einfach nichts.
 
Ich hätte da noch eine Frage:
hat das Spiel irgendwie ein Fps Limit?
Ich komm nie über 32Fps.
Auch nicht wenn ich die Auflösung auf 1680x1050 runter stelle.
Oder liegt das am Treiber für die Quadro?



Stell doch noch mehr runter die Auflösung. Ansonsten würde ich vorschlagen was einfacheres zu probieren wie Aquamark.
 
Sorry, aber man kann mit dir nicht Diskutieren. Es bringt einfach nichts.

Dann war dein Post eben wohl überflüssig? Fakt ist, dass von dir beschriebene "Ruckler" nichts mit der CPU-Architektur zu schaffen haben, überlastete Bussysteme würden grundsätzlich zu schlicht geringerer Gesammtperformance führen. Das aber noch nichteinmal dies der Fall ist erkennst du an mehreren Stellen, z.B. tadelloser Performance bei Programmen mit Vollauslastung aller 4 Kerne. Es ist unbedeutend, ob du einen Quadcore nun mit 4 Programmen zu je einem Thread oder einem Programm zu je 4 Threads auslastest.
 
Dann war dein Post eben wohl überflüssig? Fakt ist, dass von dir beschriebene "Ruckler" nichts mit der CPU-Architektur zu schaffen haben, überlastete Bussysteme würden grundsätzlich zu schlicht geringerer Gesammtperformance führen.
An welchen Fakten machst du dies fest? Ein durch hohe Last überforderter FSB kann die Daten möglicherweise nicht rechtzeitig liefern, was dann logischerweise zu Aussetzern(->Rucklern) führt.

Das aber noch nichteinmal dies der Fall ist erkennst du an mehreren Stellen, z.B. tadelloser Performance bei Programmen mit Vollauslastung aller 4 Kerne. Es ist unbedeutend, ob du einen Quadcore nun mit 4 Programmen zu je einem Thread oder einem Programm zu je 4 Threads auslastest.
Hast du da zufällig einen Test mit harten Fakten zur Hand, oder saugst du dir das aus den Fingern weil es in deine Argumentation passt?
 
Zuletzt bearbeitet:
Dann war dein Post eben wohl überflüssig? Fakt ist, dass von dir beschriebene "Ruckler" nichts mit der CPU-Architektur zu schaffen haben, überlastete Bussysteme würden grundsätzlich zu schlicht geringerer Gesammtperformance führen. Das aber noch nichteinmal dies der Fall ist erkennst du an mehreren Stellen, z.B. tadelloser Performance bei Programmen mit Vollauslastung aller 4 Kerne. Es ist unbedeutend, ob du einen Quadcore nun mit 4 Programmen zu je einem Thread oder einem Programm zu je 4 Threads auslastest.

Hmm, warum kann ich mit dir wohl nicht wirklich Diskutieren?
Im gegensatz zu dir rede ich nicht nur darüber sondern mache viel Soundbearbeitung, Raytracing, Filme Konvertierungrung usw usw
 
Okay, ich hab da mal ein wenig rumprobiert.

1) Wenn beides auf Autopriorität läuft hab ich ab und zu kleine Einbrüche auf 52 Fps (normal 62) und Cinema braucht 5min 32sec
2) Durchgehend 62 Fps bei Cinema auf Priorität niedrig (cinema Zeit 6min 04 sec)
3) Core 0+1 UT3 (62 Fps) Core 2+3 Cinema (8min 54sec)
4) Core 0+2 UT3 (62 FPS) Core 1+3 Cinema (9min 01sec)

Kann aber nicht Sagen wie es mit einer richtigen Gaming Grafikkarte ausschauen würde.
Meine ist ja eher nicht dafür gedacht.
Ramauslastung war jeweils bei ca. 7,8GB.

Edit: Auflösung 1280*1024
 
Okay, ich hab da mal ein wenig rumprobiert.

1) Wenn beides auf Autopriorität läuft hab ich ab und zu kleine Einbrüche auf 52 Fps (normal 62) und Cinema braucht 5min 32sec
2) Durchgehend 62 Fps bei Cinema auf Priorität niedrig (cinema Zeit 6min 04 sec)
3) Core 0+1 UT3 (62 Fps) Core 2+3 Cinema (8min 54sec)
4) Core 0+2 UT3 (62 FPS) Core 1+3 Cinema (9min 01sec)

Kann aber nicht Sagen wie es mit einer richtigen Gaming Grafikkarte ausschauen würde.
Meine ist ja eher nicht dafür gedacht.
Ramauslastung war jeweils bei ca. 7,8GB.

Edit: Auflösung 1280*1024
FPS-Cap/Limit von 62 FPS aufheben.
A: In der UTEngine.ini unter [Engine.GameEngine] den Eintrag
bSmoothFrameRate=True
in
bSmoothFrameRate=False
ändern.

oder den Maximalwert erhöhen, indem man folgende Einstellung anpasst:
MinSmoothedFrameRate=22
MaxSmoothedFrameRate=62
und dort die 62 durch die maximal gewünschte Framerate ersetzt.

viel spaß.
;)
 
@hydrotoxin
Sorry aber ich mach dan ganzen Kram jetzt nicht nochmal.
Ich muß nebenbei noch was Produktives abliefern :shot:
Auch wenn's nervt.
 
Also zusammenfassend: Definitiv keine ruckhaften Totaleinbrüche? Besten Dank, das bestätigt alles was ich sagte :)

Ürigens sieht man auch sehr schön, wie nachteilig es ist, die Cores fest zuzuweisen - kostet nur sinnlos Leistung.
 
Nur kleine Framedrops bei gleicher Priorität (Normal). Egal welche Kerne grad rechnen.
 
Also zusammenfassend: Definitiv keine ruckhaften Totaleinbrüche? Besten Dank, das bestätigt alles was ich sagte :)
Nunja, da ist wohl eher das Gegenteil der Fall. Schon mit dieser schwachen Grafikkarte und dementsprechend niedrigen Einstellungen gibts Einbrüche. Wie das bei hohen Einstellungen für das Game dann aussieht kannst du dir ja denken...ähh ignorieren ;)

Ürigens sieht man auch sehr schön, wie nachteilig es ist, die Cores fest zuzuweisen - kostet nur sinnlos Leistung.
Fürs Spiel scheints ideal zu sein.
 
Ich kann che_new nur zustimmen.
Das kannst du einfach nicht schlussfolgern bei fps limit durch die engine:stupid:
Ignoranz?

Schlapp sprach von stetigem Ruckeln - und das ist nun offensichtlich wiederlegt ;) Ich habs seit Anbeginn gepredigt, das ist schlicht eine Sache bzgl. der Priorisierung, was parallel alles nutzbar ist. Beste FPS und denoch eine schnelle Renderzeit gabs wie bei ihm zu sehen schon mit einer niedrigeren Priorität für C4D, aber selbst ohne dies fielen die FPS nicht unter 50 :)
 
Zuletzt bearbeitet:
Nunja, da ist wohl eher das Gegenteil der Fall. Schon mit dieser schwachen Grafikkarte und dementsprechend niedrigen Einstellungen gibts Einbrüche. Wie das bei hohen Einstellungen für das Game dann aussieht kannst du dir ja denken...ähh ignorieren ;)

Schwach ist die Karte wohl nicht grade...
Für alle die die Karte nicht kennen: KLICK MICH ICH BIN EIN LINK
Sie ist eben nur ungeeignet für Spiele -> Workstationkarte
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh