Re: [go-nuts] Channels may not be the best solution in Go

[burak serdar]

On Wed, Oct 2, 2019 at 11:07 PM Travis Keep  wrote:
>
> I've been working on a math library github.com/keep94/gomath.  This library 
> has functions for generating prime numbers, ugly numbers, harshad numbers, 
> happy numbers etc.  Since there are infinitely many prime numbers, ugly 
> number, harshad numbers etc, these functions I wrote returned either a chan 
> int64 or a chan *big.Int. However I just recently rewrote all these functions 
> to return streams instead of channels.  By streams, I mean interfaces that 
> have a Next method that returns the next value in the stream. In this post I 
> explain why I made this change.
>
> First off there is overhead for callers with channels. When my functions 
> returned channels, they had to accept a Context since callers could never 
> exhaust the returned channels. Callers would have to remember to cancel the 
> context when they were done with the returned channel or else they would leak 
> a goroutine.
>
> Second using streams is about four times faster than using channels. I don't 
> know exactly why this is but I figure there is overhead involved in running a 
> goroutine to feed the returned channel as well as implicit locking that has 
> to be done when the channel is read from or written to.

It can be argued that you were misusing channels. Channels are
synchronization mechanisms between goroutines. They are not generic
data pipes. I think the operations you describe can be implemented as
a struct:

type PrimeGenerator struct {
   // internal state for generator
}

func (p *PrimeGenerator) Next() *big.Int {...}

If you want, you can still add:

type Generator interface {
  Next() *big.Int
}

>
> Third, streams are less taxing on the GC than channels.  A chan *big.Int has 
> to emit a newly allocated big.Int off the heap each time.  The Next method of 
> a *big.Int stream can accept a *big.Int from the caller and write the next 
> value to this caller supplied *big.Int instead of having to allocate a new 
> *big.Int each time.

Note that this can be dangerous. If the returned pointer is saved
somewhere else in the program as part of the internal state,
overwriting that instance of big.Int will also modify that state. You
get into issues about who owns data, which is never easy to solve.

>
> So at least for handling data structures handling an infinite number of 
> integers or *big.Int, using streams with a Next method is better than using 
> channels.
>
>
> --
> 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/538038ca-d6b9-4f9c-a69f-510284fc3ab8%40googlegroups.com.

-- 
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/CAMV2Rqr57j9p%3DqBi3QHQmOLPq8zLTCCsjJyQYs3DzR__%2Bn_edA%40mail.gmail.com.

[go-nuts] Channels may not be the best solution in Go

[Travis Keep]

I've been working on a math library github.com/keep94/gomath.  This library 
has functions for generating prime numbers, ugly numbers, harshad numbers, 
happy numbers etc.  Since there are infinitely many prime numbers, ugly 
number, harshad numbers etc, these functions I wrote returned either a chan 
int64 or a chan *big.Int. However I just recently rewrote all these 
functions to return streams instead of channels.  By streams, I mean 
interfaces that have a Next method that returns the next value in the 
stream. In this post I explain why I made this change.

First off there is overhead for callers with channels. When my functions 
returned channels, they had to accept a Context since callers could never 
exhaust the returned channels. Callers would have to remember to cancel the 
context when they were done with the returned channel or else they would 
leak a goroutine.  

Second using streams is about four times faster than using channels. I 
don't know exactly why this is but I figure there is overhead involved in 
running a goroutine to feed the returned channel as well as implicit 
locking that has to be done when the channel is read from or written to.

Third, streams are less taxing on the GC than channels.  A chan *big.Int 
has to emit a newly allocated big.Int off the heap each time.  The Next 
method of a *big.Int stream can accept a *big.Int from the caller and write 
the next value to this caller supplied *big.Int instead of having to 
allocate a new *big.Int each time.

So at least for handling data structures handling an infinite number of 
integers or *big.Int, using streams with a Next method is better than using 
channels.


-- 
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/538038ca-d6b9-4f9c-a69f-510284fc3ab8%40googlegroups.com.

[go-nuts] Re: causal profiling in Go

[Urjit Singh Bhatia]

Hi, 

I just ran coz on a project of mine a few days ago.
Building it properly was a little bit of trail and error to figure how out 
how get the build to play nice with the profiler but eventually I got it 
working.

For builds, use

go build -o  -ldflags=-compressdwarf=false

So that coz can read the debug symbols properly.

I made a small wrapper repo here: https://github.com/urjitbhatia/cozgo

In terms of actual profiler output, I got some useful info but it isn't 
something that regular profiling tools didn't tell me so far. (That I 
memory allocation is kinda slow for me right now).

[image: Screen Shot 2019-10-02 at 4.21.09 PM.png]
I think I need to run a longer, slightly more varied loadtest on the 
application to exercise more of the profiler.


On Tuesday, October 1, 2019 at 8:13:08 PM UTC-7, Gerald Stan wrote:
>
> Hi, interesting work. @Ingo is that the only way run casual profiling in 
> go?
>

-- 
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/e69eca97-0597-492a-ab36-6dc9b762b9e1%40googlegroups.com.

[go-nuts] Go Cloud Development Kit is looking for early adopters

[JuciÊ Andrade]

"Go CDK provides commonly used, vendor-neutral generic APIs that you can 
deploy across cloud providers. The idea is to support hybrid cloud 
deployments while combining on-prem (local) and cloud tools."

https://gocloud.dev/

-- 
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/7fa895f3-0b37-44ca-8e77-746b60a44d58%40googlegroups.com.

[go-nuts] Go WASM question

[Tad Vizbaras]

I have sizable Go WASM application that creates map[string]interface{} and 
passes to JS or reads from JS library.
Go maps do not have predefined key order. But JS has object property order 
predictable in JavaScript objects since ES2015.

Problem: when JS objects are transferred from JS into Go and back they key 
order becomes scrambled.
At this point I have a small fix inside JS application that simply reorders 
keys coming from Go back into JS.
A bit of a hack but works.

Question: is there better solution?

My environment:
1. Go 1.13.
2. Chrome and Edge browsers.
3. Windows 10 desktop 64bits.

-- 
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/39a710e3-4e77-475f-9d1c-37e4a22148c6%40googlegroups.com.

Re: [go-nuts] A confusion on the cgo document.

[T L]

Got it. Thanks, Ian.

On Mon, Sep 30, 2019 at 9:10 PM Ian Lance Taylor  wrote:

> On Mon, Sep 30, 2019 at 1:01 AM T L  wrote:
> >
> > https://golang.org/cmd/cgo/#hdr-Passing_pointers
> >
> > When passing a pointer to a field in a struct, the Go memory in question
> is the memory occupied by the field, not the entire struct. When passing a
> pointer to an element in an array or slice, the Go memory in question is
> the entire array or the entire backing array of the slice.
> >
> > Why do structs and arrays have this difference?
>
> Because it's normal to call a C function with ([0], len(a)) to let
> the C function examine all elements of the array or slice.  It's not
> normal to call a C function with () and expect the C function to
> examine all elements of the struct; if the C function wants to examine
> all elements of a struct, you would pass , not   But you don't
> want to pass  to a C function; with the way C pointers work, you
> want to pass a pointer to an element, not a pointer to the array or
> slice.  (Admittedly passing a pointer to an array would work anyhow,
> but passing a pointer to a slice would not.)
>
> Ian
>

-- 
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/CAHbs%3DNbw7Yyx%2BO6E6q8AfD6VMHO2RpXDd5%2B3-rJng8UsQ4POQw%40mail.gmail.com.

Re: [go-nuts] Re: Go policy does not fully support previous release

['Axel Wagner' via golang-nuts]

Hey,

just because you asked for community-input multiple times (and I don't want
to see claims again, that the Go team would ignore community input): I was
aware of this policy and I agree with it.

If nothing else, consider that as *users* of Go, we also benefit from this
policy. Because at the end of the day, you also have to decide how many Go
versions back you want to support for your software. The fact that there is
no LTS-version of Go or whatever and that you can pretty much assume "the
current version and maybe the last" to be stable, simplifies things for the
ecosystem at large.

Also, your arguments can just as well be made about the previous to last
version, or the one before that, or the one before that… ad infinitum.
Clearly it's unreasonable to expect changes to be backported to *all*
releases, so some cutoff has to be decided. Which is, all things
considered, still arbitrary.

On Wed, Oct 2, 2019 at 7:03 AM Christoph Berger <
christoph.g.ber...@gmail.com> wrote:

> A question based on genuine interest: Which factors make it hard for you
> to upgrade to the latest Go release?
>
>
> On Monday, September 30, 2019 at 9:49:39 PM UTC+2, Liam wrote:
>>
>> I was startled to learn that regressions found in the previous release
>> (currently 1.12.x) will not be fixed in that release. Regressions are only
>> fixed in the most recent release.
>>
>> If you wait until 1.12.5 to upgrade a deployment from 1.11.x, and then
>> discover a regression on the day 1.13 comes out, tough luck. Either upgrade
>> again to 1.13 or resort to a custom build.
>>
>> I filed a proposal to change this:
>> https://github.com/golang/go/issues/34622
>>
>> --
> 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/9964ea39-6978-4fb0-83bb-bd7cbd509ee7%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfEGpku5QJ5-3PG3f_B7vcKzROjfWhk2p%3Dxk%3DzJn0KYQxQ%40mail.gmail.com.

[go-nuts] Re: go binaries behaves differently on two identical linux servers

[Jason E. Aten]

Presumably you are running the exact same binary (compiled Go program) on 
both server-1 and server-2.

Hence the differences must be due to machine configuration.  Something 
outside of your Go code.

I suggest that you spin up a 3rd linode, clone it from master (or the 
working server) and install your config again, and try on this new machine.

-- 
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/341f813a-e57e-4d72-81e0-faa9ac5ecb54%40googlegroups.com.

[go-nuts] Re: go binaries behaves differently on two identical linux servers

[Jason E. Aten]

Presumably you are running the exact same binary (compiled Go program) on 
both server-1 and server-2.

Hence the differences must be due to machine configuration.  Something 
outside of your Go code.

I suggest that you ppin up a 3rd linode, clone it from master (or the 
working server) and install your config again, and try on this new machine.

-- 
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/6514b941-2601-4f00-b3df-224e58e5063d%40googlegroups.com.