PS4 to be announced Feb 20th - Your predictions

The Game Room
201

This is not an argument.

My argument is this: multiple slow cores is a strategy that can work in applications that have data that are suitable for highly paralellized execution.

My evidence is that we’ve seen this in the real world. In video encoding, and rendering, two applications that are highly paralellized, we see an actual efficient use of multicored processing. Especially in GPUs, where the core counts are in the thousands.

And yet, in an enviornment where we’ve had multicored CPU processing available for as long, we see the main thread of games bottlenecked by processing in a single core.

If the main game thread in a video game were as paralellizable as things like rendering and video encoding, we would’ve seen multithreaded apps and games that properly take advantage of this. For the most part, we have not. The explanation is that not all data is something that you can paralellize in the same way. If you throw a non-paralellizable problem at a multicore slow processor, you just end up dragging along at the speed of the slowest thread while most cores sit idle.

It’s not a lack of developer commitment to the idea of paralellizing data - the fact that we render and encode at near-theoretical limits of efficiency with these designs proves that. It’s the unsuitability of the data.

Just saying “oh the industry is big, they’ll find a way” is missing the point. It’s not the best way to tackle this problem. Even if they manage to work around the limitations to some degree, why design those limitatons in in the first place? Large amounts of slow cores is poor design for general purpose CPUs.

You actually do need to flesh out your explanation. See, I’ve made an argument. It’s logically sound. It explains the current situation. You, on the other hand, may have entered some of those terms into google and then name dropped some of the resulting jargon to scare me off. In any case, you certainly have not offered an explanation which explains the current status quo in regards to multithreaded execution.

Uh, no? What do these have to do with the current discussion? Even if they were somehow relevant to the discussion, they’re another example along with video encoding where the data is suitable for paralellized execution.

Doth protest too much. You open by saying “Sure. Lets talk deadlocks, race conditions, and SIMD instructions. While we’re at it, we can debate the differences between CUDA and OpenCL.” and finish by implicitly saying you’re not actually going to discuss these things and that if I dare question your knowledge I should take it somewhere else.

202

Our comments are obviously orthogonal. On one hand, you state people have a hard time writing parallel code, then speak to the inherent parallelization that GPUs do.

Not sure what your point is, or what you’re debating to, but I make a pretty good living leveraging multiple core x86 procs AND leveraging GPU acceleration where necessary.

Both having nothing to do with a $400 game console. If you think consoles hold back Gaming progress, I’m sorry…the consoles that are coming out will be MUCH better than the ones they replace, and frankly won’t hold a candle to next year’s $1200 gaming rig.

$400 2013 console vs. $1200 2014 Gaming rig (or $1000, or $800, the point is the same). That’s a lesson in economics.

Restate you contention, I’ll speak to it. I’ll probably agree.

203

No, a ton of things in games are easily parallelizable. For instance, you could update pretty much every moving game object’s current position in parallel. It would be trickier, but you could probably resolve collisions in parallel. You can calculate damage taken in parallel and resolve players dying in parallel. Hell, on the AI side of things, enough cores, even slow ones with a small or nonexistent thread spawning overhead could effectively nullify the cost of a tree search (like A*). Sure, there are always interdependencies and order-dependent snags, but a good concurrent design can take care of most of that.

The problem is that

  1. The de-Facto languages (C++ mostly) does not support concurrency very well.
  2. The overhead of spawning new threads is bad, and often it’s better to multiplex a concurrent routine onto an existing thread rather than start a new one. However, the ability to make those decisions – and/or the tools that do it automatically aren’t really there (see #1)
  3. There simply aren’t enough cores to seriously consider parallelizing it.
  4. Oftentimes, the development time that would go into developing a correct, sane parallelizable concurrent structure isn’t worth it when you could be adding another feature.

You could write a very, very parallel game engine. The problem is that there aren’t any mature concurrent* languages, at least not any that can deal with the performance hacks developers do in C or C++. Someday Go might get there, but right now its compiler really doesn’t optimize well enough for a AAA game, and its library support as far as games are concerned is almost nonexistent.

It’s not necessarily that graphics is better parallelizable than the rest of a game engine, so much as graphics computations need to be parallelized to get any sort of decent performance.

  • Concurrency =/= parallelism, but concurrency is probably the sanest way to approach parallelism.
204

So at this point, you’re saying the ps3 and Xbox don’t use all three(?) cores they have? I know some housekeeping can occur (background downloading on the Xbox) at times, apparently when processing power is available.

I figured the programming environments would make it available, presumably so you can spin off things like a.i., multiplayer networking, viewport drawing, controller inputs, etc.

205

Are you talking to me or Beef?

Because as far as I know, most games at the very least have a logic thread and a render thread (which sets up and calls the GPU renderer). On top of that, a large amount have an audio-processing thread because audio can cause really weird sounds when data isn’t fed to the proper channels in time.

I understand a lot of them also spin off pathfinding threads – where the agent will move towards its destination using a steering behavior in the logic thread until the A* returns the high-level path it should take, and then it follows that path in the logic thread.

My point is that a lot more things could be parallelized if thread spawning was cheaper (and the logic of when to multiplex onto a current thread and when to spawn a new one was better), and they had inter-process communication tools better than mutexes and semaphores (a la Hoare’s Communicating Sequential Processes).

206

Yes. (However you are less antagonistic. I don’t mind having a conversation and even admitting I’m wrong, but to be dismissed out of hand is unnecessary)

So is the thread processing occurring within the application, or at the kernel/hardware level? It’s not like you can pull up a task manager/ps list while running Halo and see how things are spread about.

207

I’m not sure about consoles. I know on the PC that while threads are explicitly spawned at the application level (in C), the OS handles their scheduling and whatnot.

I understand that Go and Erlang (which are concurrency focused languages) get around this by writing a sort of lightweight “meta-scheduler” at the runtime environment level. Technically at the application level, but from a developer’s perspective it’s above the application they’re writing, but below the kernel itself. The meta scheduler grows the stack, calls functions, manages data and so-on within each thread, but schedules different concurrent routines, and ensures sub-routine and thread safety to the best degree it can. Spawning one of these routines also only takes about 4kb of memory; and is really cheap to manage and spawn (unlike threads).

Unfortunately, like I said, these languages aren’t quite mature. Go’s website flat out mentions that if you tell the language to manage multiple threads that the runtime environment and compiler simply aren’t smart about it, they’ll throw the sub-thread concurrent routines onto threads so that all existing threads have an equal number of routines. If you’re not sure your routines are very highly aided by parallelization the extra thread scheduling that occurs at the OS level may slow it down. In theory it doesn’t have to slow down, but the language tools to recognize whether you should use a new thread or an existing one just aren’t there yet.

This sort of thing takes time to mature though, and I’m not sure you could just throw money at it and discover the magical properties. I think you either need years of torture testing and/or a Carmack-level genius to figure it out. However, if you tuned the OS to this sort of thing, especially an OS for a console that’s presumably dedicated to only having at most 2-3 applications running at once, you could probably get absolutely magical results if you solved the concurrency problems I mentioned and implemented that lightweight scheduler at the OS level and then filled your console with medium-speed cores.

208

This is petty, I know, but I’m tired of “sharing” being pushed onto everything.

209

Agreed…I think they’re running out of things to differentiate themselves, the whole " take edit and share video" looks like a massive waste of resources to develop.

210

And yet, this hasn’t happened. Not in any field I’m aware of. Not in scientific applications, not in current consoles. Not unless the work is known to be highly amendable to being worked on in parallel.

Take modern PC parts that match current consoles in terms of performance on paper, and you’ll see no more than a 10-30% difference in performance. And that has more to do with latency issues between CPU and GPU and some of the overhead in the older API’s than with any sort of magic parallel processing involved.

Regardless, let’s say that future games can become more parallele in their execution - I’m not doubting that will happen. I’m only insisting that there is a limit to how beneficial that would be for a significant portion of work involved in running a game engine.

Well, I’m pretty sure a highly parallel game running on 8 1.6 Ghz, paired down CPU’s are going to run a heck of a lot better on a much more robust 8 core CPU running at 5 Ghz.

And we’re back at square 1.

211

I think the concentration on an application performing in parallel is overstated. Having multiple cores in a normal PC environment allows the system to do concurrent tasks.

And frankly, we don’t have any visibilty into how games run, it’s not like you can pop up a console and see…

I’m still surprised that people are spouting clock rates as the be-all-end-all metric. It hasn’t been about clock-rates for years. (Think Pentium 4 era). The WiiU is capabile of producing game content AT least on par with the existing stuff from Sony and Microsoft…it’s a 3 core 1.2 Ghz PowerPC. (the other two are 3 Ghz procs.)

The more important question is: Will there be a dip in gaming while folks come up to speed on a new architecture? It’s different from the PS3 (bad), but it’s otherwise a well known instruction set (good), but it looks like backward compatibility takes a shot to the head. (indifferent)

212

(missed the edit window)
Here’s another article on it: Why you can’t read too much into the Wii U’s “slow” clock speed | Ars Technica

Essentially, it’s more important what the game developers manage to DO with a gaming console, than what the numbers on the hardware say. To use a blunt analogy: A game using 100% of a WiiU’s capabilities will be better than a game using 1/3rd of an Xbox 720’s.

213

I didn’t say they were wrong. But it’s part of the script. At this point, nobody has any idea what next-gen games will really look like. At this point in the PS2’s announcement cycle, Sony was telling people that we should expect graphics on par with Toy Story 2. And at this point in the PS3’s announcement cycle, they were passing off heavy duty pre-rendered footage that must have cost them a fortune as actually gameplay.

214

I’ll say they were wrong. :stuck_out_tongue:

I’m not seeing the totally magical revolutionary games “everyone had always wanted to make” that I was promised in the 360/PS3 era. In fact, I see a lot of games that are graphically polished but streamlined versions of games from previous generations. Oh, and a bunch of dev shops that closed because at the end of the day, they couldn’t actually afford to make those games unless they sold more of them that ever before.

“Now we can make the games we’ve always wanted to make but couldn’t” is a bullshit marketing line that you roll out when you want to sell a new console. It has as much connection to reality as the average fanboy “my console is better because it’s numbers are bigger” battle, and I don’t buy it for an instant.

Also, while I still haven’t watched any of the actual footage from this event, I will eat my hat if the graphics actually impress me.

This system looks to me like Sony doing their same “throw a ton of random tech around and see if people want any of it” approach, which didn’t work real well with the Vita. Curious to see how this fares, since I don’t think anyone cares about Move in their controller or, really, about one-button video sharing.

215

by the way it looks like the PS4 will NOT block used games according to Kotaku.

216

Well, when what they can DO is limited by the numbers, again, I’m not sure what you are getting at.

If numbers don’t matter, then surely we could, now, with today’s advances in programming, go back to the PS2 and make Skyrim run on it, right?

Heck, instead of 8 cores runnign at 1.6 Ghz, why not 16 running at 800 Mhz, or imagine the amazing feats that developers could accomplish with 64 cores running at 200 Mhz each!

Someone should contact Sony and tell them they’re doing it wrong.

217

Start here: Why Clock Speed Doesn't Matter Much When Comparing Two Computer Processors | Lifehacker

218

This only makes sense when we don’t know what the architecture is like. We don’t have every detail about Jaguar, but we know it’s targeted toward mobile devices - low power consumption, low heat.

And again, I think we’re talking past each other. I’m not sure what it is that you’re trying to say.

Different architecture will perform differently at the same clock speeds? Yes, I think we all know this.

Are you trying to say that an architecture geared toward low power consumption at 1.6 Ghz will perform better than a high end desktop processor at 4.6+ Ghz? What is it that you are trying to say? 'cause you lost me somewhere, and I admit, that might be my fault. Maybe I’m missing, or not understanding something.

219

Small words:

Computational Power is only part of the equation.

Remeber that whole red-ring-of-death thing? Think that was kinda of an expensive lesson for them to learn?

Microsoft’s design criteria include parts cost and thermal design envelope.

Besides, how many times have you heard the recommendation to ‘upgrade your video card before you upgrade your cpu’?

Q: Will a lower speed, lower power cpu be worse? A:only if that’s the bottleneck.

In a $400* console, they’re going to have a component budget. If a $45 processor has enough starch and puts out less heat, they’ll probably pick that over a $150 desktop proc that needs a dedicated fan.

The developers will just have to learn to live within it. I’ll also bet, due to Moore’s Law, that it’ll be a significant percentage better than the current gen.

220

Ok, so we’re in agreement. You’re not saying that this thing is going to perform like a modern desktop CPU. All you’re saying is that it makes business sense to use a lower TDP part, even if it means lower performance.

And yes, it should be better than the aging CPU’s of the old consoles.

Did I disagree with you on this at some point? Why am I arguing?