   Programming for multi processors chipset computers
  With the new dual processors computers, does a programmer needs to take into account multiply processors?Does a programmer should use more threads in his programmer, so it will run faster on the multi processors computers?Or should he programmer exactly the same he would program to a single processor computer?What do you think?Thanks in advance.   
  just check out intel's compiler and vtune since the latest versions will automatically compile your code to take advantage of multiple core cpu's,etc.;  Sorry but to really take advantage of multicore or multicpu systems you must write code that can run in multiple threads and run effectively. Programming for multiprocessor systems isn't easy ... there isn't a magic silver bullet that will get you there either im afraid.Multithreaded games are even harder! I just hope there will be a nice quick fix maybe in the form of a new parallel processor friendly language, it would make my job easier :)   ;  So the question is, do you need to make an extra effort to write a program optimzed for multicput computers? or would the compiler's optimizations take car of it?I think it should be more sensible that the compiler will take care of most of the optimizations, because a user programmer never knows how exactly the chipset works. The people who write the compilers know better how the chipset works and therefore can do better optimizations.;Quote:Original post by daviangeljust check out intel's compiler and vtune since the latest versions will automatically compile your code to take advantage of multiple core cpu's,etc.intelcompiler is expensive :(, only the 32bit linux-ver for noncommerce is free ...i know that he makes for statements (with no changing condition) parallel...what does he optimze else?;  Well for now we have to manually write threading in say C++ but things will change because it is currently very hard. Herb Sutter is working in conjunction with Bjarne Stroustrup to change the ISO standard to accomodate easier thread coding. I saw a presentation on it recently and it looks really promising. The problem today llies in the fact that serial programms, single CPU, are running as fast now as they will ever do simply because the GHz is not increasing. So now we have to accomodate for multiple cores.Dave   ;Quote:Original post by The C modest godSo the question is, do you need to make an extra effort to write a program optimzed for multicput computers? or would the compiler's optimizations take car of it?I think it should be more sensible that the compiler will take care of most of the optimizations, because a user programmer never knows how exactly the chipset works. The people who write the compilers know better how the chipset works and therefore can do better optimizations.Well the problem isn't really that simple. Transforming sequential programs and algorithms to work well in parallel simply isn't a transformation that compilers are very good at, mostly because the algorithms aren't designed for concurrency to begin with. Compilers are decent at vectorization but that's really a far cry from actually being able to turn stuff into inherently concurrent computation. Writing fast (without needless synchronization) reliable (without deadlocks and reace condidtions) concurrent code is very hard because you need to think about it in a completly diffrent way, a way that most programming languages simply aren't designed around so they lack facilities for it forcing programmers to manage it by themself. Btw, doing concurrent work as daunting at it may seem is almost as fun as fiddling with asm :D;  Well, the free lunch is over.Autovectorization can only help a little. Languages with concurrent semantics (like Erlang) a bit more, but the only thing that can give you really good performance is a programmer that lives concurrent programming.   ;  From what I understood, the multiply cpus will each have a different purpose.For instance, maybe one cpu will be an fpu, the other for the more casual int calculations and the third for, maybe matrix calculations.So if you have an algorithem that is all done with integer calculations, seperating into threads will not be more beneficial.It will be only beneficial to seperate things that are different in their nature in the first place.I think.   ;Quote:Original post by The C modest godFrom what I understood, the multiply cpus will each have a different purpose.For instance, maybe one cpu will be an fpu, the other for the more casual int calculations and the third for, maybe matrix calculations.So if you have an algorithem that is all done with integer calculations, seperating into threads will not be more beneficial.It will be only beneficial to seperate things that are different in their nature in the first place.I think.I find that unlikely. What happens when we have 30 cores?It's all about the coder spread the load accross the CPUs. More if the multi-cpu efficiency comes from the coder than the coder than the compiler. Dave   