AMD CPU speculation... and expert conjecture

[-Fran-]

There's plenty of programming that can go into hard threads.

Just by adding complex physics you render almost any multi-CPU/GPU setups useless. Path calculation is another good example. Hell, I remember a friend of mine, that was calculating how a simple fracture can be calculated. To actually calculate it and don't die waiting you need a really nice amount of FPU units.

Now... You just need a good engine that can spawn hard threads, let you synchro with some level of ease and actually use them. Soft threads are too easy to use, but they have horrible diminishing returns and memory constraints.

Anyway, there is a wall and we all know it, but I truly believe we're still very far from hitting it

Cheers!

 

[esrever]

Pretty sure the APU already has a northbridge on die. And i hope we don't come to that point but it seriously seems that way.

Oh I was thinking southbridge. I expect AMD to eventually only make SoCs for consumer computing. Depends if they can get traction with servers and stuff, they might as well stop producing pure cpus.

 

[cgner]

Explain battlefield 3.
explain Metro 2033
explain Civ V.

those are all very much multi-core friendly. All you ever do is say "oh, they run on a dual core system, so they are only a dual core game and it will NEVER happen."

you want to cry foul, fine. explain how these games are multi-core friendly today when it will NEVER happen.

http://www.sweclockers.com/image/diagram/2506?k=142b45af179c625ccd8f53fea7385155

this is obviously fake since no game uses more than 2 cores, because the dual core system is unplayable. Single player benchmarks has shown that its perfect in every way.

If you want me to stop it, explain how games will NEVER be multi-core friendly when they are that way TODAY.

Kinda funny to me because it seems your on a crusade to keep programming simple, going against the way that hardware is headed. From tsx to lock-free to parallel. nothing is acceptable because it would require re-learning what you alredy know.

Fight the future, fight innovation, fight advancements in programming, Fight to protect the dual core systems.

Exactly, those are the very very few games that can use 6 cores. Also BF 3 hammers dual THREADED, not dual CORE processors. i3 pulled 60 fps no problem with 2 cores.

 

[Cazalan]

Oh I was thinking southbridge. I expect AMD to eventually only make SoCs for consumer computing. Depends if they can get traction with servers and stuff, they might as well stop producing pure cpus.

They will phase out eventually, like for Hondo/Temash. They're severely performance limited for now. At 5nm there should be some really impressive SoCs.

 

[m32]

^5nm tech? LOL. How many years is that going to take (if it can happen)?

 

[sarinaide]

HSA is the way forward, not only does it render multicore scaling irrelavent it is already considerably faster than traditional x86 and more efficient and easier to code for.

 

[mayankleoboy1]

HSA is the way forward, not only does it render multicore scaling irrelavent

HSA = CPU+GPU+misc PU's. So if your code is not scaling to more than 2 CPU cores, how will it scale to ~2000 GPU's smaller cores ?

more efficient to code for.

Doubt this.
More efficient only if the code is scaling.

easier to code for

Doubt this. Anything new is difficult to adapt to, usually. Plus, most programmers have not been trained to think in terms of multiprocessing.

 

[mayankleoboy1]

To all who say more threading is good, lets take the example of OpenMP.

It is really very simple concept. Whenever there are loops, or code that you think can be parallelised easily, you add some directive to the compiler, which automagically parallelises the code.
But the problem is that
1. It is extremely conservative.
2. Parallelising can lead to race conditions in rest of the code, which are almost impossible to diagnose.
3. Auto threading overhead very quickly evens out the performance gain.

So unless your workload is inherently parallel to work with like audio, video, images, array multiplication , auto/manual parallel threading wont give you much of an improvement.

 

[de5_Roy]

hsa is certainly promising. however, the software/apis don't seem to be mature yet. and since it's amd... well... software-wise, it'll take a while. meanwhile, intel isn't gonna sit on their asses and they're gonna pursuade devs into coding for xeon phis. they will go as far as to give xeon phis for free if it got them better foothold into hpc sector. additionally, arm and nvidia will push their own hsa-like technologies (arm is a member of hsa).
if hsa is the future, the future sure looks crowded.
so far, gpu-based general purpose use gives the best advantage in the way mobile devices save power by skipping cpus and using gpu cores to do some tasks. arm socs use big.little, i think that will slowly transition into custom gpus or hsa-based gpus. i doubt this will directly benefit amd (revenue-wise) unless they design those gpus.

btw, does anyone know what kind of communication logic (4g/lte) will temash and kabini use?
i dunno much about programming, so feel free to correct any mistakes. tia.

 

[butremor]

I dont want to start new topic so i'll just ask here, why the hate towards AM3+ platform? Spotted many times on this forum, people saying that AMD should drop it. It's just one year ago released platform, is it that bad?

 

[sarinaide]

HSA = CPU+GPU+misc PU's. So if your code is not scaling to more than 2 CPU cores, how will it scale to ~2000 GPU's smaller cores ?

more efficient to code for.

Doubt this.
More efficient only if the code is scaling.

easier to code for

Doubt this. Anything new is difficult to adapt to, usually. Plus, most programmers have not been trained to think in terms of multiprocessing.

Well GPU cores scale well, it is marely subsidising workloads which has been done by gaming developers for a very long time now.

 

[sarinaide]

hsa is certainly promising. however, the software/apis don't seem to be mature yet. and since it's amd... well... software-wise, it'll take a while. meanwhile, intel isn't gonna sit on their asses and they're gonna pursuade devs into coding for xeon phis. they will go as far as to give xeon phis for free if it got them better foothold into hpc sector. additionally, arm and nvidia will push their own hsa-like technologies (arm is a member of hsa).
if hsa is the future, the future sure looks crowded.
so far, gpu-based general purpose use gives the best advantage in the way mobile devices save power by skipping cpus and using gpu cores to do some tasks. arm socs use big.little, i think that will slowly transition into custom gpus or hsa-based gpus. i doubt this will directly benefit amd (revenue-wise) unless they design those gpus.

btw, does anyone know what kind of communication logic (4g/lte) will temash and kabini use?
i dunno much about programming, so feel free to correct any mistakes. tia.

I am not surprised to see Intel hitching onto someones brain child, they have done that for years using infinite wealth and resources to ensure they get what they want at the expense of the end user, it was never going to be fair game as simply put Intel have far outstriped AMD's wealth and leached on their innovations then barrage it with money and resources until the market is saturated.

AMD wont cease as it is for the next 5 years but down the line like ATI good ideas cannot sustain you when there are no resources. If AMD disappears things will look very bleak. Buying Intel is like taking everyone elses work under a guise of a corporate monolith that not even the US government can do anything about.

 

[gamerk316]

Also, I still want you to answer my question: If parallelism is so difficult, why did we ever leave single core processors? [/quote]

Because with the Pentium 4, it was discovered you can't increase clocks much above 4GHz without running into server power/heat constraints. Thus, moving to lower speed, but multiple cores, made more sense.

And for most tasks, you can usually get loading on two cores without issue; one thread to handle all the work, and one thread to manage everything else. The problem is getting more scaling beyond that, which is very hard to achieve.

Understand that programs typically have dozens of threads that run. Of those, only a handful will be parallel in nature, but of those, maybe one does any reasonable amount of work. So you see Task Manager core loading that looks something like 60%-40%-5%-1% on a quad, or 60%-50% on a dual. And again, that assumes a single task doing a lot of work; run two or more apps that do significant amounts of work, and the benefits of quads becomes much more clear.

Explain battlefield 3.
explain Metro 2033
explain Civ V.

those are all very much multi-core friendly. All you ever do is say "oh, they run on a dual core system, so they are only a dual core game and it will NEVER happen."

you want to cry foul, fine. explain how these games are multi-core friendly today when it will NEVER happen.

http://www.sweclockers.com/image/diagram/2506?k=142b45af179c625ccd8f53fea7385155

this is obviously fake since no game uses more than 2 cores, because the dual core system is unplayable. Single player benchmarks has shown that its perfect in every way.

If you want me to stop it, explain how games will NEVER be multi-core friendly when they are that way TODAY.

Kinda funny to me because it seems your on a crusade to keep programming simple, going against the way that hardware is headed. From tsx to lock-free to parallel. nothing is acceptable because it would require re-learning what you alredy know.

Fight the future, fight innovation, fight advancements in programming, Fight to protect the dual core systems.

BF3 multi shows significant benefits to using a quad, true, especially in 64-player servers. But that makes SENSE, given the extra networking code and having to manage the players in the game. Multiplayer for that reason is ALWAYS going to be more effective with more cores, simply because you are doing more processing.

Your little graph is also a little bit odd in its results: A significant gain via HTT? But at the same time, the 1100T and FX8150 lag behind to 2500k? Doesn't that kinda disprove your argument? Looking at those numbers, couldn't one conclude that HTT is better then adding more processing cores? At a quick glance, it appears clock speed/IPC is far more important to performance for that benchmark (explaining why the 2600k beats the 2500k, and why BD and the 1100T lag behind). And I note, no pictures of how the cores are actually loaded up...

There's plenty of programming that can go into hard threads.

Just by adding complex physics you render almost any multi-CPU/GPU setups useless. Path calculation is another good example. Hell, I remember a friend of mine, that was calculating how a simple fracture can be calculated. To actually calculate it and don't die waiting you need a really nice amount of FPU units.

Now... You just need a good engine that can spawn hard threads, let you synchro with some level of ease and actually use them. Soft threads are too easy to use, but they have horrible diminishing returns and memory constraints.

Anyway, there is a wall and we all know it, but I truly believe we're still very far from hitting it

Cheers!

No developer, outside of consoles, is going to use hard threads. Why? Because PC's are non-deterministic. At any point in time, I do not know how much of the system resources are in use, or the performance hit if it try to use them. Thats why loading threads to cores is left to the OS scheduler.

No, physics and pathfinding are two good examples of loads that DO scale nicely. In face, they scale so well, the results are generally calculated faster via a GPU-like architecture with hundreds of slower cores, rather then a few fast ones.

 

[-Fran-]

- Hate on AM3+

Well, my personal "hate" (dislike to be more precise) for AM3+ is that the only new thing that it actually brought to the table was SLI support. And that's about it. The socket itself is not "new" at all. and the interconnects are basically the same as previous sockets from the s939 era. That's a good 8 years old now I think and AMD hasn't improved almost nothing in the transport subsystem. Hyper Transport is too damn old and on each CPU jump, they've added just a few extra MB/s worth of bandwidth.

- HSA n' Parallelism

There's a LOT of stuff you can really thread, but you need to do a little paradigm shift. It's not an easy thing to do, but take a look, for example, at the AI in games. I think I mentioned this a long time ago, but F.E.A.R. (the first one) has incredible AI and it uses only 2 cores (AFAIK). With 4 cores today, there's not a single game that I have played which, in my personal opinion, has beat that game's AI. I'd really love to see how it was coded, cause I'm sure, if you take that code as base, you could make good use of 4+ cores with monstrous AI. And AI includes path calculations, off course, among a lot of decision trees to solve.

Now, HSA won't magically solve/improve, for example, crappy AI's become brilliant ones. There's also designed involved and we all know that to solve something, you must target a certain arch. In this case, ugh, consoles. I'm pretty sure if the previous gen consoles had more cores, we wouldn't be having this discussion

- Samsung Nexus 10

As a side note, the dual A15's are very monstruous and I'm wondering how AMD will match them in power / performance. The next gen low power APUs won't make a dent IMO.

Cheers!

 

[skitz9417]

http://www.anandtech.com/show/6202/amd-hires-exintel-labs-architect-john-gustafson-as-chief-graphics-product-architecture

 

[mayankleoboy1]

Well GPU cores scale well, it is marely subsidising workloads which has been done by gaming developers for a very long time now.

wut?

 

[amdfangirl]

- Samsung Nexus 10

As a side note, the dual A15's are very monstruous and I'm wondering how AMD will match them in power / performance. The next gen low power APUs won't make a dent IMO.

Cheers!

They don't need to.

Certain people will just buy it based on the fact it has x86 compatibility.

I wish people would continue supporting netbooks.

I like my netbooks.



[ur=http://www.theregister.co.uk/2013/02/01/goodbye_netbooks/]And so does he[/url]

I'm hoping there will be a revolt amongst users who actually want to create something on the go.

AMD can't compete yet in this department, given that lack of cellular IP. So we'll see them in tablets first.

The next Surface Pro perhaps?

 

[-Fran-]

Well, AMD has been in bed with Qualcomm before, so they kind of have access to cellular chips for their SoCs, I think. At least, they could come up with something in short term IMO.

But still, having x86 only matters for windows "apps", which seem a little weird to name x86 programs, haha. In the tablets and smartphones world, the playing field is completely different than desktop and notebook/portable. Having less flexible OS'es makes X86 or ARM irrelevant, since they depend mostly on tight APIs. Like when creating web apps... Well, it is exactly that, haha.

Anyway, performance wise, the A15 is a very strong design it seems.

Cheers!

EDIT: The Surface PRO is the closest you'll get to a Netbook for a long, long time. The other is looking at ultra-portables/thins.

 

[gamerk316]

There's a LOT of stuff you can really thread, but you need to do a little paradigm shift. It's not an easy thing to do, but take a look, for example, at the AI in games. I think I mentioned this a long time ago, but F.E.A.R. (the first one) has incredible AI and it uses only 2 cores (AFAIK). With 4 cores today, there's not a single game that I have played which, in my personal opinion, has beat that game's AI. I'd really love to see how it was coded, cause I'm sure, if you take that code as base, you could make good use of 4+ cores with monstrous AI. And AI includes path calculations, off course, among a lot of decision trees to solve.

You just fell into a major trap. AI is not self contained; it is affected by the rendering engine (Can an AI object see another object or not?), audio engine (did it hear that footstep?), and physics engine (run away from rockslide, etc).

Now, you could quite easily, using just about any OO language out there, make each AI its own unique thread, and in theory, this would scale well. In reality, because of how much interaction goes on, performance would very quickly bottleneck as your threads constantly lock eachother attempting to obtain the data they need to operate. If you have AI's working together on a common problem, things get worse (as groups of threads would constantly lock eachother, killing performance).

Upper level AI processing is done very simply:

foreach AI.Object in AI do

\\ Process AIs here

loop;

And guess what? Thats all you need to do. In the case of AI's, threading beyond more then a handful WILL slow you down. Thats why no one does it.

 

[kettu]

http://www.sweclockers.com/image/diagram/2506?k=142b45af179c625ccd8f53fea7385155

That's a good find, noob. Analysing more closely we can see how quad vs quad intel is ahead of 3.7GHz Phenom II, but dropping the clockspeed to 3.3GHz and adding two cores AMD is able to catch up (minimum framerates matter more to me than higher averages). Also performance increases between i7 975 and 2500k when cores are added even though it's and older architecture. There's no question wether or not BF3 multiplayer uses more than four cores effectively.

You're probably right that games will use more and more cores in the future. Even if some parts of computer games can't ever be parallellized accessories like Kinect will benefit from more cores. All those sensory inputs must be processed and that's not a trivial task so quite a lot of CPU time is needed. There's no point putting the processing hardware in the sensor box when people have powerfull multicore CPUs. The benefit of this approach is that it reduces the manufacturing costs of these devices improving their margins (making them more appealing for manufacturers) and/or reducing their prices (obviously making them more appealing to consumers).

By the way, want to bet that when first research began on out-of-order execution there were people saying it can never be done because it's too complex and impossible and instructions will always have to run in the same order as they are in the program?

 

[JAYDEEJOHN]

OK, lets try something here.
Saying usually cores dont get pegged at 100%, and there are at least 4 per cpu, whats that saying to us here?
When we benchmark, we choose to use those that do peg our cores as much as possible, tho most apps/games do not.

Now, IPC does make a difference, and time/thruput does as well, we are now seeing the new consoles using AMD cores, as weve reached the good enough scenario.
Why this move?
Its a question we should be asking ourselves here

 

[amdfangirl]

Well, AMD has been in bed with Qualcomm before, so they kind of have access to cellular chips for their SoCs, I think. At least, they could come up with something in short term IMO.

But still, having x86 only matters for windows "apps", which seem a little weird to name x86 programs, haha. In the tablets and smartphones world, the playing field is completely different than desktop and notebook/portable. Having less flexible OS'es makes X86 or ARM irrelevant, since they depend mostly on tight APIs. Like when creating web apps... Well, it is exactly that, haha.

Anyway, performance wise, the A15 is a very strong design it seems.

Cheers!

EDIT: The Surface PRO is the closest you'll get to a Netbook for a long, long time. The other is looking at ultra-portables/thins.

I mean like an SoC type platform. All the fancy wireless stuff integrated well into the chip.

I keep my faith in netbooks with nice keyboards.

I'm broke.

 

[gamerk316]

OK, lets try something here.
Saying usually cores dont get pegged at 100%, and there are at least 4 per cpu, whats that saying to us here?
When we benchmark, we choose to use those that do peg our cores as much as possible, tho most apps/games do not.

Now, IPC does make a difference, and time/thruput does as well, we are now seeing the new consoles using AMD cores, as weve reached the good enough scenario.
Why this move?
Its a question we should be asking ourselves here

A few things to consider: The X86/PPC performance gap has exploded since 2006, so its not like PPC is a viable performance option anymore.

Now, look at the low-power offerings from Intel and AMD: Between Atom and Llano/Trinity, which is more attractive?

 

[esrever]

Eventually computing will change. Spreading things across cores will one day be like spreading work across a team of people. They can all work on things and be managed by themselves and they can resolve much of their own interactions.

 

[JAYDEEJOHN]

Throw in some compute.......

I feel, the more we integrate gpu with cpu, the better each scenario of what does best for each workload will eventually be worked out, and with M$ being as 1 of the console makers, they too get a head start here