On November 12, 2010 at 08:59, Kofi said...
I disagree. As the name implies, a single core processor is significantly more limited with regards to data processing than a multicore. This still applies to 'single threaded' software.
OK, let's start at the beginning :).
Multiple cores help you in two ways:
1. If your application is multi-threaded. For example, when we developed WMA audio codec at Microsoft, we designed it so that when encoding in stereo (e.g. CD ripping), each channel runs as a separate thread so two cores can be used to speed it up. If we had not done that, the second core would do you no good. As it is, going beyond 2 cores doesn't help you either as that is the limit of multi-threading in that codec.
The way that is done is that the application must be explicitly written to run in multiple threads. That is a difficult task as if you have to concurrent threads in a program, they can corrupt each other's data. And when that happens, finding out where and how it occurred can be quite challenging. For this reason, most of the applications you run are single threaded.
2. If you run multiple concurrent applications which are CPU bound. That way, the operating system schedules each task to run in a different core. If your application is I/O bound (e.g. mostly waits on hard disk) then this doesn't help you either. In the above CD ripping example, most systems today are I/O bound, waiting for the CD drive to feed it data so multi-threading is kind of wasted on fast CPUs.
We can dismiss #2 here as compiling a program is usually a sequential task. The source code is parsed, assembly/object code is generated and then everything is linked.
For #1, since neither one of us works for Crestron, we can't say how their application is written. However, we can monitor what it does as it is running. My laptop is a dual-core system. If the SIMPL Windows is threaded into two or more threads and it is CPU bound, it should be able to max out my entire CPU. But it doesn't. Here is what the CPU load looks like:
As you see the total CPU used is only 53%. That is the equiv of one core out of two being in use. Therefore, we know with high certainty then that Crestron compiler is not multi-threaded and adding cores to my system would do no good. But to prove the point further, let's now run the same load on my Core i7 Desktop with 8 cores (half virtual):
As expected, the load now drops to 1/8 of the maximum available (100/8 = 12). So we have pretty conclusive proof that Crestron tools are single-threaded and do not benefit in any way from additional cores.
Your best bet then is to get the fastest speed in one of those cores. In other words, if you have a choice of quad core 2 GHz CPU and a dual core 2.8 GHz, all else being equal, the latter will run this load faster.
A quad core processor and 8 gb of RAM make everything faster. Multithreading duties are often assigned by the OS (assumikng its 64 bit), so even if the compiler isn't multithreadng, your computer will have much more overhead available for all the other data.
None of that is really material here :). 32-bit or 64-bit has no relevance to number of cores. Rather, it impacts how much memory you can have in your computer which also doesn't matter here as the tools don't need 8 Gigabytes or anything close to it to run this load. You can see that from my desktop stats which had nothing but Crestron tools running and you see that it is only using 2 Gigabytes.
The other problem is availablility. New single core processors are designed for efficiency in mobile devices, not speed. I think you'd have to find an old Pentium 4 or Xenon for a 'fast' single core processor.
I did not advocate buying a single core CPU as those are ancient animals. Instead, as I explained, you need to focus on the speed of those cores, not how many there are. So pay attention to clock frequency of the CPU (including what it jumps to when under load). That is what is going to determine your speed in *this* application.
