Question Zen 6 Speculation Thread

[Io Magnesso]

The sad part is that, what makes computer systems feel more and more anemic as time goes on isn't that the OS itself is slowing down, it's all the constant security vulnerability mitigations that keep getting piled on. The computers that felt super quick on early Windows 10 at work a few years ago are just crawling these days. You crack open performance monitor and dig around and you see all sorts of auditing activities, antivirus scanning, memory randomization efforts, intentional cache dirtying, memory address scrubs, access profiling etc.

Systems don't really idle that often. There's always something in the background with something to do.

That's right, early Windows 10 worked fine even with 4GB of RAM.

 

[Markfw]

AMD hardly had any "fixes" to slow it down, I don't know where this "slow computer" comes from.

 

[Io Magnesso]

AMD hardly had any "fixes" to slow it down, I don't know where this "slow computer" comes from.

What does that mean?

 

[LightningZ71]

A lot of it isn't processor specific. OSes in general are adopting more security fundamentals to be resistant to zero day hardware exploits. Newer languages now do memory access obfuscation and randomization by default in the background. It's a fundamental part of RUST for example.

All of that eats up processor cycles and memory access cycles.

 

[MS_AT]

memory access obfuscation and randomization by default in the background. It's a fundamental part of RUST for example.

Could you link to RUST docu, that supports these claims? I mean its first time I see it, that they have built memory obsfucation and randomization into the language.

Things like ASLR (address space layout randomization) is language agnostic afaik and depends on the OS defaults, but you can overrule them.

 

[igor_kavinski]

Safety comes at a price.

https://dl.acm.org/doi/fullHtml/10.1145/3551349.3559494

 

[MS_AT]

View attachment 126378

Safety comes at a price.

https://dl.acm.org/doi/fullHtml/10.1145/3551349.3559494

I never thought I would defend rust but to be fair, quouting from the article

"Names of the algorithms can be found in Figure 1 and all the programs are contributed by irrelevant third parties."

So they don't provide the sources of the algorithms they compare. They claim they verified them themselves but it makes it impossible to reproduce nor to tell if they were written in idomatic ways that make them easy for compiler to optimize. I mean we have to trust the authors were familiar with the best way to write in each language.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html this shows more modern take if I understand correctly. At least you can see the code. The results are more in line with each other.

Also comparison should be done between clang compiled c and rust, since both are build on top of llvm, so it is better way to single out language specific influence

 

[Markfw]

A lot of it isn't processor specific. OSes in general are adopting more security fundamentals to be resistant to zero day hardware exploits. Newer languages now do memory access obfuscation and randomization by default in the background. It's a fundamental part of RUST for example.

All of that eats up processor cycles and memory access cycles.

The vast majority is CPU wise, and Intel has way more. For the OS, they also check to see what the CPU is to decide if a certain fix is required. So you have any benchmarks to show anything concrete ?

 

[LightningZ71]

I didn't do full benchmark workups at the time because it wasn't in the scope of my investigation. We were trying to nail down where the slowdowns were coming from to make sure it wasn't intrinsic to any of our installation process program suite. Both AMD and Intel systems showed similar degrees of performance deterioration for user functions between a historic image and our current one with the same software installed. I will grant that this was last looked at before MS did their famous AMD mitigations patch a while back where they straight up admitted to enforcing unneeded mitigations on certain AMD processors, but in a cursory look, that didn't make a big change for our numbers.

In general, both Windows and Linux are having to do extra work to improve system security. IMHO, Linux distro seem to age a bit more gracefully because that's what I see in production, but it's not entirely free of this issue. And, no, I can't just choose to turn off all mitigations. That would worsen our organization's security posture. Also, it's not ALL on the OS (excluding microcode changes) as the software itself has to do more work verifying inputs don't overrun buffers and verifying their own internal file integrity. Unless they are patching out performance bugs, security updates often worsen performance.

It also depends on the processor on how well it comes with OS changes. We had a large batch of 7th Gen i5 processors in production that we're getting absolutely hammered by this. Stuff that had limited L3 amounts and less than 8 threads was really suffering. Protecting memory access causes tons of process stalls. 4 core HT processors made a big difference. It was less noticeable on the Ice Lake and tiger lake laptops that we looked at, even with their I/o mitigations in place.

 

[igor_kavinski]

It was less noticeable on the Ice Lake and tiger lake laptops that we looked at, even with their I/o mitigations in place.

Ice Lake is the context switch latency champ.

ctx_clock Benchmark - OpenBenchmarking.org

openbenchmarking.org

Random 4K I/O involves context switches. Doesn't explain better performance of Tiger Lake results you saw.

 

[LightningZ71]

As compared to 7th Gen I5? The Tiger Lake processors had more L3 and HT on top of an improved core. Much more resilient to memory access stalls.

 

[OneEng2]

guys after zen 6 release and exponential advent of AI none of this will matter......


I think most of us got excited with hardware and OC at times when computers were slow.... even most expensive Extreme Edition™ pcs were not enough... no one could run Crysis ultra unless huge crazy SLI setup etc...

hardware was lagging behind software......

but now software gonna be lagging behind hardware

computers are so fast it doesnt matter anymore... and cutting edge advances will become so complex there wont be much a point to know deep dive hardware intrinsics unless u work at that level in a major hardware company i.e. amd nvidia qualcomm samsung intel etc

This is quite true. The things that most people use their computers for don't require even a fraction of what their computer is capable of doing.

I am typing this on a Ryzen 5600g. Pittiful by today's standards, yet more powerful than anything I need it for. I do some video editing, and some audio editing, but honestly none of them tax this system much (the video takes some time to render, but the editor runs just fine). I suspect I am among the top 50% of users. I also write a bit of code at home. Again, nothing my computer can't handle.

As much as I like the Zen 6, it is highly likely I will wait for Zen 7 and the new socket it will bring so that I can again start a home build at the beginning of a design cycle.

I started this computer with a Ryzen 3300g. Upgraded the RAM to 32gb (from 8), and upgraded the processor to the 5600g. This computer is now 7 years old (also updated to Windows 11).

Like many here, I used to upgrade every couple of years. No need anymore.

And people will make react native apps to cancel the hardware advancement made

Fortunately, React is rapidly losing ground to Flutter.... which is a much thinner programming language (Dart) that compiles CTM and runs fast.

 

[OneEng2]

RUST vs C!

First off, I am hoping that chart meant C++ as I think it is tough to compare an object oriented language to one that is not. May as well say you are using ASM.

In embedded, C is fantastic and my tool of choice (I make these decisions in my company). For anything client side, I wouldn't pick a non-OOP language ever.

Now, RUST in specific SHOULD be compared to C++. I have spent a career listening to whiney software engineers complain about the development environment, editors, build tools, etc. They also love to decry C++ as being for old dudes like me and that it is outdated. Lots of love for ARC and pretty much any tool (like RUST) that makes it so they don't have to "worry about memory".

My experience has been that every time I listen to one of these whiners and allow a program to use a higher level language (than C++) we end up with a BUTT TON of memory management issues!

Now, I haven't delt with RUST yet, so perhaps it is better. I am just gun shy of the next "We should be doing this" full court press by a team of young software engineers.

There is some truth to people saying I am just caught in old ways..... but "new" hasn't been "better" for the large, performance sensitive, stability sensitive programs I have worked on.

Case in point. Java and .NET. Better than C++? Sure does make coding up the program easier. Don't have to explain for the 1000th time what the crap the difference is between * and &! Ever run out of memory space inside the interpreter? You know what the cure is? Write a C++ library and call it with a JNI interface!

Anyway, I think that C++ is a better tool for writing "serious" applications with. Anyone that feels like they require a language that "handles memory for you" should probably be doing something else other than writing code IMO. (harsh I know). Or perhaps phone apps would be a better place for them?

 

[Bigos]

RUST vs C!

First off, I am hoping that chart meant C++ as I think it is tough to compare an object oriented language to one that is not. May as well say you are using ASM.

In embedded, C is fantastic and my tool of choice (I make these decisions in my company). For anything client side, I wouldn't pick a non-OOP language ever.

Now, RUST in specific SHOULD be compared to C++. I have spent a career listening to whiney software engineers complain about the development environment, editors, build tools, etc. They also love to decry C++ as being for old dudes like me and that it is outdated. Lots of love for ARC and pretty much any tool (like RUST) that makes it so they don't have to "worry about memory".

My experience has been that every time I listen to one of these whiners and allow a program to use a higher level language (than C++) we end up with a BUTT TON of memory management issues!

Now, I haven't delt with RUST yet, so perhaps it is better. I am just gun shy of the next "We should be doing this" full court press by a team of young software engineers.

There is some truth to people saying I am just caught in old ways..... but "new" hasn't been "better" for the large, performance sensitive, stability sensitive programs I have worked on.

Case in point. Java and .NET. Better than C++? Sure does make coding up the program easier. Don't have to explain for the 1000th time what the crap the difference is between * and &! Ever run out of memory space inside the interpreter? You know what the cure is? Write a C++ library and call it with a JNI interface!

Anyway, I think that C++ is a better tool for writing "serious" applications with. Anyone that feels like they require a language that "handles memory for you" should probably be doing something else other than writing code IMO. (harsh I know). Or perhaps phone apps would be a better place for them?

You are right. You don't know Rust and are performing strange comparisons that do not make sense.

I have a lot of experience working with C++. I would not recommend this language to my enemy. "Sharp edges" is an understatement. The moment you forget about something the compiler does not check you introduce hard to find bugs. And code reviewers are also human and might miss these.

And don't put "stable software" and "C++" in the same sentence. Maybe that is possible for a relatively small software with a lot of people constantly running sanitizers and fuzzers. And for software that is old enough to have been battle-tested. But from my experience, people write something that the compiler accepts that does not work in some edge cases, and the worst is if it overwrites memory and now you have a bug you have no idea how to figure out. And then you pile more of these sometimes-works stuff on top. Now you have software that "works" but might break on unusual input. I would say that is the opposite of "stable".

You seem to be confusing memory-safe languages and garbage-collected ones. One is a superset of the other, you do not need terrible memory management to be memory safe! I detest using Java/.NET/etc for anything serious as well, but that does not mean "well, memory safety is bad"!

And if you think you never make mistakes, maybe C++ is actually for you. I will not trust any software you write, though.

 

[igor_kavinski]

I have a lot of experience working with C++. I would not recommend this language to my enemy.

What WOULD you recommend?

 

[jpiniero]

What WOULD you recommend?

JavaScript!