Názory k článku
AMD uvede Threadripper 2 s 32 CPU jádry a 7nm GPU

Podle vyjádření zástupce AMD by měl stačit u stávajících X399 (s dostatečně silným VRM) pouze update BIOSu.
https://youtu.be/E73H8HvqjEM?t=71

Otázkou je, zda jsou na stávajících X399 vzájemně propojeny DRAM moduly, nebo je jejich obsluha záležitostí pinů z CPU. V takovém připadě by asi šlo dosáhnout i octa-channel DRAM.

Co jsem koukal na ten záznam tak AMD docela dost dotahlo podpory softu od každého trochu (to nejvyužívanější, možné je, že to pak bude fungovat i u derivátů). Chválihodné.

Jaký specifický use-case takový procesor na desktopu má řešit?

Nebude pak ve většině případů úzké hrdlo někde jidne? North/south bridge? Jak jsou na tom v současnosti paměti? Za mého mládí se hodně řešil dual channel - dělá se teď něco jako hexa channel?

Pravděpodobně Tr 32c bude mít také quad-channel (jedině, že by se DIMM banky obsluhovaly samostatnými piny CPU již nyní a 32c verze by je teď využila pro octa-channel ... nepravděpodobné).

TR 1950X provozuji s 4x 8GB DDR4 3200MHz/CL14(quad-channel RAM). Nativně mi na něm běží Linux a virtuálně Windows 10(KVM/GFX_pas­sthrough). Tak v rámci jednoho PC mám k dispozici výkon právě na té platformě kde jej zrovna potřebuji. Kompatibilitu se starším světem aplikací/her mi zajištují virtuální WindowsXP s dedikovanou HD5770. Výhoda TR platformy je také v dostatku PCIe linek přímo z CPU (60?) umožňující obsloužit více zařízení, v mém případě 3x GPU(16x,16x,8x) a 2xNVMe (4x,4x). Ideální asi je, pokud se úlohy vejdou převážně do L3 cache (32MB).

Pri využití projektu Looking Glass je možné výstup v rámci Windows 10 GuestOSu zobrazit na LCD HostOSu.
https://looking-glass.hostfission.com
Prakticky: http://www.monitos.cz/tmp/paralel_GPU_load.jpg

Těmi Win7 jako GuestOS s GFX passthrough si nejsem moc jist. Také to byl také primárně můj cíl (volná FPP licence W7), ale nakonec jsem pořídil další licenci W10 pro VM (ještě to asi někdy zkusím). Mám pocit, že Looking Glass je snad podporováno jen pro W8,W10.

Těch zdrojů bylo hodně, na všechny si asi nevzpomenu. Každopádně je třeba mít na paměti, že jde o "vyšší dívčí" s extrémní citlivostí na kombinaci HW/SW (funkční řešení je zde spíše vyjímkou než pravidlem). Asi je nelepší inspirovat se podle success-stories ve fórech (v češtině toho na toto téma asi moc nebude).

HostOS je Xubuntu 17.10x64 (aktuálně s vannila 4.16.12 + gnif patchem .. pro Tr reset bug)
K virtualizaci používám KVM/QEMU z command line (bez libvirt).

HostOS využívá GTX 960 (Geforce 396.24beta?).
GuestOSy využívají ASUS STRIX GTX1080Ti OC(variantně W10 a FreeBSD), ATI HD5770(Windows XP)

ostatní HW: Asrock X399 Taichi (BIOS 2.0), Tr 1950X, 4x G.SKILL Flare-X 8GB 3200/CL14, 2xNVMe, SSD, HDD, PSU:Corsair RM1000x, case: Corsair 750D Obsidian, 2x USB SND, 2xUSB Eth, 3x KB/MS, ...

gnif patch
https://forum.level1techs.com/t/threadripper-reset-fixes/123937/6

asi největší studnice z oblasti PCI passthrough
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF

Looking Glass
https://looking-glass.hostfission.com
https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387

Level1Linux Channel
https://www.youtube.com/channel/UCOWcZ6Wicl-1N34H0zZe38w

Z řešení dílčích problémů mám pár dalších odkazů v záložkách:
https://www.maketecheasier.com/build-custom-kernel-ubuntu/
Workaround umožňující využití boot VGA (GTX 1080Ti) pro GuestOS. https://github.com/Matoking/NVIDIA-vBIOS-VFIO-Patcher/blob/master/nvidia_vbios_vfio_patcher.py
https://forum.level1techs.com/t/qemu-libvirt-sata-disk-performance/124115
https://docs.fedoraproject.org/quick-docs/en-US/creating-windows-virtual-machines-using-virtio-drivers.html#ISO_contents

Tak to vypadá, že i ty Windows 7 by mohly být dosažitelné (instalace na výchozí VM v libvirt/virt-manager a poté .xml opraven/doplněn o "GFX_passthrough" related tagy).

http://www.monitos.cz/tmp/libvirt_gfx_passthrough_win7.png

Vzhledem k tomu, ze hardwarove pozadavky softwaru dle Parkinsonovych zakonu rostou vzdy tak, ze plne vytizi nebo pretizi dostupnou kapacitu, budes v roce 2020 potrebovat 16 jader @3.5GHz jenom na to, aby prohlizec dokazal zobrazit listu se souhlasem se zpracovanim osobnich udaju, a 128 jader, aby pocitac s Windows 10 a standardni kolekci softwaru stihal instalovat aktualizace pro vsechno od BIOSu pres Avast az po AskToolbar rychleji, nez budou vychazet.
Dal je tu samozrejme korporat a fakt, ze Java bohuzel jeste nehodla zemrit.

Takze bud bez obav a zacni na procesor sporit do prasatka, nebo refinancuj svoji pujcku.

Takze podla Vas java je tiez jednym z dovodov pokroku vo vyrobe procesorov? Nuz ale nieco pravdy na tom bude: java sa totiz naozaj pouziva v korporatoch na kodenie aplikacii, co 'riadia svet'. A neuverite, taketo aplikacie naozaj potrebuju vykon. Z vasho komentu ale usudzujem, ze podla vas 90 percent vykonu zerie samotna java co nic nerobi.. Vy by ste tie apky urcite kodil v assembleri alebo C. Ako to robili nasi otcovia (dedovia).
Dalsi clovek, co sa javu nedokazal naucit, tak ju aspon ociernuje.

Java je univerzální zlo, bububu...
Pravda ale je, že Java má dost masařek, a ne vše, co je v ní napsané, by se nedalo udělat jinak (a lépe) v něčem jiném... A že JVM žere docela dost výkonu, a na některé věci je to prostě overkill je podle mě fakt. A na desktop ke koncákům by se dostat neměla, vzpomeňme (raději potichu) na Javu v prohlížečích, že?

Viete mi povedat meno jazyka, ktory nema mesiarky, je 100 percent bezpecny a vsetko sa v nom da urobit dobre? Nech mozme zacat sirit osvetu..

Vy si asi mylite pohodovu, funkcnu a poemrne pohodlnu Javu s neschopnym, nefunkcnym a nenazranym Javabugskriptom.
To je ale chyba, mily pane!
NEsouhlasím se zpracováním osobních údajů za účelem přidání názoru do diskuse!
Pouzitie slozby nesmie byt podmiene spracovanim osobnych udajov - precitajte si GDPR!

Plácáš nesmysly java funguje i na původnim rpi, nevim proč bys potřeboval bambilion jader.

Urcite to bude mit "uzke hrdlo"; 2x mene pametovych kanalu (4), nez EPYC (8), vyvazeno vyssi frekvenci. Ale porad lepsi, nez to, co ma Intel. Teoreticky bude mit AMD 100GB/s, pricemz Intel jenom 80GB/s. K tomu vice PCIe kanalu, takze clovek muze provozovat 4x Deep Learning GPU a M.2 PCIe na full speed. Perfektni pro VM, domaci servry, nektera typy kodovani videa nebo velike mnozstvi VSTi pluginu najednou pro delani hudby. Predpoklada se 250W, 3.0GHz base, 3.4GHz turbo. Originalni TR jiz mel redukovanou latency cache, kterou pak AMD dalo do Zen+, tak tam se toho uz moc zrejme nevylepsi. Ja premyslim, jestli to koupim pro Deep Learning/Spark, nebo pockam na Zen2 v 2019.

Tys asi hodne dlouho hibernoval ;-) Northbridge uz je spoustu let integrovan v CPU. EPYC je octachannel, Threadripper je quadchannel. Propustnost pameti (az na vyjimky) prekvapive neni problemem (viz testy na netu, kde osadi jen jeden nebo dva moduly a vynuti tim single/dual channel)

CPU<->southbridge je dostatecne propustne pro veci, ktere se tam pripojuji (1Gbit sitovka, par 3.1 USB, SATA SSD...). Co ma byt rychle se pripojuje ne pcie (nvme SSD, 10Gbit sitovky, profi diskove radice...)

PC platforma byla pravem nazyvana toy platform protoze propustnosti a latence byly proste spatne, zejmena v SMP situaci, kdy data mezi procesory tekla pres northbridge. Tohle se uz ted hodne zlepsilo.

Tady je par testu:
http://www.abclinuxu.cz/blog/Mihovy_sochory/2017/10/sestnactijadro-a-skalovani-pri-kompilaci-a-openssl

Pozn. Ten odkaz výše na testy 7960X (16ti jádro od Intelu).

Na Tr 1950X mi trvá překlad aktuálního vanila jádra 4.16.14 (příkazem "time make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom" ) 32-vláknově zhruba takto:

Build kernel 4.16.14 (na NVMe Corsair MP500 128GB)
NUMA mode 12m7s
UMA mode 12m12s

Build kernel 4.16.14 (na ramdisku 25G)
UMA mode 11m24s

Tak to mas neco spatne kdyz jemu vychazi ~17 kompilaci za 10 minut na 32 vlaknech a ~jedna kompilace za 10 minut na jednom vlakne (takove vysledky bych cekal) a tobe jedna kompilace za 11 minut na 32 vlaknech.