Fudzilla: Bulldozer performance figures are in

[podspi]

Vesku, I agree with you. There is a huge difference between how responsive a machine is due to having lots of available threads vs. how quickly it finishes tasks. As enthusiasts, we focus on the latter, but when the average consumer talks about how fast a computer is, they almost always are referring to the former.


How fast a computer is to (for example) my parents, is not how quickly it finishes tasks but how responsive it is. This is why many people will claim an iPad is faster than their computers.

I don't want to discount ST performance, though. AMD really DOES need to step up on that account, as they've fallen behind by a lot at this point. But I feel this is something a lot of people miss looking at benchmarks.

 

[jvroig]

As long as you're not talking about spawning new threads just for the fun of it, that's never going to happen. Thinking it will just shows how little you know about game development.

That's also too general a statement, and "never" is such a strong word. Although the game loop is pretty serial in structure, the process part (in between checking for user action or exit, and rendering) can actually be >1 thread, and the effect here could be significant or insignificant, depending on the type of game. The real problem we have is that multi-threading, while powerful, is much much harder than good old serial, single-threaded programming, and so takes more effort, more man-hours, more cost (for the studio / publisher). We hate doing it. Heck, Carmack hates doing it, not sure if he has changed his mind already. And game studios don't have it at the top of their priority list.

So partly he (wuliheron) is correct, in that the way to make sure multi-cores don't get wasted is to make this convenient to programmers, in other words, "making it easy to program games to use an arbitrary number of cpu cores". We certainly can use all the help. It's no fun being stuck in a race condition and having to spend a week fixing it while having multiple constraints, and you remember your last game didn't care about multi-threading and all you needed to worry about was making it fun (I simplify, but you get the idea).

You are also partly correct, not because he (wuliheron) is mistaken in thinking it is technologically feasible, but because while technologically feasible, it carries too much other costs that it is not often seen as "worth it".

Of course, the real "win-win" scenario is for us to just have one very fast single-core cpu, instead of multiple cores as we do now, but seeing as to how that's impossible, eventually programmers of every sort - game programmers to business application developers - will need a change in paradigm (and a change in tools and languages to accompany) to take advantage of multicore systems if harnessing the power of these systems remains a goal instead of being stuck with just 1/4th or less of the total power of mainstream systems in the future (actual figure depends on what would be mainstream in that theoretical future, of course).

 

[jvroig]

How fast a computer is to (for example) my parents, is not how quickly it finishes tasks but how responsive it is. This is why many people will claim an iPad is faster than their computers.

Very true. We actually have usability and UI guidelines for that - even how a status/progress bar is implemented goes a long way to increasing the perceived responsiveness of the system/app to the user, even though the actual task it hides/represents does not actually get any faster or slower. This is more of a psychology and software thing, though, and not really related to Intel/AMD procs.

I don't want to discount ST performance, though. AMD really DOES need to step up on that account, as they've fallen behind by a lot at this point. But I feel this is something a lot of people miss looking at benchmarks.

Well, they promised IPC will increase and have stood by it several times, so I assume they will deliver on better ST performance, although whether this "better" performance will be satisfactory or not is a different matter and will be resolved by reviews and reactions to those reviews. But your point is well-taken - benchmarking numbers don't tell the complete story, because it does not communicate responsiveness (or at least, user-noticeable responsiveness) very well. But seeing as to how such a thing is very subjective and qualitative, it is hard to incorporate into reviews, so we have what we have now.

 

[lol123]

That's also too general a statement, and "never" is such a strong word. Although the game loop is pretty serial in structure, the process part (in between checking for user action or exit, and rendering) can actually be >1 thread, and the effect here could be significant or insignificant, depending on the type of game. The real problem we have is that multi-threading, while powerful, is much much harder than good old serial, single-threaded programming, and so takes more effort, more man-hours, more cost (for the studio / publisher). We hate doing it. Heck, Carmack hates doing it, not sure if he has changed his mind already. And game studios don't have it at the top of their priority list.

I agree that "never" is a strong word, especially in this business, but games are a primarily single-threaded application and no compiler trick in the world or even "reverse hyper-threading" is going to change that. The rasterization along with the AI and physics threads and whatever else you want to add to games can never go faster than the main thread, for the simple reason that they wouldn't know what to animate and render.

 

[cantholdanymore]

Of course, the real "win-win" scenario is for us to just have one very fast single-core cpu, instead of multiple cores as we do now, but seeing as to how that's impossible, eventually programmers of every sort - game programmers to business application developers - will need a change in paradigm (and a change in tools and languages to accompany) to take advantage of multicore systems if harnessing the power of these systems remains a goal instead of being stuck with just 1/4th or less of the total power of mainstream systems in the future (actual figure depends on what would be mainstream in that theoretical future, of course).

Were where you 976 posts ago?:thumbsup:

 

[sm625]

The main thread of a game should do nothing except manage the other threads.

ps I keep checking this thread in the vain hopes that there will actually be some new information on bulldozer. Not a damn thing aside from obrovsky.

 

[Cogman]

The main thread of a game should do nothing except manage the other threads.

ps I keep checking this thread in the vain hopes that there will actually be some new information on bulldozer. Not a damn thing aside from obrovsky.

It doesn't work like that.

First, you have to ask the question "what do you mean by main thread?". Do you mean the first thread started by the OS? If that is the case, then it is impossible for that thread to just manage threads (Windows has restrictions on which thread can modify the DC. The thread that creates a window is the only thread that can change what is on the window.)

So if that isn't what you mean, then the question becomes "what does it mean to manage the threads". Do you mean, "Assign out tasks to each thread"? If that is the case, then you don't need a specific main thread for that, you can use a thread pool and make the worker threads manage themselves. That takes on an interesting model where each thread generates tasks and completes tasks currently listed in the thread. It is fairly simple to implement a thread pool, it is hard to do it correctly. If your tasks are too small, then you waste a LOT of time just going out and getting the next task (haven't a "manager" thread doesn't help this situation either). If your tasks become too large then you start to loose the benefit of multithreading.

Not only that, but just making the structure doesn't make it easy to split things up. Some tasks (like sound processing) have to be done in a timely and orderly fashion, you can't just throw it onto a queue and hope that it gets done on time to sound right. Sometimes it is more important to do something in even times distributions than it is to do something as fast as possible.

To the layman, it may sound easy "Oh, just manage things!" but that isn't the issue at hand. The issue is "How do we split things and share data in a way that is both quick and doesn't take 100 years to implement". This is one of the biggest problems of concurrency. Data sharing in particular leads to a whole mess of problems that have been studied for years.

 

[jvroig]

I agree that "never" is a strong word, especially in this business, but games are a primarily single-threaded application and no compiler trick in the world or even "reverse hyper-threading" is going to change that. The rasterization along with the AI and physics threads and whatever else you want to add to games can never go faster than the main thread, for the simple reason that they wouldn't know what to animate and render.

It is the concept of the "main thread" that is in question, not "AI or physics" or any other "add-ons".

Breaking apart the main thread (or, as in sm625's words, "main thread of a game should do nothing except manage the other threads") is what allows multi-threading to be worth it or not; how effective the break-up (or delegation, if a different POV is used) is determines how effective the scaling is, and that's the main problem - the performance will still be bound by the single "heaviest" (slowest) thread, but that does not mean the multi-threading was for nought - had the delegation not happen, this heaviest thread could have been much much heavier/slower. This is technically feasible, but as I've already noted, takes too much man-hours than the benefit it may deliver, so it isn't so high on the priority list unless the game in question actually needs the performance, in the same way that business apps that don't need the performance do not bother with multi-threading. It's not about technical feasibility - it's about project feasibility. If AAA games had twice the budget and timeline (and the precondition of "needing the performance" is there), multi-core scaling would be better. If we had been dealing wth this problem longer (>10 years), we would also have better programming techniques and tools suited for it, instead of forcing a new paradigm on old structures and tools.

If you are a fellow developer, then I don't wish to argue with your own analysis of the situation. If your experience has taught you that it is impossible and will never happen, then so be it. This is just the internet after all. I believe in the multi-cored future for software, even games. You don't. You have your reasons. I have mine. It's cool.

ps I keep checking this thread in the vain hopes that there will actually be some new information on bulldozer. Not a damn thing aside from obrovsky.

I doubt anything new will actually ever arrive until launch. Maybe a bone thrown at us in the week before that, but nothing we would really like (benches).

 

[wuliheron]

The real problem we have is that multi-threading, while powerful, is much much harder than good old serial, single-threaded programming, and so takes more effort, more man-hours, more cost (for the studio / publisher)...

So partly he (wuliheron) is correct, in that the way to make sure multi-cores don't get wasted is to make this convenient to programmers, in other words, "making it easy to program games to use an arbitrary number of cpu cores"...

You are also partly correct, not because he (wuliheron) is mistaken in thinking it is technologically feasible, but because while technologically feasible, it carries too much other costs that it is not often seen as "worth it".

Your logic is backwards. Multithreading isn't rare because it is a pain to do and expensive, it is expensive and a pain to do because until recently it was rare. Its a relatively new technology and it has taken the industry years to even begin to figure out how to make it significantly cheaper and easier.

Likewise, it has been done in games despite it being a pain and expensive because games just happen to benefit more from the technology and rake in the big bucks. Last year video games made more money then all the Hollywood movies combined. That's a lot of incentive to do exactly what Hollywood has done and invest heavily in making the technology cheaper and easier. Not just the game developers, but Intel, Microsoft, AMD, Nvidia, ARM, and just about everyone is now heavily invested in making the technology cheaper and easier to use ASAP.

 

[Cogman]

It is the concept of the "main thread" that is in question, not "AI or physics" or any other "add-ons".

Breaking apart the main thread (or, as in sm625's words, "main thread of a game should do nothing except manage the other threads") is what allows multi-threading to be worth it or not; how effective the break-up (or delegation, if a different POV is used) is determines how effective the scaling is, and that's the main problem - the performance will still be bound by the single "heaviest" (slowest) thread, but that does not mean the multi-threading was for nought - had the delegation not happen, this heaviest thread could have been much much heavier/slower. This is technically feasible, but as I've already noted, takes too much man-hours than the benefit it may deliver, so it isn't so high on the priority list unless the game in question actually needs the performance, in the same way that business apps that don't need the performance do not bother with multi-threading. It's not about technical feasibility - it's about project feasibility. If AAA games had twice the budget and timeline (and the precondition of "needing the performance" is there), multi-core scaling would be better. If we had been dealing wth this problem longer (>10 years), we would also have better programming techniques and tools suited for it, instead of forcing a new paradigm on old structures and tools.

If you are a fellow developer, then I don't wish to argue with your own analysis of the situation. If your experience has taught you that it is impossible and will never happen, then so be it. This is just the internet after all. I believe in the multi-cored future for software, even games. You don't. You have your reasons. I have mine. It's cool.


I doubt anything new will actually ever arrive until launch. Maybe a bone thrown at us in the week before that, but nothing we would really like (benches).

The problem is that it is VERY easy to take something, thread it, and end up with a result that is MUCH slower than its single threaded counterpart. So sometimes, the delegation really is purely for naught.

For example, the very act of acquiring a lock on data takes a decent amount of computational time (at least 1000 cycles). And that is when the lock is not in contention. What happens when the lock is in contention? Well, you end up having to rely on the OS to get back to the threads at let them know when they can access the data. Most of the popular threading paradigms simply have the thread wait for the lock to free up before continuing. That is a lot of lost computational power if the lock happens to be held for a long time.

It is VERY easy to forget about the slowness of locks. In fact, one of the dangers IMO of making threading slow is the abstraction of lock acquisition. All the sudden, you have no concept of when one data access will be quick and another slow. It makes it even harder to judge if the code your are going to put in will be faster or slower than its single threaded counterpart.

That is a big issue. That, and the fact that you pretty much have to commit from the get go to use multithreading, you can't just throw it in as an after thought.

 

[jvroig]

To the layman, it may sound easy "Oh, just manage things!" but that isn't the issue at hand. The issue is "How do we split things and share data in a way that is both quick and doesn't take 100 years to implement". This is one of the biggest problems of concurrency. Data sharing in particular leads to a whole mess of problems that have been studied for years.

Yes, and that's the core of it. It is not impossible. It is not even far-fetched. It is just much harder (hence, my point about "more effort, man-hours, and cost") that it is not automatically at the top of the priority list (or even in the list at all) unless the performance is needed, because the ROI for this endeavor isn't exactly obvious (or perhaps does not even exist for some projects).

Your logic is backwards. Multithreading isn't rare because it is a pain to do and expensive, it is expensive and a pain to do because until recently it was rare.

That's not what I said. All I said was that it carries too much cost, and it does, simply because it is harder: more effort, more man-hours, more cost. I don't see how you could have interpreted it as such.

Its a relatively new technology and it has taken the industry years to even begin to figure out how to make it significantly cheaper and easier.

Yes, in fact I did mention that also - in the future, if it remains a goal (and it will), better tools and paradigms will be developed for this to make it easier for programmers, because that's the direction we are all heading - Intel and AMD made sure of that.

I don't see what you are arguing with me about, seeing as to how we pretty much share the same opinion here.

 

[wuliheron]

To the layman, it may sound easy "Oh, just manage things!" but that isn't the issue at hand. The issue is "How do we split things and share data in a way that is both quick and doesn't take 100 years to implement". This is one of the biggest problems of concurrency. Data sharing in particular leads to a whole mess of problems that have been studied for years.

I certainly have no illusions about how easy it is. It involves cutting edge mathematics related to theoretical physics among other things. However, the money involved is nothing to sneeze about either and there simply is no alternative for the foreseeable future.

 

[Cogman]

Your logic is backwards. Multithreading isn't rare because it is a pain to do and expensive, it is expensive and a pain to do because until recently it was rare. Its a relatively new technology and it has taken the industry years to even begin to figure out how to make it significantly cheaper and easier.

Likewise, it has been done in games despite it being a pain and expensive because games just happen to benefit more from the technology and rake in the big bucks. Last year video games made more money then all the Hollywood movies combined. That's a lot of incentive to do exactly what Hollywood has done and invest heavily in making the technology cheaper and easier. Not just the game developers, but Intel, Microsoft, AMD, Nvidia, ARM, and just about everyone is now heavily invested in making the technology cheaper and easier to use ASAP.

You still on this kick? Multithreading about as old as computer science itself. It was extensively studied in the early 60's and has been used as long as there have been servers. Multithreading is only new in personal computer consumer level applications (which, btw, is really a small market compared to business and server applications).

As for the investing in multithreaded tech. All those companies you listed HAVE been investing HEAVILY into trying to make multithreading easier to do. http://en.wikipedia.org/wiki/OpenMP <- This, for example, has been around since 1997 and pretty much every company you listed has tried to make it successful (intel especially).

 

[sm625]

Not only that, but just making the structure doesn't make it easy to split things up. Some tasks (like sound processing) have to be done in a timely and orderly fashion, you can't just throw it onto a queue and hope that it gets done on time to sound right.

But that is basically how sound gets processed. It is all interrupt driven precisely so you dont have to manage the audio buffers. You have to have a general idea of how much buffer you have to work with, but it is a pretty wide window. I think sound is managed very efficiently in most programs. And I think that's because programmers have years/decades of experience in encapsulating audio processing.

 

[Cogman]

I certainly have no illusions about how easy it is. It involves cutting edge mathematics related to theoretical physics among other things. However, the money involved is nothing to sneeze about either and there simply is no alternative for the foreseeable future.

This has nothing to do with cutting edge mathmatics or theoretical physics. This isn't quantum mechanics we are dealing with. At best, it has more to do with statistics than anything else.

 

[Cogman]

But that is basically how sound gets processed. It is all interrupt driven precisely so you dont have to manage the audio buffers. You have to have a general idea of how much buffer you have to work with, but it is a pretty wide window. I think sound is managed very efficiently in most programs. And I think that's because programmers have years/decades of experience in encapsulating audio processing.

Sound is pretty much played the moment it is ready to play when doing games. You can't have a gunshot that sounds 100ms after the gun is fired. If you are dealing with something like a thread pool, then the sound ends up queued right after the gunshot occurs, there is no telling how long it will take for the sound to actually get to the point where it can start buffering to play (it could be seconds before the sound is played).

I was using that more as an example rather than the end all be all. By far, it is easier and cheaper to just spawn a new sound thread and give it sound information as it comes it, letting the sound thread handle playing stuff in an orderly fashion. But then you aren't really managing the sound thread, you are just throwing information at it.

 

[wuliheron]

I don't see what you are arguing with me about, seeing as to how we pretty much share the same opinion here.

You did make it sound as if the industry had a choice in the matter. To some extent they've dragged their feet and placed it low on their priority list waiting for the technology to mature, but its do or die time now. Architecture is still king and multicore rendering has now gone to the top of the list of a lot of people's priorities.

 

[wuliheron]

This has nothing to do with cutting edge mathmatics or theoretical physics. This isn't quantum mechanics we are dealing with. At best, it has more to do with statistics than anything else.

Quantum Mechanics IS a statistical theory. Trust me, this one is as deep as the rabbit hole currently goes when it comes to mathematics and logistics. Some of the research involved is even classified by the government.

 

[jvroig]

The problem is that it is VERY easy to take something, thread it, and end up with a result that is MUCH slower than its single threaded counterpart. So sometimes, the delegation really is purely for naught.

For example, the very act of acquiring a lock on data takes a decent amount of computational time (at least 1000 cycles). And that is when the lock is not in contention. What happens when the lock is in contention? Well, you end up having to rely on the OS to get back to the threads at let them know when they can access the data. Most of the popular threading paradigms simply have the thread wait for the lock to free up before continuing. That is a lot of lost computational power if the lock happens to be held for a long time.

It is VERY easy to forget about the slowness of locks. In fact, one of the dangers IMO of making threading slow is the abstraction of lock acquisition. All the sudden, you have no concept of when one data access will be quick and another slow. It makes it even harder to judge if the code your are going to put in will be faster or slower than its single threaded counterpart.

That is a big issue. That, and the fact that you pretty much have to commit from the get go to use multithreading, you can't just throw it in as an after thought.

Absolutely. It comes down to difficulty, not technical infeasibility. It's a problem we are all solving, and we will need to learn and apply new skills and paradigms, have tools better-suited for the problem domain, and have software in the chain recognize this. It's hard, and it is not surprising most of us would rather not have to deal with it unless absolutely necessary. It's a pain.

Once again, it is a project feasibility problem. If the project could afford it (timeline, budget, manpower), it would be done in a regular fashion. But we still have games like SC2 (dual-core only, right? Haven't really played it, just heard about it), because this just isn't a priority all the time, not because it's impossible. In other words, it's more of a project management call - there are other priorities in the development that contribute more to the bottomline than ensuring it plays well with 4 cores or more. As you acknowledged, and I have said repeatedly, it is a difficult and serious task, meaning more effort, man-hours, and cost, and if the costs associated with it are not recognized to be worth it (by management) due to not contributing to the enjoyment of the product and sales, then forget about it, it is not in the spec, whether or not the dev team could actually have pulled it off (they most certainly can, but maybe not in time, and not within the ideal budget).

I don't enjoy having to think of breaking up serial tasks into meaningful parallel tasks. I also don't relish having to debug parallelized programs. It takes 10x longer, sometimes I do not even think I am smart enough to do it perfectly. But as long as Intel and AMD continues on this road (and they will), what choice do we devs have? Complain? Reminisce about how all our programs used to run in only single-core machines and everything was peachy and we didn't leave performance on the table unused? All we can do is adapt, develop the skills for this, and improve the tools we have. As far as I am concerned, this is the end of the story, unless AMD and Intel change their current tune.

 

[lol123]

It is the concept of the "main thread" that is in question, not "AI or physics" or any other "add-ons".

Breaking apart the main thread (or, as in sm625's words, "main thread of a game should do nothing except manage the other threads") is what allows multi-threading to be worth it or not; how effective the break-up (or delegation, if a different POV is used) is determines how effective the scaling is, and that's the main problem - the performance will still be bound by the single "heaviest" (slowest) thread, but that does not mean the multi-threading was for nought - had the delegation not happen, this heaviest thread could have been much much heavier/slower. This is technically feasible, but as I've already noted, takes too much man-hours than the benefit it may deliver, so it isn't so high on the priority list unless the game in question actually needs the performance, in the same way that business apps that don't need the performance do not bother with multi-threading. It's not about technical feasibility - it's about project feasibility. If AAA games had twice the budget and timeline (and the precondition of "needing the performance" is there), multi-core scaling would be better. If we had been dealing wth this problem longer (>10 years), we would also have better programming techniques and tools suited for it, instead of forcing a new paradigm on old structures and tools.

If you are a fellow developer, then I don't wish to argue with your own analysis of the situation. If your experience has taught you that it is impossible and will never happen, then so be it. This is just the internet after all. I believe in the multi-cored future for software, even games. You don't. You have your reasons. I have mine. It's cool.


I doubt anything new will actually ever arrive until launch. Maybe a bone thrown at us in the week before that, but nothing we would really like (benches).

You are right that the main thread can be broken up into smaller parts (although as Cogman points out there are clear limitations to that) but even then we are still at a point, and probably will continue to be as games become even more demanding, where the single heaviest thread maxes out a single core. That means with half the clock frequency and twice as many cores, you will still get half the performance.

 

[jvroig]

You are right that the main thread can be broken up into smaller parts (although as Cogman points out there are clear limitations to that) but even then we are still at a point, and probably will continue to be as games become even more demanding, where the single heaviest thread maxes out a single core. That means with half the clock frequency and twice as many cores, you will still get half the performance.

Yes. I also did point it out myself that there will always be a single "heaviest" thread. And yes, with half the clock frequency and twice as many cores, we will still get half the theoretical performance due to that (but we already have, hopefully, improved performance compared to a completely single-threaded approach). But as I've also said in a more recent post, what do we do? Intel and AMD dictated this heading for all of us. With better "Turbo", we can have a hardware-approach to this, but as far as we devs are concerned, thanks to AMD/Intel, all we can do is refine our multi-threading kung-fu to take advantage of the performance offered by modern processors.

 

[Cogman]

Quantum Mechanics IS a statistical theory. Trust me, this one is as deep as the rabbit hole currently goes when it comes to mathematics and logistics. Some of the research involved is even classified by the government.

Quantum Mechanics RELIES heavily on statistics, but so does supply chain management. Would you suggest that supply chain management is a form of Quantum Mechanics?

Hell, gambling relies heavily on statistics. Would you claim that gambling is a form of Quantum Mechanics?

Threading only briefly brushes with statistics (at best) and it certainly isn't something at the forefront of the problem.

 

[Cogman]

You are right that the main thread can be broken up into smaller parts (although as Cogman points out there are clear limitations to that) but even then we are still at a point, and probably will continue to be as games become even more demanding, where the single heaviest thread maxes out a single core. That means with half the clock frequency and twice as many cores, you will still get half the performance.

That really has more to do with the way games are programmed. Games are setup to try their hardest NOT to yield the CPU. This is because recovering from an OS yield can take a significant amount of time (in WinXP it was about 15ms). You gain nothing by yielding (other then preventing laptop users from lighting their pants on fire).

Games like starcraft 1, for example, will consume 100% of one core if you let it. Yet, it certainly doesn't need that much processing power (hence, later patches gave the option to yield the CPU when not in use.)

 

[Red Storm]

I'm really not a fan of the vicious stabs at Intel in this thread. Do you guys not realize that the i5 760 is better than the Phenom II X6s at about the same platform cost? The i5 came out long before the X6 CPUs as well. The i5 2500K completely wrecks the X6. I'd say a 4-core wrecking a 6-core in multithreaded performance is pretty damn innovative. If anyone is slow to innovate it's AMD, who has been playing catch up for the last 4-5 years. Yes, they make more obvious jumps in performance between processors, and yes Intel makes lesser jumps. I believe that is only to keep AMD in the race though. If Intel were to make a large jump ahead of AMD like AMD does to catch up to Intel, Intel would crush AMD. AMD would then go under, and Intel wouldn't have anyone to compete with.

Bill Gates and Microsoft did the same thing with Apple in sort of a different way. When Macintosh was going under in 1997, Microsoft purchased $150 Billion in non-voting Apple stock. Keeping competition in the race (IMO) is the best business practice one can adhere to.

That's why I specifically said "anyone rooting for AMD to fail". I didn't say "anyone who likes and/or prefers Intel". People are free to pick their favorite companies. I'm only referring to individuals who want competing companies to fail, all that does is hurt us consumers by lowering the amount of competition, which leads to increased prices, and slower innovation.

 

[Nemesis 1]

lol... yes, because Intel breaks the law just like the mafia. They rob banks, kill, and cheat all the time. Those in the position of power are only in that position due to their own competency. You are quite ignorant, sir.

Look at your quote posted above This post . I just don't know. But you do understand the differance between 150 billion dollars and 150 million do you not? If you do not the differance is 1000x looking at your post . You need a reality check