If there is very little work to be done - then you have N “threads” do M partitioned work. If M is 10x N you’ve decimated the synchronization cost.
> On Jan 17, 2021, at 9:11 AM, Pete Wilson <peter.wil...@bsc.es> wrote: > > The problem is that N or so channel communications twice per simulated clock > seems to take much longer than the time spent doing useful work. > > go isn’t designed for this sort of work, so it’s not a complaint to note it’s > not as good as I’d like it to be. But the other problem is that processors > are still architected as if most code is sequential and synchronisations (and > communications) are extremely rare and so no problem if they’re as slow as > molasses (which atomic operations are) > > Your description is basically what I’m trying to do, except that I’m using > local storage rather than the array elements. It’s not clear that exchanging > array pointers is any quicker than having a 2-phase loop; the problem is > still the barriers. > > P > > > >> On Jan 16, 2021, at 11:14 PM, Bakul Shah <ba...@iitbombay.org> wrote: >> >> You may be better off maintaining two state *arrays*: one that has the >> current values as input and one for writing the computed outputs. At >> "negtive" clock edge you swap the arrays. Since the input array is never >> modified during the half clock cycle when you compute, you can divide it up >> in N concurrent computations, provided a given output cell is written by >> just one thread. So theen the synchronization point is when all the threads >> are done with they computing. That is when you swap I/O state arrays, >> advance the clock and unblock all the threads to compute again. You can do >> this with N+1 channels. The tricky part may be in partitioning the >> computation in more or less equal N parts. >> > > > > WARNING / LEGAL TEXT: This message is intended only for the use of the > individual or entity to which it is addressed and may contain information > which is privileged, confidential, proprietary, or exempt from disclosure > under applicable law. If you are not the intended recipient or the person > responsible for delivering the message to the intended recipient, you are > strictly prohibited from disclosing, distributing, copying, or in any way > using this message. If you have received this communication in error, please > notify the sender and destroy and delete any copies you may have received. > > http://www.bsc.es/disclaimer > > > > > > > WARNING / LEGAL TEXT: This message is intended only for the use of the > individual or entity to which it is addressed and may contain information > which is privileged, confidential, proprietary, or exempt from disclosure > under applicable law. If you are not the intended recipient or the person > responsible for delivering the message to the intended recipient, you are > strictly prohibited from disclosing, distributing, copying, or in any way > using this message. If you have received this communication in error, please > notify the sender and destroy and delete any copies you may have received. > > http://www.bsc.es/disclaimer > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/FE3D2098-6E4A-4A84-BF9B-2CA04B343AA6%40bsc.es. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7F03F3F5-3942-4B54-A630-8CFC7E630115%40ix.netcom.com.
