AMD Bulldozer vernichtende Entäuschung
-
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).
-
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 ^^
-
volkard schrieb:
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.
Vielleicht weil es eben doch nicht Modern ist.
-
CppJunky schrieb:
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
Aha.
Was hat das noch mit Dingen zu tun wo single-threaded Performance wichtig ist? Nix. Wenn du mir also nicht widersprechen wolltest (weil du ja bloss von deinen kleinen Projekten redest), was sollte dann dein Beitrag...?
-
hustbaer schrieb:
CppJunky schrieb:
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
Aha.
Was hat das noch mit Dingen zu tun wo single-threaded Performance wichtig ist? Nix. Wenn du mir also nicht widersprechen wolltest (weil du ja bloss von deinen kleinen Projekten redest), was sollte dann dein Beitrag...?Ich habe meine persönlichen Erfahrungen beigesteuert. Das macht man so in einem Diskussionsforum. Ich konnte ja nicht ahnen, das dass hier so religiöse Ausmaße annimmt ^^
-
Cpp_Junky schrieb:
Ich konnte ja nicht ahnen, das dass hier so religiöse Ausmaße annimmt ^^
Du konntest nicht ahnen, daß man nachfragt und ergründen will, wie es zu so unterschiedlichen Beobachtungen kommt.
Das ist aber genau das Gegenteil von Religion.
-
Mal alle halblang, Bulldozer ist nicht der Brüller geworden, aber als intel die Multicore- Sache verpennt hatte, hat ja auch nicht jeder gleich das Ende intels gesehen, die haben mit ihrem tic- toc auch gerade Herzrythmusstörungen, aber keinen Grund zur Panik, weil der core i7 ja eigentlich ganz gut rennt.
Jenseits der Performance- Bolzerei war AMD immer dafür gut, Mittelklassesysteme preiswerter anzubieten als intel. Wenn's so bleibt, ists gut so. Aber eine Singlethreading- Schwäche, die man intel jederzeit als kleine Panne verziehen hätte, als Katastrophe zu beschreien, das steht nicht dafür.
Es stehen sowieso alle Zeichen auf Multicore- Nutzung. Ich mußte im embedded- Bereich noch bis vor ein paar Jahren zwei, drei CPUs auf ein Board kleben und mit schwindligen SPI- DMA- Swaps das Zeugs per Hand synchronisieren, deswegen wundert's mich, daß sich die Mehrkernigkeit noch nicht so ganz rumgesprochen hat.
