Posted on 12/26/2007 6:48:37 PM PST by Ernest_at_the_Beach
News Source: EEtimes.com
and a new category of microprocessor that combines a general purpose CPU with an accelerator designed for specific market segments.
*drools idly*
2. Will quad core or Octal core make any difference if we are using a 32 bit operating system? In other words, will I/we need to upgrade to Vista x 64 at some point?
3. Intuitively, it seem like the complexity of writing code for multiple core chips would increase geometrically, since you have to have all the cores processing simultaneously. Is this true?
Thank you.
JAVA seems to be a new programming language that has capability to reduce the complexity of writing multiprocessing
code.
Multiprocessing code can be 32 bit.
Yes, and not just the professional ones. My little $25 video converter uses as many cores as you can throw at it (and it'll use the cores of any Mac in your home over the network). Plus running multiple programs lets the OS juggle applications between cores. And on Windows there's all the anti-virus, anti-spyware, DRM system, etc., that can use the extra cores so they don't interfere so much with the application you're using.
But you do have to worry about your OS if you're using Windows. While any version of Vista will recognize all the cores on one processor, only the higher-end versions will recognize multiple processors, the rest are artificially limited.
2. Will quad core or Octal core make any difference if we are using a 32 bit operating system? In other words, will I/we need to upgrade to Vista x 64 at some point?
Yes. You still get access to all the cores.
3. Intuitively, it seem like the complexity of writing code for multiple core chips would increase geometrically
Some might say logarithmically. It is harder, and debugging can be orders of magnitude harder since errors can be very sporadic with little evidence of what's causing them.
Most Windows programmers have been used to limited multithreading (the main mechanism for multi-processor programming) for years, as that's the only way to keep the user interface responsive. Lack of this is often why you see "Application Not Responding," the app is busy working and not using another thread to respond to user interface requests. But this is different from taking one big job and distributing it among multiple threads, or even harder, multiple different jobs that interact with each other.
But languages are starting to make it easier to program for multiple threads. There are libraries out there that can help programmers manage their threads. There are compilers that will both/either optimize your program for multiple cores and catch potential errors before they occur. The Microsoft .NET runtime automatically manages a pool of threads for you (evens the load, reduces overhead of creating threads, prevents you from creating too many that may bog down the system). And then there's Apple's OS X, where a call to various functions even in a single-threaded application automatically multithreads.
Of course, writing and optimizing a multi-threaded application is not trivial, as in some cases, resource contentions can cause unintended performance degradation.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.