24 jadro, 64GB RAM a 1TB NVMe (diskuse)

[Ruža Becelin]

Asi bych sel do 32-core a 128GB RAM, ale jinak dobry

[cbrpnk]

Take nevyuzijes ...

[Bystroushaak]

Taky trochu uvažuji o novém PC. Co jsi vybral za ostatní komponenty a jakým rozhodováním jsi se řídil?

[cbrpnk]

Riadil som sa svojim budgetom (600 eur) 480 eur ma vysla skrinka + zdroj + MB + CPU + RAM + chladenie na NVMe a 90 eur 1TB NVMe disk. Komponenty zatial neprezradzam, ale kludne si mozes tipnut na com bezim a co s budgetom 600 eur prekona vo vypoctoch hravo zostavu s Ryzenom 7 3800x, 32GB RAM bez ECC a trosku vacsim 4TB NVMe a RTX grafikou (ktoru nevyuzijem) za cca 3036 eur...

[User682]

Za ty penize je to hodne pekny.

Vas rozpocet se skoro rovna zlevneni meho CPU (3990x) asi 1.5 mesice po nakupu. Z toho by se clovek preskocil.

Ted jsem minuly tyden prohrabaval kufry se sbirkou stareho HW (zejmena ISA zvukovek) a kdyz jsem se podival za kolik se ruzne komponenty prodavaji, tak jsem se nestacil divit. Tohle potesilo.

gf

[BFU]

Muzete sem dat build time Linux 5.9-rc7 , fb0155a09b02 ("Merge tag 'nfs-for-5.9-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs") ?

$ git clean -fqdx ; make allmodconfig ; time make -j136 >/dev/null

[User682]

Jasne. Mohu. Mrknu se na to az zacatkem pristiho tydne.

Ted mam konecne dovolenou a jediny HW, co u sebe mam, je notebook.

Je ten parametr -j136 spravne ? Mam jen 128 threadu. Ale mozna to potrebujete v ramci nejakeho testu.

gf

[BFU]

Asi je to docela jedno, viz diskuse nize. Me spis zajima, jestli je nejaky vyrazny rozdil mezi ruznyma konfigracema tech 3990x. Ono jich moc neni, takze kazdy datapoint dobry.

[User682]

time make -j136 >/dev/null

real    3m28,390s
user    277m59,201s
sys     93m26,355s

Moc pekny test. Load i 140. Asi 9GB RAM obsazeno. Krasna barevna hudba v htop aplikaci...

gf

[BFU]

A verze gcc, binutils a jadra ? Ze to bere tak moc sys a malo user.

[User682]

Kernel: 5.5.0-0.bpo.2-amd64.

gcc version 8.3.0 (Debian 8.3.0-6)

binutils 2.31.1-16

[Heron]

Hele, podotýkám, že nechci rejpat, ale jsou ty výsledky v pořádku? Trklo mě do očí čas kompilace ffmpeg, na FreeBSD se mi to kompiluje z portů každý týden a můj čas na FX8350 (8 jádro, bulldozer, rok 2013) je:

real    2m21.664s
user    14m14.284s
sys     0m46.734s

Na o sedm let mladším 24 jádře ještě navíc s hyperthreadingem bych čekal jiné výsledky.

Potom sysbench (tam je to ještě horší):

[tomas@bsd ~]$ sysbench --test=cpu --threads=8 --cpu-max-prime=20000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.20 (using system LuaJIT 2.0.5)

Running the test with following options:
Number of threads: 8
Initializing random number generator from current time


Prime numbers limit: 20000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  4668.40

General statistics:
    total time:                          10.0015s
    total number of events:              46700

Latency (ms):
         min:                                    1.69
         avg:                                    1.71
         max:                                   20.45
         95th percentile:                        1.73
         sum:                                79990.98

Threads fairness:
    events (avg/stddev):           5837.5000/7.68
    execution time (avg/stddev):   9.9989/0.00

4668 vs tvých 9544. Jen 2x rychlejší?

7z b 21MB/s vs 60MB/s. Třikrát rychlejší na trojnásobném počtu jader.

Já předpokládám, že bude spíš chyba ve vybraných testech.

[Heron]

Ok, tak v linuxu na Ryzen7 a sysbench na 16cores ukazuje 5045.65. Je to nesmyslnej test (nebo to špatně interpretuju).

[cbrpnk]

tak navrhni nejake testy

[Heron]

Nevím, testy CPU nedělám. Zrovna jsem testoval povray3.7 (poslední, ale už taky pěkně starej, takže instrukční sady ze středověku) a fx8350 vs Ryzen7 vychází: 698s / 301s. Což bych tak čekal.

povray +H1500 +W1000 +A0.3 +I/usr/share/povray-3.7/scenes/advanced/benchmark/benchmark.pov +Obenchmark1.png -display0

[cbrpnk]

==== [Rendering...] ========================================================
Rendered 1500000 of 1500000 pixels (100%)
----------------------------------------------------------------------------
Render Statistics
Image Resolution 1000 x 1500
----------------------------------------------------------------------------
Pixels:          1595000   Samples:         2525283   Smpls/Pxl: 1.58
Rays:            8741004   Saved:             24198   Max Level: 12/12
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Box                          163032146        60919659     37.37
Cone/Cylinder                204855262        40781800     19.91
CSG Intersection             764834624       375101774     49.04
CSG Merge                      1717653          219983     12.81
Fractal                        3719075          676201     18.18
Height Field                   4595315          567307     12.35
Height Field Box               4595315         3668307     79.83
Height Field Triangle         18731893          587065      3.13
Height Field Block            29610461         9100201     30.73
Height Field Cell            121793197        10290618      8.45
Isosurface                    73731445         3165958      4.29
Isosurface Container          73734104        73734098    100.00
Isosurface Cache                890913           41948      4.71
Mesh                           3005052          374594     12.47
Plane                        584462708         5048859      0.86
Sphere                      1185687507       460559036     38.84
Superellipsoid                 1223024          357449     29.23
Torus                         10451875         2480051     23.73
Torus Bound                   10451875         2823537     27.01
True Type Font                 1714924          534237     31.15
Clipping Object               11427559         5078452     44.44
Bounding Box                3053287232       866293983     28.37
----------------------------------------------------------------------------
Isosurface roots:          73681945
Function VM calls:       1009612229
----------------------------------------------------------------------------
Crackle Cache Queries:         3001177
Crackle Cache Hits:            2988956 (100 percent)
----------------------------------------------------------------------------
Roots tested:               2823537   eliminated:              1807075
Media Intervals:          253454603   Media Samples:        2285354915 (9.02)
Shadow Ray Tests:         591417363   Succeeded:             336539935
Shadow Cache Hits:         15671260
Reflected Rays:             1150308   Total Internal:                4
Refracted Rays:              812100
Transmitted Rays:           2549335
----------------------------------------------------------------------------
Number of photons shot:           36326
Surface photons stored:           13877
Gather function called:         4652478
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
  Photon Time:      0 hours  0 minutes  2 seconds (2.528 seconds)
              using 51 thread(s) with 2.937 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  3 minutes  1 seconds (181.613 seconds)
              using 48 thread(s) with 8380.868 CPU-seconds total
POV-Ray finished

Dobre ci zle ?

[Heron]

181s tj o 40% rychlejší, než ten Ryzen7 (1700). Nevím no.

Copak je to přesně za CPU?

[cbrpnk]

Zatial CPU neprezradzam, ale skus si tipnut... Vsetko su to serverove komponenty v klasickej ATX skrini...

[cbrpnk]

Skus skompilovat FFmpeg ako ja z githubu na tom FX8350 ...

[MadCatX]

Taky mám dojem, že ti to někde drhne:

FFmpeg git master na Ryzen 4750U:

# time -p (./configure && make -j16)
real 120,84
user 1492,80
sys 80,48

a to jsem u toho měl puštěný seriál. Když vynechám ./configure, je to ještě o cca 25 sekund rychlejší. Podle konfigurace jader bych CPU odhadoval na nějaký intelí WhateverLake. Nechybí ti třeba aktuální mikrokód, kvůli čemuž se používají nějaké neefektivní MDS mitigace?

[cbrpnk]

Nechybí ti třeba aktuální mikrokód, kvůli čemuž se používají nějaké neefektivní MDS mitigace?

Netusim

$ time -p (./configure && make -j48)
...
...
real 75,88
user 2000,01
sys 114,32

[MadCatX]

U kompilace FFmpegu bych věřil, že na těch 48 jader už nenaškáluje ale i benchmark 7zipu mi vychází v podobném poměru:

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=cs_CZ.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs AMD Ryzen 7 PRO 4750U with Radeon Graphics (860F01),ASM,AES-NI)

AMD Ryzen 7 PRO 4750U with Radeon Graphics (860F01)
CPU Freq: 32000000 32000000 32000000 64000000 32000000 85333333 512000000 1024000000 682666666

RAM size:   31393 MB,  # CPU hardware threads:  16
RAM usage:   3530 MB,  # Benchmark threads:     16

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:      25918  1396   1806  25214  |     447892  1560   2449  38201
23:      32141  1424   2300  32748  |     447143  1559   2482  38687
24:      30387  1447   2258  32672  |     446024  1581   2476  39150
25:      29190  1470   2267  33329  |     432466  1568   2455  38488
----------------------------------  | ------------------------------
Avr:            1434   2158  30991  |             1567   2465  38632
Tot:            1501   2312  34811

Mrkni na dmesg | grep -i microcode... ale může to být cokoliv.

[cbrpnk]

Mrkni na dmesg | grep -i microcode... ale může to být cokoliv.

A sme doma:

dmesg | grep -i microcode
[    0.334099] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0xffffffff (or later)
[    0.639209] TAA: Vulnerable: Clear CPU buffers attempted, no microcode
[    0.639210] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    1.895463] microcode: sig=0x306f1, pf=0x1, revision=0x14
[    1.897512] microcode: Microcode Update Driver: v2.2.
[    2.667524] [drm] Loading JUNIPER Microcod

co s tym ? intel-microcode nainstalovany...

[MadCatX]

Podívej se, jestli existuje soubor /boot/intel-ucode.img a jestli je initrd v GRUBu zadán cca takto:

initrd	/boot/intel-ucode.img /boot/initramfs-linux.img

Na LM to může být trochu jinak ale v každém případě musí být /boot/intel-ucode.img jako první ramdisk. Pokud je pro ten CPU k dispozici nějaký aktuálnější mikrokód, měl by se provést early update, což bude vidět v dmesg.

[cbrpnk]

Podívej se, jestli existuje soubor /boot/intel-ucode.img

Nie

a jestli je initrd v GRUBu zadán cca takto: initrd /boot/intel-ucode.img /boot/initramfs-linux.img

Nie

[MadCatX]

No, to je ono. Jaký je správný postup pro zprovoznění early microcore updatu na Mintu bohužel nevím. Není ten CPU náhodou nějaký starý Broadwell? Tomu by pak ten výkon totiž možná odpovídal...

[BFU]

Ono se rika, ze se ma kompilovat s `nproc` + 1 , aby tam byl hned dalsi job kdyz na nejakem jadre job dobehne. Na threadripperu bude asi lepsi mit + 1 pro kazdy coreplex, takze asi nejake make -j 144 nebo tak neco.

[cbrpnk]

make clean && make defconfig && time make -j 144
...
...
Kernel: arch/x86/boot/bzImage is ready  (#2)

real	1m48,233s
user	58m55,211s
sys	5m52,576s

[BFU]

Tim 144 jsem chtel rict, ze pocet logickych jader co mas + neco malo navic. Jestli mas min logickych jader (48?) a pouzijes moc velke -j N, tak ti bude akorat thrashovat scheduler, protoze bude prehazovat procesy na jadrech (vic task switchu, min uzitecneho pocitani).

Ale ted jsem si ten kernel zkusil zkompilovat v tmpfs a ono to skutecne nema nejaky velky vliv, nicmene to bude nejspis dane tim, ze velka cast toho buildu pak bezi na jednom jadre, kdyz se linkuje vmlinux (linker blbe parallelizuje, proto tam jsou ty built-in.o v kazdem adresari, ty se pak slinkujou do vmlinux, a to bezi na jednom jadre a chvili to trva).

Na kompilovani by mohl byt dobry benchmark treba libreoffice nebo neco podobne velkeho, popr. rovnou nejaky build treba gentoo.

[Michal Kubeček]

Říká se ledacos, taky se říkalo, že se má dát dvojnásobek. Asi před rokem jsem to ze zvědavosti zkoušel měřit a vyšlo mi, že nemá smysl používat víc než počet threadů.

[BFU]

No vzdyt to pisu o prispevek vyse taky. On mozna taky ten kernel neni uplne idealni workload.

[kvr]

To se říkalo v době, kdy bylo málo CPU, málo RAM a pomalé IO. Tedy, RAM bylo dostatek na to, aby se tam vlezly kompilátory pro všechny CPU (a něco navíc), ale velikost kernelu na disku tu RAM značně převyšovalo. Takže ten jeden či dva job navíc zaplnil díru, kdy nějaký jiný byl blokovaný na IO.

Dneska je situace, že zdrojáky se během chvilky dostanou do cache (navíc s ohledem, že čekání na SSD či NVMe je minimální), takže není nic, co by CPU brzdilo.

Argument, že to zaplní díru, než nastartuje jiný job poté, co předchozí skončí, je nesmysl. Kernel tu zprávu o exit předá make okamžitě a stejně tak make okamžitě vyhodnotí další job a pustí jej - CPU se tedy nenudí ani na chvilku. Pouze, pokud dva jobs skončí úplně ve stejném čase, v takové situaci by na chvíli mohl být make úzkým hrdlem, nicméně extrémně krátkou a prakticky zanedbatelnou...

[BFU]

Ten skok do userspacu a zpatky taky neni zadarmo, a make rozhodne nefunguje uplne okamzite. Nicmene, nema smysl se o tom hadat, staci na to pustit perf a podivat se, kolik casu ten procesor cim travi

[kvr]

Skok do userspace zadarmo není, ale pořád je při něm plně zatížen CPU. Jiný proces v té době prostor dostat nemůže.

[BFU]

No a co kdyz mas v scheduleru rovnou dalsi process, co uz je ready a muze zacit bezet, treba dalsi instanci kompilatoru. Nemuze ji ten kernel treba pak rovnou naschedulovat, bez toho aby scheduloval make ?

[kvr]

Proč schedulovat kompilátor, když make už je v té době ready? Obojí vyžaduje CPU, takže v tom není žádný rozdíl.

(ve skutečnosti v tom rozdíl je, negativní, protože make má zanedbatelný load, takže stejně bude mít prioritu a poté, co pustí další kompilátor, tak to bude vyžadovat context switch navíc (a samozřejmě spoustu dalších později při střídání N+1 procesů na N CPU)).

[BFU]

Pokud ti bezi make chvili jenom proto, aby zjistilo, ze potrebuje naplanovat compiler, tak je to docela k nicemu. Pokud mas rovnou k dispozici compiler, tak ho proste naplanujes a make chvili pocka. Cim vic proces udela v jednom casovem kvantu, tim min task switchu potrebujes a tim mene cyklu promrhas tema task switchema, tj. MCCCC je optimalnejsi nez MCMCMCMC (M-make C-compiler).

[kvr]

Už trochu se zpožděním, ale abychom nemátli budoucí náhodné čtenáře...

MCCCC by bylo v případě, když by čtyři kompilátory skončily přibližně ve stejné době a zároveň make měl vysoký load a v důsledku nízkou prioritu. To první je silně nepravděpodobné, to druhé je zcela nereálné, neboť make (na rozdíl od kompilátoru) prakticky nic nedělá. Takže make obvykle dostane přednost před kompilátorem, spustí další kompilátor a ty se pak mezi sebou můžou zbláznit přes context switch.

Při N kompilátorech na N CPU naopak ke context switch dochází pouze v případě, kdy se proces sám o sobě dobrovolně suspenduje (make - pustí další proces a čeká na child exit, kompilátor - vlastní exit), tedy pouze v nutných situacích, kdy by k tomu stejně došlo. Na jednom CPU izolovaně tedy proběhne při exit kompilátoru jednoduchý switch C-M-C a jede se dál...

[Michal Kubeček]

Už jsem to tu psal dříve: "make defconfig" vyrobí konfiguraci, která je nerealistická a hlavně příliš chudá, aby se využilo tolik procesorů. Jestli chcete testovat výkon 24-jádrového procesoru při překladu jádra, tak místo toho použijte "make allmodconfig".

[cbrpnk]

ok, takze:

$ make clean && make allmodconfig && time make -j 48
real	17m34,207s
user	704m17,333s
sys	68m26,675s

[Michal Kubeček]

Paralelizuje to docela slušně, poměr celkového spotřebovaného času CPU a "real" vychází přibližně 44. Ale výkon na jedno jádro asi nebude moc hvězdný, protože na Ryzen 3900X (12 jader, gcc 7.5.0, překládal jsem aktuální mainline - commit fb0155a09b02) mám

  ...> make -j24 allmodconfig && time make -j24 >/dev/null
  ...
  real    8m46.714s
  user    180m29.398s
  sys     20m25.186s

[cbrpnk]

Paralelizuje to docela slušně, poměr celkového spotřebovaného času CPU a "real" vychází přibližně 44. Ale výkon na jedno jádro asi nebude moc hvězdný, protože na Ryzen 3900X (12 jader, gcc 7.5.0, překládal jsem aktuální mainline - commit fb0155a09b02) mám

asi by sme mali pustat rovnake commandy a rovnake GCC, ale uznavam ze na 3900x asi mat nebudem

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

cize skusim este raz:

make clean && make -j48 allmodconfig && time make -j48 >/dev/null
...
...
real	16m51,505s
user	692m6,255s
sys	66m15,762s

Tak je to pomalsie ako Ryzen 3900x ale zase Ryzen stoji (445 eur) skoro ako moja cela masina (480 eur)

[Michal Kubeček]

Tak gcc9 (9.3.1) je trochu pomalejší (jednak je obecně pomalejší, jednak jsou s ním zapnuté některé volby navíc, hlavně CONFIG_KASAN a související):

  real    9m35.167s
  user    198m34.368s
  sys     20m48.244s

Co se toho přesměrování výstupu týká, chtěl jsem měřit build a ne rychlost terminálu (který je navíc přes ssh). Většinou to ale takhle spouštím i normálně, protože jsou pak lépe vidět warningy a případnou chybu nemusím hledat kdesi daleko v historii.

[cbrpnk]

/ram/linux-5.13.8# make clean && make -j48 allmodconfig && time make -j48 >/dev/null
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#

real    10m32.796s
user    431m38.799s
sys     39m16.563s

gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[xsubway]

Pěkný stroj, jen si trochu rejpnu: nemůže to někdo kompilovat za tebe? :D [řečnická otázka]

Prosím foto! Teda toho stroje :)

[cbrpnk]

Pěkný stroj, jen si trochu rejpnu: nemůže to někdo kompilovat za tebe? :D [řečnická otázka]

¯\_(ツ)_/¯

Prosím foto! Teda toho stroje :)

Pridam, ale az ked niekto uhadne CPU Teda pridam urcite - aj ked neuhadne

[User682]

zdravim,

gratuluji k vykonu. Vitejte v klubu..

Zeptam se.

1) Jakou radu Threadripperu mate ? 2970X nebo 3960X ? 2XXX rada je precijenom o dost pomalejsi.

2) Co presneji delate ? "Kompilovanie, virtualizácia". Kolik virtualu/instanci Vam bezi v jednom case ?

3) Kompilace v jakem jazyce ?

4) Co pamet ? Neuvazoval jste vzhledem k velikosti disku a cache rovnou o 128GB ?

diky, gf.

[cbrpnk]

zdravim,

Zdravim

gratuluji k vykonu. Vitejte v klubu..

Dakujem.

1) Jakou radu Threadripperu mate ? 2970X nebo 3960X ? 2XXX rada je precijenom o dost pomalejsi.

Je to Intel, zatial viac neprezradzam...

2) Co presneji delate ? "Kompilovanie, virtualizácia". Kolik virtualu/instanci Vam bezi v jednom case ?

caste kompilacie zdrojakov programov, virtualizaciu este len rozbieham, nakolko stroj mam 24 hodin - ale otestujem subezne bezanie virtualok (moja potreba bude tak 3 - 7 sucasne max).

3) Kompilace v jakem jazyce ?

C, C++, python, obcas Java

4) Co pamet ? Neuvazoval jste vzhledem k velikosti disku a cache rovnou o 128GB ?

Doska ma podporu 512GB RAM, takze casom az budu nejake volne financie do 128/256 GB asi pojdem.

[kvr]

Pěkná mašina, o tom žádná. Ale k čemu to je? . Jenom pro zvědavost, jaký to má průměrný load?

PS: Ne, že bych v práci dříve nepoužil 64 CPU s RAM v řádu stovek GB, ale na desktop? Předpokládám, že vývoj běží na nějakém rozumném vzorku, nikoliv produkčních datech...

[cbrpnk]

Pěkná mašina, o tom žádná. Ale k čemu to je? .

Na také to domáce chrumkanie Nerád akosi čakám, všetko chcem aby sa vykonalo rýchlo, a posledné 4 jadro mi už nestíhalo

PS: Ne, že bych v práci dříve nepoužil 64 CPU s RAM v řádu stovek GB, ale na desktop?

A tak niekto používa ako hlavné PC aj Duron ci Athlon XP aj v dnesnej dobe, ale preco ked su ine moznosti ?

Předpokládám, že vývoj běží na nějakém rozumném vzorku, nikoliv produkčních datech...

Jj

[User682]

Delam ted na jednom projektu (BigData+data-mining), kde produkcni vstupni data slouzi i pro vyvoj. Je to zajimave, ze obcas se ty hranice mezi produkci a vyvojem mohou smazat. Na nejake lepsi nahodne regresni otestovani je to take zajimave.

Ale to neni bezny postup a ani bezny projekt. Jinak samozrejme vetsina vyvoje a testy jedou nad malymi vzorky dat.

gf

[Blaazen]

Já hádám tohoto fešáka.

[cbrpnk]

Nie Ale parametre su skoro presne rovnaké (takt, cache, vykon - akurat moj setup ma vyššie TDP)

[Ondřej J]

Jako na hraní fajn, ale paradoxně nějaké novější osmijádro by mohlo mít i lepší výkon, protože na 24 jader spoustu věcí neškáluje. A elektřinu bych asi taky platit nechtěl.

[cbrpnk]

Koľko myslíte že ta zostava berie v idle ?

[Michal Kubeček]

paradoxně nějaké novější osmijádro by mohlo mít i lepší výkon, protože na 24 jader spoustu věcí neškáluje

Podle toho porovnání s 3900X by současný osmijádrový procesor nejspíš měl o něco vyšší výkon i v dobře paralelizovatelných úlohách.

[veteran z vietnamu]

to je mozne, ale za nove 8 jadro s 64 GB DDR4 ECC RAM (podporuju ich ryzeny vobec?) by dal nad 1200 eur...

[Michal Kubeček]

A proč by to dělal? Ryzen 3800XT (TDP 105 W) se dá pořídit za 394.90 EUR, Ryzen 3700X (TDP 65 W) dokonce za 311.90 EUR a k tomu 64 GB paměti (jako 2x32, aby zůstala rezerva na další rozšíření) za 241.60 EUR. Ať počítám, jak počítám, vychází mi to tak na polovinu toho, co tvrdíte.

[okolosediaci]

tie RAM su ECC?

[Michal Kubeček]

Nejsou (kdybyste kliknul na ten odkaz, nemusel byste se ptát). ECC by byly za 329.80 EUR, tedy o něco dražší (a pomalejší), ale pořád v součtu hluboko pod těmi "nad 1200 eur".

[johnyK]

kouknul jsem se po netu a daj se sehnat i za 300 Euro, ale stejne je otazka, jestli to ma na desktop cenu.

[Michal Kubeček]

Na to se názory různí, sebe jsem zatím nepřesvědčil, že by mi to za to stálo. Sice je pravda, že kdybych měl ECC paměti, identifikoval bych problémy s kompatibilitou pamětí, na které jsem začátkem roku narazil, rychleji a jednoznačněji, ale na druhou stranu je docela možné, že bych pak měl jiné problémy s kompatibilitou a měl bych je dodnes. :-)

[Petr Fiedler]

Nejsou (kdybyste kliknul na ten odkaz, nemusel byste se ptát). ECC by byly za 329.80 EUR, tedy o něco dražší (a pomalejší), ale pořád v součtu hluboko pod těmi "nad 1200 eur".

Myslím, že RDIMM by mu byly s Ryzenem na nic.

[Petr Fiedler]

Za relativně dobrý peníz (5k Kč) 2x tohle (Česko). Tady je to na webu výrobce.

[Petr Fiedler]

Ale koukám, že ty Haswelly zvládnou jen 2133 MHz, takže by se cena dala možná ještě trochu stlačit.

[okolosediaci]

a kde je doska, chladic, grafika, skrinka, zdroj? hmmm?

[Michal Kubeček]

O těch v komentáři, na který jsem reagoval, nebylo ani slovo. Ten pouze tvrdil něco o tom, kolik by autor údajně dal za procesor s pamětmi. Hmmmm?

[Nie som robot]

Ale ved berieme celu zostavu, alebo staci CPU a RAM a mozeme virtualizovat ? Tych 1200 eur som pochopil za celu zostavu s Ryzenom... A Ryzen potrebuje grafiku a tak sa mi zda ze aj maticnu dosku a zdroj, ale niesom si tym isty ... Cela zostava s Ryzenom bude okolo 1000 - 1200 eur s ECC RAM, grafikou a doskou a vsetkym co k funkcnosti zostavy treba ...

[Michal Kubeček]

Ale ved berieme celu zostavu, alebo staci CPU a RAM a mozeme virtualizovat?

Někde se zastavit musíme. Ten příspěvek tvrdil naprosto explicitně: "za [procesor] s [paměť] by dal [částka]". Tak jsem ho bral tak, jak byl napsaný, a nezkoušel hádat, jestli bych k tomu měl počítat i case a zdroj (které mi typicky vydrží nejméně deset let), případně i disky (které mají u mne naprosto nezávislý životní cyklus) nebo snad kompletní počítač, případně i počítač s monitorem.

Ale to je celkem jedno, tenhle thread byl od začátku spíš o tom, že jakkoli "24-jádrový procesor" budí respekt, v porovnání se současnou produkcí to až takové dělo vlastně moc není.

[User682]

Uz jsem to zkousel si pustit par virtualu (uzivatel uvadi - 3-7), nejake preklady kodu, nejake vyvojove prostredi na 8 jadru a teda reknu Vam nic moc. Kazde jadro se pocita.

Jasne, ze se to da spustit i na 4 jadrovem notebooku nebp PC, ale neni to ono. Ale je to levnejsi.

Vcelku by me zajimaly nejake vypocty kolik to sezralo energie. 1-2 stovky mesicne ? I kdyby to bylo 5-8 stovek, tak to je uplne krasne na to, co se s tim da delat a ze vubec nektere veci muzete delat. Me to prijde, ze kdyz ma nekdo nadupanou grafiku v PC a hraje hry po vecerech, tak ze je to OK. Pokud si koupite procesor se spotrebou 200W v plne zatezi, kterou nemate furt, tak ze je to uz spatne.

Delal jsem ted nejake kalkulace na uziti Amazon EC2 ci jineho cloudu na nejake distribuovane vypocty a operace. Mam na mysli placene sluzby. Je to hodne zajimave. Priznam se, ze si nejak moc nedovedu prestavit, ze nektere veci budu zkouset na 2-4 jadrovem notebooku. Nebo, ze by mne to vubec napadlo kdysi neco takoveho delat. A prave ty vykonne masiny doma jsou dobry zacatek. Nejake skalovani aplikaci se pod 10 jader vubec nenaucite.

gf

[Michal Kubeček]

Uz jsem to zkousel si pustit par virtualu (uzivatel uvadi - 3-7), nejake preklady kodu, nejake vyvojove prostredi na 8 jadru a teda reknu Vam nic moc.

To se nedá říct takhle obecně, záleží na tom, co ty virtuály mají dělat. Kdysi jsem běžně používal sadu 12 virtuálů na hostu, který měl čtyřjádrový Phenom 9750 a 8 GB paměti (původně dokonce 6 GB) a žádný problém s tím nebyl, protože nepotřebovaly moc paměti a neběželo na nich nic náročného na procesor.

Spotřeba v plné zátěži je zajímavá spíš pro nasazení, kde to v té plné zátěži běží buď trvale nebo podstatnou část doby, ale to je obvyklé spíš u serverovů. Typický desktopový uživatel, i když spouští věci náročné na CPU, stejně většinu času procesor moc nezatěžuje, takže pro celkovou spotřebu důležitější ta klidová.

[Ondřej J]

Souhlasím, a ten nákup chápu.

Ale přirovnání by bylo spíš koupit na hraní nějakou žravou grafiku, která má výkon jako dnešní grafiky s poloviční i menší spotřebou a relativně nízkou cenou.

[pushkin]

Repas za 10 000,-?

[freehate]

a? mas nejaky lepsi tip za 10 000 na vykonnu zostavu?

[pushkin]

Ne, jenom že mě docela překvapily ty postarší komponenty (hlavně procesor). S novými věcmi by se to samozřejmě výkonnostně překonalo, ale i ta cena by byla jinde...

[robotek]

Jako Genuine Intel CPU se často označují levné preprodukční Xeony z Činy s falešnou nálepkou, je toho plný ebay.

[okolosediaci]

alebo aj Engineering sample a su podla teba akoze fejky?

[robotek]

Nenapsal jsem že jsou fejky, alespoň dokud je číňan nepřelepí. Procesor přece nemůže být "fejk", na to by se přišlo rychle.

[karel]

Když to srovnám s výkonem 2 roky starého notebooku za 15000 s předminulou generací ryzenu, tak mi to přijde dost bídný a moc bych se takovou "dobrou" koupí nechlubil (cca. 3,5x lepší výkon u procesoru s 6x méně jádry a zhruba 10x menším TDP). Další benchmarky nemá cenu zkoušet. Já bych teda šel na hraní do něčeho inteligentnějšího nebo do cloudu. IMHO i moderní notebook je pro učení se paralelizace nebo vývoj lepší volba (i když teda za víc peněz, ale zase ne o tolik aby to pro lidi z IT hrálo roli, pro ostatní je něco takového totální nesmysl).

$ 7z b

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx (810F10),ASM,AES-NI)

AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx (810F10) CPU Freq: 64000000 - - - - - - - -

RAM size: 15507 MB, # CPU hardware threads: 8 RAM usage: 1765 MB, # Benchmark threads: 8

Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS

22: 17024 650 2548 16562 | 230166 789 2490 19632 23: 16562 654 2580 16875 | 222431 791 2435 19249 24: 16243 655 2667 17465 | 219539 792 2434 19269 25: 15898 658 2759 18153 | 216505 793 2431 19268 ---------------------------------- | ------------------------------ Avr: 654 2638 17263 | 791 2447 19354 Tot: 723 2543 18309

[cbrpnk]

Mizerný výkon máš veru, mizerný... a ešte ani príspevky nevieš kultúrne napísať, by som sa neozýval na tvojom mieste takto verejne...

[karel]

* 3,5x horší výkon ...

[cbrpnk]

Hehe to určite

[freehate]

Dle mistnich komenaru je to totalni nevykonna sunka hodna tak 50 eur max. a vykonne jsou iba Ryzeny bez ECC

[karel]

Vykonove to odpovida dnesnim ultrabookum, takze jak pises, nevykonna sunka.

Ale piču s ryžou...

[cbrpnk]

jasnéééé, tak to je

[mimi.vx]

v okamziku kdy do tabulky pridas spotrebui tak je to navic nenazrana nevyukonna sunka, vicemene muzes mit jader kolik chces ale pokud je mas 5 a vice let stara tak vykon nebude nikdy nic moc a spotreba bude o to vice bolet

[Napájení PCIe slotů?]

Jak je to u serverových MB s napájením poskytovaným z PCIe slotů? Při osazení non-serverovými kartami mohou tyto částečně spoléhat na energii ze slotu (až 75W u PCIe16x). U desktopových MB (a ojediněle i WS/serverových) se za tímto účelem na MB vyskytuje přídavný PCIe 6pin. Serverové MB sice kromě ATX24 mají i 2x EPS12V 8piny, ale netuším zda z nich kromě CPU/RAM získává energii i MB.

Nedostupnost 64GB unbuffered DDR4 DIMMů pro TRX4 diskvalifikuje tuto platformu pro paměťově náročnější úlohy, WS Threadrippery jsou předraženým HW pro ty co nezajímá jejich certifikace. Snad Zen 3 EPYCy přidají pár set MHz boost a base taktů, aby se trochu sevřely nůžky ST výkonu. A snad se konečně (po více než roce od uvedení Epyc Rome) dočkáme varianty dual-socket SP3 MB s PCIe4/3200 pro DIY trh.

[xxxs]

vies zmerat spotrebu? zataz a aj klud?

[cbrpnk]

Zmerané, idle 50 - 60W, load 180 - 250W.