Official AMD Ryzen Benchmarks, Reviews, Prices, and Discussion

[formulav8]

LLVM 5.0 Should Offer Better AMD Ryzen Performance

 

[formulav8]

This is very simple, a program should not act diferently if it has 2, 4 or 256 cores, it is as simple as that

I hope you're not a programmer.

 

[cytg111]

This is very simple, a program should not act diferently if it has 2, 4 or 256 cores, it is as simple as that, a modern MT code will scale properly, and i think you will have a hard time finding the "first check how many cores you have at runtime" on any programing guide. F1 2016 is using old style programing if it needs to know how many cores it has avalible. /period

Wait what why? There is no free thread-lunch, sorry, they have overhead and that overhead grows.
Imagine a scalable problem and even throw something akin to TSX into the mix

https://image.slidesharecdn.com/tra...transactional-memory-55-638.jpg?cb=1466938325

Diminishing returns, and this is *with* the developer turning him/her self inside out to get it to scale. If 500 cores wont run Crysis, neither will 1000. (Bad example I know... i had to though).

 

[Glo.]

This is very simple, a program should not act diferently if it has 2, 4 or 256 cores, it is as simple as that, a modern MT code will scale properly, and i think you will have a hard time finding the "first check how many cores you have at runtime" on any programing guide. F1 2016 is using old style programing if it needs to know how many cores it has avalible. /period

You know what? People who are programming games, for iOS, to which I have shown your post, are laughing their asses off.

Let me tell you whats the problem. You know that bell rings in a church. You do not know in which one, exactly. Do more research. This is not to be mean, just an advice.

For your defense - you are partially correct. But 90% of what you have presented is simply - misinformation about the nature of programming, and threading the workloads.

 

[Mr Evil]

This is very simple, a program should not act diferently if it has 2, 4 or 256 cores, it is as simple as that, a modern MT code will scale properly, and i think you will have a hard time finding the "first check how many cores you have at runtime" on any programing guide. F1 2016 is using old style programing if it needs to know how many cores it has avalible. /period

As a programmer myself, I can tell you that if you have a task that can be split into an arbitrary number of threads, it's pretty important to know how many threads will yield the best performance. That will of course vary depending on the CPU. I'm not sure what sort of "programming guides" you read, but it's not hard to find discussions among programmers about this.

 

[innociv]

For many threaded tasks in games, they don't care how many cores there are. They spawn a thread and the OS scheduler may stack it with another large thread, or it may not.

But for easily parallel tasks like physics, yeah those are things that they need to be aware of the thread count to spawn as many as there are cores or maybe one less. And in the case of Ryzen, it may be better to have main threads on one CCX and dumb parallel tasks on the other, as one example. But no, you don't just spawn 256 threads for one task and let the scheduler handle those.

 

[Zstream]

For many threaded tasks in games, they don't care how many cores there are. They spawn a thread and the OS scheduler may stack it with another large thread, or it may not.

But for easily parallel tasks like physics, yeah those are things that they need to be aware of the thread count to spawn as many as there are cores or maybe one less. And in the case of Ryzen, it may be better to have main threads on one CCX and dumb parallel tasks on the other, as one example. But no, you don't just spawn 256 threads for one task and let the scheduler handle those.

When I programmed, I did not care to keep track of the amount of threads and let the OS do it. However, the program often pegged one core and became sluggish at times. If I was smart, I'd still like to know how many threads a machine had and attempt to allocate or divide tasks in a way that one core wouldn't take the brunt of the workload.

So if I had two cores, I'd try to run one worker in one core and the rest on the other. If I had four cores, I'd move network functions to one core, math to one, and general AI to the third and leave the remaining for OS tasks.

I'm not sure how to do this in a game though. I'd like to see a game company start to do this.

 

[tamz_msc]

Its easier than getting rid of the main thread, so yes.

All I can infer from your statement is that you have zero clues as to what AVX is and how it is used by applications.

 

[theevilsharpie]

No, i got it right, if the game needs to identify anything means its not using the new model of "just create threads and forget about them", creating threads and letting the O.S. scheduler do its job, thats the new and current model. If you do that its the same if is 4, 8, 16 or 128 cores, or if it runs on Window,s Linux, Android or console, your code should aways run right, as long you dont run intro main thread bottleneck. If you need to idenfity CPU then you are doing it the old way.

The games does not need to read ANYTHING AT ALL. Just create the threads you need and keep on going, is the O.S. job to do load balancing and thread affinity.
If it needs to read core count thats because it runs on a outdated programing model.

This is very simple, a program should not act diferently if it has 2, 4 or 256 cores, it is as simple as that, a modern MT code will scale properly, and i think you will have a hard time finding the "first check how many cores you have at runtime" on any programing guide. F1 2016 is using old style programing if it needs to know how many cores it has avalible. /period

This is wrong, and you've repeated this misinformation multiple times across multiple pages.

Threads aren't free. If you have more threads scheduled to run than processors that can run them, the OS has to context switch, where it has to stop the thread, save the memory that it's using, evict the registers and cache that it's using, load a new thread, and so on. All of this takes CPU cycles away from processing the workload.

In addition to context switches, threaded workloads typically have some type of shared memory where writes to it need to be controlled (so one thread doesn't overwrite the work done by another). This is generally done with some type of lock, which has to be coordinated among all of the threads. The more threads sharing a data structure, the more cycles the OS has to spend managing access to those data structures.

Every programming language that supports multiprocessing has some type of function or method to discover at runtime how many processing cores the machine has, specifically so that the application can assign an appropriate number of threads. This has been the case for as long as SMP systems have existed, and it continues to be the case today.

But hey, if you have a technique that allows an application to spawn an arbitrarily large number of compute-bound threads on a machine with finite processors/memory without consequence, please publish it and collect your Noble prize.

If you have any doubt open the resource manager and take a closer look at the number of threads a game starts howdays.

The dozens of threads that an application spawns are primarily threads to manage I/O operations (e.g., file access, listening for events from inputs devices, network access, sound, etc.). These are spun off into their own threads so that the main thread doesn't block waiting for I/O. It doesn't really matter how many of these threads there are (within reason) because they spend most of their time waiting, and the OS can schedule other threads to run in the meantime.

You wouldn't run compute-intensive threads in this manner for the reasons that I described above.

 

[Zucker2k]

Nobody is expecting games to implement user mode scheduling, the potential 3-7% performance improvement is simply not worth it.

There is a difference between a lack of optimisation and a bug, it is pretty big stretch to claim that the windows scheduler is buggy due to the missing CCX optimisations. Hopefully they will add the optimisations in the future

AMD made their choice with the CCX typology, it is a compromise - I doubt the performance penalty comes as a surprise to AMD.

This.

 

[Mockingbird]

AMD announces Ryzen series 5 with six and four-core processors available April 11

http://www.guru3d.com/news-story/am...-four-core-processors-available-april-11.html

EDIT: article was taken down.

Screenshot:

 

[french toast]

Incredible value.

 

[tamz_msc]

The 1400 and 1500X are too closely priced for what they offer - AMD should have priced the 1400 at ~130 and it would have killed off the i3s once and for all.

They are probably going to do that with Raven Ridge I supppose.

 

[PhonakV30]

AMD announces Ryzen series 5 with six and four-core processors available April 11

http://www.guru3d.com/news-story/am...-four-core-processors-available-april-11.html

EDIT: article was taken down.

Screenshot:

https://videocardz.com/67342/amd-ryzen-5-to-launch-on-april-11th

 

[prtskg]

Most important thing to see will be how far they go beyond their turbo frequency. I'm now more interested in zen apu as they won't have to deal with ccx and by that time foundry's capability should improve.

 

[french toast]

Raven ridge might be the first apu you can buy that is valid for gaming on its own merrit, think ill buy one and hold off on a gpu untill 2018/2019.

 

[cytg111]

Most important thing to see will be how far they go beyond their turbo frequency. I'm now more interested in zen apu as they won't have to deal with ccx and by that time foundry's capability should improve.

Gonna be interresting what HBM brings to the table .. may be first real viable gaming APU around..

 

[Borealis7]

to me, the real interesting comparison will be a 1500X+OC vs i7-7700 (non K).
both CPUs are 4C/8T and similar TDP but the i7 costs more, and will probably be better from a pure power perspective, but the 1500X would probably win the price/performance metric.

 

[Qwertilot]

Gonna be interresting what HBM brings to the table .. may be first real viable gaming APU around..

I fear that may get a bit annoying - AMD clearly now have the technology to produce a really good single chip gaming solution, whether they've got the spare R&D for a niche thing like that is another matter.

 

[cytg111]

I fear that may get a bit annoying - AMD clearly now have the technology to produce a really good single chip gaming solution, whether they've got the spare R&D for a niche thing like that is another matter.

I hear that but I am also thinking that there will be common ground between those and the next xbox/ps skus, there may be a "shared" R&D budget there.

 

[imported_jjj]

As per the Videocardz leak:
1600X 6 cores at 3.6GHz base and 4GHz turbo at 249$
1600 6 cores at 3.2GHz base and 3.6GHz turbo at 219$
1500X 4 cores at 3.5GHz base and 3.7GHz turbo at 189$
1400 4 cores at 3.2GHz base and 3.4GHz boost at 169$


How does that make any sense?
They had room for another 6 cores SKU between the 1600 and 1600x but the naming scheme doesn't allow it.
The quads appear clocked low and even if they end up with 200-300MHz XFR, lots of potential buyers won't be aware of it. AMD needs to list higher clocks than those.
The ii5 7500 goes to 3.8GHz, AMD needed a SKU at 4GHz listed clocks.
The 1400 vs 7400 doesn't look great either as AMD somehow turns XFR into a disadvantage by excluding it from listed clocks.
They push MT high enough (considering that they got SMT enabled) but keep ST too low.
Why they stop at 169$ is unclear and why waste half a year to reach 99$ for a quad.
Is their goal to avoid making money?
The gap between the 1600X and the 1700 is super dumb. They should focus on the 250-350$ price band and flood it with more SKUs Intel can't but AMD can.They need at least 3 more SKUs there or they are leaving money on the table.

 

[beginner99]

They had room for another 6 cores SKU between the 1600 and 1600x but the naming scheme doesn't allow it.

they are all unlocked so I say it's perfectly OK as it is. OCers will choose the cheaper one everybody else the 1600x. No need for a 3rd sku.

The quads are probably the worst binning chips that can't reach higher clocks (and not necessarily dies with broken cores).

 

[PotatoWithEarsOnSide]

7500/7400 will be up against the R3 4c/4t SKUs. They'll be clocked higher for sure.

 

[imported_jjj]

they are all unlocked so I say it's perfectly OK as it is. OCers will choose the cheaper one everybody else the 1600x. No need for a 3rd sku.

The quads are probably the worst binning chips that can't reach higher clocks (and not necessarily dies with broken cores).

Not that many OC and those that do can buy cheaper SKUs to do it.
Might be ok for you but it's not ok for AMD,if the goal is to make money.

As for binning, they need to make the products exciting.
If they need the best clocking dies for 4GHz 4 cores so be it.
With "blah"specs they define the mood for the entire line and that's a 1 billion $ mistake.
They need to make the choice easy for potential buyers and the biggest problem is that XFR is not listed in specs by shops. Don't give customers any reason to hesitate.

The listed specs for the 4 cores feel like budget, we'll give you barely enough to make the SKU competitive.

 

[Atari2600]

This is very simple, a program should not act diferently if it has 2, 4 or 256 cores, it is as simple as that, a modern MT code will scale properly

HAHAHAHAHAHA

I knew you were pretty absent of knowledge before now, but that is breathtaking.

Consider all you posts to be filtered from now as the gibberish mutterings of a person that can barely turn on a computer.