Which CPUs do you love or hate

[Karlos]

No votes for the 6502 or Z80?

You guys suck.


Seriously though, if you profess to love or hate a CPU you are either slightly weird or you are a coder. Assuming you are the latter and of the age range of original Amiga users, you probably cut your teeth on a 6502 or Z80 and moved up to the 68000 with the Amiga.

[Karlos]

Love: 68000 - the first CPU I learned to program... I still have the 68k architecture in the back of my mind when ever I program anything...

Love: The first Athlon64 - the x86 done right, probably done more for the modern computer industry than any other.

Hate: PPC 603 - cost me a lot of money and offered very little.

Hate: Pentium4 - total dead end...

To be fair, it wasn't the 603 that let you down, it was the hardware it was plugged into and  the whole context switch thing. No L2 cache, slow memory bus. Any code you wrote that would fit into the 603's instruction cache and didn't need to spill registers onto the stack could run a lot faster than the 68K CPU on the same card.

Writing efficient code for WarpOS (and presumably PowerUP) is an interesting challenge.

[Karlos]

The 68010 was an important processor. It was never intended to be faster than the 68000, it was intended to better support P&G virtualisation. To that effect, it was the first 680x0 to properly segregate supervisor and user modes and be able to recover from various bus errors.

You can't knock it for not improving the experience on a machine where none of these features really mattered.

[Karlos]

This Q9450 isn't bad, I suppose.

From a number crunching perspective, I'm more into GPU's at the moment.

[Karlos]

I can't believe people are complaining about multicore CPU's. I find my quad core indispensible, especially when transcoding my media collection. Really, why convert one stream at a time, when you can do three concurrently and still have ample horsepower left to do all your normal stuff?

[Karlos]

@ Karlos: you won't find much logic when Amigans start bashing "competing" platforms

I'll let top answer that:

Code: [Select]

Tasks: 155 total,   4 running, 151 sleeping,   0 stopped,   0 zombie
Cpu(s): 72.2%us,  0.4%sy,  0.0%ni, 16.9%id, 10.3%wa,  0.1%hi,  0.1%si,  0.0%st
Mem:   4053804k total,  4026464k used,    27340k free,     8892k buffers
Swap: 20000884k total,    18008k used, 19982876k free,  3396568k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                        
 8631 karlos    20   0  175m  32m 5096 R  100  0.8  13:58.72 mencoder                                                                                                                                                                      
 8652 karlos    20   0  170m  27m 4652 R   97  0.7   6:05.80 mencoder                                                                                                                                                                      
 8642 karlos    20   0  170m  27m 4652 R   96  0.7   7:52.02 mencoder

(...snip...)


[Karlos]

I take it that top reports every thread as a separate CPU? an octocore, nice

If graphs are more your thing, the standard gnome system monitor shows a separate trace for each core (as does windows task manager). Or if you prefer the console but top is too spartan, htop shows a bar for each core and one for memory usage.

[Karlos]

don't like : Dual/Quad core : they show the lack of progress in CPU technology

If you think they are less evolved than single core CPU's running at higher clock rates then you must have a pretty one dimensional view of processor development. Just recall the P4; an exercise in marketing the "MHz myth". One core on my Q9450 at 2.66 GHz does more work per MHz than the 3.2GHz P4 at work. And there's four of them.

It astounds me that amiga enthusiasts, who, let's face it evangelised pre-emptive multitasking as the holy grail of OS design fail to appreciate how multicore CPU's are the hardware equivalent. Four cores means that 4 threads can each run at any instant, unlike a single core CPU wherein (even given HT) only one process is running at any given moment.

You don't even need specially written massively threaded software to appreciate multiple core, just run a few big CPU hogging apps concurrently and you see the benefit immediately.

[Karlos]

which is fine with me, I'm having fun with my mobile device...

Is the sock feeling jealous yet?

[Karlos]

What are the advantages of a single core? Other than power consumption and price. When we have multi cores with totally independent cores, which can be completely turned off and on as needed (is it already possible?) the power consumption also won't be an issue.

On my Q9450, the clock speed of each core can independently switch between 2GHz or 2.66GHz as needed. That might not sound much but as the current draw is proportional to both the voltage (which increases with clock) and the number of gates switching per second, this would imply a pretty large difference in power dissipation between the two states.

[Karlos]

The fact that the Amiga had coprocessors tells you all you need to know about single core CPUs

Well, to be fair, the coprocessor argument is slightly different. A dedicated GPU is almost always going to be more efficient at graphics operations than a CPU.

However, it is worth noting that modern GPU's are so efficient at what they do due to using a many-core solution to the inherent parallel data operations common to graphics processing.

If you heavily multitask, a multicore CPU is always going to outshine a single core, no contest. I was able to use 3 of my 4 cores for encoding video (three separate mencoder processes, see above) and get the job done in 1/3 the time it would take a single core. And all without losing any speed at all, since the fourth core was more or less free to run all the non-cpu bound stuff.

Of course, it would probably have been even faster if I were to use the GPU for the job

[Karlos]

To address the above point about each having their respective strengths and weaknesses, I honestly can't see any advantage to a single core CPU over a multi core one. Unless you are not in a position to leverage the more than one core, that is, in which case there's obviously no benefit of more than one core.

[Karlos]

Depends on what your definition of "an operating system using more than one core" is

What would interest me more than just having one program crunching numbers within one core, another crunching numbers in another core, a third crunching numbers in a third core etc is if the operating system itself could could be split across the cores running a different task in each core,

I dunno where you are getting your impression from but the OS does do exactly this. If one core is busy, any newly created processes will be put on a different core. Also, most kernels allow a process to move between cores whenever the task scheduler decides to redistribute the load. For example, on my machine, a single-thread process using 100% cpu load is actually distributed across all four cores (although only one one of them at any instant), spending approximately the same amount of time on each one. That's probably better thermally for the CPU than having one core at 100% and the other's permanently idling along.

or i could get one program to split itself across each core.  I hardly ever need to encode more than on video/dvd at the same time, but I'd like to have four cores all working to decode that single DVD at the same time.  At the moment this doesn't happen particularly  well, if at all, as most software and the OS is not designed to detach into parallel tasks like that. Most benchmarks I've seen from dual core systems are at best 30-50% faster than a single core at the same clock speed, and for some benchmarks with some dual core cpu's the dual core can even be slower.  (Windows 7 might be better, i haven't had any experience with it)

Programs must be written to support this. Presently, the only way for an application to do this would be to create several threads and give a portion of the workload to each one. This assumes that the job they are doing supports this type of parallelism. Many jobs don't. There's no magic way to automatically fork a process into subthreads and divide work between them.

The next generation of C++ aims to include language-level support for writing multithreaded code, which will certainly help.

Incidentally, I was using 3 of the 4 cores to encode a single DVD. Each one was working on a subset of the total number of titles on the disc. I could have used all four cores but the number of titles was an exact multiple of 3 and I was doing other stuff at the same time, so I launched three processes. So, in effect I was getting exactly what you were asking for.

[Karlos]

Apple have added blocks to C...

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10

this goes hand in hand with their grand central dispatch subsystem...

Actually, I find that absolutely disgusting. New syntax should not be added to C for any reason whatsoever, unless it is an official ISO standard that can be adopted openly. Which pretty much hasn't happened since C99. For multithreading, I would much prefer a standard library of functions. Actually changing the language syntax breaks portability in a way that's incredibly awkward to work around. Redefining the ^ operator for passing a block of code isn't even readily ported to C++ where operator overloading is a language feature.

Now, C++ added further syntax to C but it didn't change any meaning of existing C syntax (ok, there are a few small gotchas) but whenever something new is added to C++ nowadays, it's via the STL.

[Karlos]

Wait, hang on. That was given in answer to your earlier point. Didn't you say you'd prefer it if the OS distributed the work between the cores? Well, that's exactly what the kernel does do. To the extent that even a single thread will move from one core to another depending on the existing load on each core and for improved thermal distribution (if nothing else).

A single thread of execution, by definition cannot run on several cores concurrently. Do not confuse multi core with superscalar execution. They are not the same thing and for what it's worth, each of these multiple cores is superscalar and nicely pipelined too. Each one is thus executing more than one sequential instruction in whichever thread they happen to be executing at any instant.

Now, as for the issue about writing stuff for multi core, you have to accept that not every computational task is parallelisable. Therefore there will be some things that cannot on their own take advantage of more than one core. However, you must bear in mind that on all multitasking operating systems there are usually many threads that are ready to run and the scheduler has to pick just one of them per quantum. Not so on a multicore. It will allow as many threads to execute per quantum as the hardware will allow. From a throughput perspective, running four threads in one quantum is up to 4x faster (assuming no interdependencies) than running one each for four successive quantums. Better throughput means less latency for all tasks.

What I am saying is, that unless you use a single application on a single-tasking "OS" (or MacOS classic as it's more commonly known :lol:), it's impossible to not reap a performance gain from multi core in general use.

The principal exception to this rule is when you want to run a single, very CPU intensive task that cannot ever be optimized for parallel execution where a single core processor may offer a price/performance benefit over a more costly multi core part that can't run that one task any faster.

Now, amiga users are fans of multitasking, after all it was always our OS's strength. Seems a bit daft to try to ignore the clear advantage of a multi core CPU in an SMP capable multitasking OS.