Hallo zusammen
06:26:02.529 | marclluswallace1982 | 1/6/12 | AMD Ryzen 5 1600 @ 4.00Ghz | 16GB DDR-4/2666 16-18-18-44 | X370 Taichi | x370| Microsoft Windows 10 Professional 64-bit 1809
Hallo zusammen
06:26:02.529 | marclluswallace1982 | 1/6/12 | AMD Ryzen 5 1600 @ 4.00Ghz | 16GB DDR-4/2666 16-18-18-44 | X370 Taichi | x370| Microsoft Windows 10 Professional 64-bit 1809
Willkommen im Forum und danke für deine Einsendung! Ist eingetragen!
05:42:44.228 | Thomsen-XE | 1/8/16 | Intel Xeon E5-1660 v4 ES 3.20 GHz | 64GB DDR-IV/ 2400 17-17-17-39 2T | ASRock Rack EPC612D4I | C612 | Windows 10 Prof. x64
Interessanterweise lief die CPU mit einem All-Core-Turbo von 3.40 GHz.
Die AVX-Berechnungen haben den Takt nicht gedrückt.
Ist jetzt nur eine blinde Vermutung meinerseits, aber vielleicht hat das Power-/Thermalbudget einfach ausgereicht, womit die Drosselung nicht notwendig war? Aber keine Ahnung, ob der Broadwellturbo sowas kann. Oder kann das eventuell eine Eigenheit des Engineering Samples sein?
Das könnte sein. Zu der CPU gibt es leider keine Daten zwecks AVX- Clock.
CPU ist offen, was den Turbo betrifft.
Muss ich dann noch auf einem Board testen, welches OC kann.
4:37:25.000 | Bromart | 1/8/16 | AMD Ryzen 7 1800X @4GHz | 32GiB DDR4 3200 14-14-14-34 1T | Gigabyte GA-AX370-Gaming K7 | X370 | Debian 9.6
Hallo und willkommen im Forum!
Danke für die Teilnahme, Ergebnis ist eingetragen!
4:51:15.109 | Bromart | 1/8/16 | AMD Ryzen 7 1800X @4GHz | 32GiB DDR4 3200 14-14-14-34 1T | Gigabyte GA-AX370-Gaming K7 | X370 | Windows 10 Pro x64 v.1809
Ah, hat er Dualboot? Und ich dachte schon wir hätten einen reinen Linux User gefunden.
Und antworten kann er auch nicht
Eigentlich bin ich ein reiner Windows User. Mich hatte hauptsächlich der Einfluss des OS auf das Benchmark-Ergebnis interessiert.
Ich finde es immer noch witzig, daß x265 auf Linux (und auch UNIX) schneller rennt als auf Windows. Bei x264 gibt es diese Affinität so nicht. Also "witzig" deswegen, weil die Entwickler von dem Encoder eigentlich auf Windows bauen, und weil Windows deren Primärzielplattform darstellt.
Mich wundert das eigentlich nicht. Eher das es bei x264 nicht so ist. Immerhin rödelt ja bei Windows doch so allerhand im Hintergrund was man bei nem Linux ja nicht so ausgeprägt hat.
Aber ich lasse jetzt Windows noch mal durchlaufen. Diesmal mit Energieprofiel "Ultimative Leistung" oder wie sich das schimpft. Mal schauen ob das einen unterschied macht.
Najo, ich verwende Linux jetzt schon seit 16 Jahren intensiv, privat und beruflich (und Windows noch länger), und kann dir aus Erfahrung eines sagen: Auf einem modernen Desktop Linux läuft im Hintergrund auch nicht weniger Scheiß mit als auf Windows 10.
Ich habe Linux und Windows tlw. auch auf sehr alter Hardware verglichen (wo man das schön merkt), und die Mär vom ressourcenarmen Linux bewahrheitet sich bei modernen Standarddistros einfach überhaupt nicht mehr. Das sind maximal Propaganda oder Sonderfälle wie Damn Small Linux damals.
Es gibt aber auch signifikante Unterschiede in der NUMA Implementierung in x265, also zwischen Windows und Linux (x264 hat noch keinen NUMA Support), und da vermute ich einen Teil des Problems. Muß ich direkt Mal die Entwickler fragen, warum das so ist. Wär eh interessant (also für mich zumindest).
Okay, kein signifikanter Unterschied zwischen "Ultimative Leistung" und "Für AMD Ryzen ausbalanciert" im Benchmark.
Ich schätze Mal wennst der CPU soviel Stoff gibst, wird's in beiden Modi voll hochtakten. Vielleicht spart das "ausbalancierte" Ding was bei geringen Lasten? Aber ich weiß nicht so ganz genau was die Energieprofile im Detail anstellen.
Jepp, wird wohl nur bei Wechsellasten was aus machen.
Najo, ich verwende Linux jetzt schon seit 16 Jahren intensiv, privat und beruflich (und Windows noch länger), und kann dir aus Erfahrung eines sagen: Auf einem modernen Desktop Linux läuft im Hintergrund auch nicht weniger Scheiß mit als auf Windows 10.
Ich habe Linux und Windows tlw. auch auf sehr alter Hardware verglichen (wo man das schön merkt), und die Mär vom ressourcenarmen Linux bewahrheitet sich bei modernen Standarddistros einfach überhaupt nicht mehr. Das sind maximal Propaganda oder Sonderfälle wie Damn Small Linux damals.
Es gibt aber auch signifikante Unterschiede in der NUMA Implementierung in x265, also zwischen Windows und Linux (x264 hat noch keinen NUMA Support), und da vermute ich einen Teil des Problems. Muß ich direkt Mal die Entwickler fragen, warum das so ist. Wär eh interessant (also für mich zumindest).
Die großen Distris mit Gnome, KDE, CDE, MATE und Trinity sind allesamt Ressourcenfresser. Jedoch solche Distris wie VectorLinux oder ähnlich sind genügsam. Dennoch läuft kaum noch eine davon flüssig, oder eher überhaupt auf einem 386er...
Ich werde den 265er erst mit Ryzen 2 drüber laufen lassen. Den 264er habe ich ja schon übern Xeon X5670 gejagt vor ein paar Jahren. Da schon auf Platz 49 zurück gefallen, wär wirklich mal Zeit für was neues. ?
Ist ok! Bis dahin sollte ich Mal die CPU-Z Komponente vom Bench aktualisieren, das wird langsam echt nötig.
CryptonNite: Der Linux Kernel unterstützt seit Version 3.8 keine 386er mehr. Da ist es auch egal mit welchem Compiler man baut, weil auch 486+ Assemblycode im Kernel steckt. Geht also prinzipiell nicht mehr. Zudem machen's auch die Distributoren schwer, die meisten bauen jetzt für i686, und einige wenige schon gar nicht mehr für 32-bit.