If you use GOMAXPROCS as a subset of physical cores and have the same number of routines you can busy wait in a similar fashion.
> On Jan 17, 2021, at 9:50 AM, Pete Wilson <[email protected]> wrote: > > That’s exactly the plan. > > The idea is to simulate perhaps the workload of a complete chiplet. That > might be (assuming no SIMD in the processors to keep the example light) 2K > cores. Each worklet is perhaps 25-50 nsec (worklet = work done for one core) > for each simulated core > > The simplest mechanism is probably that on finishing work, every worker sends > a message to main; when it’s got all the messages, it sends a message to each > of the workers. Nice and simple. But it seems as though a channel > communication is of the order of 100ns, so I’m eating 200nsec per phase > change in each worker > > With 10 executing cores and 2K simulated cores, we get to do around 200 > worklets per phase per executing core. At 25ns per worklet that’s 5 > microseconds of work per worker, and losing 200nsec out of that will still > let the thing scale reasonably to some useful number of cores. > > But tools are more useful if they’re relative broad-spectrum. If I want to > have 20 worklets per core per phase (running a simulation on a subset of the > system, to gain simulation speed), I now am using ~ 200ns out of 500 ns of > work, which is not a hugely scalable number at all. Probably it’d run slower > than a standard single core sequential implementation regardless of the > number of cores, so not a Big Win > > Were the runtime.Unique() function to exist (a hypothetical scheduler call > that, for some number of goroutines and cores, allows a goroutine to declare > that it should be the sole workload for a core; limited to a fairly large > subset of available cores) I could spinloop on an atomic load, emulating > waitgroup/barrier behaviour without any scheduler involvement and with times > closer to the 10ns level (when worklet path lengths were well-balanced) > > I’d also welcome the news that under useful circumstances channel > communication is only (say) 20ns. That’d simplify things beauteously. (All ns > measured on a ~3GHz Core i7 of 2018) > > [Historical Note: When I were a young lad, I wrote quite a bit of stuff in > occam, so channel-y stuff is lapsed second nature - channels just work - and > all this building barrier stuff is terribly unnatural. So my instincts are > (were?) good, but platform performance doesn’t seem to want to play along] > >> On Jan 17, 2021, at 9:21 AM, Robert Engels <[email protected]> wrote: >> >> 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. > > > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8B022EE1-8A65-43E9-8451-99E99A29BEB2%40ix.netcom.com.
