• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Leaked AMD Ryzen Benchmarks?

If it costs a lot less than $1,049.99 that the Core i7-6900k currently sells for, it should do well.
 
Pieter3dnow said:
I would say that the opposite is true , gaming is being held back by the API and the complacent gaming industry where they would put profit over anything else. The development cycle of a game tends to be around 5 years. The way the industry has been operating was always with a keen sense of biggest common denominator approach.

Without this gaming should move forward to see dual cores still operate says enough about the leaps in technology versus the need for better engines were talking about almost a decade now and they wonder why PC market is not selling as well as it used to.
Click to expand...

Consoles have been multicore for ages and people have been coding for multithreading for 30 years+ on the PC. I always find it funny when someone just claims its lazy developers and lack of APIs. The limitation is diminishing returns and serial code that cant be threaded.
 
Pieter3dnow said:
...

I would say that the opposite is true , gaming is being held back by the API and the complacent gaming industry where they would put profit over anything else. The development cycle of a game tends to be around 5 years. The way the industry has been operating was always with a keen sense of biggest common denominator approach.

Without this gaming should move forward to see dual cores still operate says enough about the leaps in technology versus the need for better engines were talking about almost a decade now and they wonder why PC market is not selling as well as it used to.
Click to expand...

Not sure what you are saying here, game development is a business and there is nothing new here and nothing that really should change either. The game developers themselves are hardly non committal to their work and lately with the game development platforms I think we have seen the development area of gaming grow in maturity quite well.

Assuming the use of a game engine platform (which is the norm these days, either internally or external product) it stands to reason that they want the best performance possible to stay competitive so I am not sure what you mean with "held back by the API". Do you mean from a game developers viewpoint or the game engine development? Not sure what API we are talking about either, multi core support is not something that's new and the API to make use of that has been around for ages (as an example pthread standard has been around since 95).

Its a common misunderstanding that 2x the cores = 2x the performance but I hardly think that's something that readers of H believes.
 
Pieter3dnow said:
Without this gaming should move forward to see dual cores still operate says enough about the leaps in technology versus the need for better engines were talking about almost a decade now and they wonder why PC market is not selling as well as it used to.
Click to expand...

Not this core nonsense again. It is based on a fundamental misunderstabding of how multithreaded code works..

Multithreading will never work on most tasks. Not because of lazy uncommitted developers or not willing to spend effort or money, but because it violates the fundamentals of computer science.

I'd argue that with a few notable exceptions, multithreading in 2016 is as good as it will ever get. What can be multithreaded mostly has been already. Not all tasks lend themselves to multithreading. In fact, most don't.

If you try to multithread them, you wind up with thread locks and other problems either resulting in hangs or workarounds that make the code slower than it would have been if you didn't try to multithread it in the first place.

Games are notorious for this. Most game engine tasks can not be multithreaded at all. They try to get around this by "faking" multithreading by splitting various tasks off into their own dedicated threads, which usually results in one main game thread taking the majority of one core and some other tasks running on other cores, but it isn't true multithreading where the code distributes itself across all available cores.

Ever since AMD started trying to make up for poor per core performance by adding more and more cores, AMD fanboys have been talking about how AMD was ahead of their time and just wait until software catches up.

Well that is total bull. You can not make up for per core performance with many cores in most tasks. Yes, there are some notable exceptions, like rendering and encoding operations, but for most tasks the software will never "catch up" not because of a lack of determination, but because that's not how software works.

Once you reach a certain threshold of cores (3-4 somewhere) stronger, fewer cores will always trump more weaker cores in gaming type tasks.

This will never change. It's sort of like violating the first law of thermodynamics. It will never happen, and if you think it will you know absolutely nothing about software development.
 
Last edited:
Agree with Z but tried to be more diplomatic :)

Although I think that games in itself is a good environment for multi threaded code, however most of the areas are handled by HW these days, the only remaining big chunk that I can think of is AI mechanics where you can have more dynamic elements in the world since these are all (or can be) mostly independent of each other. However most of these are fluff items and might give a more seemingly interactive world but arent crucial for game play.
 
Zarathustra[H] said:
Not this core nonsense again. It is based on a fundamental misunderstabding of how multithreaded code works..
Multithreading will never work on most tasks. Not because of lazy uncommitted developers or not willing to spend effort or money, but because it violates the fundamentals of computer science.
I'd argue that with a few notable exceptions, multithreading in 2016 is as good as it will ever get. What can be multithreaded mostly has been already. Not all tasks lend themselves to multithreading. In fact, most don't.
If you try to multithreading them, you wind up with thread locks and other problems either resulting in hangs or workarounds that make the code slower than it would have been if you didn't try to muktithread it in the first place.
Games are notorious for this. Most game engine tasks can not be multithreaded at all. They try to get around this by "faking" multithreading by splitting various tasks off into their own dedicated threads, which usually results in one main game thread taking the majority of one core and some other tasks rubbing on other cores, but it isn't true multithreading where the code distributes itself across all avaabke cores.
Ever since AMD starred trying to make up for poor per core performance by adding more and more cores, AMD fanboys have been talking about how AMD was ahead of their time and just wait until software catches up.
Well that is total bull. You can not make up for per core performance with many cores in most tasks. Yes, there are some notable exceptions, like rendering and encoding operations, but for most tasks the software will never "catch up" not because of a lack of determination, but because that's not how software works.
Once you reach a certainthreshold of cores (3-4 somewhere) stronger, fewer cores will always trump more weaker cores in gaming type tasks.
This will never change. It's sort of like violating the first law of thermodynamics. It will never happen, and if you think it will you know absolutely nothing about software development.
Click to expand...
If your sentiment is true then why would have they have bothered making Mantle Vulkan and DX12 , for the fun of it just make something totally useless that has no use.

In real life Xbox and Playstation prove that you can have something no one on this forum would ever use as a gaming cpu run games in 1080P.

It is no nonsense ...
 
eneq said:
It's not as simple as that, there are just a limited number of tasks within a game that benefits from multiple cores, graphics are already taken care of by the GPU which leaves math, sound, ai, data management. Math is the only really big item left and if you are running physx most of that is gone anyway, sound is not really relevant and you end up with ai and general data management.

AI has a big benefit due to the amount of actors on the scene but I personally dont see this as a big selling point compared to higher core performance because the benefit of more cores is limited since the more cores you have the bigger data synchronization overhead is needed a 4/8 setup compared to a 8/16 is negligible for games.

Also we should not forget about economics of scale, most game engines will focus on the larger segment so until a very large part of the market runs 8/16 we wont really see any gains at all.

However AMD still has a hit on their hand in the server rooms and this is NOT a small market, just not something I really care that much for though.
Click to expand...
So you are saying, and you are by the way, games will stagnant in the near future. CPU cores are virtually at their limit for clock speed and IPC. If everything is now limited by how effective you can multi-thread with a limit of 8 threads, game advancement will utterly become limited by the CPU no matter what you do. I fully disagree.

So what happens when you have 4x to 12x more objects on the scene that are dynamic and can interact? DX 12 will allow this. Sorry a few cores is not going to get you there if they are stagnant I am saying. Each object or series of objects can have their own AI, physics etc. Location or thread coordination can be timed per frame for the object which then can be rendered. Awareness of other objects can be communicated at this time in a simplified distance. Lighting and most other stuff can keep the same for the rendering phase.

Hm, Frostbite seems to have effectively used 8 threads, less then 8 threads or cores you see marked decreases in performance for BF1. These results are very interesting but basically the anemic low IPC FX 8370 keeps up with the stout IPC I7 5960x. Frostbite engine is one of the top notch performance and IQ engines out there most likely because it does indeed use effectively more then 2 cores of a cpu.


http://www.guru3d.com/articles_pages/battlefield_1_pc_graphics_benchmark_review,10.html
 
Pieter3dnow said:
If your sentiment is true then why would have they have bothered making Mantle Vulkan and DX12 , for the fun of it just make something totally useless that has no use.

In real life Xbox and Playstation prove that you can have something no one on this forum would ever use as a gaming cpu run games in 1080P.

It is no nonsense ...
Click to expand...


LLAPI give the ability to use other threads of the CPU for CERTAIN things, NOT EVERYTHING LOL. the difference in multithreaded programmable model vs single threads vs the needs of an application are different things.

Many games/egnines do use a task based system for parallel processing. The game spawns a fixed number of worker threads which are used for multiple tasks. Now going wider is a factor of how wide the game needs the developer needs to know when to not to go too wide because it will hinder performance not help. Work is divided up into small pieces and queued, then sent to be processed by the worker threads as they become available. Consoles have been doing this for years now. The PS3 is a perfect example of this, the Xbox 360 can emulate a task/job setup that was designed for PS3 as it has multiple cores.

Now thread safe code is different, thread safe means it can go as wide as you want, that doesn't happen most of the time because tasks always have dependencies, and that will never change. When that happens, it will end up with stalls or race conditions if not careful and this is because games and API's are event driven, even in LLAPI's same thing, so yeah as I stated above there are still limitations to how wide you can go even with them.

LLAPI's removed the barrier of the driver from accessing multiple threads, the rest of the game mechanics, engine mechanics, those have not changed, further more won't change much because of them being event driven.
 
Last edited:
Pieter3dnow said:
If your sentiment is true then why would have they have bothered making Mantle Vulkan and DX12 , for the fun of it just make something totally useless that has no use.

In real life Xbox and Playstation prove that you can have something no one on this forum would ever use as a gaming cpu run games in 1080P.

It is no nonsense ...
Click to expand...

Main benefit of Vulkan and DX12 is the reduction of API overhead and especially so when multiple threads are involved, there are ofcourse other aspects of these APIs that are interesting as well.

BTW you should never discount the developers need to make something "better" just for the sake of it.
 
noko said:
So you are saying, and you are by the way, games will stagnant in the near future. CPU cores are virtually at their limit for clock speed and IPC. If everything is now limited by how effective you can multi-thread with a limit of 8 threads, game advancement will utterly become limited by the CPU no matter what you do. I fully disagree.

So what happens when you have 4x to 12x more objects on the scene that are dynamic and can interact? DX 12 will allow this. Sorry a few cores is not going to get you there if they are stagnant I am saying. Each object or series of objects can have their own AI, physics etc. Location or thread coordination can be timed per frame for the object which then can be rendered. Awareness of other objects can be communicated at this time in a simplified distance. Lighting and most other stuff can keep the same for the rendering phase.

Hm, Frostbite seems to have effectively used 8 threads, less then 8 threads or cores you see marked decreases in performance for BF1. These results are very interesting but basically the anemic low IPC FX 8370 keeps up with the stout IPC I7 5960x. Frostbite engine is one of the top notch performance and IQ engines out there most likely because it does indeed use effectively more then 2 cores of a cpu.


http://www.guru3d.com/articles_pages/battlefield_1_pc_graphics_benchmark_review,10.html
Click to expand...

Looking at the CPU aspect of things I would def. say things have stagnated the last few years, that isn't the same as saying that games development have stagnated but that's in some aspects HW related (GPU) and in no small effort due to better tools.

BF1 or the frostbyte engine is a very good example actually, it is a showpiece of new graphical solutions (algorithms) that have yet to move to GPU support. For instance occlusion is done in SW (or was, I am not sure on the last iteration but I would expect it to still be) but eventually this will also move to GPU as is the case with most if not all heavy parallelizable tasks.

I see most of the coming advancements in gaming to come from multi gpu solutions, where extra GPUs will take over physics and general compute. The CPU is more or less a conductor and has been for some time.

I am not saying that there wont be situations where 8/16 is beneficial, I could maybe see a situation where you have two rendering pipelines for VR for instance and 8/16 might be a benefit but then again almost all of the pipeline remains the same...

edit:
Just saw a comment from the lead on Frostbyte;

The CPU, as we know it, and its APIs are only in the way

He actually argues for a new type of additional process for high-throughput oriented massive data-parallel tasks.
 
Last edited:
Pieter3dnow said:
If your sentiment is true then why would have they have bothered making Mantle Vulkan and DX12 , for the fun of it just make something totally useless that has no use.

In real life Xbox and Playstation prove that you can have something no one on this forum would ever use as a gaming cpu run games in 1080P.

It is no nonsense ...
Click to expand...

Mantle and DX12 are real. Remember, rendering is one area that is very well suited to multithreading.

Unfortunately you greatly overestimate the portion of the CPU load that is directly caused by the GPU rendering operations.

DX12 and mantle do help improve this,as did DX11 and DX10 respectively with their threaded improvements prior to this.

There is MUCH more to the game engine - however - than just the rendering.

If you spread out 5% of the overall load across all cores, it might actually help, but you still have 95% of the load not particularly well threaded.

That, and as we saw with Civ6, it actually LOWERS performance in many cases. End of round times in Civ6 actually go up when you enable DX12, presumably because the increased threading thrashes the per core L1 and L2 caches.
 
Last edited:
Still waiting on the [H] review.

If it would perform like an i5 without the i5 pricing, I'd seriously consider jumping back to AMD.
 
Zarathustra[H] said:
Mantle and DX12 are real. Remember, rendering is one area that is very well suited to multithreading.
Unfortunately you greatly overestimate the portion of the CPU load that is directly caused by the GPU rendering operations.
DX12 and mantle do help improve this,as did DX11 and DX10 respectively with their threaded improvements prior to this.
There is MUCH more to the game engine - however - than just the rendering.
If you spread out 5% of the overall load across all cores, it might actually help, but you still have 95% of the load not particularly well threaded.
That, and as we saw with Civ6, it actually LOWERS performance in many cases. End of round times in Civ6 actually go up when you enable DX12, presumably because the increased threading thrashes the per core L1 and L2 caches.
Click to expand...


Actually you refer to a game which used a solution that obviously was not the best case for it to use that is not due to anything else then the people which programmed it.
I actually never even mentioned multi-threading in my post so I'm not so sure what you were on about.

If I take a game as Diablo 3 which runs like crap on AMD cpu but runs fine on current consoles. The case I would make about game design is that it is ran by people whom are stuck because the PC version would have no hope in hell running on any amount of Jaguar cores and yet the console version does it well.

So Blizzard hired the most inbred redneck they could find for the PC version and for the console version they hired the champion of this universe in programming. Common sense tells us both can't be true.
 
Shintai said:
Consoles have been multicore for ages and people have been coding for multithreading for 30 years+ on the PC. I always find it funny when someone just claims its lazy developers and lack of APIs. The limitation is diminishing returns and serial code that cant be threaded.
Click to expand...

Yes they have. However, console ports ARE NOT as well threaded as native console games. Not even close. It's no myth. Consoles are multithreaded because they need to be. No one wants a console that draws 300w. So their designs are wide (more cores and clocked lower usually) with shorter pipeline stages. SB/IB etc have 14 - 19 vs today's console's 15 and all of the consoles today have 8 cores I believe. The PS3 I think had 8 with one disabled each with it's own cache and it came out in 2006. You can see the same thing in server designs. If you want more things to happen at once you need more cores not higher clocks. If you want things to happen in parallel then they have to be threaded. Higher clocks cannot eliminate the latency of executing more instructions than a single core can handle. Hide it? Sure. Eliminate it? No. Then you have to think about power usage.

Console games (good ones) use every single resource as close as possible to maximum efficiency. The problem with ports are two (maybe three) fold: A) The PC spec isn't fixed and the OS is much larger on a PC. Half of the gamers out there are on dual core the other half are quads. Some run cheapy 2.9Ghz i3s while others have 4.4Ghz+ overclocked quads, which do you test and program for? The spec that includes everyone or the spec that's limited to half or less of the market? Furthermore heaven-the-fuck help you if you have proprietary APIs which have licensing fees attached to them that only work on a particular console anyway. B) The tools used to port aren't sophisticated enough (more so with the older stuff - think PS2 or PS3) to port and keep the performance profile the same. It's much easier now (x86) than it's ever been. However, the problem is still point A. It's so much easier to put majority of the load on one core and use the second for remaining assets, lock the FPS and call it a day. Oh and C) Money and time to port. That's why console ports suck.
 
Last edited:
Pieter3dnow said:
Actually you refer to a game which used a solution that obviously was not the best case for it to use that is not due to anything else then the people which programmed it.
I actually never even mentioned multi-threading in my post so I'm not so sure what you were on about.

If I take a game as Diablo 3 which runs like crap on AMD cpu but runs fine on current consoles. The case I would make about game design is that it is ran by people whom are stuck because the PC version would have no hope in hell running on any amount of Jaguar cores and yet the console version does it well.

So Blizzard hired the most inbred redneck they could find for the PC version and for the console version they hired the champion of this universe in programming. Common sense tells us both can't be true.
Click to expand...


Diabo III ran poorly because of the CPU overhead in AMD drivers, along with other problems or bugs in drivers that were fixed fairly quickly after release, WIndows 10 introduced some other issues for AMD but those were fixed as well.

CPU wise Diablo III or ROS were not intensive at all, now multiplayer is a different story that will affect AMD CPU's quite a bit more as networking and physics get pretty heavy when working together. The console versions did not have the same physic effects as the PC version did. You are comparing apples and oranges and trying to draw a conclusion that has no basis.

Blizzard as a company is one the best examples of a company that doesn't care about IHV's (they don't even care much about their publisher's deadline, they are done when they are done and that is it) and they just want their games to play on all systems, they also don't care about doing crazy optimizations if they don't have to. Because like most game companies they only want one thing, make the best game possible. They don't push graphics tech like others do, Their games work on systems that are 5 years old with acceptable performance.
 
kac77 said:
Yes they have. However, console ports ARE NOT as well threaded as native console games. Not even close. It's no myth. Consoles are multithreaded because they need to be. No one wants a console that draws 300w. So their designs are wide (more cores and clocked lower usually) with shorter pipeline stages. SB/IB etc have 14 - 19 vs today's console's 15 and all of the consoles today have 8 cores I believe. The PS3 I think had 8 with one disabled each with it's own cache. You can see the same thing in server designs. If you want more things to happen at once you need more cores not higher clocks. Higher clocks cannot eliminate the latency of executing more instructions than a single core can handle. Hide it? Sure. Eliminate it? No. Then you have to think about power usage.

Console games (good ones) use every single resource as close as possible to maximum efficiency. The problem with ports are two fold: A) The PC spec isn't fixed. Half of the gamers out there are on dual core the other half are quads. Some run cheapy 2.9Ghz i3s while others have 4.4Ghz+ overclocked quads, which do you test and program for? The spec that includes everyone or the spec that's limited to half or less of the market? Furthermore heaven-the-fuck help you if you have proprietary APIs which have licensing fees attached to them that only work on a particular console anyway. B) The tools used to port aren't sophisticated enough (more so with the older stuff - think PS2 or PS3) to port and keep the performance profile the same. It's much easier now (x86) than it's ever been. However, the problem is still point A. It's so much easier to put majority of the load on one core and use the second for remaining assets, lock the FPS and call it a day. Oh and C) Money and time to port. That's why console ports suck.
Click to expand...


Don't mistake multithreaded vs low level code, too different things, low level code changes going from consoles to PC's can be a nightmare, most of the problems come from the GPU side not the CPU side. Also because PC's are more limited to 4 core with and without hyperthreading (vast majority), PC ports have to take that into consideration. Cause once you go wide, as I stated before, programs target how wide they need to go, vs what is the best performance they can get. Everything goes hand in hand.

Of course shader intrinsics takes care of some part of these issues, but not all.

How do you classify good console games vs bad ones? Cause I haven't seen any "bad" console games from a performance point of view as of yet, hence why only certain experienced developers are allowed to make them. And the benefits of a closed system.
 
Chebsy said:
If it costs a lot less than $1,049.99 that the Core i7-6900k currently sells for, it should do well.
Click to expand...

I'd like to see a full range of benchmarks before I make that statement confidently.

I have this sneaky suspicion we are still only seeing the benchmarks it does best in, and not the ones it doesn't, throwing off the perception.
 
razor1 said:
How do you classify good console games vs bad ones? Cause I haven't seen any "bad" console games from a performance point of view as of yet, hence why only certain experienced developers are allowed to make them. And the benefits of a closed system.
Click to expand...

Well, not only that, but the PC is often an afterthought on many of these titles.

The studio spends all their time optimizing the Console version to sell it to the lowest common denominator in volume, and the PC version is an afterthought ported by the lowest bidder for the contract.
 
razor1 said:
Don't mistake multithreaded vs low level code, too different things, low level code changes going from consoles to PC's can be a nightmare, most of the problems come from the GPU side not the CPU side.
Click to expand...
Usually only studios with massive budgets with their own engines do low level coding on consoles now. You can list them on one hand. Square, Crystal, ID and maybe Blizzard and Firaxis. Most stick with the standard dev tools using engines we all have heard of. I left the GPU part out because of the topic at hand but yes that has an effect as well.

razor1 said:
How do you classify good console games vs bad ones? Cause I haven't seen any "bad" console games from a performance point of view as of yet, hence why only certain experienced developers are allowed to make them. And the benefits of a closed system.
Click to expand...
By bad, I mean ones that aren't as optimized in relation to what the hardware is capable of or what's necessary. I can't give you specific titles because I don't need anyone hunting my ass down. But I can tell you that often times assets are much larger than they need to be.

This isn't the best example for CPU but it's the easiest visualized. There was one title specifically that I worked on that was pretty bad when it came to asset management. Basically it's the difference between what the artists want versus what the hardware can do. The problematic asset was something you would find in your every day environment but it consisted of 30,000 polygons (it might have been more than that) and the asset was placed throughout the environment many many times. Thus the game initially had a hard time running 30 FPS consistently on the PC. By the time we were done it ran 60 FPS easily but that didn't happen until much much later in the development cycle. Had that work not been done then the console port would have been pretty damn bad (back then ports went from PC to console). This is a little off topic but this affects CPUs too.

In the simplest of terms the CPU instructs something to happen and the GPU makes it happen. The more things you want to happen the more CPU resources are used. Once you get to stuff like explosions and tons of crap leaving and entering it all becomes too much for a single core to handle especially on consoles. Low level or not you'll get to a point when things need to almost happen in parallel. Once you get here then you need either a high IPC high clocked core, or lower clocks but more cores with passive or low airflow cooling. One is easier to do than the other.
 
Last edited:
kac77 said:
Usually only studios with massive budgets with their own engines do low level coding on consoles now. You can list them on one hand. Square, Crystal, ID and maybe Blizzard and Firaxis. Most stick with the standard dev tools using engines we all have heard of. I left the GPU part out because of the topic at hand but yes that has an effect as well.
Click to expand...

To get those dev kits studios need teams with 3 + released titles of AAA game making experience to begin with (every single member of the core team). So that is kinda of moot. Xbox has less strict guidelines but MS still needs to approve the final product.

By bad, I mean ones that aren't as optimized in relation to what the hardware is capable of or what's necessary. I can't give you specific titles because I don't need anyone hunting my ass down. But I can tell you that often times assets are much larger than they need to be. For example there was one title specifically that I worked on that was pretty bad when it came to asset management. Basically it's the difference between what the artists want versus what the hardware can do. The problematic asset was something you would find in your every day environment but it consisted of 30,000 polygons (it might have been more than that) and the asset was placed throughout the environment many many times. Thus the game initially had a hard time running 30 FPS consistently on the PC. By the time we were done it ran 60 FPS easily but that didn't happen until much much later after people complained. Had that work not been done then the console port would have been pretty damn bad (back then ports went from PC to console).
Click to expand...

Asset development is important, but most likely it wasn't a polygon count issue. I can make 200k characters (animated) work fine on consoles and PC's with the UE4 engine, so I'm thinking maybe something to do with the vertex data or something that is messing that up and making a mess in the engine (maybe something to do with physics and animation system interacting with the engine?). Most likely to do with engine code than the asset, and probably done something the wrong way.

Yeah that is the thing though, very rarely something like that happens, and your team fixed it, its much easier to fix a problem that is on a close system ;) only need to fix it once.
 
ManofGod said:
Unfortunately, my French reading skills are non existent. Thanks for the link though.
Click to expand...

Seems that that the 5 GHz on air is for a single core. I think I read somewhere that the AMD chip will boost one core when confronted with a single core workload like the newest Intel chips. I could very well be wrong though. I don't remember where I read that though.

Maybe it's the SenseMi Precision Boost like mentioned in this article?
http://www.anandtech.com/show/10907...nvme-neural-net-prediction-25-mhz-boost-steps

In the translation it says one heart was active; I take that to mean one core.
  • ZenOC @ Air = 5G
We hide regularly some easter eggs in the magazine. In March, we had coded "Intel GPU = AMD" in a binary string of the CPU page of the purchase guide. Virtually no one had seen the information at that time when it made a big noise 6 months later. In short, we are teasing. The presence of the chain of the current issue, which decodes "ZenOC @ Air = 5G" in this issue people talking on forums for 2 days. Being unmasked, we owe you some details. First, we did not summarize a test in a few bits. If we had been able to test ourselves overclocking, we would have told you openly in the preview. In spite of everything, we know with almost certainty that the CPU that we used for the tests actually came close to the 5 GHz with an (huge) air-dissipator. The I / O multiplier is not clamped at this time and is configured in steps of 0.25x. One heart, however, was active; The Motherboard VRMs seemed at that time too unstable to test with all of the cores. Other Ryzen ES are currently in the hands of overclockers and you should not delay to learn more: a demonstration of overclocking could occur at the CES if good results are achieved.
 
If we can OC 16T Zen to 4GHz with still reasonably low TDP it is already pretty great. Anything extra is just a bonus.
 
johnnyf3v3r said:
Since Ryzen has only a 95W TDP we won't need extra powerful cooling or an overly expensive AIO to get the highest clock speeds as it was mentioned at New Horizon. I'm just really stoked. :)
Click to expand...

reality - expectations = happiness

You're setting yourself up for disappointment. A 6700k is 91W which has been around for quite a while. I guess if you're comparing it to a 9570 then it's great. Once you start OC'ing you'll still need good cooling.
 
I'm still on the fence on wether or not to watercool Zen + Vega. I ordered a NZXT S340 and it can only fit a 280 or 240mm rad.

I have an EK Supremacy Evo for CPU and a universal GPU block. 2 cheap but good chinese pumps, and a 480mm radiator.
 
TheLAWNoob said:
I'm still on the fence on wether or not to watercool Zen + Vega. I ordered a NZXT S340 and it can only fit a 280 or 240mm rad.

I have an EK Supremacy Evo for CPU and a universal GPU block. 2 cheap but good chinese pumps, and a 480mm radiator.
Click to expand...

Well with that the rad is already out (what 480 is it if you don't mind my asking) and there is nothing saying that the Supremacy will fit the new AM4 socket, or the universal fitting (I was gonna get an EK universal for my Fury, no bracket for the holes :/ )
 
cageymaru said:
Seems that that the 5 GHz on air is for a single core. I think I read somewhere that the AMD chip will boost one core when confronted with a single core workload like the newest Intel chips. I could very well be wrong though. I don't remember where I read that though.

Maybe it's the SenseMi Precision Boost like mentioned in this article?
http://www.anandtech.com/show/10907...nvme-neural-net-prediction-25-mhz-boost-steps

In the translation it says one heart was active; I take that to mean one core.
  • ZenOC @ Air = 5G
We hide regularly some easter eggs in the magazine. In March, we had coded "Intel GPU = AMD" in a binary string of the CPU page of the purchase guide. Virtually no one had seen the information at that time when it made a big noise 6 months later. In short, we are teasing. The presence of the chain of the current issue, which decodes "ZenOC @ Air = 5G" in this issue people talking on forums for 2 days. Being unmasked, we owe you some details. First, we did not summarize a test in a few bits. If we had been able to test ourselves overclocking, we would have told you openly in the preview. In spite of everything, we know with almost certainty that the CPU that we used for the tests actually came close to the 5 GHz with an (huge) air-dissipator. The I / O multiplier is not clamped at this time and is configured in steps of 0.25x. One heart, however, was active; The Motherboard VRMs seemed at that time too unstable to test with all of the cores. Other Ryzen ES are currently in the hands of overclockers and you should not delay to learn more: a demonstration of overclocking could occur at the CES if good results are achieved.
Click to expand...

I'm wondering a couple of things about how well the technology AMD presented at Horizon is implemented.

Would a 8C16T Ryzen perform single thread (or up to 4) better when there are 4 cores disabled in the bios or through software (windows allows you to designate specific cores to that task) or with the AMD technology.
 
Pieter3dnow said:
I'm wondering a couple of things about how well the technology AMD presented at Horizon is implemented.

Would a 8C16T Ryzen perform single thread (or up to 4) better when there are 4 cores disabled in the bios or through software (windows allows you to designate specific cores to that task) or with the AMD technology.
Click to expand...
I would think turning off cores would allow better OCs, Windows would still use the unassigned cores plus they will be running at clock speeds most likely the same unless they are turned off. Now if Zen has a easy way to decouple the core clocks also turning them off inside of Windows would be very interesting. For example a game using only 2 cores you could push the OC very high, decouple or turn off unused cores etc. I just think Zen will be powerful enough that the extra clock speeds (like for use in Arma 3) would be pointless in more cases then not. A motherboard may not be able to support 8 cores at 5ghz but 6 it might is another thought which for most games is more then enough cores.
 
Original source:
http://blog.livedoor.jp/nichepcgamer/archives/1063391211.html

Compare with a 6900K:
3caf3fb9.jpg
 
Damn so far all "leaked" benchmarks have looked much worse then AMD has shown so far....... Well either Intel has a camp of sending out false info or AMD is hyping again.....
 
You must log in or register to reply here.
Back
Top