Live data from Hacker News

Ryzen Threadripper Pro 3995WX Spotted

guru3d.com

151–160 of 170 posts

Re: Ryzen Threadripper Pro 3995WX Spotted

#151
post #12

I feel like 64 cores is getting rather close to a tipping point: What workloads are so massively parallel that they can use 64 cores of x86 but can’t use the thousands of CUDA cores on a Quadro card? I’m sure right now there are workloads that just need particular x86 instructions, but that feels like a temporary problem. Am I wrong about that being a temporary problem (that would feel frustrating)? Are these cores j…

"Plain old" (not neural net) machine learning tasks would be sooo much faster.

Re: Ryzen Threadripper Pro 3995WX Spotted

#152
post #120

Earlier quoted context omitted.

> VERY limited memory and no virtual memory This is incorrect.

Compared to 2-4TB max in a 2 socket server system, the 16 or 32GB/card you get on a GPU is pretty small. The other issue is loading that memory - PCIe 4 is still the transfer time bottleneck between GPU and main memory.

The part about no virtual memory is kind of incorrect though. It doesn't work exactly like on the CPU, but still.

Re: Ryzen Threadripper Pro 3995WX Spotted

#153
post #85
post #12

I feel like 64 cores is getting rather close to a tipping point: What workloads are so massively parallel that they can use 64 cores of x86 but can’t use the thousands of CUDA cores on a Quadro card? I’m sure right now there are workloads that just need particular x86 instructions, but that feels like a temporary problem. Am I wrong about that being a temporary problem (that would feel frustrating)? Are these cores j…

> What workloads are so massively parallel that they can use 64 cores of x86 but can’t use the thousands of CUDA cores on a Quadro card? Building software, for one. C compilers and python interpreters don't run on a GPU. Lots of stuff doesn't run on a GPU. In fact in practice the only things that run on a GPU are the tiny handful of known subproblems that the industry has collectively decided are "GPU problems". Like…

Disclaimer: I am not a HW designer, I could very well be wrong.

It is true that there are tasks where threading matters, but still require a CPU rather than a GPU. I wonder however if these tasks do need full SSE/AVX etc. Couldn't these extensions be removed of the CPU cores and instead have the necessary work performed by the GPU?

It would be interesting to produce statistics on how much these extensions are used in these scenario. Imagine how much space and complexity could be saved on a CPU die by making stripped down versions. That space could in turn be used for more cores!

I read a little about the Xeon PHI cpus, which iirc, is a multicore CPU with a very small ISA, but I wonder why x86 makers aren't trying to go in that direction: isn't there plenty of dedicated workloads which would happily run on these (eg, web servers), or is this just a (too) simplistic view?

Re: Ryzen Threadripper Pro 3995WX Spotted

#154
post #116

Earlier quoted context omitted.

The (bit of) article mentioned 2T, but the thing that was interesting was the 8 channel memory. My current TR4 boards are doing quad, so 2 banks of 4 slots. Sounds like a single set of 8... so wonder if this is a potential BIOS update on the sTR4 or if there is a new chipset on route?

The traces are wired to CPU pins, there is no potential BIOS update to make it 8 channels from CPU pins for only 4 channels. You need different socket with double the number of pins for memory to double the number of channels. Your 4 channels with 2 slots each have the 4 channels daisy chained to 2 slots, but they are just 4 channels. With 8 channels and 2 slots per channel you can have 16 slots, with 32 GB unbuffere…

Ah... that answers my real question then. sTR4 will likely be a short lived series.

Re: Ryzen Threadripper Pro 3995WX Spotted

#155

Earlier quoted context omitted.

wasm can only do what javascript can already do, but faster. What specifically do you think wasm will change?

Threads. There's going to be a lot of 'throw threads at it and hope performance issues go away'-type solutions. https://github.com/WebAssembly/proposals/issues/14

To be clear, you are saying you don't want something powerful and fundamental to be added because you don't want to learn how to turn a feature off or learn how install an adblocker?

Not only that, but better performance is what pushes you over the edge, not popups, connection slow downs, auto playing videos or tracking?

Re: Ryzen Threadripper Pro 3995WX Spotted

#156

Earlier quoted context omitted.

What a miserable hopeless post - "they're going to fuck us and what can we do????". Answer: quite a lot, if you have even minimal technical understanding (like, enough to use a blocklist or an ad blocker). Are you incapable even of that?

Your ad blocker is going to filter a private web socket link funneling ads and content together? It's going to patch the WASM?

Why would it be difficult to turn off web sockets or turn off multi-threading? Multiple threads already run on single cores all the time, there is no reason a web browser couldn't just put them all on one core.

Re: Ryzen Threadripper Pro 3995WX Spotted

#157
post #12

I feel like 64 cores is getting rather close to a tipping point: What workloads are so massively parallel that they can use 64 cores of x86 but can’t use the thousands of CUDA cores on a Quadro card? I’m sure right now there are workloads that just need particular x86 instructions, but that feels like a temporary problem. Am I wrong about that being a temporary problem (that would feel frustrating)? Are these cores j…

We process, merge and create PDF files. Sometimes large multi-GB PDF files. We try to adjust and optimize them in parallel, but often we also need to merge different files into one for further processing, for example printing or archival. We need a lot of ram and it takes a lot of time. The more CPU, the better.

Re: Ryzen Threadripper Pro 3995WX Spotted

#158
post #12

I feel like 64 cores is getting rather close to a tipping point: What workloads are so massively parallel that they can use 64 cores of x86 but can’t use the thousands of CUDA cores on a Quadro card? I’m sure right now there are workloads that just need particular x86 instructions, but that feels like a temporary problem. Am I wrong about that being a temporary problem (that would feel frustrating)? Are these cores j…

What they call "cores" in CUDA is different from CPU cores. On GPU "cores" and "threads" refer to the ways in a SIMD ALU. Under this classification a 64 core CPU with AVX-256 like Threadripper is at least 512 cores. So 4K "CUDA cores" translates to 128 "CPU cores" when you are not doing massively parallel computations. 128 cores still is no joke but those are not Zen cores, unfortunately. On top of running off much lower clock (7nm GPUs are at ~2Ghz, 14nm is ~1Ghz) their IPC is nowhere close to that of a CPU, add advanced caches and memory controllers, branch prediction, speculative execution etc and CPU cores are much faster. A GPU will beat any CPU on a SIMD-friendly payload but it won't be any good for serving webpages or compiling code or doing any other task you cannot nicely lay out for a SIMD.

Re: Ryzen Threadripper Pro 3995WX Spotted

#159
post #85

Earlier quoted context omitted.

> What workloads are so massively parallel that they can use 64 cores of x86 but can’t use the thousands of CUDA cores on a Quadro card? Building software, for one. C compilers and python interpreters don't run on a GPU. Lots of stuff doesn't run on a GPU. In fact in practice the only things that run on a GPU are the tiny handful of known subproblems that the industry has collectively decided are "GPU problems". Like…

Disclaimer: I am not a HW designer, I could very well be wrong. It is true that there are tasks where threading matters, but still require a CPU rather than a GPU. I wonder however if these tasks do need full SSE/AVX etc. Couldn't these extensions be removed of the CPU cores and instead have the necessary work performed by the GPU? It would be interesting to produce statistics on how much these extensions are used in…

> It is true that there are tasks where threading matters, but still require a CPU rather than a GPU. I wonder however if these tasks do need full SSE/AVX etc. Couldn't these extensions be removed of the CPU cores and instead have the necessary work performed by the GPU?

SSE/AVX shares an L1 cache that's damn near instantaneous to access for the CPU core. Total L1 bandwidth is on the scale of TB/s.

PCIe -> GPU takes 1-microsecond to 10-microseconds per access, and operates only at 50GB/s (or 1/20th the speed of L1 bandwidths).

------------

Case in point: Memset is very commonly AVX'd to clear out L1 cache and initialize ~1kb to 32kb of data to 0 as quickly as possible.

There's no way for "memset" to move from CPU to GPU unless you feel like obliterating the entire point of L1, L2, and L3 cache. If you moved a "memset" to GPU, it'd operate only at 15GB/s (the speed of PCIe 3.0 x16 lanes), far, far slower than L1 cache AVX-loads/stores.

SIMD units, like SSE and AVX, are highly "local" and have huge advantages.

Re: Ryzen Threadripper Pro 3995WX Spotted

#160
post #96
post #85

Earlier quoted context omitted.

> What workloads are so massively parallel that they can use 64 cores of x86 but can’t use the thousands of CUDA cores on a Quadro card? Building software, for one. C compilers and python interpreters don't run on a GPU. Lots of stuff doesn't run on a GPU. In fact in practice the only things that run on a GPU are the tiny handful of known subproblems that the industry has collectively decided are "GPU problems". Like…

> Building software Well, the problem with that is that no make system can utilise so much core. Even linux kernel, probably the biggest C project in mainstream use, can not consistently load even 16 cores with mostly handwritten makefiles. P.S. I do not say that building software is not CPU parallelisable in principles, I'm saying that regular make systems have trouble handing big number of parallel tasks in practic…

Something is wrong on your end, you can parallelize the build of typical C and C++ software almost infinitely. The reason why is because most C and C++ software do not have 'happens-before' dependency relationships due to the way translation units work, so basically every translation unit in a module can be compiled 100% independently of any other translation unit. In practice that means you can easily scale up to 1000+ processes with no issue, and in fact, this has been accomplished in combination with AWS Lambda:

https://stanford.edu/~sadjad/gg-paper.pdf

Actual screencast of it in action compiling FFMPEG:

https://asciinema.org/a/257545

(Perhaps the issue is you are bottlenecking on I/O or some other resource?)

Post reply on HN