3 ms·

I protyped dynamic dataflow machine which (in theory) could be scaled to hundreds of cores (corelets - something very small which does not have even jump comman

by thesz 15y ago

I protyped dynamic dataflow machine which (in theory) could be scaled to hundreds of cores (corelets - something very small which does not have even jump command). In my experiments readying information to be sent accounts for hefty 30%+ of code. http://thesz.mskhug.ru/svn/hhdl/previous/HSDF/CoreletTest.hs http://thesz.mskhug.ru/svn/hhdl/previous/HSDF/CoreletTest.hs The link above contains some simple "Hello, world!" program, in five "big instructions" which contains 21 corelet instruction in total. 8 of those 21 instructions are send and front advancing instructions - their only purpose is to establish communication between program parts. My machine sends pointers to "big instructions", up to 32 bytes long (up to 32 instructions if you're lucky) while GA144 could send only 4 instructions max. 30% of 4 instructions is 1 instruction. Another one instruction from those 4 is a loop or jump or something like that. So you have two instructions to perform program logic. And this is best case. So I again express dislike of GA144 as a computing machine. And I again express my gratitude to Chuck Moore for proving that clockless design works.

bitcracker 15y ago
> In my experiments readying information to be sent accounts for hefty 30%+ of code. Unfortunately I don't have time to dive into your design but AFAIK the GA144 doesn't need 30% preparation code because every instruction can be executed immediately by neighbor nodes. That means (correct me if I am wrong) if core X has to evaluate a Forth function of say five arguments then it could pass all five arguments to its neighbors (without any preparation) by sending them the code addresses of the arguments, wait until they have finished and then use their results to compute the function result. These neighbor nodes themselves could evaluate (or delegate) subexpressions to other (free) nodes and so on. This form of parallelization would require an efficient shared memory access. This problem needs to be solved because AFAIK I/O ports are accessible by the edge cores only. It doesn't make much sense to transport each shared data through several columns or rows of cores.
- thesz 15y ago
  I think you're wrong about many arguments for command send to other core. You can send a word, ie, "big command" composed from four MISC command. One of MISC commands in "big command" can retrieve data from other core. So most of the time you will wait to send a command or to receive some data.

by thesz 15y ago

bitcracker 15y ago

> In my experiments readying information to be sent accounts for hefty 30%+ of code. Unfortunately I don't have time to dive into your design but AFAIK the GA144 doesn't need 30% preparation code because every instruction can be executed immediately by neighbor nodes. That means (correct me if I am wrong) if core X has to evaluate a Forth function of say five arguments then it could pass all five arguments to its neighbors (without any preparation) by sending them the code addresses of the arguments, wait until they have finished and then use their results to compute the function result. These neighbor nodes themselves could evaluate (or delegate) subexpressions to other (free) nodes and so on. This form of parallelization would require an efficient shared memory access. This problem needs to be solved because AFAIK I/O ports are accessible by the edge cores only. It doesn't make much sense to transport each shared data through several columns or rows of cores.

thesz 15y ago
I think you're wrong about many arguments for command send to other core. You can send a word, ie, "big command" composed from four MISC command. One of MISC commands in "big command" can retrieve data from other core. So most of the time you will wait to send a command or to receive some data.