Question Zen 6 Speculation Thread

[Hulk]

3% extra isn't worth the risks associated with dropping even 16 bit stuff, never mind 32 bit that is still very actively used - MAYBE 30% would have been justifiable, but there is no way dropping that stuff will get more than very little - internally it must be all mapping to existing hardware stuff anyway, and simple remap can't be very expensive.

The main thing you'd gain is a bunch of short opcodes that can be repurposed for new stuff, but is decoding really the biggest problem right now?

Anyway, it (dropping 32 bit stuff) is all academic - this ain't going to happen in x86 like EVER.

I would take that 3% in a heartbeat. Any 16 or 32 bit software I have I'd jettison or if really necessary now and then run in compatibility mode. It's been hanging on long enough.

I understand it's really only the front end, and decode in particular that would be affected but there is a lot of inefficiencies going on with many of those 32 bit and especially 16 bit instructions going on that the decode has to deal with and then the backend has to execute.

If you're still stuck with 16/32 bit baggage there is always emulation. But again, this is just my preference.

Of course this assumes any 16/32 bit legacy instructions built into the OS would be immediately jettisoned, like booting would have to immediately be fully 64 bit.

So if that was the path then yes, I'd take the 3% to move on and make life eventually easier for hardware and software developers.

 

[Tuna-Fish]

I understand it's really only the front end, and decode in particular that would be affected but there is a lot of inefficiencies going on with many of those 32 bit and especially 16 bit instructions going on that the decode has to deal with and then the backend has to execute.

No, because the 64-bit instructions use the same encodings. All the inefficiencies remain even after old instructions are dropped. The only win for dropping backwards compatibility on x86 is in validation. There are no performance gains to be had for dropping a few legacy decoder paths.

 

[luro]

Guys can we go back to the topic already?

 

[MerryCherry]

Guys can we go back to the topic already?

Zen60% ?

 

[adroc_thurston]

Zen60% ?

More than that in server.

 

[Kaffeekenan]

More than that in server.

Yeah, AMD already confirmed 70%+.

 

[OneEng2]

That's not an easy thing and I definitely would be one of those who would've quit. Time is too precious to waste on Microsoft stuff. I haven't even tried Office 21 and 24 to see if it's better or faster. No point. The moment they introduced their subscription based Office 365, that was the end of any interest in Office. Not interested in paying a yearly tax and not interested in paying for the perpetual licensed product that will definitely be inferior to the subscription based one.

When working on corporate stuff, MS is the standard though. Painful, but true 🙁

Yeah, AMD already confirmed 70%+.

... and really, for AMD's profit purposes, this is ALL that really matters. Also, this next generation seems like Intel is just giving up on DC completely (ironically, their laptop and desktop offerings might be pretty convincing).

It seems like a very strange freaky Friday. Intel is going "more cores" and "value choice" and AMD is all DC and HEDT/Gaming.

I think AMD has their priorities correct.

 

[Hulk]

No, because the 64-bit instructions use the same encodings. All the inefficiencies remain even after old instructions are dropped. The only win for dropping backwards compatibility on x86 is in validation. There are no performance gains to be had for dropping a few legacy decoder paths.

Wouldn't some transistors space be available that would not be needed?

 

[Thibsie]

Yeah, AMD already confirmed 70%+.

MT I guess but what about ST ??

 

[adroc_thurston]

MT I guess but what about ST ??

Freq SKUs for Venice SP8 are also very very nice.