AMD Further Unveils Zen Processor Details

Zarathustra[H] said:
Well, I'm a confirmed Linux fan, so it would take an act of God to get me to switch back to Windows as my primary OS again.

That being said, Windows 10 runs great when I dual boot to it for games. It irks me that it has uninstallable Microsoft apps on it. It's like the bad old days before I had a Nexus phone, and had to put up with pre-installed bloatware I never wanted. If I could remove all the tablet apps, xbox integration, TV & movies app, the music app (forget what it's called) the Microsoft store, edge, etc. and completely disable any Ms data collection, and any cloud integration I'd stop complaining right away.

They really did a good job in making a smooth running OS, I just hate all the strong-arm bs to try to get you to use their services and collect your data.
Click to expand...

I'm in the same boat but with a different result.

For the longest time I was using a dedicated laptop to learn Linux. Had the original Aspire One 9" netbook I started on, had been running a mini server on a hacked Dockstar with Debian. When the netbook got long in the tooth, I replaced it with an easily hackable Chromebook and that became my daily driver because of how great it all ran. I replaced that after 3 years with a cheap "Cloudbook" that had a fanless Bay Trail CPU in it and like everything before it, Linux runs like an absolute champ on it.

My desktop, after I installed Linux, felt like three of the four CPU cores got disabled and someone depressed the Turbo button on that one core on top of it. So back to Windows 7 on the Desktop. Granted, I tried xUbuntu 14.04 then and 16.04 is out now... so there may be enough changes between the kernel versions that would solve my hardware issues.

And that's sort of my problem with Linux in general. That lag time behind hardware support compared to Windows. But when it works, it works fucking great. If only Adobe would start supporting Linux systems because I know a lot of production houses would just LOVE to get the fuck off Macs and not deal with Microsoft.
 
NKD said:
Are you serious? I just clicked on that thing and it seems like a click bait spam. I hope you weren't serious with that stuff. No where on that page it actually has a download button for 10antispy, all clicks are click bait to somehting else. SMH
Click to expand...

Just click "Mirrors" and they're all right there.

Download 10AntiSpy - MajorGeeks
 
Yes it takes you to majorgeeks to download. I use it. Just watch what you disable. I have all my win 10 apps off .Depends on what you use. You can select some to keep. My win 10 app sidebar thing is empty now and only has shortcuts that I added myself for stuff I use.
 
michalrz said:
I asked that question (renaming registers) because I had out of order execution in mind at the time.
Seeing that this AMD gen will have so many cores, it just sounds like a bummer if they won't get to be used.
I was wondering if it's possible and/or viable to somehow 'hint' the CPU/OS scheduler to use, say, the first available idling core, because you know you'll be needing additional time for an incoming 'difficult' instruction. Or you want to have a core begin preparing for a specific data segment.
Maybe they already do this, I don't know.
Click to expand...

Let's look at how two different OS schedulers work, shall we?

Windows:

The Windows scheduler, at its simplest, will ALWAYS run the highest priority runnable thread(s). There's a lot that goes on under the hood to adjust thread priority over time, but at any given instant, the highest priority thread(s) that are capable of executing will be the ones scheduled by the OS. This is why threads tend to jump between CPU cores; a thread could have run on Core 2, but if Core 2 is busy the next time the thread is runnable and Core 4 is unused, then the thread goes on Core 4. Obviously, you lose a little bit of performance if you need to transfer data across the CPU cache, but this ensures the highest priority threads are ALWAYS running.

Linux:

The default Linux scheduler uses per-core runqueues, which basically means threads are divided among cores ahead of time and a load-balancing algorithm will occasionally reshuffle thread allocation to try and keep core usage flat. While this does a very good job resulting in low-latency across all applications, this will occasionally result in periods where a runnable thread is not run despite the presence of an idle CPU core, resulting in a overall loss of application performance. [I have a VERY low opinion of the Linux scheduler; I estimate gaming performance in Linux is suffering a 20-30% penalty as a result of it].


Again, the root issue here is threads that do meaningful work. And when it comes to games, you're going to have two REALLY heavy threads (main engine and the primary rendering thread), with a handful of other worker threads (mainly rendering related) doing some additional work. The fact that two threads will account for ~60%+ of application performance means your application is dominated by how quickly those two threads execute. The fact you have 64+ CPU cores is irrelevant; a faster dual core processor will win that benchmark.

Wide execution has it's place; see GPUs as the most obvious example. But application level performance, with few exceptions, is mostly linear in execution, and cares for faster cores over more cores. And this isn't going to change, no matter how much some people wish it so.
 
gamerk2 said:
Let's look at how two different OS schedulers work, shall we?

Windows:

The Windows scheduler, at its simplest, will ALWAYS run the highest priority runnable thread(s). There's a lot that goes on under the hood to adjust thread priority over time, but at any given instant, the highest priority thread(s) that are capable of executing will be the ones scheduled by the OS. This is why threads tend to jump between CPU cores; a thread could have run on Core 2, but if Core 2 is busy the next time the thread is runnable and Core 4 is unused, then the thread goes on Core 4. Obviously, you lose a little bit of performance if you need to transfer data across the CPU cache, but this ensures the highest priority threads are ALWAYS running.

Linux:

The default Linux scheduler uses per-core runqueues, which basically means threads are divided among cores ahead of time and a load-balancing algorithm will occasionally reshuffle thread allocation to try and keep core usage flat. While this does a very good job resulting in low-latency across all applications, this will occasionally result in periods where a runnable thread is not run despite the presence of an idle CPU core, resulting in a overall loss of application performance. [I have a VERY low opinion of the Linux scheduler; I estimate gaming performance in Linux is suffering a 20-30% penalty as a result of it].


Again, the root issue here is threads that do meaningful work. And when it comes to games, you're going to have two REALLY heavy threads (main engine and the primary rendering thread), with a handful of other worker threads (mainly rendering related) doing some additional work. The fact that two threads will account for ~60%+ of application performance means your application is dominated by how quickly those two threads execute. The fact you have 64+ CPU cores is irrelevant; a faster dual core processor will win that benchmark.

Wide execution has it's place; see GPUs as the most obvious example. But application level performance, with few exceptions, is mostly linear in execution, and cares for faster cores over more cores. And this isn't going to change, no matter how much some people wish it so.
Click to expand...

Thank you very much sir. This clears up a lot of the issue for me.
 
gamerk2 said:
Let's look at how two different OS schedulers work, shall we?

Windows:

The Windows scheduler, at its simplest, will ALWAYS run the highest priority runnable thread(s). There's a lot that goes on under the hood to adjust thread priority over time, but at any given instant, the highest priority thread(s) that are capable of executing will be the ones scheduled by the OS. This is why threads tend to jump between CPU cores; a thread could have run on Core 2, but if Core 2 is busy the next time the thread is runnable and Core 4 is unused, then the thread goes on Core 4. Obviously, you lose a little bit of performance if you need to transfer data across the CPU cache, but this ensures the highest priority threads are ALWAYS running.

Linux:

The default Linux scheduler uses per-core runqueues, which basically means threads are divided among cores ahead of time and a load-balancing algorithm will occasionally reshuffle thread allocation to try and keep core usage flat. While this does a very good job resulting in low-latency across all applications, this will occasionally result in periods where a runnable thread is not run despite the presence of an idle CPU core, resulting in a overall loss of application performance. [I have a VERY low opinion of the Linux scheduler; I estimate gaming performance in Linux is suffering a 20-30% penalty as a result of it].


Again, the root issue here is threads that do meaningful work. And when it comes to games, you're going to have two REALLY heavy threads (main engine and the primary rendering thread), with a handful of other worker threads (mainly rendering related) doing some additional work. The fact that two threads will account for ~60%+ of application performance means your application is dominated by how quickly those two threads execute. The fact you have 64+ CPU cores is irrelevant; a faster dual core processor will win that benchmark.

Wide execution has it's place; see GPUs as the most obvious example. But application level performance, with few exceptions, is mostly linear in execution, and cares for faster cores over more cores. And this isn't going to change, no matter how much some people wish it so.
Click to expand...

Agreed, and very good summary.

I'd add that the Linux scheduler has its place, it's just optimized for different work loads than Windows. It really shouldn't make a HUGE difference though, unless you are running a CPU intensive game, AND are also running heavy background tasks at the same time. In situations like these the Windows Scheduler will take the advantage for games.

All of the cross platform titles I have tried in Linux and Windows show Windows with a marginal lead in performance, but I attribute this mostly to the GPU rendering pipeline and the API's used, as well as how it was ported. In some cases game ports are actually real time translating DX calls into OpenGL which is never going to be particularly efficient. (Talk about shitty ports...)

Do you happen to know what the effect is of changing the Windows setting regarding "prioritize current active program" vs "prioritize background services" does at a detail level? This one I ave never read up much on, beyond one is better for server tasks and the other is better for client tasks. I'm not quite sure what it does on the functional level.
 
Last edited:
Zarathustra[H] said:
Do you happen to know what the effect is of changing the Windows setting regarding "prioritize current active program" vs "prioritize background services" does at a detail level? This one I ave never read up much on, beyond one is better for server tasks and the other is better for client tasks. I'm not quite sure what it does on the functional level.
Click to expand...

The idea (at least as of Vista, which is where I believe that functionality got added) is that any thread that belongs to a background application has it's priority slightly reduced, and any thread that belongs to the currently active window has it's priority slightly raised. The intent is to reduce the amount of times a low interest background task from bumping a thread that needs 90%+ CPU time for an application your are currently interacting with. Granted, the higher priority foreground thread will eventually bump (Priorities get adjusted as threads are running/waiting to prevent stalls), but at a significantly lower rate then it would without that option.
 
You guys rock, this is like I met aliens and got to ask anything I ever wanted to know.

Linux-wise, wow about the X-server part?
Say, we have the two threads you mentioned - the game engine and the renderer. Does the x-server need talking to often enough to 'get in' on the reshuffling and thus produce another cause for lag?
In other words, if it wasn't a client server model (I assume it is), would it be snappier?
 
michalrz said:
In other words, if it wasn't a client server model (I assume it is), would it be snappier?
Click to expand...
I don't understand what you're asking aside from this line, so I'll try to respond to this line. A client server model doesn't impact performance on its' own and might be necessary for graphical rendering. I can't imagine what a peer to peer graphical render-er would look like (which may be a failure of imagination on my part). Anyway, that aside X is an old beast which was never made for performance. This was in the news today
The Threaded Input Support In X.Org Server 1.19 - Phoronix
and that will probably help on the x performance front. That said, wayland is the real solution to linux's graphical infidelity.
 
I am going to save myself some energy of being disappointed. The smartest thing to do is to set aside funds slowly and buy an Intel system. AMD isn't doing anything to save their own asses from the flames of hell! I expect AMD to be out the CPU business in less than 2 years. AMD's debt is accumulating and it is getting scary! The debt level wouldn't be bad if they had a product that could compete against Intel, the truth is....AMD is only focused on the cookie crumbs laying on the ground!
 
Nobified[H] said:
I am going to save myself some energy of being disappointed. The smartest thing to do is to set aside funds slowly and buy an Intel system. AMD isn't doing anything to save their own asses from the flames of hell! I expect AMD to be out the CPU business in less than 2 years. AMD's debt is accumulating and it is getting scary! The debt level wouldn't be bad if they had a product that could compete against Intel, the truth is....AMD is only focused on the cookie crumbs laying on the ground!
Click to expand...

Then do so and enjoy whatever you buy. However, I cannot agree with your assessment of AMD's future and that is fine too. Me, I am not surprised they have not yet released Zen since Global Foundries has never released anything on time that I am aware of. (I would say that is an excuse if they had somewhere else they could quickly go but alas, they do not.)
 
Nobified[H] said:
I am going to save myself some energy of being disappointed. The smartest thing to do is to set aside funds slowly and buy an Intel system. AMD isn't doing anything to save their own asses from the flames of hell! I expect AMD to be out the CPU business in less than 2 years. AMD's debt is accumulating and it is getting scary! The debt level wouldn't be bad if they had a product that could compete against Intel, the truth is....AMD is only focused on the cookie crumbs laying on the ground!
Click to expand...

Their debt level actually went down by around 400 million, of course shareholders is taking a hit, it is not all doom and gloom but they are in an unfavorable situation.
 
ManofGod said:
Then do so and enjoy whatever you buy. However, I cannot agree with your assessment of AMD's future and that is fine too. Me, I am not surprised they have not yet released Zen since Global Foundries has never released anything on time that I am aware of. (I would say that is an excuse if they had somewhere else they could quickly go but alas, they do not.)
Click to expand...

I want AMD to succeed, they are surely going out of their way to hinder those efforts by making poor decisions.
 
You must log in or register to reply here.
Back
Top