Multiple cores?

[sci4me]

Hey guys. So, this isnt specifically mcu's or fpga's, but its related. I was wondering, in a multi core processor, how are both cores used? Is it a software thing mostly or hardware? What are the hardware aspects to making multiple cores work together?

[pigtwo]

It's been a little while since I've read about this so someone correct me if I'm wrong. 

Each core mostly acts as if it is it's own isolated processor.  The operating system has the job of deciding which core to give each process(technically a thread, a process is made up of one or more threads).  Once a core as been assigned a thread it will solely work on that thread.  This is because it is very difficult to have two cores work on the same thread without either computing things unnecessarily or just repeating things that the other core has already done.

For example.  If you have a statement like:

Code: [Select]

if(a == b)
   do(c)
else
   do(d)
In this case, until a==b is computed, the program does not know whether 'do(c)' or 'do(d)' so while one core is computing a==b, the other core has nothing to do.( Side note: processors actually do try to predict what branch to take and then pre-compute it.  Interestingly enough it is fairly effective even when all it does to predict is a little rule like 'always take the true if branches' or 'always compute while loops'.  But there are much more complicated systems of predicting branches.)

The other reason core are usually very isolated is because of the inherent problems in sharing data(IE what if both cores change a variable at the same time. )

I'm sure there are little ways in which separate cores can cooperate but I would imagine they are specific situations.  If I remember right there is something where separate cores can share registers and that can help but my memory on this is very fuzzy(and probably wrong).

So to summarize:  The cores in a processor are mostly separate and do not work together very often(on a single thread).  A program can be written to take advantage of all the cores but in that case there is just a separate thread created for each core for some specific job and the program merges all of the data.  So in the end it is a software thing.

If you're interested in how processors work on a high level I recommend Inside The Machine.  It only goes up to the core 2 duo but the concepts are very interesting mostly still relevant. 

If you're interesting in how operating systems schdule tasks like I described and how multi-core processors are handled by the operating sytems then I recommend Operating System Concepts.  This is a long book and not very much of it actually about this topic.  But it is still an excellent book if you're interested in the jobs that operating systems have to do and how they do them.

I hope that made sense.

[sci4me]

Thanks, that answers my question.

[ve7xen]

I'm sure there are little ways in which separate cores can cooperate but I would imagine they are specific situations.  If I remember right there is something where separate cores can share registers and that can help but my memory on this is very fuzzy(and probably wrong).

What's becoming somewhat more popular is shared execution units, so a pair of cores might have their own integer and address units, but share a floating point unit or some other execution hardware, with the frontend handling the scheduling of micro-ops (Bulldozer does something like this). The goal in modern CPU design is to keep as much execution hardware (which is pipelined, so can stall on branches etc.) busy as much of the time as possible.

They're still separate cores from the OS's point of view, but do share some of their execution hardware. Cache is also very commonly shared.

Jon Stokes wrote an excellent series of articles for Ars Technica on CPU architecture back at the turn of the century. They're a bit hard to track down (and read) these days due to being archival content, but well worth it if CPU architecture is interesting to you. Very readable, yet still accurate and concise, if a tad dated now. As far as your current queries, his intro to HyperThreading is probably a good start.

[Berni]

Yes cores are essentially multiple CPUs connected to the same memory bus. Software has to be specifically and it's quite messy. You can give multithreaded programming a go in .net with Visual Studio.

One chip I seen that does it diferently is the Xmos ones. They don't share any memory space but instead pass packets of data using special instructions, they also talk from chip to chip.But I find that just as messy. The more interesting thing is that they run up to 8 threads on a core, but they need at least 4 threads running to reach there 500MIPS spec(because of pipelining of course). But don't get to exited, they need a significant amount of support circuitry and they are not all that cheep, so not really an all that good mcu replacement.

[MasterOfNone]

One chip I seen that does it diferently is the Xmos ones. They don't share any memory space but instead pass packets of data using special instructions, they also talk from chip to chip.But I find that just as messy. The more interesting thing is that they run up to 8 threads on a core, but they need at least 4 threads running to reach there 500MIPS spec(because of pipelining of course). But don't get to exited, they need a significant amount of support circuitry and they are not all that cheep, so not really an all that good mcu replacement.

Déjà vu?  In the 80s another British Company with a name ending in ‘MOS’ was going to revolutionize the computer industry with a Microprocessor design that would pass messages between chips to achieve true parallel processing. The Company was INMOS and the chips were called Transputers. The chips could be programmed in C or a specially created language called OCCAM (plus a few other languages), special serial links were provided to pass messages between Transputers, and it was possible to build systems with grids of Transputers. 
Some of the problems this idea faced was it was sometimes difficult to partition the software into communicating blocks that would fit nicely in this model, and deadlocks could occur if the software wasn’t designed correctly.  But the XMOS chips probably don’t suffer from these problems.

[Berni]

Yup those are the same guys behind XMOS. They suffer from the usual problems of multicore architectures, but on the upside they are pretty fast for a chip that comes in a reasonable pin count quad flat pack package(if you are prepared to accept the external boot flash and Vcore, reset circuitry...)

I remember intel had an idea some time ago of having a 64 core CPU built up from simple small cores, but they probably have not solved the issue of writing software to run on something like that. Right now very repetitive tasks are handled quite well by graphics cards, so probably no point in having such an hugely multicore CPU in the first place.

[MasterOfNone]

Yup those are the same guys behind XMOS. They suffer from the usual problems of multicore architectures, but on the upside they are pretty fast for a chip that comes in a reasonable pin count quad flat pack package(if you are prepared to accept the external boot flash and Vcore, reset circuitry...)

I remember intel had an idea some time ago of having a 64 core CPU built up from simple small cores, but they probably have not solved the issue of writing software to run on something like that. Right now very repetitive tasks are handled quite well by graphics cards, so probably no point in having such an hugely multicore CPU in the first place.

Thanks for the info, I thought it was too much of a coincidence, Wow the Transputer is alive and well (kind of).

[Bored@Work]

Thanks for the info, I thought it was too much of a coincidence, Wow the Transputer is alive and well (kind of).

The transputer is dead, and so are a couple of companies who trusted Inmos that they could deliver what they promised. Delays in delivering the T9000 killed a good number of aspiring supercomputer companies in Europe and elsewhere.

As for XMOS, well, that is what you do when your job as a Professor bores you to death and you don't really have new ideas. Since a few years they try to get a foot in the door with that thing. I think they have re-target their marketing a few times, currently calling it a multicore microcontroller and targeting stuff like audio processing. Quite a difference from what was once supposed to be the heart of supercomputers.

[MasterOfNone]

Thanks for the info, I thought it was too much of a coincidence, Wow the Transputer is alive and well (kind of).

The transputer is dead, and so are a couple of companies who trusted Inmos that they could deliver what they promised. Delays in delivering the T9000 killed a good number of aspiring supercomputer companies in Europe and elsewhere.

As for XMOS, well, that is what you do when your job as a Professor bores you to death and you don't really have new ideas. Since a few years they try to get a foot in the door with that thing. I think they have re-target their marketing a few times, currently calling it a multicore microcontroller and targeting stuff like audio processing. Quite a difference from what was once supposed to be the heart of supercomputers.

OK so the Tranputer is dead, and I wont be shedding any tears, because even though the later version like the T805 worked and you could program it in C. Design proving your processing card was a pain because the tools were a bit crap. Whilst the engineers working on the newfangled DSPs had their fancy ICE debugging tools, the team on Transputers had to use print statements and a PC base Transputer Card with some software called Winserver that could display the debug messages (which it received via its Transputer link). Oh happy days.

[orion242]

Check out this 8 core uP.

http://www.parallax.com/tabid/407/Default.aspx

Not too hard to work with.  Having cores dedicated to certain tasks allows for hardware to be emulated in software.

[mrflibble]

If you want to play around with multiple cores, with thepurpose of playing around with it, then Parallella definitely looks interesting. The reason I say playing around ... I wouldn't get one for performance reasons, I would get one for learning purposes.

[mrflibble]

Check out this 8 core uP.

Heh. From that link.

"Its eight processors (cogs) can operate simultaneously, either independently or cooperatively, sharing common resources through a central hub. The developer has full control over how and when each cog is employed; there is no compiler-driven or operating system-driven splitting of tasks among multiple cogs."

Translation: we don't supply a (RT)OS, nor do we supply libraries for scheduling. You have to sort out your own shit, have fun!

Which is cool if you want to muck about with it on that level, otherwise it's going to cost you a nice chunk of development time. Not that this is necessarily a bad thing, but I found the quoted bit ... amusing.

[Crazy Ape]

Tilera have some funky multicore chips as well.
http://www.tilera.com/products/processors/TILE-Gx_Family

[Hardcorefs]

Like all multi-core designs... it comes down to bandwidth and infrastructure....