Re: [go-nuts] Re: WASM Performance

[David Suarez]

 
 
  
   reading emails in reverse, apologies, may be similar to what I just sent.  Is it easy enough to try the request animation frame approach?  may help rule out an error in web worker code or approach if you emulate his flow to start, then start optimizing back to web worker if it solves to avoid whatever may have caused the delta.  Just a thought
  
  
   
On 09/05/2021 10:13 AM Stephen Illingworth  wrote:
   
   

   
   

   
   
Thanks for that, it was interesting reading. The problem he was describing in the Doom case seems to be have been caused by the WASM program taking up all the CPU time, meaning the browser itself is unresponsive. I've solved that by using a Web Worker. From what I understand requestAnimationFrame() is a different solution to the same problem. Somebody correct me if I'm wrong.

   
   

   
   
What is interesting though is the profile differences between his Doom port and my 2600 emulator. The top image is from the Doom port:
   
   

   
   

   
   

   
   

   
   
And this is from Web2600, over a similar time period:

   
   

   
   

   
   

   
   

   
   
We can see a lot more gaps in the second case than the first, which would account for the performance drop I think.
   
   

   
   
Does this bring me closer to a solution?

   
   

   
   

 On Sunday, 5 September 2021 at 13:28:44 
 


 I had read an article that may be useful (format was different so may not be the same) -->  https://github.com/diekmann/wasm-fizzbuzz  (goes from basic WASM to Doom)
 
  
 
 
  The key thing in the Doom port that I recall was needed was to change the perspective of the owning thread (now the browser) so needed to ensure it was never blocked/ responded quickly.  When you read through you may find your answer or something that gives you an idea to start searching through in your code.  
 
 
  
 
 
  Hope it helps, David
 

   
   -- 
   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/N10hzvkDA1A/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 https://groups.google.com/d/msgid/golang-nuts/aa9b40d9-b154-48dd-bb52-62f139e3bceen%40googlegroups.com.
   
  
  
   
  
  
   Sincerely,
   David Suarez
   Gallup Strengths Finder:  Achiever * Strategic * Relator * Ideation * Learner
   https://www.linkedin.com/in/davidjsuarez/ 
  
 




-- 
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/1023779990.108994.1631069424500%40email.ionos.com.

Re: [go-nuts] Re: WASM Performance

[David Suarez]

 
 
  
   Did moving rendering to the browser side (just have the other side prep the data to be rendered) solve for the difference?  how much?  Did he do the same in the Doom article to get it to OK?
  
  
   
On 09/07/2021 8:34 AM Stephen Illingworth  wrote:
   
   

   
   

   
   
Yes. I'm seeing a 10x difference in speed too. So at least I know I'm not doing anything fundamentally wrong. It's a general problem at the moment.

   
   

   
   
Thanks. 

   
   

 On Tuesday, 7 September 2021 at 09:31:41 UTC+1 ma...@eliasnaur.com wrote:
 


 In my experience (Gio projects), WASM is very slow compared to native code; my investigations are part of #32591. You may find https://github.com/golang/go/issues/32591#issuecomment-517835565 relevant, because I cut out rendering to eliminate the JS<=>Go crossing overhead. It was a ~10x difference in 2019 and I don't think anything major has changed since then.
 
 Elias
 

   
   -- 
   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/N10hzvkDA1A/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 https://groups.google.com/d/msgid/golang-nuts/6893845f-894b-4546-bb3e-f811e61c01ben%40googlegroups.com.
   
  
  
   
  
  
   Sincerely,
   David Suarez
   Gallup Strengths Finder:  Achiever * Strategic * Relator * Ideation * Learner
   https://www.linkedin.com/in/davidjsuarez/ 
  
 




-- 
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/143741806.108972.1631069234142%40email.ionos.com.

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

[David Suarez]

I agree generally with constraint and interface really being different 
should be named differently.  Is the simplest solution that is also clean 
to have a constraint type that only allows the type parameter (for now) and 
can also include an interface type?  The generic definitions can allow for 
either an interface (more common case) and the constraint definition in 
that case while allowing the constraint defintion to grow independently of 
the interface type.  

I think what this would solve is:

   - Interface is an interface and will always work, no exceptions need to 
   be documented 
   - By default only an interface is required to support generics, a 
   constraint can optionally be used where needed which is what I think the 
   new solution is addressing by selecting interface 
   - Level of documentation on what is/isn’t an interface in generics is 
   cleaner – less cognitive load (most cases an interface can be used to 
   satisfy generic and when not, use the specialized type).  No except when 
   type documentation needs to occur 
   - Potentially some of the later "to be solved" items can be solved more 
   directly by focusing on just the constraint type keeping things simpler 
   (e.g. use constraints for specialized cases/ issues related to generics 
   will keep complex solutioning limited to one type and not "junk up" 
   interface over time) 

Just wanted to add a +1 to the below thread with a potential solution.  The 
constraint would effectively look like a struct, e.g.:
type myConstraint constraint {
   type list here
   interface here 
}

Thoughts?


On Friday, June 19, 2020 at 11:32:28 AM UTC-5, Bryan C. Mills wrote:
>
> On Fri, Jun 19, 2020 at 1:30 AM Ian Lance Taylor  > wrote:
>
>> On Wed, Jun 17, 2020 at 7:58 PM 'Bryan C. Mills' via golang-nuts
>> > wrote:
>> >
>> > On Wednesday, June 17, 2020 at 12:08:59 AM UTC-4 Ian Lance Taylor wrote:
>> >>
>> >> On Tue, Jun 16, 2020 at 9:04 PM Xie Zhenye  wrote:
>> >> >
>> >> > I agree. constraint is different from normal interface. It's better 
>> to use type SomeConstraint constraint {} than type SomeConstraint interface 
>> {}
>> >>
>> >> That is an option, but then we would have two different concepts,
>> >> constraints and interfaces, that are very very similar. It's not
>> >> clear that that is better.
>> >
>> >
>> > I think we already have two very different concepts — we're just 
>> conflating them together by giving them the same name.
>> > As far as I can tell, the semantics of non-type-list interface types 
>> and the semantics of type-list interface types are not compatible.
>> >
>> > Today, if we have two interface types T1 and T2, with T1's method set 
>> is a superset of T2's, then any value assignable to T1 is also assignable 
>> to T2: that is, T1 is a subtype of (not just assignable to!) T2. That 
>> observation is also reflected in the Featherweight Go paper, in which a 
>> type argument satisfies a type constraint if (and only if) the argument is 
>> a subtype of the constraint.
>> >
>> > Based on the semantics of type-lists in type constraints, I would 
>> expect that a run-time interface type containing a type list would mean “an 
>> interface value whose dynamic type is one of the listed types”, or perhaps 
>> “an interface value whose dynamic type has one of the listed types as its 
>> underlying type”. For consistency, such interfaces should also have the 
>> same sort of subtyping relationship: if type T1's type-list is a strict 
>> subset of T2's type-list, then any value assignable to T1 (including a 
>> variable of type T1 itself!) should be assignable to T2.
>> >
>> > So, for example:
>> > type SmallInt interface { type int8, int16 }
>> > should be a subtype of
>> > type MediumInt interface { type int8, int16, int32 }
>> >
>> > However, in the current design draft, a constraint that is a type-list 
>> interface allows use of the operators common to the types in the list.
>> > In the presence of type-list subtypes of interface types, the semantics 
>> for those operators would be confusing at best. Consider the program:
>> >
>> > func Add(type T MediumInt)(x, y T) T {
>> > return x + y
>> > }
>> >
>> > func main() {
>> > var a int8 = 127
>> > var b int16 = 1
>> > fmt.Println(Add(SmallInt)(a, b))  // Should this print 128, or -128?
>> > }
>>
>> I'm not sure whether it affects your point, but I want to point out
>> that this program is invalid.  The MediumInt type constraint accepts
>> any type whose underlying type is int8, int16, or int32.  The type
>> SmallInt, an interface type, is not one of those types.  So you are
>> not only extending the design draft to permit SmallInt to be an
>> ordinary interface type, you are extending the meaning of a type list
>> in a constraint to accept an interface type that implements the type
>> constraint.  That can't work, and this example shows why it can't
>> work: you can't add an int8 value and an int16 value.
>>
>> This code is acting as though, if ordinary 

[go-nuts] First column in sql rows.Scan is always zero

[David Suarez]

Lol!  Lack of sleep is real...  apologies for the horrible keyboard offset 
below.  What I was trying to suggest was to check the case on your ID field.  
In your struct it is all capitalized.  The constant and my guess the 
dereferenced string is a lower case i with a capital D.  Running your code 
through a debugger at that point might confirm why it isnt falling into your 
expected area vs my above guess based on the case mismatch of your ahortened 
example. 
 Good luck!  I am sure you will figure it out soon... David

-- 
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/cfb4e2e8-7616-49a2-92f7-bdcf450b5cdao%40googlegroups.com.

[go-nuts] First column in sql rows.Scan is always zero

[David Suarez]

I havemf eun tour code bit the lower case "eye" jumps out as something to look 
at...  "case iD".  

Hope that helps.  A debugger to walk through should help!

-- 
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/5e2b718d-ed0d-469c-9545-51fff938278ao%40googlegroups.com.

[go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[David Suarez]

The number of posts on this topic piqued my curiosity so I hope to add some 
considerations after doing some research on this trail that I hope you find 
useful.

TL;DR:  It is possible that the reason for the interest in improving 
"exception handling" in the proposed way is driven by individuals that are 
not yet fully comfortable in the language

>From what I have gathered, the reason for improving this area was due to a 
Go Survey.  This reminds me of this popular quote:
Quote. “*If* I had *asked* people what *they wanted*, *they* would have 
said faster horses.”  Henry Ford, Innovation, 

Please note that while I did not participate in the survey, I would 
probably have said the same thing until I got "used to it".  The 
interesting support bit from the survey was the answer to, "I have used Go 
for..."  -  suggests that 1/3rd of the respondents have only 1 year 
experience or less with the language and a full half have less than 2 years 
experience. In my experience, when I started Go I was (and still am in some 
cases) using some Java paradigms in them that make sense to me which is 
great for transition but may not be great for the language long run

I am sure folks that have been around a while would agree that some of the 
reasons they are considering or actively changing languages tend to be due 
to bloat and unnecessary features that eventually weigh down productivity 
because there are 10 ways to skin the cat and everyone has a different 
opinion due to either how the rest of the code base does it or what is 
new.  

The large response to this thread suggests that potentially there may be a 
better feature out there that merits some attention and I would suggest it 
may be something that should come from the 2+ years experience crowd (if 
weighting of the results is possible) as those are likely the challenges 
that newbies like me will eventually encounter.  Weighing the survey 
results by experience may help Go stay ahead of the curve.  Just my .02

**  Side note:  I am a relative newcomer to Go (~8-9 months) so there is 
likely some bias there from my newness.  Add salt here

On Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:
>
> If anyone hasn't seen it, an issue with the "proposal" tag was created 
> earlier on the Go issue tracker titled "Proposal: leave "if err != nil" 
> alone?" (here ). This issue seems to 
> have resonated with a lot of people, which may be an important data point 
> when considering the try proposal , but 
> I was surprised to see how poorly the discussion has gone. There are quite 
> a few "me too" comments, a few image-only posts, some less than stellar 
> personal conduct, and overall not a lot of nuanced discussion. I feel that 
> perhaps these kinds of anti-proposals should be discouraged because they're 
> inherently reactionary, which seems to get the discussion off on the wrong 
> foot.
>
> That said, this anti-proposal attracted a whole new group of Go users that 
> I don't remember from the original try proposal discussion, which was 
> mostly dominated by ten or twenty participants. The discussion was better, 
> but the number of active users was much smaller. I wonder if there's a way 
> to better engage a larger portion of the Go user base while still 
> encouraging healthy, technical discussion.
>

-- 
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/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Resolving methods on pointer types

[David Suarez]

I could be wrong but this seems like over-complicating what you need.  Just 
return the pointer to your foo struct.  If you have your NewFoo return your 
pointer it should be accessible but not modifiable and a quick test I just 
did seems to validate that.  Let me know if I misunderstand, in package 1 I 
added the base parts of what you have:

package model

type foo struct {
bar int
}

func (f *foo) GetBar() int {
return f.bar
}

func NewFoo(bar int) *foo {
return {bar: bar}
}


In package 2 I then validated that I can only "see"/ print out the public 
method:
func TestSimpleFoo(t *testing.T) {
f := model.NewFoo(456)
fmt.Printf("bar has: %v", f.GetBar())
}

Potentially since you have it all in one class it is hard to "see" that it 
works but if you split up it will be easier?

Hope that helps, let me know if I misunderstood the question.

Sincerely,
David


On Sunday, February 24, 2019 at 3:31:10 PM UTC-6, Deomid Ryabkov wrote:
>
> Why can't Go resolve methods declared on the pointer receiver of the 
> destination type?
>
> consider:
>
> type foo struct{
> bar int
> }
>
> type Foo *foo
>
> func (f *foo) GetBar() int {
> return f.bar
> }
>
> func NewFoo(bar int) Foo {
> return {bar: bar}
> }
>
> func main() {
> f1 := {bar: 123}
> fmt.Printf("%d\n", f1.GetBar())
> f2 := NewFoo(456)
> fmt.Printf("%d\n", f2.GetBar())
> }
>
>
> (playground link: https://play.golang.org/p/v0f9pYaTJAa )
>
> it fails to compile with "prog.go:25:23: f2.GetBar undefined (type Foo has 
> no field or method GetBar)" but it's not clear to me, why Foo doesn't get 
> pointer methods from *foo.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Why is Context explicit vs. implicit in Go?

[David Suarez]

First off, I am really loving Go overall.  I probably did what many do and 
started out with less Context use and now it is becoming a standard for a 
few tiers which I see was in a blog somewhere from Google as well.  What I 
haven't been able to find is if there has ever been a conversation on 
making it implicit vs. explicitly passed in method calls.  In java you can 
do this to grab, set a context variable and then pull it a few steps down 
the request cycle without explicitly adding it to method signatures in 
between.  Is there a specific reason it is not implicit (e.g. readability 
or other) or just a conversation that hasn't happened yet?  Should it be a 
feature request to minimize its use to only those areas it is really 
needed? 

-- 
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.
For more options, visit https://groups.google.com/d/optout.