Robert I was interested in channel peformance only because it's the 'go idiom'. Channel communication is relatively complex, and so is a useful upper limit to costs of inter-goroutine synchronisation. It's reassuring to see that 50nsec per operation is what my machinery delivers. Simpler operations with atomics will therefore be no slower, and quite possibly quicker. This is good. And checkable by experiment
Once the sync costs are settled, I suspect it's the load-balancing which will rate-limit. That's more of a concern. But first things first. On Monday, January 18, 2021 at 8:59:15 PM UTC-6 ren...@ix.netcom.com wrote: > Channels are built with locks which without biased locking can lead to > delays as routines are scheduled / blocked under -especially under > contention. > > github.com/robaho/go-concurrency-test might illuminate some other options > to try. > > On Jan 18, 2021, at 8:13 PM, Pete Wilson <peter....@bsc.es> wrote: > > No need to beg forgiveness. > > > For me, the issue is the synchronisation, not how the collection is > specified. > You’re right; there’s no reason why a slice (or an array) couldn’t be used > to define the collection. In fact, that’s the plan. > But the synchronisation is still a pain. > > FWIW I built a channel-based experiment. > > I have N worker threads plus main > I have an N channel array toworkers; each gets a pointer to its own channel > I have an N-buffered channel fromthreads > > workers wait for an input on their input > when they get it, they send something on the buffered channel back to main > ..each loops L times > > main sends to each worker on its own channel > main waits for N responses on the communal buffered channel > .. loops L times > > The end result is that > - at one goroutine per core, message send or receive costs 100-200 nsec > - but the 6-core, 12-virtual core processor only runs at 2.5 cores worth > of load. > - presumably, the go runtime has too much overhead timeslicing its thread > when there’s only one goroutine per thread or core > > If we put 32 threads per core, so the go runtime is busily engaged in > multiplexing goroutines onto a thread, cost per communication drops to > around 50-60 ns > > For my purposes, that’s far too many threads (gororutines) but it does > suggest that synchronisation has an upper limit cost of 50 ns. > So tomorrow we try the custom sync approach. Results will be published. > > Meanwhile, thanks to all for thoughts and advice > > — P > > > On Jan 18, 2021, at 5:23 PM, golan...@googlegroups.com wrote: > > golan...@googlegroups.com > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics> > Google > Groups > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > > Topic digest > View all topics > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics> > > > - [ANN] New Go package: xmorph - 1 Update > - nil pointer ref can't figure out why - 3 Updates > - Advice, please - 2 Updates > - confusing compile error message after renaming module - 2 Updates > > [ANN] New Go package: xmorph > <http://groups.google.com/group/golang-nuts/t/e8d89ccdaf8813f5?utm_source=digest&utm_medium=email> > > Scott Pakin <scot...@pakin.org>: Jan 18 12:24PM -0800 > > It's perhaps a bit of a niche tool, but I just released *xmorph*, a > package > for warping and morphing images. The code is available from > > https://github.com/spakin/xmorph > > (If nothing else, you can see there my crude attempt at morphing the > cartoon Go gopher into the corresponding plush toy.) > > The Go package is essentially a wrapper for the C libmorph library ( > http://xmorph.sourceforge.net/), which is what the morph CLI and the > xmorph > and gtkmorph GUIs build upon. > > Enjoy! > > — Scott > Back to top > nil pointer ref can't figure out why > <http://groups.google.com/group/golang-nuts/t/64f3f2843e746622?utm_source=digest&utm_medium=email> > > Alexander Mills <mll...@justin.tv>: Jan 18 12:00PM -0800 > > I have this line: > > fmt.Printlin("the dao:", dao); > > and it logs: > > the dao: &{<nil> <nil>} > > > the overall method looks like: > > func (dao *UserAttributeDao) GetDecryptedUserAttributes(workflowID string) > (*PayoutUserAttributeRecord, error) { > getItemInput := &dynamodb.GetItemInput{ > TableName: aws.String(payoutUserAttributesTableName), > ConsistentRead: aws.Bool(true), > Key: map[string]*dynamodb.AttributeValue{ > payoutUserAttributesPK: {S: aws.String(workflowID)}, > }, > } > > fmt.Println("the dao:", dao) > > record, err := dao.GetItem(getItemInput) // NIL POINTER REF HERE > if err != nil { > logrus.WithError(err).Errorf("error during GetItem from DynamoDB table %v > for id: %v", > payoutUserAttributesTableName, workflowID) > return nil, err > } > > > does anyone know why calling the method would result in a nil pointer? To > me it seems like the object for which the method is being called is nil, > but that doesn't make that much sense to me. My main method looks like: > > func main() { > log.Println("doing some printing") > > var d = new(lib.UserAttributeDao) > x, err := d.GetDecryptedUserAttributes(""); // THIS RESULTS IN NIL POINTER > > if err != nil { > log.Fatal(err) > } > > } > > > .... > Axel Wagner <axel.wa...@googlemail.com>: Jan 18 09:16PM +0100 > > On Mon, Jan 18, 2021 at 9:12 PM 'Alexander Mills' via golang-nuts < > > > does anyone know why calling the method would result in a nil pointer? To > > me it seems like the object for which the method is being called is nil > > No, it is a pointer to a struct with two fields, both of which are nil. It > says `&{<nil> <nil>}`, not `<nil>`. > > > > var d = new(lib.UserAttributeDao) > > You are initializing `d` to a pointer, pointing at the zero value of > `lib.UserAttributeDao` - which is a struct with two fields, I assume. So, > for the zero value, both of those are nil. > > > Axel Wagner <axel.wa...@googlemail.com>: Jan 18 09:17PM +0100 > > You might want to use `Printf("the dao: %+v", dao)`, for example - it will > also print type-names and should make it more obvious what you have. > > On Mon, Jan 18, 2021 at 9:16 PM Axel Wagner <axel.wa...@googlemail.com> > wrote: > > Back to top > Advice, please > <http://groups.google.com/group/golang-nuts/t/caac5f1881832abe?utm_source=digest&utm_medium=email> > > Kevin Chadwick <m8il...@gmail.com>: Jan 18 12:39PM > > On 1/17/21 4:46 PM, Bakul Shah wrote: > > > With linked lists you’re wasting half of the memory bandwidth and > potentially > > the cache. Your # of elements are not going to change so a linked list > doesn’t > > buy you anything. An array is ideal from a performance PoV. > > Potentially forgive me and ignore this message if inappropriate as I > haven't > been paying close attention to this thread at all really. > > However, it strikes me that arrays are perfectly usable in GO. Similarly > to how > you might use a global array with tinygo to ensure memory usage limits are > not > breached. What is the issue of using an array in Go? Even a global one, > *IF* > suited to the task at hand and dishing the work out to workers with a > scheme a > little more complex than odd, even etc. as required? > > With the benefit that an off by one etc. causes a panic and not something > potentially worse? > Bakul Shah <ba...@iitbombay.org>: Jan 18 10:50AM -0800 > > > breached. What is the issue of using an array in Go? Even a global one, > *IF* > > suited to the task at hand and dishing the work out to workers with a > scheme a > > little more complex than odd, even etc. as required? > > Go arrays are perfectly usable. My comment had more to do with the fact > that > you'd just have a fixed number of threads and if synchronization using > channels > is not fast enough, you'd have to roll your own, in which case Go doesn't > really buy you much. I'd just keep the simulator code as a separate process > that does nothing but simulation and have it communicate with a separate > program that does visualization, logging etc. which can be in Go. Pete > Wilson > in his response said that simulated cores are already generated functions > in C > so this is not a big step. I'd just have the code generator generate the > whole > simulator or something like it. Just different tradeoffs to consider. > Back to top > confusing compile error message after renaming module > <http://groups.google.com/group/golang-nuts/t/93207c432a09ad75?utm_source=digest&utm_medium=email> > > DrGo <salah....@gmail.com>: Jan 17 08:14PM -0800 > > Wondering if someone knows what is going on here: > > I renamed a module in go.mod from liverserver [sic] to gols and imported > it > in main.go in a "cmd" subdir. Now I am getting this error when I compile > main.go: > > ./main.go:8:2: imported and not used: "github.com/drgo/gols" as > liverserver > ./main.go:13:12: undefined: gols > ./main.go:60:12: undefined: gols > > These are the lines referred to in the compiler output above > > import ( > "github.com/drgo/gols" > ) > > var config gols.Config > > if err :=gols.Serve(&config); err!= nil { > > > go mod tidy and go go clean -cache -modcache -i -r did not make a > difference. > > why the compiler still wants to import gols as liverserver > > I am using go1.16beta1 darwin/amd64 > > Thanks, > DrGo <salah....@gmail.com>: Jan 17 08:21PM -0800 > > Of course, once you post about a problem, you immediately figure it out. > I forgot to update the go files in the package folder to reflect the name > change > package liverserver--> package gols fixes the issue. > > > > On Sunday, January 17, 2021 at 10:14:36 PM UTC-6 DrGo wrote: > > Back to top > You received this digest because you're subscribed to updates for this > group. You can change your settings on the group membership page > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/join> > . > To unsubscribe from this group and stop receiving emails from it send an > email to golang-nuts...@googlegroups.com. > > > > > > > > > > *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 > <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...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/1033748D-DA67-417C-AAC8-391409034FF2%40bsc.es > > <https://groups.google.com/d/msgid/golang-nuts/1033748D-DA67-417C-AAC8-391409034FF2%40bsc.es?utm_medium=email&utm_source=footer> > . > > -- 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/d611e220-2d87-4d2a-aa3d-b5f738c03324n%40googlegroups.com.
