Power 7 CPU - 8 cores

[KimmoK]

Any CPU engineer will tell you instantly we have hit the wall and all this multi-core desktop CPU stuff is just a scam really. The maximum number of cores without losing efficiency of code execution is effectively 3. Not 4 not 8 but 3. You can not utilise much more than this without actually starting to waste cycles of CPU time delaying/setting up use of threads to run on other cores. ....For desktop computers 3 or 4 is about it. So Moore's law is f**ked well and trully unless we start seeing 5 and 6ghz CPUs QUICKLY!

It depends on desktop's use how it can share load. Some applications can split their doings to hundreds of small items to be processed parallelly, while some other taks run fastest in one pipe. Some jobs can even be split to SIMD and shader units of the system.

Easy to share/split are: renderings, video encoding, compiling, etc... Even I have used ten CPUs clusters that work very well indeed.

Latest TCOM chips have 32 cores, perhaps more. And on workstations you see things like multiple i7 chips on one motherboard. They are there because they work.


And finally... latest overclocked CPUs run faster than 9Ghz. Even if you can buy only 5Ghz parts from (IBM) shop.

[Hattig]

If I'm not mistaken, PA6T is a mobile PPC970 ... and IIRC, PPC970 is a Power6 stripped and modified for desktop?

So it is not generations behind, even if it runs circles around (PA6T might be better in performance per watt).

Nope, PA6T is a completely different design to the PPC970.
The PPC970 was derived from POWER4 IIRC.

Power7 is a very nice chip, but the closest we will get to it as consumers will probably be a next generation console, if any of them use the basic core in their designs (i.e., WiiU, XBox720 - PS4 is most likely x86 according to the rumours).

[KimmoK]

Honestly everyone goes on about AmigaOS vs Windows 7/8 but frankly AOS does absolutely nothing in comparison to it. If, and it's obviously a hypothetical if, AmigaOS development had continued in parity with Windows and x86 over the years then we'd all be whining about the same things. It's not some wonder-CPU-architecture that made AOS usable, it was simply because it was extremely primitive compared to modern operating systems.

Windows has a lot of features (and people really use 1% of them) but M$ has failed in basic things.

AOS is primitive? To modern standards, perhaps. But AOS is flexible and simple. To me it seems to offer enough to do all desktop tasks on top of it, we mainly need the SW on top (and to ease up the SW development we need some things to OS). Unless AOS is totally being broken by it's implementators, I doubt it will ever be as sluggish as the mainstream. (not even memory protection should break responsiveness, it has been demonstrated by RTOSs)

[matthey]

None of that is down to the CPU. You'd encounter the same issues running a super-68k CPU because it's software. When you don't have to deal with a modern OS and the thousands of processes it has to manage then you can get plenty of performance out of ANY of these architectures.

I can debug, disassemble, fix bugs and optimize code in the AmigaOS because the CPU is easy to use and the code is small. Programming is easier on a flexible low latency CPU than a DSP/SIMD like high latency CPU also. The CPU does matter to me at least. Give me a superscaler N68070@500MHz using the 68kF ISA and I'll be happy .

Honestly everyone goes on about AmigaOS vs Windows 7/8 but frankly AOS does absolutely nothing in comparison to it. If, and it's obviously a hypothetical if, AmigaOS development had continued in parity with Windows and x86 over the years then we'd all be whining about the same things. It's not some wonder-CPU-architecture that made AOS usable, it was simply because it was extremely primitive compared to modern operating systems.

The AmigaOS has the basics and it's extensible. That's better than being stuck with whatever bloat is thrown into Windows.

AOS is primitive? To modern standards, perhaps. But AOS is flexible and simple. To me it seems to offer enough to do all desktop tasks on top of it, we mainly need the SW on top (and to ease up the SW development we need some things to OS).

Yep. Simple and extensible.

 Unless AOS is totally being broken by it's implementators, I doubt it will ever be as sluggish as the mainstream. (not even memory protection should break responsiveness, it has been demonstrated by RTOSs)

I think partial memory protection could be implemented (with MMU) and not affect responsiveness. I'm talking about protecting code and read only data but NOT copying messages. A full sandbox would likely impact the responsiveness.

[Iggy]

Code density matters for small electrical devices especially with batteries. That is why I talked about competing with ARM and not x86 on the desktop. I'm thinking of laptops, pads, netbooks, smart phones, embedded devices, fanless desktops where ARM leaves something to be desired and x86_64 is like taking a MAC truck to the grocery store. Better code density also means more instructions in the instruction cache and a smaller instruction fetch is needed. Less memory usage is still a small advantage in general, more so on low end electrical devices.

Actually, ARM has definate advantages in the area.
Its very low power.
X86 isn't quite there yet.
And the 68K never was a low power device.
 
So, arguing the code density issue from that point makes little sense.
 

Can you show me how to program utilizing all the cores?

I noticed that a lot of people have mentioned code modularity.
In the '80s we had a 6809 based point of sales system that had about 255 memory resident concurrent tasks that were all assigned priority levels (Microware OS-9 again).
This type of system would have moved very well into an SMP environment.
 
These days I still tend to code this way. Writing small routines that can thread info to other modules and call other tasks.
With an SMP capable OS this allows the operating system to spread tasks across multiple CPUs. And the software will still run in a single CPU environment.
 
Its not so much asv writing code for multiple CPUs as it is writing code that can run better in a multiple CPU environment.

[minator]

Any CPU engineer will tell you instantly we have hit the wall and all this multi-core desktop CPU stuff is just a scam really. The maximum number of cores without losing efficiency of code execution is effectively 3. Not 4 not 8 but 3. You can not utilise much more than this without actually starting to waste cycles of CPU time delaying/setting up use of threads to run on other cores.

Apparently the GPU guys didn't get that memo. top end GPUs run half a million threads on hundreds of cores in parallel.


Building faster single threaded CPUs is getting more and more difficult.

The 5GHz variant of the Pentium 4 was cancelled because it was going to use 150W.  They went to a more efficient design with multiple cores after that because it is far more power efficient.

Even mobile phones are quad core these days.  Expect to get a lot more cores in the future.

[minator]

PS4 is most likely x86 according to the rumours.

But it wont be *just* x86.

Their CTO mentioned what it has very vague terms in a speech.  If there's an x86 in there it'll just be one of many processors.

I took it to mean PS4 will be  x86 + Cell + GPU, with an FPGA thrown in for good measure.


XBox 720 is said to have a 16 core CPU that IBM designed but no one seems to know what the cores are.  According to a leaked Microsoft doc they could be x86 or ARM.


Wii U is supposed to have 3 PPC cores supposedly based on the POWER7 cores.

[AJCopland]

@matthey
Yes but that's my point. You can't compare AmigaOS from 1980's to Windows 7 from 201X hence my hypothetical example of IF AmigaOS had continued to be updated then it'd be in the same sluggish state.

I'm just saying that you're falling into the old-OS vs new-OS fanboy behaviour. You cannot compare the two, they're both OS's but from 30 years apart that do completely different jobs.

There are things to be said for the simplicity of AmigaOS but if you like that sort of thing then you should look at HaikuOS and see how to achieve it's minimal feature set still requires some serious CPU performance before you start running any programs on it.

I agree that you can definitely take the 68k design and get a lot more performance out of it. The 68060 design was already going down the path that x86 successfully followed. Superscalar design, multiple ALUs, Out-of-Order, branch prediction, op-fusion + cache, pre-fetching, etc these are all things that x86 & PPC (and other ISAs) have all successfully integrated and they're as applicable to 68k as to anything else. Although some are more applicable to hard designs than to FPGA based ones apparently.

I think you're on the right track if you take something like the TG68 fpga design and start to do things like improve it to make instructions run in a single cycle, add a 2nd ALU, improve the cache performance ad infinitum.

Andy

[matthey]

Actually, ARM has definate advantages in the area.
Its very low power.
X86 isn't quite there yet.
And the 68K never was a low power device.
 
So, arguing the code density issue from that point makes little sense.

ARM has a simple decoder and consumes very little electricity but the integer CPU could be more powerful. x86 is more powerful but has a very complex decoder wasting electricity. The 68k would fit in between with a moderately complex decoder but is similar in integer performance, if not better than x86 (assuming basic enhancements like in 68kF and no 64 bit for low power target). While consuming more electricity than ARM, the 68k has the best code density which helps performance and allows for a smaller memory footprint. The 68060 was pretty low power consumption for it's performance and time.

I have rated the 4 most common processors according to what I think is important for a modern integer CPU. The asterisks are stars with 5 asterisks being the best:

1) electrical consumption/decoder and pipeline simplicity
2) powerful integer instructions and addressing modes
3) conditional and branch hazard performance
4) code density
5) ease of use

68kF in a modernized 68060 like implementation
1) ***
2) *****
3) ***
4) *****
5) ****

ARM with Thumbs
1) *****
2) ***
3) ***
4) ****
5) ***

x86
1) *
2) ****
3) **
4) ****
5) *

PPC
1) ****
2) *****
3) ****
4) *
5) **

Agree or disagree with these ratings? Of course the x86 is a pig made to fly with plenty of money.

[NorthWay]

Now my sarcasm detector is failing.
THAT definately was sacasm, wasn't it?

Nope, a P795 does not simply have a fan, it has an Air Moving Device. Which is not a fanblade as might be expected, but a rather big river-boat style shovel(?) - a rotating mousewheel with blades digging into the air as it rotates.
You can _hear_ the box power up from a long way away when that thing starts moving. And that in an already noisy datacenter. It works. The box keeps its cool.

[matthey]

I'm just saying that you're falling into the old-OS vs new-OS fanboy behaviour. You cannot compare the two, they're both OS's but from 30 years apart that do completely different jobs.

I like what works well. AmigaOS does and Windows does not.

There are things to be said for the simplicity of AmigaOS but if you like that sort of thing then you should look at HaikuOS and see how to achieve it's minimal feature set still requires some serious CPU performance before you start running any programs on it.

Haiku looks pretty kool from the videos I've seen. I might give it a try if support other than x86 gets better. Otherwise, AROS is getting better .

I think you're on the right track if you take something like the TG68 fpga design and start to do things like improve it to make instructions run in a single cycle, add a 2nd ALU, improve the cache performance ad infinitum.

It would be better to start with the N68050 if Jens ever releases it like he's been talking .

[commodorejohn]

Apparently the GPU guys didn't get that memo. top end GPUs run half a million threads on hundreds of cores in parallel.

There's a big, big difference between massive multicore in special-purpose applications, and massive multicore for general-purpose computing, though. Graphics in particular is a task that's pretty much tailor-made for massive parallelism. Word processors, file managers, web browsers, and other unglamorous productivity software? Not so much.

[minator]

ARM has a simple decoder and consumes very little electricity but the integer CPU could be more powerful. x86 is more powerful but has a very complex decoder wasting electricity. The 68k would fit in between with a moderately complex decoder but is similar in integer performance, if not better than x86 (assuming basic enhancements like in 68kF and no 64 bit for low power target). While consuming more electricity than ARM, the 68k has the best code density which helps performance and allows for a smaller memory footprint. The 68060 was pretty low power consumption for it's performance and time.

As I understand it the 68K was running into difficulties when it was getting to things like the 68060.  That was one of the reasons they abandoned it.

Having a complex and powerful ISA might be wonderful from the programmer point of view but it's most likely the opposite from the hardware designer's point of view.  Someone has to implement all those commands in hardware and this can lead to some very tricky situations.

e.g.  What happens if your processor is doing some complex operation and an interrupt comes in?  Do you hold the interrupt and keep going?  What if the operation takes a long time involves reading from RAM?  You probably can't wait that long so you have to find a way of halting the processor, storing the state mid instruction, handling the interrupt, recovering the state and restarting where you left off.

Thats the sort of problem the hardware designers have to deal with.  Then you have to build it and test it, including that particular behaviour.  There's a reason no one but IBM and Intel use CISC these days - and they both tried to get rid of it.

[commodorejohn]

As I understand it the 68K was running into difficulties when it was getting to things like the 68060.  That was one of the reasons they abandoned it.

Having a complex and powerful ISA might be wonderful from the programmer point of view but it's most likely the opposite from the hardware designer's point of view.  Someone has to implement all those commands in hardware and this can lead to some very tricky situations.

This is true enough, but x86 faced the exact same hurdle at the same time - they solved it by moving the Pentium Pro to a RISC microarchitecture which implemented the CISC instruction set, and they've stuck with that approach ever since. I don't see any reason the 68k couldn't do the same. It's a kluge, admittedly, but it's a kluge that could give us a rich, friendly instruction set with increased performance, and that's nothing to sneer at.

e.g.  What happens if your processor is doing some complex operation and an interrupt comes in?  Do you hold the interrupt and keep going?  What if the operation takes a long time involves reading from RAM?  You probably can't wait that long so you have to find a way of halting the processor, storing the state mid instruction, handling the interrupt, recovering the state and restarting where you left off.

I don't know of any processor that supports breaking for an interrupt mid-instruction - that would be overly complex to implement, introduce a highly undesirable degree of non-determinacy, and not get you anything more than slightly lower interrupt latency for the trouble.

Besides which, most of the 68k instructions that are particularly long-ish are that way mostly because they haven't been implemented a particularly efficient way - multiplication on the original 68000, for example. One of the key things you'd want to do in a new 68k design is address some of those, anyway.

[matthey]

As I understand it the 68K was running into difficulties when it was getting to things like the 68060.  That was one of the reasons they abandoned it.

B.S. This was just anti-marketing the 68060 because Motorola decided they were going the PPC route. The 68060 was outperforming the early PPC processors. Apple made their OS incompatible with the 68060 so it wouldn't be the fastest Macintosh available. In the meantime, Intel was having no problems upping the performance of their x86 line which is more difficult to enhance than the 68k family.

Having a complex and powerful ISA might be wonderful from the programmer point of view but it's most likely the opposite from the hardware designer's point of view.  Someone has to implement all those commands in hardware and this can lead to some very tricky situations.

Many times you are correct but the 68kF was created with performance considerations like:

1) Address registers only allow full 32 bit register updates.
4) Most new instructions update full 32 bit register.
2) SELcc and SBcc were added instead of MOVcc.
3) Smaller 32 bit immediates are compressed (using sign extend instead of shift).
4) Bitfield instructions are retained as they can be fast and update the whole register.
5) Trashing registers is avoided where possible in many different ways.
6) Better orthogonality, address registers allowed more, less register shuffling needed.
7) Many new instructions have a stealth 3 op format without requiring more units.

It is helpful to know a little bit about how a processor works before creating an ISA .

e.g.  What happens if your processor is doing some complex operation and an interrupt comes in?  Do you hold the interrupt and keep going?  What if the operation takes a long time involves reading from RAM?  You probably can't wait that long so you have to find a way of halting the processor, storing the state mid instruction, handling the interrupt, recovering the state and restarting where you left off.

It's more complex but it's already handled well in the 68060. The 68040 was kind of a mess though. There are more complex problems addressed all the time in modern processors than this. Take branch hazards for instance.

Thats the sort of problem the hardware designers have to deal with.  Then you have to build it and test it, including that particular behaviour.  There's a reason no one but IBM and Intel use CISC these days - and they both tried to get rid of it.

Freescale with the ColdFire?

[minator]

There's a big, big difference between massive multicore in special-purpose applications, and massive multicore for general-purpose computing, though.

I know, that why I mentioned single threaded next :-)

Graphics in particular is a task that's pretty much tailor-made for massive parallelism.

Yup.

Word processors, file managers, and other unglamorous productivity software? Not so much.

True, but it's now got to the point that a lot of software doesn't require a high end processor anyway.

On the other hand a lot of the stuff that does require high end processors can be parallelised.  I just bought a new high end laptop with a quad core CPU because I run things that can max it out - video editing, recording music and photo editing.

These can all run across multiple cores.  That said, editing 22 Mpixel images appears will happily use all 8 hardware threads but it seems to be more limited by the hard disk (which is actually a s**t hot fast SDD).

[/QUOTE]web browsers[/QUOTE]

Actually these do quite a lot at the some time so they can take advantage of multiple processors.