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, [email protected] wrote:
>
> [email protected]
> <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 <x-msg://16/#group_thread_0> - 1 Update
> nil pointer ref can't figure out why <x-msg://16/#group_thread_1> - 3 Updates
> Advice, please <x-msg://16/#group_thread_2> - 2 Updates
> confusing compile error message after renaming module
> <x-msg://16/#group_thread_3> - 2 Updates
> <>[ANN] New Go package: xmorph
> <http://groups.google.com/group/golang-nuts/t/e8d89ccdaf8813f5?utm_source=digest&utm_medium=email>
>
> Scott Pakin <[email protected]>: 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 <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/ <http://xmorph.sourceforge.net/>), which is
> what the morph CLI and the xmorph
> and gtkmorph GUIs build upon.
>
> Enjoy!
>
> — Scott
> Back to top <x-msg://16/#digest_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 <[email protected]>: 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 <[email protected]>: 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 <[email protected]>: 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 <[email protected]>
> wrote:
>
> Back to top <x-msg://16/#digest_top> <>Advice, please
> <http://groups.google.com/group/golang-nuts/t/caac5f1881832abe?utm_source=digest&utm_medium=email>
>
> Kevin Chadwick <[email protected]>: 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 <[email protected]>: 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 <x-msg://16/#digest_top> <>confusing compile error message after
> renaming module
> <http://groups.google.com/group/golang-nuts/t/93207c432a09ad75?utm_source=digest&utm_medium=email>
>
> DrGo <[email protected]>: 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 <[email protected]>: 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 <x-msg://16/#digest_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 [email protected]
> <mailto:[email protected]>.
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://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/1033748D-DA67-417C-AAC8-391409034FF2%40bsc.es.
