THE most important thing is that you are happy
Of course, I get excited over a new can of air to clean my computers...
I did it!...I just configured and ordered a Athlon Dual Core from CyberPowerSystems
- Thread starter ElectricSavant
- Start date
THE most important thing is that you are happy
Of course, I get excited over a new can of air to clean my computers...
DeepMarket,
You raise a pointed question. Some 5+ years ago I once looked at asm code to accomplish this. With C and C++, I really am not sure myself about this.
The state of confusion by many about your question is best illustrated by the following search-selections of the C and C++ newsgroups. There is no doubt left that obtaining processor loading IS FAR FROM AN AUTOMATIC USER BLIND thing.
http://groups.google.com/group/comp.lang.c/search?q=threading+processor&start=0&
http://groups.google.com/group/comp.lang.c++/search?q=threading+processor&start=0&scoring=d&
If anybody has a precise reference or answer to this, I also would be interested.
I was just stating that in the threaded applications that I have written in Java and C++, I did not have to tell the OS which CPU to use. Be it a dual processor or a 64 processor machine - the OS always took care of it. Now, that was with Solaris, Dynix, Linux - I don't know how it is with Windows. I just assumed it was the same (bad assumption, I know).
Someone in this thread showed how to assign one processor, in an AMD dual-processor system, to just one program that you are running - so that different programs don't all load just one chip (Task Manager always maxes out at just 50%, with just one chip working at a time). Windows XP has a way to do this. But now I can't find this post!
Help?
Help?
I dunno, but I would suggest that there is little to be gained from doing such a thing. There has been 40 - 50 years of work that has been put into the design of operating system scheduling algorithms and probably 20 years or more for scheduling on multiple CPU machines. Statically assigning processes to a particular CPU is not likely to beat this. Best to leave it up to the operating system.
windows does handle multi core processor fairly well.
just like linux, unix, and mach (osx)
for the record, a dual core 2.0ghz does not mean it is twice as fast as a solo 2.0ghz.
dual core can perform better in multiprocess, multhreaded environment compare to a solo core. but it is upto the OS to manage the context switches, and also any of the traditional bottlenecks only got worse in the dual core environment. (mem, caches.... etc)
if you have a dual core running in windows, you are deriving its power every time you run any program. dont think of your program should be multithread in order to take advantage of have a "duo core". because there are countless processes in your OS are also running and utilizing either core at any given moment.
just like linux, unix, and mach (osx)
for the record, a dual core 2.0ghz does not mean it is twice as fast as a solo 2.0ghz.
dual core can perform better in multiprocess, multhreaded environment compare to a solo core. but it is upto the OS to manage the context switches, and also any of the traditional bottlenecks only got worse in the dual core environment. (mem, caches.... etc)
if you have a dual core running in windows, you are deriving its power every time you run any program. dont think of your program should be multithread in order to take advantage of have a "duo core". because there are countless processes in your OS are also running and utilizing either core at any given moment.
Quote from nononsense:
canyonman,
That's exactly what I observed too. Looking at multiprocessor configurations, it is very obvious that windoz XP doesn't take care of this. The programmer has to get involved here. Very little run of the mill software has been written in the past for true multiprocessor configurations.
If the latest Dual Core processors will change anything at this? I doubt it, the OS must still intervene unless a completely revamped OS version would be released. In spite of all the hype and hullabaloo surrounding Dual Core, this question is carefully sidestepped by the manufacturers.
Sorry, this is incorrect and out of date. You are referring to so called 'green threads' that some Java VMs used in Linux implementations a few years ago. As far as I know all current Java VMs use native (ie kernel) threads - certainly on Linux and Solaris. I cannot imagine that Sun would do it differently on Windows - it would be a huge competative disadvantage. Furthermore both Solaris and Linux now have have an N:N threading model - 1 user space thread == 1 kernel thread.
This makes Java very suitable for multithreaded high performance applications.
The only good answer to all this is benchmarking. I have not done this for the dualcore chips, but from intensive testing of dual processors under non-server loads, it's quite frustrating to see that total processor load almost never exceeds 50%. In my experience, the OS and driver processes you are alluding to indeed run on the other processor but constitute typically only a fraction of your application loads.
I simply never came across a competent explanation as to why a dual core should be better in all this. This is simply marketeering, now that chip manufacturers ran into the wall of physical limitations. They absolutely want the ignorant to think that indeed 1 + 1 = 2.