Bulldozer fail prediction by AMD Staff

Discussion of all forms of processors, from AMD to Intel to VIA.

Moderators: Flying Fox, morphine

Re: Bulldozer fail prediction by AMD Staff

Postposted on Sun Jul 10, 2011 6:50 pm

Glorious wrote:
deadrats wrote:1) the common programming language C is about 40 years old (from circa 1970) and does not have native support for threads, you need to use a threading library like pthreads or the win api and neither of those is all that easy to work with. if programming languages allowed programmers to do something like:

thread1{
commands go here};
thread2{
commands go here};

you would see much more multi-threaded code, however you have a chicken and the egg scenario, programming languages haven't traditionally offered programming constructs like that because cpu's didn't have many cores and cpu's didn't have many cores because programming languages didn't allow for easy multi-threading.


1) The inelegant expression or obtuseness of the APIs is not the primary problem when it comes to threading. The difficulty of using threads is not the limiting factor, rather, it is the difficulty of using threads well. You are treating the entire concept of concurrent execution as little more than a programming language's high-level primitive, and that's ridiculous. Those are just tools. The relative ease of handling the tools has very little to do with the overall difficulty of the project you are attempting to finish with them.

2) The difficulty in using concurrent execution for single programs is coherent synchronization. Thread 1, thread 2, thread n are all trying to accomplish result 1. Your multiplicity of threads is working towards a unity of result, and this means that your program is going to have to resolve them together somehow at some point. This problem is not even remotely trivial. Race hazards suck and the methods needed to prevent them sap performance, increase development time, and require skill.

3) Your chicken & egg narrative is simply wrong. Hardware historically lacked SMP because it was prohibitively expensive. It wasn't until the gains from using transistors towards IPC began to level off that it made sense to start going after TPC. They reason you didn't see two original pentiums on the same die is because it was uneconomical to the point of being physically infeasible.

4) Your narrative about programming language is inaccurate. Procedural programming languages are inherently uncomfortable with threading because of their paradigm; they are step-by-step depictions of the execution environment and threading completely confounds that. It's easy for you to invoke "thread 1 do this" and "thread 2 do that", but that's clearly just a description of two different programs you've merely called threads. The question isn't what they are doing separately, but what they are separately doing together. Keeping that effort coherent means either leaving the procedural concept altogether or making it thread-safe, something you cannot invoke via a primitive. In reality, it usually takes an intensive amount of effort to make code thread-safe, and that's what most of those APIs you mention are about. Even then, they merely provide the tools to do it correctly, it's ultimately up to the programmer.

deadrats wrote:in fact if you ever go through a comp sci program, you won't take a class on multi-threaded programming until your third or fourth year, though that may be different in colleges like penn state that have switched to teaching all their comp sci classes in java as java has multi-threading built into the language.


Which is indicative of the fact that TLP isn't remotely simple. You have to be well-versed in all the basics before you can even begin.

As to using a new language like java, you're really asking a different question at that point.

deadrats wrote:you are however seeing the better programmers taking advantage of Open CL, Direct Computer and CUDA to leverage the multiple streaming cores within gpu's to allow for the calculation of physics and AI on the gpu (that's why many games only enable certain physics effects via PhsyX, because a gpu with it hundreds of cores is capable of handling all the collision calculations without choking while a cpu with just a handful of alu's would be brought to it's knees of it tried to perform hundreds of collision calculations per second.


Flappy flags and moar particle effects! Whooo! I'm glad I spent all that money on "better programmers." :roll:

Thank you for posting what I was just about to type out.
Z68XP-UD4 | 2700K @ 4.4 GHz | 16 GB | 770 | PCP&C Silencer 950 | XSPC RX360 | Heatkiller R3 | D5 + RP-452X2 | HAF 932 | 1 TB WD Black w/ SRT
Waco
Gerbil Elite
 
Posts: 746
Joined: Tue Jan 20, 2009 4:14 pm

Re: Bulldozer fail prediction by AMD Staff

Postposted on Mon Jul 11, 2011 7:50 am

There should be a sticky about this subject or something because people continually say incorrect and silly things about it.
Glorious
Darth Gerbil
Gold subscriber
 
 
Posts: 7844
Joined: Tue Aug 27, 2002 6:35 pm

Previous

Return to Processors

Who is online

Users browsing this forum: No registered users and 1 guest