Bronies.de

Ein FX8320 hat ein wenig weniger Singlethread Leistung als ein Phenom 980.
Im Mulitcore kommt er auf die Leistung des 4460, wenn er denn alle 8 Threads ausspielen kann, was meist nicht der fall ist.

Der 965er ist ziemlich lahm. In Kombination mit einer 7750 merkt das nicht aber bei starken Grafikkarten kommt die Cpu nicht mehr mit.
Mit X4 965 + r9 390 ist flüssiges Spielen natürlich möglich aber die Gpu wird dann oft ausgebremst auf höheren Einstellungen und bei manchen Spielen hat man vielleicht große Probleme.

Aber ja die Grafikkarte sollte zuerst geupradet werden. Das ist klar.

Es gab mal einen Test dazu, wann limitiert was, ist schon etwas her, aber eine GTX570 bzw. 6970 ging noch, danach fängt die CPU an zu limitieren.

Kommt sicher auch das Spiel an, aber sinnig eine 390 oder Fury bzw. 970 oder 980 mit einem Phenom zusammen zu packen ist es sicher nicht.

(19.11.2015)elitecat schrieb: [ -> ]Wenn er lieber Amd mag dann lasst ihn doch.  

Die nächste cpu wurd auch bei mir ein amd werden entweder kriege nen fx prozessor ne 8 kerner  vom kollegen günstig oder hohle mit die neuen die raus komme wird. Aber die grafikarte ist mir wichtiger da muss ne neue her. Bin froh das diese ark schafft auf mittel ^^

Es geht aber doch darum das beste Preis/Leistungsverhältnis auszunutzen. Da gibt es momentan nicht wirklich viel mit Präferenzen.

Mag sein, dass die FX ausreichend sind, aber wenn man wirklich die maximale Leistung für den gleichen Preis haben will, sollte man sich einen Intel holen.

Das Argument mit Intel's Preispolitik halte ich für unsinnig, da
1. der eine nicht-kauf garantiert nichts daran ändern wird und
2. die Preise der Prozessoren in den letzten Jahren doch sehr stabil geblieben sind.

Ich beginne mich langsam auch etwas darüber zu ärgern, anstelle des FX-8350, den ich vor einem Jahr gekauft habe, nicht lieber zu einem etwas teureren Core i5-4670k gegriffen zu haben. Wohl extrem limitiertes Budget...

Jedenfalls würde ich zurzeit niemandem einen AMD-Prozessor empfehlen.

Nvidia unterstütze ich auch nicht, trotz höherer Leistungsaufnahme würde ich nur zu AMD-Karten greifen. Aber wenn es sich irgendwann im nächsten Jahr lohnt, den Prozessor mal wieder auszuwechseln, gehe wahrscheinlich auch ich zu Intel.

Oh, und btw.:


A handful of NOPE.

Was ich mich jedoch frage, ist der Sinn über das Wechseln der Grafikkarte in absehbarer Zeit. Ich hab eine R9 280X. In Auflösungen jenseits der 1080p spiele ich ohnehin nicht, und reproduzierbare Messungen in 3DMark Fire Strike zeigen klar und deutlich (etwa anhand des "Brawn"-Achievements) dass die GPU aufgrund der CPU bisher noch nicht einmal ihr volles Leistungspotential entfalten konnte. Würde es sich hier lohnen, in absehbarer Zeit (das heißt binnen der nächsten 12 Monate) eine neue Karte zu kaufen? Oder reicht auch einfach ein gescheiter Prozessor?

Ist natürlich die frage wie Pacsal oder Artic Island wird, das kann dir keiner sagen.

Von einer 280x auf eine Fury umsteigen macht nur wenig sinn, speziell bei dem Preis.

CPU hingegen macht jetzt schon sinn, zumindest von einem FX.

Wie siehts denn mit Übertakten aus?
Sonst warte ab. Was kommt kann keiner so genau sagen..

Und was sagen die werten Herren so zur 380X? Ich bin ja schon recht enttäuscht, was die Performance angeht. Die Lücke zwischen 380 und 390 schließt die Karte aus meiner Sicht nicht zufriedenstellend, dafür ist sie zu nah an der 380 ohne X. Stromsparender als die 280X und etwas moderner vom Chip her, aber performancemäßig nur auf einer Stufe. Hatte mir mehr erhofft.

(19.11.2015)Conqi schrieb: [ -> ]

(18.11.2015)mowny schrieb: [ -> ]Das ist doch einfach. Die vom System als unbenutzt markierten Bereiche werden irgendwann wieder zum Schreiben genutzt, der Gesamtspeicher wird ja aus Systemsicht nicht mehr, auch wenn die SSD mehr Blöcke hat als sie mindestens bräuchte und die lustig kreuz und quer gemappt werden. Daher können nur maximal so viele Blöcke aus SSD-Sicht in Benutzung sein, wie die SSD aus Systemsicht groß ist. Mit jedem Schreibvorgang wird also ein Block aus dem Reservepool geholt und einer wieder freigegeben.

Aber ich dachte die SSD verteilt die Daten selbst, um gleichmäßige Schreiblast zu erzielen. Also nicht dass das System fest sagt "schreibe das in Block 25", sondern "schreibe das irgendwohin" und die SSD entscheidet dann, wohin damit. Oder habe ich da bereits was falsch verstanden? Denn wenn das so abläuft, dann wäre die SSD ja gar nicht in der Lage zu erkennen, ob sie Daten gefahrlos überschreiben kann. Wenn hingegen das System entscheidet, wohin geschrieben wird, dann bräuchte die SSD ja keine Intelligenz bzgl. der gleichmäßigen Verteilung von Schreibvorgängen.

Das System sieht eigentlich die SSD nur als Speichermedium mit $GANZVIEL Sektoren und sagt der SSD "schreibe das in Sektor $bla bis Sektor $blubb", und wenn das System SSD-aware ist und die echte Blockgröße der SSD rausfinden kann, dann richtet es eine Schreibvorgänge möglichst an den Blockgrenzen der SSD aus, um das Beschreiben von Teilblöcken zu vermeiden (weil das zu den bereits beschriebenen Problemen führt; etwas nicht ganz unähnliches passiert beim nicht korrekt ausgerichteten Schreibzugriff auf Platten, die intern 4K-Sektoren haben aber nach außen so tun als hätten sie herkömmliche 512byte große).
Die SSD hat aber eine interne Blockverwaltung, die dann halt sagt "Der Block von Sektor $bla bis Sektor $rhabarber ist jetzt in dem Chip da drüben, dritte Reihe links, der hat noch nicht so viele Zyklen runter; dafür ist der Platz wo der Block vorher hingemappt war jetzt wieder frei". Auf diese Blockverwaltung hat das System normalerweise keinen Zugriff, dafür sind sehr spezielle Tools notwendig. Die dazugehörige Mappingtabelle (die idR auch gleich die Defektmarkierung miterledigt) ist natürlich immens wichtig - egal ob die irgendwo am Stück liegt oder jeder Block seinen Datenanteil selber trägt; wenn darin ein Fehler auftritt, ist die SSD erstmal hin, mit etwas Glück ist die SSD mit Erase noch wiederbelebbar, aber die Daten sind weg ...
Bei einer neuen SSD ist anfangs noch gar kein Block belegt, auf einen beliebigen Lesezugriff antwortet die SSD nur mit Nullen. Ähnlich wie bei einem sparse file. Das funktioniert normalerweise auch umgekehrt: Wenn man einen Block nur mit Nullen beschreibt, sagt man damit der SSD, daß dieser Block frei ist, auch ohne TRIM. Das sollte man aber nur mit ganzen Blöcken tun, einfach den gesamten freien Platz mit Nullen beschreiben kann aber je nach Granularität der Blockverwaltung suboptimal sein, weil man damit der SSD ggf. einen Löschzyklus für alle teilbelegten Blöcke aufzwingt.
Diese teilbelegten Blöcke sind aber auch mit TRIM ein Problem, weil sie bei zunehmender Fragmentierung dazu führen, daß irgendwann alle im Rahmen der Nennkapazität belegbaren Blöcke auch belegt sind und die SSD von TRIM kaum noch profitiert, weil nur noch selten ein kompletter Block frei wird und zurück in den Pool kann. In diesem Fall ist der Pool, genau wie bei einem System ohne TRIM nach mindestens einmaligem Schreiben in alle Blöcke, auf die Reservekapazität beschränkt.

---

(19.11.2015)Leon schrieb: [ -> ]TRIM hat übrigens keinen direkten Einfluss auf die Lebensdauer

Indirekt schon - wenn der Pool größer ist, weil auch mal wieder Blöcke zurückkommen ohne daß neue belegt werden, kann die SSD besser wear leveling machen.

Zitat:sondern nur auf die Performance. Moderne SSDs haben angeblich auch bei Systemen ohne TRIM keinen deutlichen Performanceverust wie die alten Generationen, wobei ich nicht genau weiß, wie das dann gelöst wurde.

Verbessertes wear leveling, größerer Reservepool (und wenn es nur so ist, daß der absolut größer geworden ist durch die insgesamt vergrößerte Kapazität heutzutage). Andererseits, heutzutage haben die SSDs ja häufig nicht mehr Vielfache von 30GB als Kapazität, sondern von 32, beides allerdings in "Plattenherstellerzählung", so daß immer noch Reserve bis zu den "echten" 32GB auf den Flashchips ist; dadurch hat eine SSD mit 64GB Nennkapazität absolut knapp mehr Reserveblöcke als eine mit 30GB. Sieht erstmal günstiger aus weil mehr nutzbare GB fürs Geld, rächt sich aber, wenn wie oben ausgeführt alle Blöcke belegt sind und der Pool durch defekte Blöcke sowieso schon kleiner wird.

(19.11.2015)Conqi schrieb: [ -> ]Und was sagen die werten Herren so zur 380X? Ich bin ja schon recht enttäuscht, was die Performance angeht. Die Lücke zwischen 380 und 390 schließt die Karte aus meiner Sicht nicht zufriedenstellend, dafür ist sie zu nah an der 380 ohne X. Stromsparender als die 280X und etwas moderner vom Chip her, aber performancemäßig nur auf einer Stufe. Hatte mir mehr erhofft.

Sehr enttäuschend, die 290 wurde in einigen Tests nicht mehr mit rein genommen, obwohl die 380x gegen diese Konkurieren sollte. Der Gap zwischen der 380x und der 390 sollte ja anders verlaufen als bei der 280x und 290, war auch nicht der fall.

Aber das was ich gesehen habe sieht nicht gut aus, die 380x wenn sie mal ein Optimiertes Spiel bekommt, und keins mit nVidia Shitwörks etc dann wird diese von der 280x besiegt, auch sonst ist der Leistungsunterschied zwischen der 280x und 380x nicht sehr hoch, ich bezweifel das die 380x überhaupt an einer 290 rankommt.

Vielleicht fehlt auch einfach nur die Treiber Optimierung, wer weiß.

Die 380x gibt es für 250 € +, eine gute 380 [4GB] ab 210 €, dabei ist die 380x durchschnittlich 7-10 % stärker.

Ob das nun die knappe 40-50 €, je nach Modell, aufpreis rechtfertigt, ich weiß ja nicht.

Hab aus Interesse mal den 32-bit-Test von Geekbench 3 gemacht, und das Ergebnis ist teils ernüchternd.
Während der i5-4670k mit dem FX-8350 im Single-Thread-Test absolut den Boden wischt, mit 3610 Punkten, sind sich die beiden Chips im Multi-Thread-Test doch recht ebenbürtig, mit 11569 Punkten für den i5. Das macht den FX in Prozessen wie Rendering, in diesen viele Threads verwendet werden können, zwar minimal schneller, dafür hat er in Spielen, wo meist nicht mehr als 2 Kerne (wenn überhaupt) genutzt werden, deutlich das Nachsehen. Da sollte ich vielleicht nächstes Jahr wirklich mal nachhelfen.

(19.11.2015)mowny schrieb: [ -> ]und wenn das System SSD-aware ist und die echte Blockgröße der SSD rausfinden kann, dann richtet es eine Schreibvorgänge möglichst an den Blockgrenzen der SSD aus, um das Beschreiben von Teilblöcken zu vermeiden

Hast du dafür eine Quelle? Sinnvoll wäre eine Ausrichtung der Schreibvorgänge an den Zellengrößen, nur hab ich meine Zweifel, dass die Dateisysteme tatsächlich schon so weit sind, und solche Meta-Blockgrößen abseits der üblichen 4k schon beherrschen.

Andererseits, die SSD sortiert ja eh alles um, wird vermutlich keinen allzu großen Unterschied machen.

(19.11.2015)mowny schrieb: [ -> ]Diese teilbelegten Blöcke sind aber auch mit TRIM ein Problem, weil sie bei zunehmender Fragmentierung dazu führen, daß irgendwann alle im Rahmen der Nennkapazität belegbaren Blöcke auch belegt sind und die SSD von TRIM kaum noch profitiert, weil nur noch selten ein kompletter Block frei wird und zurück in den Pool kann.

Die SSD hätte immerhin die Möglichkeit, mehrere wenig belegte Blöcke zu einem zusammen zu legen, und so die anderen frei zu geben.
Worst case, wenn kein ganzer Block frei ist, kann die SSD immer noch einen fast freien Block nehmen und neu schreiben, und kann die ungenutzte Kapazität des Blocks komplett für andere Daten nutzen.

Ohne Trim hingegen muss die Platte letztlich irgendwann davon ausgehen, dass jeder Block zu 100% mit wichtigen Daten gefüllt ist, d.H. auch wenn nur ein Sektor geschrieben wird, muss die SSD den ganzen Block lesen, den einen Sektor ändern, und alles zurück schreiben, auch wenn es vielleicht nur noch Datenreste ohne Wert sind.

(20.11.2015)404compliant schrieb: [ -> ]Hast du dafür eine Quelle? Sinnvoll wäre eine Ausrichtung der Schreibvorgänge an den Zellengrößen, nur hab ich meine Zweifel, dass die Dateisysteme tatsächlich schon so weit sind, und solche Meta-Blockgrößen abseits der üblichen 4k schon beherrschen.

Windows unterstützt (native) 4k-Blöcke übrigens erst ab Windows 8. Windows 7 und viele Raid-Controller benötigten emulierte 512-byte-Blöcke, was bei fast allen Festplatten derzeit der Fall ist.

(20.11.2015)404compliant schrieb: [ -> ]Hast du dafür eine Quelle? Sinnvoll wäre eine Ausrichtung der Schreibvorgänge an den Zellengrößen, nur hab ich meine Zweifel, dass die Dateisysteme tatsächlich schon so weit sind, und solche Meta-Blockgrößen abseits der üblichen 4k schon beherrschen.

Nicht so sehr das Dateisystem (okay, zfs und ähnliche Exoten können wahrscheinlich auch sowas), aber zumindest dem lvm kann man ne passende Blockgröße mitgeben.

Zitat:Die SSD hätte immerhin die Möglichkeit, mehrere wenig belegte Blöcke zu einem zusammen zu legen, und so die anderen frei zu geben.
Worst case, wenn kein ganzer Block frei ist, kann die SSD immer noch einen fast freien Block nehmen und neu schreiben, und kann die ungenutzte Kapazität des Blocks komplett für andere Daten nutzen.

Dafür muß die SSD sich aber auch die Subblockbelegung merken können. Machen die das wirklich, oder halten die solche Daten nur in ihrem RAM? Immerhin wäre das gerade bei subblock merging eine ganze Menge Speicher, der auch noch besonders belastbar sein muß ...

---

(20.11.2015)Leon schrieb: [ -> ]Windows unterstützt (native) 4k-Blöcke übrigens erst ab Windows 8. Windows 7 und viele Raid-Controller benötigten emulierte 512-byte-Blöcke, was bei fast allen Festplatten derzeit der Fall ist.

Auf der Bootplatte vielleicht. Zusätzliche Platten konnten sogar schon unter DOS mehr als 512 Byte pro Sektor haben. Womit außer DOS selbst allerdings nicht alles klargekommen ist. Mein olles MO-Laufwerk hat zB 2048-Byte-Sektoren. DVD-RAM auch.

Heute mal wieder das eigene Glück mit Hackintosh versucht, und obwohl es besser lief als zuvor, läuft beileibe nicht alles perfekt. Nachdem sowohl Audio als auch Grafik (mit zwei Behelfstreibern) sich problemlos installieren ließen, fiel mir regelmäßig der Netzwerktreiber aus, was am Ende zu einer vollständig Neuinstallation mit Disk permissions-Reperatur führte. Auch Spiele funktionieren. Es gibt jedoch ein kleines Problem, und das bemerkt man, wenn man sich die Geekbench 3-Werte erneut anschaut:
Abseits von drastisch niedrigeren Werten gegenüber den Werten auf Windows 10 weiter oben (welche höchstwahrscheinlich an einem ineffizient geschriebenen Kernel liegt, der zudem AMD-Anfragen in Intel-Anfragen übersetzen muss) wird findigen Usern auffallen, dass er erstmal anstelle von 4 Kernen und 8 Threads 8 Kerne und gar keine Threads erkennt. Weiterhin wird der gesamte L1-Cache völlig fehlinterpretiert. Dies schlägt sich in einer drastisch ausgebremsten Grafikkarte nieder.
Zum gegebenen Zeitpunkt lässt selbst ein MacBook Air meinen Prozessor völlig hinter sich.

(20.11.2015)Leon schrieb: [ -> ]Windows unterstützt (native) 4k-Blöcke übrigens erst ab Windows 8. Windows 7 und viele Raid-Controller benötigten emulierte 512-byte-Blöcke, was bei fast allen Festplatten derzeit der Fall ist.

Da wirfst du etwas durcheinander. Du meinst 4k-Sektoren, die von der Festplatte als kleinste Einheit gemeldet werden. Die wurden vor 30 Jahren mal unter DOS unterstützt, sind dann irgendwie verloren gegangen, und werden jetzt wieder unterstützt.

Dateisysteme hingegen verwenden intern schon seit Ewigkeiten als kleinste Einheit mindestens 4k große Cluster. Das geht auch bis zu seligen DOS-Zeiten zurück, und gilt auch für fast alle anderen Dateisysteme, weil sie so zur 4k-Speicherseiten-Größe der Prozessoren passt, ein Cluster belegt so immer ganze Speicherseiten, das macht das swappen und die memory mapped files leichter.

Seit Windows 7 (glaube ich) achten sie auch auf das Alignment, d.H. ein Cluster beginnt auch immer auf einer glatten 4k-Adresse, ältere Dateisysteme haben die 4k-Cluster gerne mal um 512 Byte verschoben gespeichert. Das strafen aber moderne Festplatten und SSDs mit Performance-Verlusten ab.

Ja, ich meinte Sektoren (der Festplatte), keine Blöcke (des Dateisysems).
Korrekt ausgerichtete Partitionen bei Festplatten mit emulierten 512-Byte-Sektoren kann übrigens bereits Windows Vista SP1 erstellen. Bei Windows XP ging es dagegen nur mit Zusatztools.

(20.11.2015)404compliant schrieb: [ -> ]Dateisysteme hingegen verwenden intern schon seit Ewigkeiten als kleinste Einheit mindestens 4k große Cluster. Das geht auch bis zu seligen DOS-Zeiten zurück, und gilt auch für fast alle anderen Dateisysteme, weil sie so zur 4k-Speicherseiten-Größe der Prozessoren passt, ein Cluster belegt so immer ganze Speicherseiten, das macht das swappen und die memory mapped files leichter.

Nope. DOS hat damals 2 oder 4 Sektoren benutzt, und mußte dank FAT16 bei höheren Kapazitäten größere Blöcke machen, bis zu 16KB. FAT32 hat per default 4 Sektoren genommen, ein Kompromiß zwischen FAT-Größe und Speicherverschwendung durch kleine Fisseldateien.
Mit swap und mmap hat das gar nix zu tun, weil beide auf Dateiebene operieren und damit ein paar Ebenen über Sektoren und Clustern.