BenRo
Software-Overclocker(in)
Hallo,
Da ich zu dem Thema noch nichts gefunden habe, hab ich einfach mal selbst experimentiert.
Mein i7 3970X läuft normalerweise bei 4Ghz, das reicht mir und ist absolut stabil. Mehr Leistung habe ich bisher eher selten gebraucht.
Leider muss ich momentan täglich ca. 30mal einige grunt-Tasks lokal laufen lassen*. Diese lassen sich nicht mit grunt-concurrent auf mehrere Threads verteilen* und lasten die CPU voll aus.
Also wollte ich mal kurz testen, wie viel hier Overclocking bringt. Da ich kein OC-Experte bin und ich nicht soooo viel Zeit in das Lesen von weiteren Tipps (OC-Guide hier im Forum hab ich natürlich gelesen) stecken wollte, hab ich "nur" 4,7 Ghz wirklich absolut stabil gekriegt, bei einer VCore von 1,4V. Obwohl grunt wie gesagt nur einen Kern nutzt, hab ich alle Kerne angelassen (ich brauch die ja schließlich auch für andere Anwendungen) und alle liegen bei besagten 4.7Ghz.
Verwendet wird ein Gruntfile welches die folgenden Tasks nacheinander durchführt: clean, concat, copy, uglify, cssmin, string-replace – aus dem einfachen Grund, dass ich ein Gruntfile von einem echten Projekt von mir verwendet habe, um authentische Werte zu bekommen. Der uglify-Task verbraucht 92% der Zeit, der cssmin-Task 2% der Zeit, die anderen Tasks zusammen den Rest.
grunt verwendet bei diesem Beispiel ca. 1,4 Gigabyte RAM (DDR3-1600, Corsair Dominator), Auslagerungsspeicher wird nicht verwendet. Betriebssystem, grunt und alle verwendeten Daten liegen auf einer 512 GB Samsung 840 Pro SSD, es sind 38 GB frei.
Im Hintergrund läuft ne KDE-Oberfläche, netbeans (jaja, Schande über mein Haupt, aber da ich es in allen Tests mitlaufen ließ und es im Gegensatz zu grunt multithreaded passen die Ergebnisse trotzdem), top (Auslastung checken), sensors (Temperaturen checken) ein cat von /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq (Aktuelle CPU-Frequenz). Im großen und ganzen fressen die Hintergrundprozesse kaum CPU-Power.
Ergebnisse – das schöne ist, dass sich diese Ergebnisse bei grunt sehr gut reproduzieren lassen:
4,0 Ghz – 20,4 Sekunden – 52° core temp
4,7 Ghz – 17,2 Sekunden – Allerdings auch bei 60° core temp, was zwar absolut unbedenklich ist, wobei ich aber meine Wakülüfter in den deutlich störenden Bereich aufgedreht habe, um mich wohlzufühlen
Ich habe also von der Build-Zeit 15,6% abgezwackt – das entspricht fast, aber nicht ganz, der Erhöhung des Taktes. Das Ergebnis ist jetzt weder bahnbrechend, noch unerwartet, aber ich dachte, es könnte euch trotzdem interessieren.
* = Mir ist bewusst, dass man das Problem anders lösen sollte: Anderer Aufbau des Buildfiles sodass grunt-concurrent möglich ist, Änderung der Arbeitsabläufe, sodass grunt auf nem Server läuft, mit grunt-newer und Watchern arbeiten… Aber jede Änderung am Buildfile ist potentiell gefährlich und kostet viel Arbeit, daher hab ichs erstmal so probiert.
Da ich zu dem Thema noch nichts gefunden habe, hab ich einfach mal selbst experimentiert.
Mein i7 3970X läuft normalerweise bei 4Ghz, das reicht mir und ist absolut stabil. Mehr Leistung habe ich bisher eher selten gebraucht.
Leider muss ich momentan täglich ca. 30mal einige grunt-Tasks lokal laufen lassen*. Diese lassen sich nicht mit grunt-concurrent auf mehrere Threads verteilen* und lasten die CPU voll aus.
Also wollte ich mal kurz testen, wie viel hier Overclocking bringt. Da ich kein OC-Experte bin und ich nicht soooo viel Zeit in das Lesen von weiteren Tipps (OC-Guide hier im Forum hab ich natürlich gelesen) stecken wollte, hab ich "nur" 4,7 Ghz wirklich absolut stabil gekriegt, bei einer VCore von 1,4V. Obwohl grunt wie gesagt nur einen Kern nutzt, hab ich alle Kerne angelassen (ich brauch die ja schließlich auch für andere Anwendungen) und alle liegen bei besagten 4.7Ghz.
Verwendet wird ein Gruntfile welches die folgenden Tasks nacheinander durchführt: clean, concat, copy, uglify, cssmin, string-replace – aus dem einfachen Grund, dass ich ein Gruntfile von einem echten Projekt von mir verwendet habe, um authentische Werte zu bekommen. Der uglify-Task verbraucht 92% der Zeit, der cssmin-Task 2% der Zeit, die anderen Tasks zusammen den Rest.
grunt verwendet bei diesem Beispiel ca. 1,4 Gigabyte RAM (DDR3-1600, Corsair Dominator), Auslagerungsspeicher wird nicht verwendet. Betriebssystem, grunt und alle verwendeten Daten liegen auf einer 512 GB Samsung 840 Pro SSD, es sind 38 GB frei.
Im Hintergrund läuft ne KDE-Oberfläche, netbeans (jaja, Schande über mein Haupt, aber da ich es in allen Tests mitlaufen ließ und es im Gegensatz zu grunt multithreaded passen die Ergebnisse trotzdem), top (Auslastung checken), sensors (Temperaturen checken) ein cat von /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq (Aktuelle CPU-Frequenz). Im großen und ganzen fressen die Hintergrundprozesse kaum CPU-Power.
Ergebnisse – das schöne ist, dass sich diese Ergebnisse bei grunt sehr gut reproduzieren lassen:
4,0 Ghz – 20,4 Sekunden – 52° core temp
4,7 Ghz – 17,2 Sekunden – Allerdings auch bei 60° core temp, was zwar absolut unbedenklich ist, wobei ich aber meine Wakülüfter in den deutlich störenden Bereich aufgedreht habe, um mich wohlzufühlen
Ich habe also von der Build-Zeit 15,6% abgezwackt – das entspricht fast, aber nicht ganz, der Erhöhung des Taktes. Das Ergebnis ist jetzt weder bahnbrechend, noch unerwartet, aber ich dachte, es könnte euch trotzdem interessieren.
* = Mir ist bewusst, dass man das Problem anders lösen sollte: Anderer Aufbau des Buildfiles sodass grunt-concurrent möglich ist, Änderung der Arbeitsabläufe, sodass grunt auf nem Server läuft, mit grunt-newer und Watchern arbeiten… Aber jede Änderung am Buildfile ist potentiell gefährlich und kostet viel Arbeit, daher hab ichs erstmal so probiert.
