Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD Discloses Initial Zen 2 Details

fuse.wikichip.org

Post reply on HN
Print view View original

101–110 of 207 posts

Re: AMD Discloses Initial Zen 2 Details

#101

Post by ll01 »

nabla9 wrote: post #65
screye wrote: post #51

Earlier quoted context omitted.

I hate the Cuda monopoly in machine learning right now. I hope some of the mature libraries (TF, Pytorch) start officially supporting AMD GPUs. Nvidia is looting customers that want to use GPUs for Machine Learning on the cloud (like AWS, GCP)

Nvidia is cashing in their investments for software and integration. It's AMD's job to make machine learning work in their GPU's. If they don't believe in it and spend the necessary time and effort, nobody else will. Radeon Open Compute Platform (ROCm) has existed for years but apparently it's not good enough. ps. Tensorflow has ROCm backend support. https://hub.docker.com/r/rocm/tensorflow/ but is MI25 competitive?…

No clue but if consumer vega is competitive http://blog.gpueater.com/en/2018/04/23/00011_tech_cifar10_be... MI25 has a chance of being

Re: AMD Discloses Initial Zen 2 Details

#103

Post by BeeOnRope »

shaklee3 wrote: post #84
BeeOnRope wrote: post #69

Earlier quoted context omitted.

Well AMD has gone wider - to 5 or 6 wide depending on how you count it in Ryzen. Intel hasn't really been able to make any changes to make any major uarch changes in years, since they've been stuck on Skylake (and all the various Skylake++ variants that followed which were Skylake in name only). In Skylake, most of the effort seemed focused on bringing AVX-512 to bear, and outside of that the basic design is largely…

Skylake also got rid of the ring core architecture, and went to the grid. That was a pretty drastic change, and very different from their previous generations.

Yes, true - that showed up in the SKX uncore. I wonder if it is being used in CNL client parts as well?

Re: AMD Discloses Initial Zen 2 Details

#104

Post by singhrac »

esistgut wrote: post #70
screye wrote: post #51

Earlier quoted context omitted.

I hate the Cuda monopoly in machine learning right now. I hope some of the mature libraries (TF, Pytorch) start officially supporting AMD GPUs. Nvidia is looting customers that want to use GPUs for Machine Learning on the cloud (like AWS, GCP)

Isn't ROCm a viable alternative?

Not really, at least not yet. It doesn't exactly provide the same API capabilities as CUDA yet (there are some unsupported functions) and no one has realistic comparisons of benchmarks but the consensus is that there's some performance gap between similar chips from Nvidia and AMD.

Both are being actively worked on, and I expect to see this gap shrink in the next few months to a year.

Re: AMD Discloses Initial Zen 2 Details

#105

Post by zamadatix »

majewsky wrote: post #82
ChuckMcM wrote: post #74

"Oh the places you'll go" :-) Assuming this chip doesn't trip all over itself moving things around, it will be an astonishing amount of computer power in a reasonably sized package. This is for me, the only reason to work at an internet giant; because they will build a tricked out motherboard with two sockets and up to 8TB of RAM and with say a petabyte of attached non-volatile storage available, field solvers, CFD a…

> exact numerical solutions Isn't that an oxymoron? Numerical solutions always involve some sort of rounding errors because of limited floating-point precision, so they cannot be exact.

A computer can be however exact you want it to be, that it supports floating point in hardware doesn't mean that is as accurate as it can get.

It is far more apt to bring up most "interesting" solutions do not have an exact closed-form expression.

Re: AMD Discloses Initial Zen 2 Details

#106

Post by monocasa »

mehrdadn wrote: post #77
monocasa wrote: post #75

Earlier quoted context omitted.

The KAFFITY in the GROUP_AFFINITY struct is a bitmap ULONG, so 64 bits on 64 bit archs, and 32 bits on 32 bit archs.

Yes but that means every group is 64 CPUs. Notice you can set affinity for any group (16-bit index).

But AFAIK, if I have 128 logical cores, I can't say "schedule this thread on any of the 128 cores because you as the scheduler should know better than me". You have to manually manage the two thread groups each of 64 cores because new threads are round robin assigned to the two groups on thread creation and aren't migrated as circumstances change.

Re: AMD Discloses Initial Zen 2 Details

#107

Post by zamadatix »

bluecalm wrote: post #29
blattimwind wrote: post #20

Earlier quoted context omitted.

Windows can use more than 64 hardware threads, but a single process kinda can't.

It can but you have to take care too change process affinity groups every time you want to work with threads in another group as a group is limited to 64 virtual cores. It complicates thread pool implementation significantly.

But bringing it back to the parent comment thread it's easier to manage affinity of your processes than it is to synchronize them across multiple OS instances.

Re: AMD Discloses Initial Zen 2 Details

#108

Post by mehrdadn »

monocasa wrote: post #106
mehrdadn wrote: post #77

Earlier quoted context omitted.

Yes but that means every group is 64 CPUs. Notice you can set affinity for any group (16-bit index).

But AFAIK, if I have 128 logical cores, I can't say "schedule this thread on any of the 128 cores because you as the scheduler should know better than me". You have to manually manage the two thread groups each of 64 cores because new threads are round robin assigned to the two groups on thread creation and aren't migrated as circumstances change.

Huh, I don't really know much about this to be honest, but are you sure that's not a consequence of prefering not to migrate threads across NUMA nodes rather than across thread groups? Are you aware if there's any documentation on the behavior you're mentioning?

Re: AMD Discloses Initial Zen 2 Details

#109

Post by beerlord »

djsumdog wrote: post #47

I hope AMD has something on their video chip line-up against nVidia as well. I'm curious if they knew nVidia was working on ray-tracing and plan to implement the same API or if they have some other tech they have up their sleeve they've been working on vendors with. I hate how nVidia has such a monopoly on the video chip market. Who knows, maybe Intel will finally get back into the gamer 3D market and we might finall…

By all accounts RTX delivers negligible visual improvement for games, for a huge performance hit.

The technology is a lot more interesting in professional 3D modelling where light baking and rendering can be done much faster.

Re: AMD Discloses Initial Zen 2 Details

#110

Post by 0x8BADF00D »

temac wrote: post #97
0x8BADF00D wrote: post #72

Earlier quoted context omitted.

This seems like a familiar issue I've run into with workstations I've used in the past running Xeons. Not sure how NTOSKRNL handles scheduling of parallel tasks. I'd venture a guess and say it's hybrid (M:N threads), where multiple userland application threads are mapped to some "virtual processor" in kernelmode. That leads to priority inversion between the userland and kernelmode threads, which could explain why Win…

As far as I know Win NT threads are 1:1. Not even sure how it would work or even make any sense to have N:M handled by the kernel. N:M is usually a mainly a userspace thing. And Windows is even less likely to use that kind of convolution, because IIRC it can call back from kernel to userspace (that design I would not recommend, btw, but oh well). You have fibers, of course, but that's a different thing. Windows does…

> Not even sure how it would work or even make any sense to have N:M handled by the kernel. N:M is usually a mainly a userspace thing.

Correct, I meant that the benchmarking program itself probably used that implementation. Not the Win NT kernel’s implementation of OS threads.

Post reply on HN