AMD Bulldozer vernichtende Entäuschung



  • Gregor schrieb:

    Kariiya schrieb:

    Der treibende Faktor für HW ist heute noch viel mehr als damals die Spieleindustrie.

    Glaube ich nicht. Damals (vor 15 Jahren) gab es regelmaessig neue Spiele, die selbst mit den neuesten Rechnern kaum fluessig spielbar waren. Heute ist das nicht mehr so. Zumindest ist es mir nicht bekannt. Welche aktuellen Spiele brauchen denn die neuste Hardware, um halbwegs spielbar zu sein?

    Das gibts heute auch noch... für Starcraft 2 gibt´s z.B. Fun Maps, die mein System über seine Grenzen belasten. Bei einer Auflösung von 1920x1200 und maximaler Grafikqualität hatte ich teilweise nur noch 11 FPS (Core i7-2500K und GeForce 470 GTX).



  • Firefox-Compilieren gemessen:
    auf Ramdisk: 9m10s
    auf SSD: 9m32s



  • dot schrieb:

    Wie wärs damit: Zugriffsgeschwindigkeiten im Bereich von 100x schneller als normale HDD?

    Schon, aber beim Compilieren gehen die Uhren anders.
    Gelesen wird fast nur aus dem Cache. Geschrieben wird nur in den Cache.
    Wenn die Platte langsamer ist als die Ramdisk, dürfte das wohl vor allem am Dateisystem liegen, nämlich daß tmpfs einfacher aufgebaut ist und dafür weniger gerechnet werden muß, weniger gelockt werden muß oder so Kram.



  • volkard schrieb:

    dot schrieb:

    Wie wärs damit: Zugriffsgeschwindigkeiten im Bereich von 100x schneller als normale HDD?

    Schon, aber beim Compilieren gehen die Uhren anders.
    Gelesen wird fast nur aus dem Cache. Geschrieben wird nur in den Cache.

    Naja, aber dann bin ich ja nicht I/O bound, ich dachte wir reden hier von einem hypothetischen Fall wo ich I/O bound bin 😉



  • dot schrieb:

    Naja, aber dann bin ich ja nicht I/O bound, ich dachte wir reden hier von einem hypothetischen Fall wo ich I/O bound bin 😉

    Ich wollte einwerfen, daß man diesen hypothetischen Fall nicht befürchten muß, wenn man nicht gerade zu wenig RAM eingebaut hat. Mir war nicht klar, daß die Diskussion in den hypothetischen Fall gerutscht war.



  • Naja, ist trotzdem durchaus interessant. Ich hab das Argument, dass man mit einer schnelleren Festplatte die Compiletime evtl. stark reduzieren kann, schon ziemlich oft gehört. Gut mal von jemandem der Erfahrung hat zu hören, was wirklich dran ist 😉



  • Ernsthafte Vergleiche habe ich nur unter Linux mit reiserfs, nilfs2 oder btrfs.
    Insbesondere mit nilfs2 habe ich monatelang auf einem USB-Stick gearbeitet. Null problemo auch mit solch einer ultra-langsamen "Platte". Außer mit Firefox, der anscheinend dauernd die gesamte Platte synct.

    Unter Windows könnte das anders sein. Da will ich mal nichts versprechen.

    Aber lesen kann auch Windows aus dem Cache und schreiben tut auch Windows in den Cache. Zum Beispiel schreibt keiner eine Ramdisk für Windows, weil es nichts bringen würde. Das könnte man eigentlich auch nur totmachen, wenn man andauerd unsinnigerweise die gesamte Platte synct.

    Früher hatten viele Leute einfach zu wenig RAM, dann brachte eine schnelle Platte natürlich sehr viel. Mit meinen 2GB war ich aber schon jenseits der Probleme. Und bis Win95 war Schreiben wohl auch nicht kostenlos (aber für Win95 gab es prima Ramdisks).


  • Mod

    dot schrieb:

    Naja, ist trotzdem durchaus interessant. Ich hab das Argument, dass man mit einer schnelleren Festplatte die Compiletime evtl. stark reduzieren kann, schon ziemlich oft gehört. Gut mal von jemandem der Erfahrung hat zu hören, was wirklich dran ist 😉

    Das hättest du doch auch selber ausprobieren können. Du compilierst doch sicherlich oft genug irgendwas.



  • SeppJ schrieb:

    dot schrieb:

    Naja, ist trotzdem durchaus interessant. Ich hab das Argument, dass man mit einer schnelleren Festplatte die Compiletime evtl. stark reduzieren kann, schon ziemlich oft gehört. Gut mal von jemandem der Erfahrung hat zu hören, was wirklich dran ist 😉

    Das hättest du doch auch selber ausprobieren können. Du compilierst doch sicherlich oft genug irgendwas.

    Natürlich, aber ich hatte noch nie das Problem mit derart langen Compilezeiten, dass es mich irgendwie gestört hätte 😉



  • volkard schrieb:

    Ernsthafte Vergleiche habe ich nur unter Linux mit reiserfs, nilfs2 oder btrfs.
    Insbesondere mit nilfs2 habe ich monatelang auf einem USB-Stick gearbeitet. Null problemo auch mit solch einer ultra-langsamen "Platte". Außer mit Firefox, der anscheinend dauernd die gesamte Platte synct.

    Unter Windows könnte das anders sein. Da will ich mal nichts versprechen.

    Ich hab ein paar Wochen mein Projekt auf USB-Stick rumgetragen und auf verschiedenen Rechnern gearbeitet. Beim Compilieren hatte ich elende Zeiten, warum auch immer. Inzwischen packe ich den kram auf dem jeweiligen Rechner immer auf Platte und synchronisiere per git mit dem USB-Stick.

    Beim Übersetzen von HDD hänge ich dann schon an der CPU.



  • pumuckl schrieb:

    Ich hab ein paar Wochen mein Projekt auf USB-Stick rumgetragen und auf verschiedenen Rechnern gearbeitet. Beim Compilieren hatte ich elende Zeiten, warum auch immer.

    Vermutung: Ohne den Schreibcache anzumachen, was auch nur geht, wenn er mit NTFS formatiert wurde, ist die Performance ganz sicher ganz im Keller.



  • Cpp_Junky schrieb:

    Klar bremst die Platte.. Das läuft hier (Core i5 2400, 6 GB RAM / 2 GB für die RD) gefühlt fast doppelt so schnell durch, wenn ichs auf der RD kompilieren lasse (Und meine HDD ist ein Sata II Stripe). Und was hat überhaupt SSD damit zu tun?! 😕

    Alter Schwede...
    Nein, die Platte bremst nicht.
    Nicht bei den Projekten von denen ich spreche, und die ich häufiger compiliere. Nicht in der Code-Generation Phase mit LTCG. Da steht alles schon im RAM, ein Core (aber eben nur einer) ist auf 100%, die Platte tut genau nix.

    Und was ne SSD damit zu tun hat? Im Ernst? Du schreibst "Ramdisk", ich erwidere "ich hab ne SSD". Tjo...

    BTW: dein SATA II Stripe-Set wird, sofern du normale drehende Scheiben meinst, gegen jede moderne SSD nichtmal den Hauch einer Chance haben.



  • dot schrieb:

    @hustbaer: Rein aus Interesse, wenn du da ständig auf die SSD kompilierst, hast du da schonmal eine SSD komplett abgenutzt, oder zumindest gemerkt, dass sie langsamer wird?

    Nö.

    Ich hab mir ja nun auch eine SSD als Systemlaufwerk zugelegt und bin sehr begeistert davon. Allerdings hab ich alles mögliche unternommen, um die Writes auf die Platte möglichst gering zu halten. Was SSD write endurance angeht, findet man ja leider viel zu viel widersprüchliche Aussagen...

    Pfuh, ja, ich hab auch nicht SO viele SSDs, aber die die ich habe halten alle noch.
    Ich mach da aber auch nicht laufend Tests oder sowas.
    Und ich tu genau nix um Schreibvorgänge zu sparen. Eher im Gegenteil: dadurch dass das Ding schneller ist, wird sicher mehr draufgeschrieben, weil ich flotter arbeiten kann, und daher mehr Schreibvorgänge auslöse (z.B. indem ich öfter rebuild-all mache oder sowas).

    Ich kann in der Arbeit leider nicht so einfach nachgucken wie abgenutzt sich meine SSD schon fühlt, da in dem PC noch zwei normale HDDs drinnen sind die per BIOS-RAID gespiegelt sind - und sobald das BIOS-RAID aktiv ist kann die OCZ Toolbox nimmer mit der Vertex 2 plauschen 😞



  • Was ist die englische Übersetzung von Hamsterpups?

    Wie war nochmal die Fließkommaleistung?

    Gibt es irgendwo einen guten opencl Compiler?

    ..und Profiler?

    Sollte man nicht schon allein wegen dem Intel-Compiler einen Intel kaufen?

    Und können Grafikkarten nicht viel besser parallelisieren?

    Gibt es multikernasmbefehle (mov raxmulti(8) (16 Kernen insgesamt) oder mov rax(1,2,3,4,5,6,7,8,12),i+ -< also rax1 = 1 rax2 = 2 rax3 = 3 usw, wäre in diesem Falle rax12=9 falls i=1)...ginge auch mov raxall,rbx+ oder mov rax(1-16),rbx(fib) ?

    Und was war eigentlich nochmal eine gute Threading Api?

    Können mehr Rechenkerne nicht eine viel schönere Gegnerintelligenz herbeirechnen?

    ...und Bitcoins...?



  • hustbaer schrieb:

    Cpp_Junky schrieb:

    Klar bremst die Platte.. Das läuft hier (Core i5 2400, 6 GB RAM / 2 GB für die RD) gefühlt fast doppelt so schnell durch, wenn ichs auf der RD kompilieren lasse (Und meine HDD ist ein Sata II Stripe). Und was hat überhaupt SSD damit zu tun?! 😕

    Alter Schwede...
    Nein, die Platte bremst nicht.
    Nicht bei den Projekten von denen ich spreche, und die ich häufiger compiliere. Nicht in der Code-Generation Phase mit LTCG. Da steht alles schon im RAM, ein Core (aber eben nur einer) ist auf 100%, die Platte tut genau nix.

    Und was ne SSD damit zu tun hat? Im Ernst? Du schreibst "Ramdisk", ich erwidere "ich hab ne SSD". Tjo...

    BTW: dein SATA II Stripe-Set wird, sofern du normale drehende Scheiben meinst, gegen jede moderne SSD nichtmal den Hauch einer Chance haben.

    Alter Schwede, erstens rede ich hier vom Unterschied auf meinem System (SATA HDD vs RD), zweitens ist eine "physikalisches" SSD Laufwerk an einem SATA Bus oder wasauchimmer immernoch nicht das selbe wie eine Ramdisk im Arbeitsspeicher eines Rechners. Und jetzt darfst du dir einen Keks nehmen, weil du mit deinen Superduper-Platten keine I/O Engpässe beim Coden hast 🙄



  • CppJunky schrieb:

    Und jetzt darfst du dir einen Keks nehmen, weil du mit deinen Superduper-Platten keine I/O Engpässe beim Coden hast 🙄

    Willst Du damit andeuten, Du hättest welche?



  • 🤡



  • volkard schrieb:

    CppJunky schrieb:

    Und jetzt darfst du dir einen Keks nehmen, weil du mit deinen Superduper-Platten keine I/O Engpässe beim Coden hast 🙄

    Willst Du damit andeuten, Du hättest welche?

    Naja was heisst "Engpass", ich spüre den Unterschied jedenfalls ohne es Messen zu müssen ^^



  • Cpp_Junky schrieb:

    Naja was heisst "Engpass", ich spüre den Unterschied jedenfalls ohne es Messen zu müssen ^^

    Miß trotzdem mal. Kann mir gar nicht vorstellen, daß ein modernes Betriebssystem da so großen Mist baut.



  • Werd ich machen. Ist vielleicht auch Compilerabhängig? Ich hab hier noch oldschool Visual Studio 6 im Einsatz ^^


Anmelden zum Antworten