Dual Core CPU's

[VectraMan]

I have one at work. Works really well, though it's important to remember that often your hard disk ends up being the bottleneck so multiple CPUs doesn't help (in fact it can make things worse).

For some reason I had to turn it on in the BIOS (possibly the IT people switch it off on all new PCs so not to create more support issues), so you might want to check that. However, when I did switch it on XP gave the "detected new hardware" message, rebooted and all was well. So I don't think you need to reinstall with XP.

[VectraMan]

The point I was making is that unless the application is specifically designed to use 2 cpus windows will not be able to utilise both cpus (or cores in this case) for any application that you are running. So individual applications will not run faster, but you will be able to run more applications in tandem without experiancing slow downs. If you get a Linux distro with dual CPU support however it willl fully utilise both CPU's givine you double the performance.

So with Linux applications designed to run on one thread still use multiple CPUs?

[Cowboy Bob]

So with Linux applications designed to run on one thread still use multiple CPUs?

No, but multithreaded apps will automatically use multiple CPUs (which is most apps really - certainly anything with a GUI). On Windows it's my understanding that only apps built for multi-CPUs will do this - though Windows itself will schedule individual apps across the different CPUs.

[AtW]

Multi-threading support on Windows is a lot better than that on Linux - old model of Unix is to use multiple processes rather than threads: results are close when processes run long time so that overheads to spawn it are low.

I've got 5x dual core CPUs from AMD and will get more - though maybe Core 2 Due, but probably not since AMD dropped prices big time and SKA needs high level of memory bandwidth.

[DimPrawn]

No, but multithreaded apps will automatically use multiple CPUs (which is most apps really - certainly anything with a GUI). On Windows it's my understanding that only apps built for multi-CPUs will do this - though Windows itself will schedule individual apps across the different CPUs.

The problem with the Linux crowd is they believe the Linux bulltulip. Linux was much better than Windows NT, but that was 10 yrs ago.

Windows XP & 2003 supports multicore natively. Any modern Windows application (not games) will be multi-threaded and use the cores correctly giving a big boost in responsiveness and performance. Many of the Windows services running in the background are multithreaded. IIS and SQL Server are fully multi-threaded.

It all works beautifully.

[Addanc]

Multi-threading support on Windows is a lot better than that on Linux - old model of Unix is to use multiple processes rather than threads: results are close when processes run long time so that overheads to spawn it are low.

Linux has a good implementation of POSIX threads, I would respectfully suggest better than Windows (I've worked on both).

[AtW]

Threading on Linux only recently approached efficiency of Windows - POSIX or not, the native way for Unix is using multiple processes - lots of apps designed as single threaded in anticipation that they will be spawned many times.

At least when I write software for Windows NT 2000 threading I know that it will run on all versions of Windows now and later (counting from NT 2000) without making user bend over backwards to download and recompile different thread libraries with infinite number of dependencies, yuck, if Linux was not free then almost nobody would have used it.

[VectraMan]

Indeed. I think the impression a lot of people have of Windows is still based on the Win95/98/Me line for which Microsoft deserve everything they get, whereas the NT product line has always been vastly superior.

As for dual core, the issue is the majority of desktop apps are only single threaded so don't gain anything (although taking off the load of other services does help), probably because the history of windows development has been 99% for single processor machines.

Having said I have a dual core machine at work, I'm wondering if it's just hyperthreading. How do I tell the difference?

[DimPrawn]

Dual core Intel are known as Pentium D (800 series and 900 series).

Look at the sticker on the box. If it has a D on it, it's dual core.

Hyperthreading is basically a load of old crap that actually makes most applications slower.

[TheMonkey]

Ok misinformation cleared up. Firstly, I'm not a Linux or windows fan boy. I just use whatever works for the job.

1. Hyperthreading does benefit applications with lots of small threads, nothing else. All it does is allow the pipeline to execute other threads if it's busy waiting for something to finish. It just increases utilisation of the silicon at any point in time. It can yield a 5-10% increase in performance in some applications. The only things it slows down are poorly implemented.

2. Dual core doesn't give you 2x the performance as you need to consider total FSB of both CPUs to RAM, cache snoop coherency (which there is NONE on Intel dual cores!) and the fact that some sequential mathematical operations are not thread portable. Realistically a single task scales to between 1x and 1.8x the performance. It does however allow lots of small tasks run efficiently. Lots of large tasks are unaffected as they generally have to flush the cache in their entirety therefore switching context. This leads to the overheads increasing considerably negating the benefit of dual cores.

3. Linux threads were user space. They have only recently become kernel threads. User space threads are crap as the moment a process has to do IO, the overhead for determining what thread within the process was supposed to handle it is absolutely crazily immense. Linux was not designed for threads. Linux was designed to pipe information between distinct kernel processes or use IPC (pipes/semaphores) between processes, which is what it does well. This applies to POSIX threads. Windows actually had threading in mind from day one!

4. I am the god of threads. I'm building something very scarily large which uses distributed shared memory over 16 hosts and a wonderful 5000 concurrent threads at the moment with complete failover