Beiträge von Umlüx

    hier mein test:

    shooock! kuma shock!

    da bencht man haufenweise kisten und vergisst auf seine eigene (mit aktueller taktung). der vollständigkeit halber also:

    48:45.891 | X | 1/4/8 | Umlüx | Intel Core i7-2600K 3.40GHz @ 4.30GHz | 16GB DDR-III/1600z | ASUS P8Z68-V | Windows 10 pro x64 (Offical r2705 Build)
    1:27:51.222 | X | 1/4/8 | Umlüx | Intel Core i7-2600K 3.40GHz @ 4.30GHz | 16GB DDR-III/1600z | ASUS P8Z68-V | Windows 10 pro x64

    so!

    wir haben eh schon drüber gesprochen thrawn, deine binary hats leider nicht gebracht. dennoch danke für die mühe.

    was mich schlussendlich weitergebracht hatte war Node Interleaving im bios. er lastete zwar großteils weiterhin nur die hälfte der zur verfügung stehenden threads voll aus, sprang aber zwischendurch immer wieder auf bis auf 90% auslastung hoch.
    und was ausserdem noch einen starken schub verschafft hat, war das deaktivieren von HyperThreading. nur die physikalischen cores gut auszulasten scheint in diesem szenario wesentlich günstiger auf den x264 code zu wirken als einen ganzen haufen threads zur verfügung zu haben.
    ebenfalls noch interessant: Server2016 war durchwegs und reproduzierbar um die 10 sekunden langsamer als Windows7 unterwegs

    ich will aber nicht lange herumreden, hier die ergebnisse:

    00:38:37.774 | X | 2/16/32 | Umlüx | Intel Xeon E5-2683 v4 2.10 GHz | 256GB DDR4 2400MHz |ProLiant BL460c Gen9 (ID6F00) | Windows 7 pro x64
    00:16:35.234 | X | 2/16/32 | Umlüx | Intel Xeon E5-2683 v4 2.10 GHz | 256GB DDR4 2400MHz |ProLiant BL460c Gen9 (ID6F00) | Windows 7 pro x64 (offz. r2705)
    00:12:45.399 | X | 2/16/32 | Umlüx | Intel Xeon E5-2683 v4 2.10 GHz (HT off) | 256GB DDR4 2400MHz |ProLiant BL460c Gen9 (ID6F00) | Windows 7 pro x64 (offz. r2705)

    wärend ich noch den server in die mangel nehme, gibts zwischendurch noch eine kleinigkeit:
    die prozessorfrequenz ist bei der cpu ein wenig kompliziert. angegeben ist sie mit 1,90-3,00GHz
    ich gebe mal die an, die er mehr oder weniger über den ganzen bench lange halten konnte ;)

    04:13:19.687 | X | 1/2/4 | Umlüx | Intel Core i7-3517U 2,7GHz | 4GB DDR3-800 | Asus Zenbook Prime (Intel HM76) | Win10 pro x64

    02:22:14.709 | X | 1/2/4 | Umlüx | Intel Core i7-3517U 2,7GHz | 4GB DDR3-800 | Asus Zenbook Prime (Intel HM76) | Win10 pro x64 (r2705)

    und noch eine kleinigkeit von mir. leider nicht ganz ohne kopfzerbrechen:

    00:45:18.021 | X | 2/16/32 | Umlüx | Intel Xeon E5-2683 v4 2.10GZh @ 2.58GHz| 256GB DDR4 2400MHz |ProLiant BL460c Gen9 (ID6F00) | Windows Server 2016 Trial
    00:21:26.713 | X | 2/16/32 | Umlüx | Intel Xeon E5-2683 v4 2.10GZh @ 2.58GHz| 256GB DDR4 2400MHz |ProLiant BL460c Gen9 (ID6F00) | Windows Server 2016 Trial (offz. r2705)

    der benchmark hat hier nur 32 threads verwendet. bios/windows zeigt aber brav alle 64 an? ich hab leider keine ahnung woran das liegen könnte. ich habe es parallel dazu auch mit einem Server 2008 R2 Enterprise versucht - selbes ergebnis. kann es sein, dass man eine noch dickere version braucht (z.b. datacenter) um alle threads auszulasten?
    hat dazu jemand eine idee?

    wie funktioniert das? läuft das in einer schleife für alle dateien durch? oder wird der code für jede datei extra aufgerufen?
    die aller primitivste und schnellste lösung wäre wohl einfach den letzten dateinamen in einer weiteren variable abzuspeichern und dann per if mit dem aktuellen dateinamen zu vergleichen. unterscheiden sie sich, setzt du die zählervariable zurück.

    mein neues zuhause: ein thermaltake core v41
    eigentlich nichts besonderes. nichts verändert. ich wollte nur GATs überflüssigen 140mm noctuas ein zuhause bieten :)

    [Blockierte Grafik: http://www.umluex.at/bilder/tt_core_v41/IMG_7639.jpg]
    [Blockierte Grafik: http://www.umluex.at/bilder/tt_core_v41/IMG_7641.jpg]
    [Blockierte Grafik: http://www.umluex.at/bilder/tt_core_v41/IMG_7646.jpg]
    [Blockierte Grafik: http://www.umluex.at/bilder/tt_core_v41/IMG_7644.jpg]

    so, von mir gibts jetzt auch wieder mal was neues da wir frische hardware bekommen haben und ich jetzt zugriff auf ein paar threads mehr habe. genauer gesagt 40 davon! :) das wird auch gleich ein netter test, wie gut der x264 codec skaliert.

    das system ist ein HP Blade BL460c Gen8 in einem c7000 blade center und verfügt über zwei E5-2660 v2 und 128GB RAM.
    für die die es interessiert: drei davon werden künftig unsere Citrix XenDesktop virtualisierung befeuern.

    aussehen tut es schonmal sehr nett!
    [Blockierte Grafik: http://www.umluex.at/bilder/x264/2.JPG]
    [Blockierte Grafik: http://www.umluex.at/bilder/x264/1.JPG]

    aber aussehen gewinnt natürlich keinen blumentopf. schauen wir mal, was das unterm strich bringt. erstmal lassen wir den vanilla bench laufen, so wie GAT ihn zusammengestellt hat.

    man merkt schon, die inzwischen etwas ältere x264 binary hat merkliche probleme soviele threads voll auszulasten. und der takt der cpu ist nicht sonderlich hoch.

    [Blockierte Grafik: http://www.umluex.at/bilder/x264/3.JPG]
    [Blockierte Grafik: http://www.umluex.at/bilder/x264/4.JPG]

    damit haben wir das erste ergebnis:
    0000:58:27.353 | Umlüx | 2/10/20 | Intel Xeon E5-2660 v2 2.2GHz | 128GB Reg. ECC DDR-III/1066 | HP BL460 G8 | Win7 x64 pro

    damit geben wir uns aber noch nicht zufrieden und setzen der maschine mal den neuesten r2538 x64 build vor.
    und hier läufts schon deutlich besser. alle threads sind mehr oder weniger gut ausgelastet und die cpu gibt richtig gas! :)

    [Blockierte Grafik: http://www.umluex.at/bilder/x264/5.JPG]
    [Blockierte Grafik: http://www.umluex.at/bilder/x264/6.JPG]

    kann man, denke ich, so stehen lassen:
    0000:21:53.319 | Umlüx | 2/10/20 | Intel Xeon E5-2660 v2 2.2GHz | 128GB Reg. ECC DDR-III/1066 | HP BL460 G8 | Win7 x64 pro (Official r2538 x64)

    es ist beinahe schade, dass ich nun XenServer installieren gehn muss :D