Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com  
> wrote:
>
>> Why? That is an undocumented implementation detail. Furthermore, the 
>>> length of "x1" and "x2" at the time when they are appended to, in 
>>> combination with the value being appended, are reasonable predictors of the 
>>> capacity of the new slice. It is up to you to prove that a different 
>>> heuristic performs better. 
>>>
>>
>> Are there some evidences to prove the current algorithm is better?
>>
>
> It is your responsibility to show that a different heuristic (not 
> "algorithm"). is better. 
>

I have shown some examples above, which outputs will be more in line with 
exception
if the heuristic will only depends on the sum length of the two arguments.

Clarification: I don't think the exponential growth algorithm is bad.
I just think it should make the capacities increase monotonically.
 

>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/8892db72-1392-4ee3-b336-5c64c6ef7f1cn%40googlegroups.com.

[go-nuts] Re: Function to escape and unscape string

[tapi...@gmail.com]

This is a known problem: https://github.com/golang/go/issues/8618
I looks the root cause is reflect.TypeOf and ValueOf make the values 
referenced by the arguments escape, though often this is over-cautious.

On Sunday, August 29, 2021 at 3:02:42 PM UTC-4 nadashin wrote:

> fmt.Printf has a format specifier, %q that escapes string with Go
> syntax and add quotes around the string. ( %#v also does it)
>
> But it doesn't have one that unescapes a string.
>
> I couldn't find any stdlib function that escape and unescape a string
> following Go syntax. (and doesn't add quotes around the string)
>
>

-- 
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/0b860574-4075-43c1-a419-b1192ba4c3b0n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Kurtis Rader]

On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com 
wrote:

> Why? That is an undocumented implementation detail. Furthermore, the
>> length of "x1" and "x2" at the time when they are appended to, in
>> combination with the value being appended, are reasonable predictors of the
>> capacity of the new slice. It is up to you to prove that a different
>> heuristic performs better.
>>
>
> Are there some evidences to prove the current algorithm is better?
>

It is your responsibility to show that a different heuristic (not
"algorithm"). is better.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9gN5Qw%3D3txpcoBtsm565REmyOOSzLX3kiB-CAbpdoBgA%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Sunday, September 5, 2021 at 12:12:46 AM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 8:57 PM tapi...@gmail.com  
> wrote:
>
>> On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:
>>
>>> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com  
>>> wrote:
>>>
 The problem of the current algorithm is it is not monotonically 
 increasing:

>>>
>>> Please explain why that is a problem. Also, I think you are 
>>> misusing "monotonically increasing". The behavior up to length 1024 is not 
>>> "monotonically increasing". It is exponential growth.
>>>
>>
>> I mean the whole length range. Why would you seect [0, 1023]?
>> I never deny it is exponential growth.
>>
>
> Okay, I agree that technically your use of "monotonically increasing" does 
> not preclude exponential growth. However, your contrasting the behavior 
> around the pivot point of 1024 implies that exponential growth is excluded 
> since the growth is exponential on each side of the pivot point and you 
> stated it was "monotonically increasing" on one side but not the other. 
>

My opinions include:
1. there should not be a slip in the whole number range.
2. the increasing should totally depend on the sum length of the two 
arguments.
 

>  
>
>> x1 := make([]int, 897)
 x2 := make([]int, 1024)
 y := make([]int, 100)
 println(cap(append(x1, y...))) // 2048
 println(cap(append(x2, y...))) // 1280

 And it is not symmetrical:

>>>
>>> Again, please explain why this is a problem.
>>>
>>
>> When I merge two slices, I expect the argument orders are not important.
>>
>
> Why? That is an undocumented implementation detail. Furthermore, the 
> length of "x1" and "x2" at the time when they are appended to, in 
> combination with the value being appended, are reasonable predictors of the 
> capacity of the new slice. It is up to you to prove that a different 
> heuristic performs better. 
>

Are there some evidences to prove the current algorithm is better?
 

>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/1b4a000d-a71b-4d89-b509-9201b81ba547n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Sunday, September 5, 2021 at 12:16:48 AM UTC-4 kortschak wrote:

> This is what you're describing, right? 
> https://play.golang.org/p/RJbEkmFsPKM 
>
> The code that does this is here 
>
> https://github.com/golang/go/blob/9133245be7365c23fcd60e3bb60ebb614970cdab/src/runtime/slice.go#L183-L242
>  
> . Note that there are cap adjustments to optimise block sizes and 
> alignments. This explains why we see what we do. 
>

Yes, this is the current algorithm. I don't think aligning to a nearby 
memory block size is a problem.
Personally, I think the slice grow algorithm should not depend on slice 
capacities.
 

>
> On Sat, 2021-09-04 at 20:57 -0700, tapi...@gmail.com wrote: 
> > 
> > 
> > On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader 
> > wrote: 
> > > On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com  > > > wrote: 
> > > > The problem of the current algorithm is it is not monotonically 
> > > > increasing: 
> > > > 
> > > 
> > > Please explain why that is a problem. Also, I think you are 
> > > misusing "monotonically increasing". The behavior up to length 1024 
> > > is not "monotonically increasing". It is exponential growth. 
> > > 
> > 
> > I mean the whole length range. Why would you seect [0, 1023]? 
> > I never deny it is exponential growth. 
> > 
> > > 
> > > > x1 := make([]int, 897) 
> > > > x2 := make([]int, 1024) 
> > > > y := make([]int, 100) 
> > > > println(cap(append(x1, y...))) // 2048 
> > > > println(cap(append(x2, y...))) // 1280 
> > > > 
> > > > And it is not symmetrical: 
> > > > 
> > > 
> > > Again, please explain why this is a problem. 
> > > 
> > 
> > When I merge two slices, I expect the argument orders are not 
> > important. 
> > 
> > > 
> > > > x := make([]int, 98) 
> > > > y := make([]int, 666) 
> > > > println(cap(append(x, y...))) // 768 
> > > > println(cap(append(y, x...))) // 1360 
> > > > 
> > > > And it depends on the capacity of the first argument, 
> > > > which is some logical but often not for many cases: 
> > > > 
> > > > x := make([]byte, 100, 500) 
> > > > y := make([]byte, 500) 
> > > > println(cap(append(x, y...))) // 1024 
> > > > println(cap(append(x[:len(x):len(x)], y...))) // 640 
> > > > 
> > > > On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote: 
> > > > > Hey Guys, 
> > > > > 
> > > > > We know slices grow by doubling until size 1024, the capacity 
> > > > > will grow at 25%. The question that I had was why after 1024 
> > > > > elements? Why didn't the developers chose another number like 
> > > > > 2048 or other numbers? 
> > > > > 
> > > > > Thanks, 
> > > > > Milad 
> > > > -- 
> > > > 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/45753fb8-429b-4407-9728-411b75a98484n%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/ca26dfa4-03d0-425f-a6b4-2b80e5f7e65an%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

['Dan Kortschak' via golang-nuts]

This is what you're describing, right?
https://play.golang.org/p/RJbEkmFsPKM

The code that does this is here
https://github.com/golang/go/blob/9133245be7365c23fcd60e3bb60ebb614970cdab/src/runtime/slice.go#L183-L242
. Note that there are cap adjustments to optimise block sizes and
alignments. This explains why we see what we do.

On Sat, 2021-09-04 at 20:57 -0700, tapi...@gmail.com wrote:
>
>
> On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader
> wrote:
> > On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com  > > wrote:
> > > The problem of the current algorithm is it is not monotonically
> > > increasing:
> > >
> >
> > Please explain why that is a problem. Also, I think you are
> > misusing "monotonically increasing". The behavior up to length 1024
> > is not "monotonically increasing". It is exponential growth.
> >
>
> I mean the whole length range. Why would you seect [0, 1023]?
> I never deny it is exponential growth.
>
> >
> > > x1 := make([]int, 897)
> > > x2 := make([]int, 1024)
> > > y := make([]int, 100)
> > > println(cap(append(x1, y...))) // 2048
> > > println(cap(append(x2, y...))) // 1280
> > >
> > > And it is not symmetrical:
> > >
> >
> > Again, please explain why this is a problem.
> >
>
> When I merge two slices, I expect the argument orders are not
> important.
>
> >
> > > x := make([]int, 98)
> > > y := make([]int, 666)
> > > println(cap(append(x, y...))) // 768
> > > println(cap(append(y, x...))) // 1360
> > >
> > > And it depends on the capacity of the first argument,
> > > which is some logical but often not for many cases:
> > >
> > > x := make([]byte, 100, 500)
> > > y := make([]byte, 500)
> > > println(cap(append(x, y...))) // 1024
> > > println(cap(append(x[:len(x):len(x)], y...))) // 640
> > >
> > > On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote:
> > > > Hey Guys,
> > > >
> > > > We know slices grow by doubling until size 1024, the capacity
> > > > will grow at 25%. The question that I had was why after 1024
> > > > elements? Why didn't the developers chose another number like
> > > > 2048 or other numbers?
> > > >
> > > > Thanks,
> > > > Milad
> > > --
> > > 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/45753fb8-429b-4407-9728-411b75a98484n%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/10393e5ca795593dece41075042ae0f3b7c6863a.camel%40kortschak.io.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Kurtis Rader]

On Sat, Sep 4, 2021 at 8:57 PM tapi...@gmail.com 
wrote:

> On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:
>
>> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com 
>> wrote:
>>
>>> The problem of the current algorithm is it is not monotonically
>>> increasing:
>>>
>>
>> Please explain why that is a problem. Also, I think you are
>> misusing "monotonically increasing". The behavior up to length 1024 is not
>> "monotonically increasing". It is exponential growth.
>>
>
> I mean the whole length range. Why would you seect [0, 1023]?
> I never deny it is exponential growth.
>

Okay, I agree that technically your use of "monotonically increasing" does
not preclude exponential growth. However, your contrasting the behavior
around the pivot point of 1024 implies that exponential growth is excluded
since the growth is exponential on each side of the pivot point and you
stated it was "monotonically increasing" on one side but not the other.


> x1 := make([]int, 897)
>>> x2 := make([]int, 1024)
>>> y := make([]int, 100)
>>> println(cap(append(x1, y...))) // 2048
>>> println(cap(append(x2, y...))) // 1280
>>>
>>> And it is not symmetrical:
>>>
>>
>> Again, please explain why this is a problem.
>>
>
> When I merge two slices, I expect the argument orders are not important.
>

Why? That is an undocumented implementation detail. Furthermore, the length
of "x1" and "x2" at the time when they are appended to, in combination with
the value being appended, are reasonable predictors of the capacity of the
new slice. It is up to you to prove that a different heuristic performs
better.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-_ytZbLZzSMHTro7ej%2BE4UKk7e%2BCep4Z24W5Myf47iZA%40mail.gmail.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com  
> wrote:
>
>> The problem of the current algorithm is it is not monotonically 
>> increasing:
>>
>
> Please explain why that is a problem. Also, I think you are 
> misusing "monotonically increasing". The behavior up to length 1024 is not 
> "monotonically increasing". It is exponential growth.
>

I mean the whole length range. Why would you seect [0, 1023]?
I never deny it is exponential growth.
 

>  
>
>> x1 := make([]int, 897)
>> x2 := make([]int, 1024)
>> y := make([]int, 100)
>> println(cap(append(x1, y...))) // 2048
>> println(cap(append(x2, y...))) // 1280
>>
>> And it is not symmetrical:
>>
>
> Again, please explain why this is a problem.
>

When I merge two slices, I expect the argument orders are not important.
 

>  
>
>> x := make([]int, 98)
>> y := make([]int, 666)
>> println(cap(append(x, y...))) // 768
>> println(cap(append(y, x...))) // 1360
>>
>> And it depends on the capacity of the first argument,
>> which is some logical but often not for many cases:
>>
>> x := make([]byte, 100, 500)
>> y := make([]byte, 500)
>> println(cap(append(x, y...))) // 1024
>> println(cap(append(x[:len(x):len(x)], y...))) // 640
>>
>> On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote:
>>
>>> Hey Guys,
>>>
>>> We know slices grow by doubling until size 1024, the capacity will grow 
>>> at 25%. The question that I had was why after 1024 elements? Why didn't the 
>>> developers chose another number like 2048 or other numbers?
>>>
>>> Thanks,
>>> Milad
>>>
>> -- 
>>
> 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/45753fb8-429b-4407-9728-411b75a98484n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/529b4ee9-14a8-4145-853d-1ebdb9e9fa67n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[Kurtis Rader]

On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com 
wrote:

> The problem of the current algorithm is it is not monotonically increasing:
>

Please explain why that is a problem. Also, I think you are
misusing "monotonically increasing". The behavior up to length 1024 is not
"monotonically increasing". It is exponential growth.


> x1 := make([]int, 897)
> x2 := make([]int, 1024)
> y := make([]int, 100)
> println(cap(append(x1, y...))) // 2048
> println(cap(append(x2, y...))) // 1280
>
> And it is not symmetrical:
>

Again, please explain why this is a problem.


> x := make([]int, 98)
> y := make([]int, 666)
> println(cap(append(x, y...))) // 768
> println(cap(append(y, x...))) // 1360
>
> And it depends on the capacity of the first argument,
> which is some logical but often not for many cases:
>
> x := make([]byte, 100, 500)
> y := make([]byte, 500)
> println(cap(append(x, y...))) // 1024
> println(cap(append(x[:len(x):len(x)], y...))) // 640
>
> On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote:
>
>> Hey Guys,
>>
>> We know slices grow by doubling until size 1024, the capacity will grow
>> at 25%. The question that I had was why after 1024 elements? Why didn't the
>> developers chose another number like 2048 or other numbers?
>>
>> Thanks,
>> Milad
>>
> --
> 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/45753fb8-429b-4407-9728-411b75a98484n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9yaLXYL66HGYgYupnk4a%2BUQGpT-9srGUKoGxhHT%2Bk7kQ%40mail.gmail.com.

[go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[tapi...@gmail.com]

The problem of the current algorithm is it is not monotonically increasing:

x1 := make([]int, 897)
x2 := make([]int, 1024)
y := make([]int, 100)
println(cap(append(x1, y...))) // 2048
println(cap(append(x2, y...))) // 1280

And it is not symmetrical:

x := make([]int, 98)
y := make([]int, 666)
println(cap(append(x, y...))) // 768
println(cap(append(y, x...))) // 1360

And it depends on the capacity of the first argument,
which is some logical but often not for many cases:

x := make([]byte, 100, 500)
y := make([]byte, 500)
println(cap(append(x, y...))) // 1024
println(cap(append(x[:len(x):len(x)], y...))) // 640

On Saturday, September 4, 2021 at 1:14:30 PM UTC-4 Miraddo wrote:

> Hey Guys,
>
> We know slices grow by doubling until size 1024, the capacity will grow at 
> 25%. The question that I had was why after 1024 elements? Why didn't the 
> developers chose another number like 2048 or other numbers?
>
> Thanks,
> Milad
>

-- 
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/45753fb8-429b-4407-9728-411b75a98484n%40googlegroups.com.

Re: [go-nuts] GNU getopt-style Go packages?

[ori]

Quoth jlfo...@berkeley.edu :
> Some of these don't look active, and I'm sure I've missed some.

What kind of activity are you expecting? Are you
seeing unaddressed bugs?

Command line parsing isn't hard, and it's possible
the packages are just finished.

> Any comments on any of the above? What have you used for command line 
> parsing in the past, and what would you use in the future?

I just use the flags package; I don't love it, but
I also don't feel a need to pull in an additional
dependency for flag parsing.

-- 
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/26014B343FB88F7233B4C5D35A4FA9FF%40eigenstate.org.

Re: [go-nuts] GNU getopt-style Go packages?

[Javier Ruano]

Dese Jon
I have seen this one too

https://github.com/avelino/awesome-go#command-line

Searching like argsparse
Regards
Javier Ruano


El sáb., 4 sept. 2021 20:48, jlfo...@berkeley.edu 
escribió:

> I'm wondering what the current state of GNU getopt-style Go packages is.
> I've done some research and found the following:
>
> DavidGamba / go-getoptions
> alecthomas / kong
> elegos / flags
> jessevdk / go-flags
> pborman / getopt
> pborman / options
> skeeto / optparse-go
> spf13 / cobra
> subchen / go-cli
> tcler / cmdline-go
> urfave / cli
> vma / getopt
>
> Some of these don't look active, and I'm sure I've missed some.
>
> Any comments on any of the above? What have you used for command line
> parsing in the past, and what would you use in the future?
>
> Cordially,
> Jon Forrest
> UC Berkeley (ret.)
>
> --
> 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/8dd1a249-68c3-466f-a571-46b7df3b1c97n%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/CAFiaYrN__PpiuOUHzhFQRAooCK3nEsGxyEeVCTV9i6Fiv-S8bQ%40mail.gmail.com.

Re: [go-nuts] Two consecutive reads from a buffered channel results in deadlock

[Michael Dwyer]

Kurtis, thank you for your explanation and for the links, providing more 
detailed information on the subject matter.
This was what I was looking for, a reasoned explanation and documentation 
that would explain why this condition occurred.

Always good when there are those willing to provide helpful hints and 
documentation, so others can learn.

Greatly appreciate your time an assistance.


THANX(MKD).

On Saturday, September 4, 2021 at 9:31:32 PM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 5:55 PM Michael Dwyer  wrote:
>
>> I encountered a deadlock when reading from a buffered channel.
>> The deadlock occurs when an attempt is made to read from the channel 
>> twice, without an intermediate write to the channel.
>>
>
> That is not a deadlock. Reading from a buffered channel blocks when the 
> channel is empty. From https://golang.org/ref/spec#Channel_types:
>  
>
> Otherwise, the channel is buffered and communication succeeds without 
> blocking if the buffer is not full (sends) or not empty (receives). A nil 
> channel 
> is never ready for communication.
> You can use the "select" operator (
> https://golang.org/ref/spec#Select_statements) to detect if the channel 
> is empty.
>  
>
>> The problematic code is as follows:
>>
>> func main() {
>> myInt  := 432
>>
>> readerChan := make(chan int, 3)
>>
>> for forI := 0; forI <= 1; forI++ {
>> readerChan <- myInt
>> fmt.Printf("%d:", <- readerChan)
>> fmt.Printf("%d:", <- readerChan)
>> }
>>
>> close(readerChan)
>> }
>>
>> The first read from variable readerChan succeeds.
>> The second read from variable readerChan results in a deadlock.
>>
>> I have two links to playground.
>> The first link is the problematic code.
>> The second link is for similar code that has an intervening write to the 
>> channel.
>>
>> I understand that a buffered channel allows a queue of results to be 
>> stored from other Go routines writing to the channel.
>> But, the code is attempting multiple read operations.
>>
>> Looking for a technical explanation to help me better understand this 
>> particular case.
>> Thanks in advance ...
>>
>>
>> The problematic playground link : https://play.golang.org/p/veo7phAZzMv
>> The working playground link : https://play.golang.org/p/qvYZNN9keqN
>>
>>
>> THANX(MKD).
>>
>> -- 
>> 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/44057a7a-b0aa-4ea1-9fb3-39836cd5713dn%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/7b41546f-f4cd-4c73-90bc-ee86775431fan%40googlegroups.com.

Re: [go-nuts] Two consecutive reads from a buffered channel results in deadlock

['Dan Kortschak' via golang-nuts]

What would you expect to happen here? A chan that has had one item sent
and then one item received has no items on it, so a receive must wait
until another item is sent.

On Sat, 2021-09-04 at 17:55 -0700, Michael Dwyer wrote:
> I encountered a deadlock when reading from a buffered channel.
> The deadlock occurs when an attempt is made to read from the channel
> twice, without an intermediate write to the channel.
>
> The problematic code is as follows:
>
> func main() {
>   myInt  := 432
>
>   readerChan := make(chan int, 3)
>
>   for forI := 0; forI <= 1; forI++ {
>   readerChan <- myInt
>   fmt.Printf("%d:", <- readerChan)
>   fmt.Printf("%d:", <- readerChan)
>   }
>
>   close(readerChan)
> }
>
> The first read from variable readerChan succeeds.
> The second read from variable readerChan results in a deadlock.
>
> I have two links to playground.
> The first link is the problematic code.
> The second link is for similar code that has an intervening write to
> the channel.
>
> I understand that a buffered channel allows a queue of results to be
> stored from other Go routines writing to the channel.
> But, the code is attempting multiple read operations.
>
> Looking for a technical explanation to help me better understand this
> particular case.
> Thanks in advance ...
>
>
> The problematic playground link :
> https://play.golang.org/p/veo7phAZzMv
> The working playground link :
> https://play.golang.org/p/qvYZNN9keqN
>
>
> THANX(MKD).


-- 
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/a7c8565153debfbfae94ca44ffcba6eabec73f9b.camel%40kortschak.io.

[go-nuts] Two consecutive reads from a buffered channel results in deadlock

[Michael Dwyer]

I encountered a deadlock when reading from a buffered channel.
The deadlock occurs when an attempt is made to read from the channel twice, 
without an intermediate write to the channel.

The problematic code is as follows:

func main() {
myInt  := 432

readerChan := make(chan int, 3)

for forI := 0; forI <= 1; forI++ {
readerChan <- myInt
fmt.Printf("%d:", <- readerChan)
fmt.Printf("%d:", <- readerChan)
}

close(readerChan)
}

The first read from variable readerChan succeeds.
The second read from variable readerChan results in a deadlock.

I have two links to playground.
The first link is the problematic code.
The second link is for similar code that has an intervening write to the 
channel.

I understand that a buffered channel allows a queue of results to be stored 
from other Go routines writing to the channel.
But, the code is attempting multiple read operations.

Looking for a technical explanation to help me better understand this 
particular case.
Thanks in advance ...


The problematic playground link : https://play.golang.org/p/veo7phAZzMv
The working playground link : https://play.golang.org/p/qvYZNN9keqN


THANX(MKD).

-- 
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/44057a7a-b0aa-4ea1-9fb3-39836cd5713dn%40googlegroups.com.

Re: [go-nuts] slices grow at 25% after 1024 but why 1024?

[Rob Pike]

What would you pick? You need to pick something.

It was just arbitrary, I'm sure. 1024 is a nice number, and it's larger
than the length of many slices.

Sometimes a number is just a number.

-rob


On Sun, Sep 5, 2021 at 3:14 AM Miraddo  wrote:

> Hey Guys,
>
> We know slices grow by doubling until size 1024, the capacity will grow at
> 25%. The question that I had was why after 1024 elements? Why didn't the
> developers chose another number like 2048 or other numbers?
>
> Thanks,
> Milad
>
> --
> 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/21a5a2b5-2eaf-45d6-a538-5a882fafd0a6n%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/CAOXNBZQZRKOrxPKve5eNsQGS3X-fyBGmNFy8aqe4HcVL3nUeMQ%40mail.gmail.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Brian Candler]

Ah, I missed the bit where it says "Flag syntax is xyz (set) 
or -xyz (clear) or xy-z (set xy, clear z)."  You're quite right, there's a 
much simpler way:
https://play.golang.org/p/upupUQUcsR8

On Saturday, 4 September 2021 at 20:51:53 UTC+1 kziem...@gmail.com wrote:

> Thank you for your answer and opinion Briana Candler.
>
> I ask about unset only because of the cryptic text, at least to me, in the 
> description of RE2 (https://github.com/google/re2/wiki/Syntax). From 
> practical point of view, your solutions look good.
>
> I try to google about changes in examples in Go's stdlib, maybe this can 
> be done?
>
> Best
> Kamil
>
> pt., 3 wrz 2021 o 21:42 Brian Candler  napisał(a):
>
>> I believe (?m) applies to the current group only; if you want to "unset" 
>> it then start a separate group.
>> https://play.golang.org/p/wT_ZTrUSABL
>>
>> And I think you're right, there's no need to have capture groups for 
>> FindIndex.
>>
>> On Friday, 3 September 2021 at 20:33:14 UTC+1 kziem...@gmail.com wrote:
>>
>>> Hello,
>>>
>>> My struggles with regexp is going and I have another problem. I read 
>>> closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax) 
>>> and I still not sure if I understand one example from regexp package.
>>>
>>> In example in method func (*Regexp) FindIndex (
>>> https://pkg.go.dev/reg...@go1.17#Regexp.FindIndex 
>>> ) we have line
>>>
>>> pattern := regexp.MustCompile(`(?m)(?P\w+):\s+(?P\w+)$`)
>>>
>>> Does (?m) set value of flag m to true and if I want set it to false I 
>>> should write (?-m) or not? By default m should be false, but as example it 
>>> is fine.
>>>
>>> As a side note, this regular expression is used in other examples, when 
>>> we need  and , but looks unnecessary complex for method 
>>> FindIndex. I guess
>>> `(?m)\w+:\s+\w+$`
>>> would work fine. Am I wrong?
>>>
>>> Best
>>> Kamil
>>>
>>> środa, 1 września 2021 o 12:29:58 UTC+2 Kamil Ziemian napisał(a):
>>>
 Kurtis Rader, peterGo thank you for the answers. I probably need to 
 learn more about RPC protocols, for now I can only expand acronym. But 
 this 
 point with ignoring leading zeros is clear enough. And probalby more 
 "elementary (and stupid)?" questions is comming.

 Kamil
 poniedziałek, 30 sierpnia 2021 o 03:02:51 UTC+2 peterGo napisał(a):

>
>
> K,
>
> For a finite, unsigned binary number, ignoring leading zeros, how many 
> binary digits (the length in bits) are needed to represent a number?
>
> Peter
> On Sunday, August 29, 2021 at 4:07:41 PM UTC-4 kziem...@gmail.com 
> wrote:
>
>> Thank for explanation, but I don't understand "But how many bits do 
>> you need to represent 0? The question is malformed as there are no set 
>> bits 
>> in the used representation of 0.". Why this is malformed questions? When 
>> I 
>> think of coding 1, I think about thaking one bit with 1 inside and when 
>> it 
>> goes to 0, I would take one bit with 0 inside.
>>
>> K.
>> piątek, 27 sierpnia 2021 o 07:14:45 UTC+2 Volker Dobler napisał(a):
>>
>>> On Thursday, 26 August 2021 at 22:17:55 UTC+2 kziem...@gmail.com 
>>> wrote:
>>>
 Another topic. I needed to check package "math/bits" (learning 
 about Go can lead us in such places quite fast) and I'm confused about 
 function "Len(x uint) int". In its description we have (
 https://pkg.go.dev/math/bi...@go1.17 
 )
 BEGINNING
 Len returns the minimum number of bits required to represent x; the 
 result is 0 for x == 0.
 END
 I have no problem with using function that says 0 can be encoded in 
 0 bits, but it is still odd. Maybe it is connected to something done 
 under 
 the hood, about which I don't know a thing? Does anyone know why this 
 choose was made?
>>>
>>>  
>>> No, the description doesn't say that 0 can be encoded in 0 bits:
>>> It says that Len(0) returns 0.
>>> If you want Len to be a total function you must return a value for 
>>> every input.
>>> For most inputs the value is strictly determined by what the 
>>> functions does
>>> (number of bits needed to represent), so Len(9) == 3. But how many 
>>> bits
>>> do you need to represent 0? The question is malformed as there are 
>>> no 
>>> set bits in the used representation of 0. One could have declared
>>> "Len(0) returns -42"
>>> but this makes no sense at all. Having Len(0)==0 results in
>>> Len(a) <= Len(b) if a < b without having to invent totally arbitrary
>>> values for Len(0).
>>>
>>> You probably should not overinterpret Go's documentation.
>>> This is not lyric. "the result is 0 for x == 0" has no hidden 
>>> meaning.
>>>
>>> V.
>>>
>> -- 
>> You 

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

Thank you for your answer and opinion Briana Candler.

I ask about unset only because of the cryptic text, at least to me, in the
description of RE2 (https://github.com/google/re2/wiki/Syntax). From
practical point of view, your solutions look good.

I try to google about changes in examples in Go's stdlib, maybe this can be
done?

Best
Kamil

pt., 3 wrz 2021 o 21:42 Brian Candler  napisał(a):

> I believe (?m) applies to the current group only; if you want to "unset"
> it then start a separate group.
> https://play.golang.org/p/wT_ZTrUSABL
>
> And I think you're right, there's no need to have capture groups for
> FindIndex.
>
> On Friday, 3 September 2021 at 20:33:14 UTC+1 kziem...@gmail.com wrote:
>
>> Hello,
>>
>> My struggles with regexp is going and I have another problem. I read
>> closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax)
>> and I still not sure if I understand one example from regexp package.
>>
>> In example in method func (*Regexp) FindIndex (
>> https://pkg.go.dev/reg...@go1.17#Regexp.FindIndex
>> ) we have line
>>
>> pattern := regexp.MustCompile(`(?m)(?P\w+):\s+(?P\w+)$`)
>>
>> Does (?m) set value of flag m to true and if I want set it to false I
>> should write (?-m) or not? By default m should be false, but as example it
>> is fine.
>>
>> As a side note, this regular expression is used in other examples, when
>> we need  and , but looks unnecessary complex for method
>> FindIndex. I guess
>> `(?m)\w+:\s+\w+$`
>> would work fine. Am I wrong?
>>
>> Best
>> Kamil
>>
>> środa, 1 września 2021 o 12:29:58 UTC+2 Kamil Ziemian napisał(a):
>>
>>> Kurtis Rader, peterGo thank you for the answers. I probably need to
>>> learn more about RPC protocols, for now I can only expand acronym. But this
>>> point with ignoring leading zeros is clear enough. And probalby more
>>> "elementary (and stupid)?" questions is comming.
>>>
>>> Kamil
>>> poniedziałek, 30 sierpnia 2021 o 03:02:51 UTC+2 peterGo napisał(a):
>>>


 K,

 For a finite, unsigned binary number, ignoring leading zeros, how many
 binary digits (the length in bits) are needed to represent a number?

 Peter
 On Sunday, August 29, 2021 at 4:07:41 PM UTC-4 kziem...@gmail.com
 wrote:

> Thank for explanation, but I don't understand "But how many bits do
> you need to represent 0? The question is malformed as there are no set 
> bits
> in the used representation of 0.". Why this is malformed questions? When I
> think of coding 1, I think about thaking one bit with 1 inside and when it
> goes to 0, I would take one bit with 0 inside.
>
> K.
> piątek, 27 sierpnia 2021 o 07:14:45 UTC+2 Volker Dobler napisał(a):
>
>> On Thursday, 26 August 2021 at 22:17:55 UTC+2 kziem...@gmail.com
>> wrote:
>>
>>> Another topic. I needed to check package "math/bits" (learning about
>>> Go can lead us in such places quite fast) and I'm confused about 
>>> function
>>> "Len(x uint) int". In its description we have (
>>> https://pkg.go.dev/math/bi...@go1.17
>>> )
>>> BEGINNING
>>> Len returns the minimum number of bits required to represent x; the
>>> result is 0 for x == 0.
>>> END
>>> I have no problem with using function that says 0 can be encoded in
>>> 0 bits, but it is still odd. Maybe it is connected to something done 
>>> under
>>> the hood, about which I don't know a thing? Does anyone know why this
>>> choose was made?
>>
>>
>> No, the description doesn't say that 0 can be encoded in 0 bits:
>> It says that Len(0) returns 0.
>> If you want Len to be a total function you must return a value for
>> every input.
>> For most inputs the value is strictly determined by what the
>> functions does
>> (number of bits needed to represent), so Len(9) == 3. But how many
>> bits
>> do you need to represent 0? The question is malformed as there are no
>> set bits in the used representation of 0. One could have declared
>> "Len(0) returns -42"
>> but this makes no sense at all. Having Len(0)==0 results in
>> Len(a) <= Len(b) if a < b without having to invent totally arbitrary
>> values for Len(0).
>>
>> You probably should not overinterpret Go's documentation.
>> This is not lyric. "the result is 0 for x == 0" has no hidden meaning.
>>
>> V.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/RPPfjiuSRHU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

[go-nuts] GNU getopt-style Go packages?

[jlfo...@berkeley.edu]

I'm wondering what the current state of GNU getopt-style Go packages is. 
I've done some research and found the following:

DavidGamba / go-getoptions
alecthomas / kong
elegos / flags
jessevdk / go-flags
pborman / getopt
pborman / options
skeeto / optparse-go
spf13 / cobra
subchen / go-cli
tcler / cmdline-go
urfave / cli
vma / getopt

Some of these don't look active, and I'm sure I've missed some.

Any comments on any of the above? What have you used for command line 
parsing in the past, and what would you use in the future?

Cordially,
Jon Forrest
UC Berkeley (ret.)

-- 
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/8dd1a249-68c3-466f-a571-46b7df3b1c97n%40googlegroups.com.

[go-nuts] slices grow at 25% after 1024 but why 1024?

[Miraddo]

Hey Guys,

We know slices grow by doubling until size 1024, the capacity will grow at 
25%. The question that I had was why after 1024 elements? Why didn't the 
developers chose another number like 2048 or other numbers?

Thanks,
Milad

-- 
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/21a5a2b5-2eaf-45d6-a538-5a882fafd0a6n%40googlegroups.com.

Re: [go-nuts] pkg.go.dev: navigation index is confusing

[Wojciech S. Czarnecki]

Dnia 2021-09-03, o godz. 17:45:27
Markus Heukelom  napisał(a):

> > @Markus: I normally use browser's search function to get to the function
> > and it works well with pkg.go.dev too.

> If you vaguely remember a function name, for example "TrimPrefix" (note:
> it's actually "StripPrefix"), search obviously doesn't work.

It works, highlighting proper places. 57 of them. Just scroll and note 
highlights.

If you do want really concise form to skim the `go doc` tool output is way to 
go.
Just grep for a few letters for the hints:

`go doc net/http | grep -i pref`
 const TrailerPrefix = "Trailer:"
func StripPrefix(prefix string, h Handler) Handler

`go doc net/http | grep -i pars`
func ParseHTTPVersion(vers string) (major, minor int, ok bool)
func ParseTime(text string) (t time.Time, err error)

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20210904142439.7aff3d84%40xmint.

Re: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

I was hoping it was the rendering code that was the problem but I'm almost 
100% certain that it isn't. If I just allow the emulation to run without 
drawing anything to the HTML canvas (and just writing a frame count to the 
console) the performance is still the same.

Good tip about Ebiten though. I don't think it'll help with my immediate 
problem but it shouldn't be too difficult to add it as an alternative 
presentation method. The main reason I opted for SDL was because I was 
familiar with it. Ebiten might be a good alternative.
On Saturday, 4 September 2021 at 11:34:08 UTC+1 arn...@gmail.com wrote:

> Hi Stephen,
>
> I haven't really looked at your code in detail but one obvious
> difference between your version and the original is the rendering
> code. Are you certain that the slowness is not confined to your
> rendering code (I have no reason to believe it is btw)?
>
> Here is a suggestion. I have had a good experience using a 2d library
> called ebiten (https://github.com/hajimehoshi/ebiten). It abstracts
> the rendering and can target native or browsers via wasm. In my
> experience performance when targeting the browser has been acceptable,
> so you could write an implementation of television.PixelRenderer
> backed by ebiten. You could then compile both to native and wasm and
> see if there is still a big performance difference?
>
> HTH
>
> Arnaud
>
> On Sat, 4 Sept 2021 at 11:12, Stephen Illingworth
>  wrote:
> >
> > I don't think I'm going to be able to make any progress with this. I 
> chopped away enough code so that it compiles with TinyGo. It works but it's 
> even slower.
> >
> > I was hoping to find a way of profiling the WASM code but I see DWARF 
> support for WASM binaries is still a work in progress. 
> https://github.com/golang/go/issues/33503 I don't know enough about WASM 
> to be able to contribute to that issue unfortunately.
> >
> > Thanks to anyone who looked at this.
> > On Friday, 3 September 2021 at 11:20:26 UTC+1 stephen.t@gmail.com 
> wrote:
> >>
> >> To follow up on this I should clarify what my questions are:
> >>
> >> 1) How much of a performance drop (when compared to AMD64 for example) 
> should I expect when compiling to the WASM target?
> >>
> >> 2) Is there anything obvious I can do to counter any performance drops?
> >>
> >> And I suppose this is a non-Go question, but:
> >>
> >> 3) I know nothing about WASM beyond the bare minimum. How can I profile 
> and understand the compiled WASM binary? Is it possible to use the pprof 
> tool in some way?
> >>
> >>
> >> On Fri, Sep 3, 2021 at 10:40 AM Stephen Illingworth <
> stephen.t@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Sep 3, 2021 at 10:15 AM Brian Candler  
> wrote:
> 
>  Could you explain a bit more about what you're comparing?
> 
>  - Is the wasm version running in a browser? If so, which one? Or have 
> you got a way to run wasm directly on the host (in which case, what is it)?
> >>>
> >>>
> >>> Running it in Firefox (78.13.0esr) and Chromium (92.0.4515.159)
> >>>
> 
>  - How is the linux/amd64 version running, if it's not talking to a 
> DOM-type environment? If the native version is still using syscall/js, then 
> how is it doing so? Or is the native version in a different repo?
> 
>  - By "the parent emulator project" do you just mean web2600 itself?
> >>>
> >>>
> >>> Web2600 is using the emulation core of the parent project
> >>>
> >>> https://github.com/JetSetIlly/Gopher2600
> >>>
> >>> The parent project runs on the desktop. It currently uses SDL and 
> OpenGL etc. but it is designed to allow different methods of presentation.
> >>>
> >>> Web2600 is using the core of the emulator (ie. the non-presentation 
> parts) and so doesn't use SDL or OpenGL.
> >>>
> >>> For presentation, the television package in the core emulation allows 
> you to register "PixelRenderers". So Web2600 adds itself as a pixel 
> renderer. The implemented SetPixels(), NewFrame() (etc.) functions will 
> then talk to the DOM as appropriate.
> >>>
> >>> The web version works but is just exceedingly slow by comparison.
> >>>
> >>>
> > --
> > 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/6bb486eb-7481-4356-94cd-29c365c02416n%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/57e25373-2219-4d04-b45d-d8f24501b8c7n%40googlegroups.com.

Fwd: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

I was hoping it was the rendering code that was the problem but I'm almost
100% certain that it isn't. If I just allow the emulation to run without
drawing anything to the HTML canvas (and just writing a frame count to the
console) the performance is still the same.

Good tip about Ebiten though. I don't think it'll help with my immediate
problem but it shouldn't be too difficult to add it as an alternative
presentation method. The main reason I opted for SDL was because I was
familiar with it. Ebiten might be a good alternative.


On Sat, Sep 4, 2021 at 11:34 AM Arnaud Delobelle  wrote:

> Hi Stephen,
>
> I haven't really looked at your code in detail but one obvious
> difference between your version and the original is the rendering
> code.  Are you certain that the slowness is not confined to your
> rendering code (I have no reason to believe it is btw)?
>
> Here is a suggestion.  I have had a good experience using a 2d library
> called ebiten (https://github.com/hajimehoshi/ebiten).  It abstracts
> the rendering and can target native or browsers via wasm.  In my
> experience performance when targeting the browser has been acceptable,
> so you could write an implementation of television.PixelRenderer
> backed by ebiten.  You could then compile both to native and wasm and
> see if there is still a big performance difference?
>
> HTH
>
> Arnaud
>
>

-- 
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/CAPmHGLNpp_g8L0BbpniA1Lghxv1N6F5d5MXtW9sKrm8Q4MQ6sw%40mail.gmail.com.

Re: [go-nuts] Re: WASM Performance

[Arnaud Delobelle]

Hi Stephen,

I haven't really looked at your code in detail but one obvious
difference between your version and the original is the rendering
code.  Are you certain that the slowness is not confined to your
rendering code (I have no reason to believe it is btw)?

Here is a suggestion.  I have had a good experience using a 2d library
called ebiten (https://github.com/hajimehoshi/ebiten).  It abstracts
the rendering and can target native or browsers via wasm.  In my
experience performance when targeting the browser has been acceptable,
so you could write an implementation of television.PixelRenderer
backed by ebiten.  You could then compile both to native and wasm and
see if there is still a big performance difference?

HTH

Arnaud

On Sat, 4 Sept 2021 at 11:12, Stephen Illingworth
 wrote:
>
> I don't think I'm going to be able to make any progress with this. I chopped 
> away enough code so that it compiles with TinyGo. It works but it's even 
> slower.
>
> I was hoping to find a way of profiling the WASM code but I see DWARF support 
> for WASM binaries is still a work in progress. 
> https://github.com/golang/go/issues/33503 I don't know enough about WASM to 
> be able to contribute to that issue unfortunately.
>
> Thanks to anyone who looked at this.
> On Friday, 3 September 2021 at 11:20:26 UTC+1 stephen.t@gmail.com wrote:
>>
>> To follow up on this I should clarify what my questions are:
>>
>> 1) How much of a performance drop (when compared to AMD64 for example) 
>> should I expect when compiling to the WASM target?
>>
>> 2) Is there anything obvious I can do to counter any performance drops?
>>
>> And I suppose this is a non-Go question, but:
>>
>> 3) I know nothing about WASM beyond the bare minimum. How can I profile and 
>> understand the compiled WASM binary? Is it possible to use the pprof tool in 
>> some way?
>>
>>
>> On Fri, Sep 3, 2021 at 10:40 AM Stephen Illingworth 
>>  wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 10:15 AM Brian Candler  wrote:

 Could you explain a bit more about what you're comparing?

 - Is the wasm version running in a browser? If so, which one? Or have you 
 got a way to run wasm directly on the host (in which case, what is it)?
>>>
>>>
>>> Running it in Firefox (78.13.0esr) and Chromium (92.0.4515.159)
>>>

 - How is the linux/amd64 version running, if it's not talking to a 
 DOM-type environment?  If the native version is still using syscall/js, 
 then how is it doing so?  Or is the native version in a different repo?

 - By "the parent emulator project" do you just mean web2600 itself?
>>>
>>>
>>> Web2600 is using the emulation core of the parent project
>>>
>>> https://github.com/JetSetIlly/Gopher2600
>>>
>>> The parent project runs on the desktop. It currently uses SDL and OpenGL 
>>> etc. but it is designed to allow different methods of presentation.
>>>
>>> Web2600 is using the core of the emulator (ie. the non-presentation parts) 
>>> and so doesn't use SDL or OpenGL.
>>>
>>> For presentation, the television package in the core emulation allows you 
>>> to register "PixelRenderers". So Web2600 adds itself as a pixel renderer. 
>>> The implemented SetPixels(), NewFrame() (etc.) functions will then talk to 
>>> the DOM as appropriate.
>>>
>>> The web version works but is just exceedingly slow by comparison.
>>>
>>>
> --
> 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/6bb486eb-7481-4356-94cd-29c365c02416n%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/CAJ6cK1abWOrcv%3DWx-foEeDEqBCZro%2BEYgse_j4uwshBxyG2XJA%40mail.gmail.com.

Re: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

I don't think I'm going to be able to make any progress with this. I 
chopped away enough code so that it compiles with TinyGo. It works but it's 
even slower.

I was hoping to find a way of profiling the WASM code but I see DWARF 
support for WASM binaries is still a work in progress. 
https://github.com/golang/go/issues/33503 I don't know enough about WASM to 
be able to contribute to that issue unfortunately.

Thanks to anyone who looked at this. 
On Friday, 3 September 2021 at 11:20:26 UTC+1 stephen.t@gmail.com wrote:

> To follow up on this I should clarify what my questions are:
>
> 1) How much of a performance drop (when compared to AMD64 for example) 
> should I expect when compiling to the WASM target?
>
> 2) Is there anything obvious I can do to counter any performance drops?
>
> And I suppose this is a non-Go question, but:
>
> 3) I know nothing about WASM beyond the bare minimum. How can I profile 
> and understand the compiled WASM binary? Is it possible to use the pprof 
> tool in some way?
>
>
> On Fri, Sep 3, 2021 at 10:40 AM Stephen Illingworth <
> stephen.t@gmail.com> wrote:
>
>>
>>
>>
>> On Fri, Sep 3, 2021 at 10:15 AM Brian Candler  wrote:
>>
>>> Could you explain a bit more about what you're comparing?
>>>
>>> - Is the wasm version running in a browser? If so, which one? Or have 
>>> you got a way to run wasm directly on the host (in which case, what is it)?
>>>
>>
>> Running it in Firefox (78.13.0esr) and Chromium (92.0.4515.159)
>>  
>>
>>> - How is the linux/amd64 version running, if it's not talking to a 
>>> DOM-type environment?  If the native version is still using syscall/js, 
>>> then how is it doing so?  Or is the native version in a different repo?
>>>
>> - By "the parent emulator project" do you just mean web2600 itself?
>>>
>>
>> Web2600 is using the emulation core of the parent project 
>>
>> https://github.com/JetSetIlly/Gopher2600
>>
>> The parent project runs on the desktop. It currently uses SDL and OpenGL 
>> etc. but it is designed to allow different methods of presentation.
>>
>> Web2600 is using the core of the emulator (ie. the non-presentation 
>> parts) and so doesn't use SDL or OpenGL.
>>
>> For presentation, the television package in the core emulation allows you 
>> to register "PixelRenderers". So Web2600 adds itself as a pixel renderer. 
>> The implemented SetPixels(), NewFrame() (etc.) functions will then talk to 
>> the DOM as appropriate.
>>
>> The web version works but is just exceedingly slow by comparison.
>>
>>
>>

-- 
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/6bb486eb-7481-4356-94cd-29c365c02416n%40googlegroups.com.

Re: [go-nuts] how map in golang solve hash collision?

['Axel Wagner' via golang-nuts]

I recommend https://www.youtube.com/watch?v=Tl7mi9QmLns to learn about how
Go maps work. It's quite in-depth.
To your specific question: Go maps use separate chaining. Every bucket is a
linked list, where every list element stores 8 map entries.

On Sat, Sep 4, 2021 at 9:58 AM xie cui  wrote:

> I am discussing with my friends about how map solve hash collision.
> In my opinion, map uses separate chaining to solve hash collision.
> but some of my friends think it is linear probing that solve the hash
> collision.
>
> --
> 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/aef554b8-5067-401e-b9d4-a09adf9691c2n%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/CAEkBMfGOR6BvPx%2BWAKi0%3DiysmdVoWAONraKPYcPnPTE9-QRrJw%40mail.gmail.com.

[go-nuts] how map in golang solve hash collision?

[xie cui]

I am discussing with my friends about how map solve hash collision. 
In my opinion, map uses separate chaining to solve hash collision.
but some of my friends think it is linear probing that solve the hash 
collision.

-- 
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/aef554b8-5067-401e-b9d4-a09adf9691c2n%40googlegroups.com.