Last visit was: Tue Jun 25, 2024 6:24 am
It is currently Tue Jun 25, 2024 6:24 am



 [ 2 posts ] 
 core / thread / resource parallellism direct use in code? 
Author Message

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 53
"gates are cheap" - a philosophy that seems to be feeding the evolution of both gfx cards and multi-core CPUs.

The models in use today seem to be centered around totally separate logical entities: Everything that processes is self-contained.

There have been many models attacking this, including (and perhaps missing a few):
- Out-of-Order - executing along multiple paths and discarding wrong paths taken. Not visible for code.
- Power4(3? 2?)/ Parallax - round robin resource use, but separate register set for each core
- Pentium/Power5 - OO with best fit resource use, separate register set for each thread looking like a core
- Power5 and many others - many parallel cores only sharing IO logic, also incorporating threads
- VLIW - executing several instructions explicitly at the same time. Static approach.
- EPIC - like VLIW but being able to run parallel computations much like OO and pick one "path" at the end
- Transputers - more like a network/river of computing nodes? Don't know too much about them.

I'm kinda partial to the VLIW idea myself, but what I am wondering is: Have any architectures ever let a Master thread (MCP? :-) start and stop other hw threads (or suicide) that share the same register set?
I can see something like that get very messy - do you number the threads directly, or does the cpu have some list of free threads it will give you one from (and what happens if you ask for a new thread and none are available?)?

The programming model could be everything you have in a normal instruction set, but also something like
fork BranchTaken,r3
kill r8
wait r11
signal r9
die
merge r3
All of the above (except form) would probably have typical test or branch semantics (die-on-equal, die-always, kill-carry).

The idea of all this mess is to fork out as many paths as possible in your code at once and run them in parallel and terminate the dead ends and let the survivor get control. Much like you do with OO anyway, but sw controlled. I could envision a very convoluted loop that runs half(or something) a loop ahead of itself until it get a dependency on a previous result where it has to merge control.

(This rambling is so clear in my head, and so hard to put down in words...)


Tue Feb 05, 2013 5:23 pm

Joined: Wed Jul 24, 2013 10:17 pm
Posts: 3
Probably nobody has done this because it's incompatible with existing compilers.

Speaking as someone who has worked on compilers, the amount of work required to support this in a compiler would be very high.

Toshi


Wed Jul 24, 2013 10:29 pm
 [ 2 posts ] 

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software