[go-nuts] Re: Congrats to the Go team

[Stephen Illingworth]

How does it perform with v1.22.0? I found a small but measurable drop in 
throughput in one of my projects when compiled with 1.22.0. Issue raised 
here:

https://github.com/golang/go/issues/65647#issuecomment-1944830588

I have a feeling it's an issue with my older development hardware. But it's 
a compute bound project , similar to your project, so I'd be interested in 
hearing how you think it performs with 1.22.0
On Wednesday 24 April 2024 at 19:27:07 UTC+1 Robert Engels wrote:

> I have a fairly stable project github.com/robaho/fixed which is almost 
> 100% cpu bound. It doesn’t change so it makes a great way to compare the 
> performance of different Go versions using the same hardware. I took the 
> time to re-run the tests today.
>
> Using 1.21.17:
>
> BenchmarkAddFixed-8 20   0.59 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkAddDecimal-8500   243 ns/op 
> 176 B/op  8 allocs/op 
>   
> 
> BenchmarkAddBigInt-81   14.3 ns/op
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkAddBigFloat-8  200078.8 ns/op
> 48 B/op  1 allocs/op  
>   
>
> BenchmarkMulFixed-8 34.88 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkMulDecimal-8   200072.0 ns/op
> 80 B/op  2 allocs/op  
>   
>
> BenchmarkMulBigInt-81   17.1 ns/op
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkMulBigFloat-8  300035.5 ns/op
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkDivFixed-8 34.71 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkDivDecimal-8200   779 ns/op 
> 568 B/op 21 allocs/op 
>   
> 
> BenchmarkDivBigInt-8300046.1 ns/op
>  8 B/op  1 allocs/op  
>   
>
> BenchmarkDivBigFloat-8  2000   108 ns/op  
> 24 B/op  2 allocs/op  
>   
>
> BenchmarkCmpFixed-8 20   0.38 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkCmpDecimal-8   2  

[go-nuts] Critical Section - static analysis

[Stephen Illingworth]

Hello,

I've created a proof-of-concept for a method of defining critical sections.
Crucially, the scheme allows for static analysis, thereby helping prevent
violations of the critical sections.

It's a simple concept but I think it's something that can be built upon.

https://github.com/JetSetIlly/critsec

I'm posting it here because I think it's an interesting problem and I would 
like
to hear expert opinion. The problem is a real one but does this solution 
have any
merit?

-

The basic mechanism in this project is something I've used in a large 
rproject
where performance is important. I wanted a way of locking access to data but
without the risk of forgetting to unlock it. Very simple: 

func (crit *Section) Lease(f func() error) error {
crit.lock.Lock()
defer crit.lock.Unlock()
return f()
}

I've been very happy with that but I thought it would be interesting to 
come up
with a method for statically analysing usage of the Lease() function. In 
other
words, to detect those times when I access critical data outside of a Lease.

What's needed for this to work is a way of tagging data to say that it 
should
only be accessed 'inside' a Lease().

My idea is this: define critical data by embedding a crit.Section struct in 
a
new struct type:

type Section struct {
lock sync.Mutex
}


type exampleCritSectioning struct {
crit.Section
a int
b bool
}

We can then lease the critical section:

var C exampleCritSectioning
_ = C.Lease(func() error {
a = 100
return nil
})



So, critical data is identified with the crit.Section type and critical 
sections
by the entry and exit of the Lease function. Static analysis is now 
relatively
simple:

1. Find all instances of types that embed the crit.Section type
2. Find all accesses to data of those types
3. Check whether the callgraph to those access include a call to the 
Lease() function
   
   
The proof-of-concept project includes an analysis package as well as the 
crit
package. A detailed example of an analysis report is given in the README


Notes

I haven't used the analysistest package for testing because I had problems 
with
getting it to work with a go.work file. The examples/ package is used in 
lieue
of that. 

A standalone driver for the analysis is in 'analysis/cmd/critcheck'

The callgraph is created with the 'x/tools/go/callgraph/vta' package. I 
didn't put
much though into this so there might be a better graph method. But VTA 
provided
the best results during experimentation


Regards
Stephen

-- 
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/e2d9f1d9-958a-45df-b402-fe98a213fa67n%40googlegroups.com.

[go-nuts] Re: v1.22.0 Performance Issues

[Stephen Illingworth]

Hi Michael,

Thanks for looking at the profiles. I must confess that I didn't know about 
the --diff_base option. I'll take a closer look at the results of the diff 
and see if that can help me spot anything.

In answer to your questions: I'm certain these profiles were produced from 
the same source code and I'm also certain that the same amount of logical 
work was being done. I can rerun the tests and reproduce the results.

I'll raise an GitHub issue tomorrow if nothing else comes to light.


Thanks again
Stephen

On Friday 9 February 2024 at 22:16:10 UTC Michael Knyszek wrote:

> Hey Stephen,
>
> I poked at your profiles (diffing them) but my only guess is that it's a 
> compiler change that's the culprit. (For future reference, I produced this 
> output with the --diff_base flag, which subtracts one profile from 
> another.)
>
> Showing nodes accounting for -1.34s, 0.44% of 305.86s total
> Dropped 4 nodes (cum <= 1.53s)
> Showing top 20 nodes out of 248
>   flat  flat%   sum%cum   cum%
> -2.85s  0.93%  0.93% -2.89s  0.94%  
> github.com/jetsetilly/gopher2600/hardware/tia/audio.(*Audio).Step
> -2.80s  0.92%  1.85% -1.68s  0.55%  
> github.com/jetsetilly/gopher2600/hardware/tia.(*TIA).QuickStep
>  1.52s   0.5%  1.35%  1.91s  0.62%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*Video).Pixel
>  1.27s  0.42%  0.94%  2.04s  0.67%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*MissileSprite).tick
> -1.18s  0.39%  1.32% -1.18s  0.39%  
> github.com/jetsetilly/gopher2600/hardware/memory/cartridge.(*Cartridge).AccessPassive
>  
> (inline)
> -0.84s  0.27%  1.60% -0.99s  0.32%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*PlayerSprite).tick
>  0.67s  0.22%  1.38%  1.24s  0.41%  
> github.com/jetsetilly/gopher2600/hardware/cpu.(*CPU).read8Bit
>  0.61s   0.2%  1.18%  1.46s  0.48%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*Video).Tick
> -0.54s  0.18%  1.35% -0.59s  0.19%  
> github.com/jetsetilly/gopher2600/hardware/memory/cartridge.(*atari4k).Access
> -0.54s  0.18%  1.53% -0.51s  0.17%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*PlayerSprite).pixel
>  0.49s  0.16%  1.37%  0.49s  0.16%  
> github.com/jetsetilly/gopher2600/hardware/memory/memorymap.MapAddress 
> (inline)
>  0.47s  0.15%  1.22%  0.60s   0.2%  
> github.com/jetsetilly/gopher2600/hardware/memory/cartridge.(*Cartridge).Write 
> (inline)
>  0.47s  0.15%  1.06%  1.32s  0.43%  
> github.com/jetsetilly/gopher2600/hardware/riot/timer.(*Timer).Step
>  0.41s  0.13%  0.93%  0.41s  0.13%  
> github.com/jetsetilly/gopher2600/hardware/memory/vcs.(*RIOTMemory).ChipRefer
>  0.40s  0.13%   0.8%  0.44s  0.14%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*MissileSprite).pixel
>  0.39s  0.13%  0.67%  0.39s  0.13%  
> github.com/jetsetilly/gopher2600/hardware/memory/vcs.(*RIOTMemory).ChipHasChanged
>  0.36s  0.12%  0.55%  0.62s   0.2%  
> github.com/jetsetilly/gopher2600/hardware/riot/ports.(*Ports).Step
>  0.35s  0.11%  0.44%  0.35s  0.11%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*BallSprite).pixel
> -0.33s  0.11%  0.55% -0.59s  0.19%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*BallSprite).tick
>  0.33s  0.11%  0.44%  0.85s  0.28%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*MissileSprite).tickHMOVE
>
> A couple questions just so we're on the same page:
> - Are you certain these two profiles were produced from the same source 
> code?
> - Are you certain these two profiles represent the same amount of logical 
> work being done? (As an example, in the context of a web service, I 
> wouldn't want to measure 30s of traffic, but rather N identical requests 
> handled to make an apples-to-apples comparison.)
>
> If yes to both, then I think my conclusion is that this is probably the 
> result of a compiler change, given that the flat time increases all seem to 
> come from "user" code (as opposed to, say, runtime code).
>
> Do you have a reproducer? It might be worth filing a GitHub issue at this 
> point. (https://github.com/golang/go/issues/new/choose)
>
> Thanks,
> Michael
>
> On Friday, February 9, 2024 at 3:13:12 PM UTC-5 Stephen Illingworth wrote:
>
>> Hello,
>>
>> I'm trying v1.22.0 and I'm measuring an approximate drop in performance 
>> of 10%. I'm comparing to v1.21.7
>>
>> I'm looking at the release notes but I can't see anything that I would 
>> think would be having an impact. Is anyone else noticing a performance drop?
>>
>> I've created a cpu.profile for my project for each the t

[go-nuts] v1.22.0 Performance Issues

[Stephen Illingworth]

Hello,

I'm trying v1.22.0 and I'm measuring an approximate drop in performance of 
10%. I'm comparing to v1.21.7

I'm looking at the release notes but I can't see anything that I would 
think would be having an impact. Is anyone else noticing a performance drop?

I've created a cpu.profile for my project for each the two go versions. 

I can't see anything obviously different between the two profiles but then 
again, I'm not very skilled with pprof. I've uploaded them to github if 
anyone wants to help.

https://github.com/JetSetIlly/gopher2600_performance_profiles


Regards
Stephen

-- 
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/eaf270fe-0010-48c5-9442-1a14e4de6b16n%40googlegroups.com.

Re: [go-nuts] Go ARM

[Stephen Illingworth]

On Wednesday, 15 November 2023 at 21:25:37 UTC Def Ceb wrote:

I downloaded and ran `go env` with both the 32-bit and 64-bit Go 
toolchains from go.dev, and the GOGCCFLAGS results were: 

Since you're on a newer Raspberry Pi with a 64-bit ARM environment, you 
should download the 64-bit Go toolchain, not the 32-bit one. 


That's it! Thank you. Not sure why I didn't spot the ARM64 build on the 
download page. 

-- 
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/f921505c-8ddb-40ff-b441-5d785bd3b939n%40googlegroups.com.

Re: [go-nuts] Go ARM

[Stephen Illingworth]

That works better although not perfectly for my purposes. More work 
required from me.

I'm curious though, about the -marm flag. How can I remove it from the 
GOGCCFLAGS variable? Or are we saying we can't use the aarch64 compiler in 
conjunction with cgo?

Thanks for the help

On Wednesday, 15 November 2023 at 20:05:59 UTC Jan Mercl wrote:

> On Wed, Nov 15, 2023 at 8:30 PM Stephen Illingworth <
> stephen.i...@gmail.com> wrote:
> > I'm trying to build a project on the Raspberry Pi, natively.
> >
> > Using "go env" I can see that Go has the following value for GOGCCFLAGS
> >
> > GOGCCFLAGS='-fPIC -marm -Wl,--no-gc-sections -fmessage-length=0 
> -ffile-prefix-map=/tmp/go-build745518569=/tmp/go-build 
> -gno-record-gcc-switches'
> >
> > However, the native compiler (gcc 12.2) does not have the -marm flag. 
> The compilation of the project fails.
>
> From the above I guess you might be running gcc for aarch64 as the arm 
> version accepts the -marm flag here:
>
> jnml@pi32:~/tmp/gcc$ go version
> go version go1.21.4 linux/arm
> jnml@pi32:~/tmp/gcc$ cat main.c 
> #include 
>
> int main() {
> printf("Hello, world!\n");
> }
> jnml@pi32:~/tmp/gcc$ rm -f a.out ; gcc -marm main.c && ./a.out && echo ok
> Hello, world!
> ok
> jnml@pi32:~/tmp/gcc$ gcc --version
> gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> jnml@pi32:~/tmp/gcc$ 
>
> I tried the solution from 
> https://jensd.be/1126/linux/cross-compiling-for-arm-or-aarch64-on-debian-or-ubuntu
>  
> and it seems to work fine:
>
> jnml@pi64:~/tmp/gcc$ jnml@pi64:~/tmp/gcc$ go version
> go version go1.21.4 linux/arm64
> jnml@pi64:~/tmp/gcc$ cat main.c
> #include 
>
> int main() {
> printf("Hello, world!\n");
> }
> jnml@pi64:~/tmp/gcc$ rm -f a.out ; gcc main.c && ./a.out && echo ok
> Hello, world!
> ok
> jnml@pi64:~/tmp/gcc$ rm -f a.out ; gcc -marm main.c && ./a.out && echo ok
> gcc: error: unrecognized command-line option ‘-marm’
> jnml@pi64:~/tmp/gcc$ sudo apt install gcc-arm-linux-gnueabi 
> binutils-arm-linux-gnueabi
> ...
> jnml@pi64:~/tmp/gcc$ rm -f a.out ; arm-linux-gnueabi-gcc -marm main.c && 
> file a.out
> a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically 
> linked, interpreter /lib/ld-linux.so.3, 
> BuildID[sha1]=2191a16290d46b039bfae26fd5918106dff99749, for GNU/Linux 
> 3.2.0, not stripped
> jnml@pi64:~/tmp/gcc$
>
> HTH
>
>

-- 
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/af718786-7479-4a98-bfb2-7feee41017can%40googlegroups.com.

[go-nuts] Go ARM

[Stephen Illingworth]

Hello,

I'm trying to build a project on the Raspberry Pi, natively.

Using "go env" I can see that Go has the following value for GOGCCFLAGS

GOGCCFLAGS='-fPIC -marm -Wl,--no-gc-sections -fmessage-length=0 
-ffile-prefix-map=/tmp/go-build745518569=/tmp/go-build 
-gno-record-gcc-switches'

However, the native compiler (gcc 12.2) does not have the -marm flag. The 
compilation of the project fails.

I know you can't edit the GOGCCFLAGS environment variable directly but it's 
not clear to me how to remove this unneeded flag.

I've tried the CGO_CFLAGS_DISALLOW environment variable but that doesn't 
seem work. But maybe I'm misusing it.

This is a brand new installation of Raspbian. The only other software I've 
installed is Go for Arm from the official Go distribution site.

Help
Stephen

-- 
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/82a69c96-5cbd-4aa2-a911-8141071b2610n%40googlegroups.com.

Re: [go-nuts] ldflags -X

[Stephen Illingworth]

Yes. I agree that it's correct given the general rules.
On Wednesday, 8 November 2023 at 15:42:25 UTC Jan Mercl wrote:

> On Wed, Nov 8, 2023 at 4:01 PM Stephen Illingworth
>  wrote:
>
> > I would have expected the "main.A" string to require the same form. But 
> either way, that's the correct solution.
>
> It is the correct form. Package main cannot be imported and has a
> special import path. Though I don't know where it is documented.
>

-- 
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/70151c0b-b270-40c7-8ed7-b54f6029a8dcn%40googlegroups.com.

Re: [go-nuts] ldflags -X

[Stephen Illingworth]

I would have expected the "main.A" string to require the same form. But 
either way, that's the correct solution.

Thanks.



-- 
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/eed87ed7-7a61-48ca-844b-f7143f37a7e4n%40googlegroups.com.

[go-nuts] ldflags -X

[Stephen Illingworth]

Hello,

I'm trying to use the -X ldflag to set a string at compile time. I can do 
this successfully if the string is in the main package but it does not work 
if the string is in a subpackage.

For illustration purposes, I have prepared a simple test project

https://github.com/JetSetIlly/ldflags_X_test

The build.sh file contains the build string. It contains one useful line, 
which I'll repeat it here:

go build -ldflags "-X 'main.A=foo' -X 'sub.B=bar'"

When built, the main function will print out the A string correctly but the 
B string is unset.

What am I doing wrong?

Regards
Stephen

-- 
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/90c1b0aa-1bec-48dd-84d8-da5c558d730cn%40googlegroups.com.

Re: [go-nuts] Re: Help with WASM performance

[Stephen Illingworth]

Heh. Yes, it is only an "aim" I suppose.

Yes. My code is single threaded. I note that threading will be added to the 
WASM spec in the near future so maybe there will be opportunity for me 
there when the change is added to the Go compiler.

I'll put this issue to rest for now and revisit it in a few months.

Thanks

On Saturday, 23 September 2023 at 09:53:34 UTC+1 TheDiveO wrote:

> The cynic in me notes the use of "aims".
>
> IIRC is single-threaded, do you know if your code is single- threaded too, 
> or does it use several core for decoding? 
>
> On Saturday, September 23, 2023 at 7:37:13 AM UTC+2 Stephen Illingworth 
> wrote:
>
>> Comparison to native speeds is the key attraction of WASM. From the 
>> go.org blog published 10 days ago: https://go.dev/blog/wasi
>>
>> "WebAssembly (Wasm) <https://webassembly.org/> is a binary instruction 
>> format originally designed for the web. It represents a standard that 
>> allows developers to run high-performance, low-level code directly in web 
>> browsers at near-native speeds."
>>
>> And from the front page of webassembly.org
>>
>> "The Wasm stack machine <https://webassembly.org/docs/semantics/> is 
>> designed to be encoded in a size- and load-time-efficient binary format 
>> <https://webassembly.org/docs/binary-encoding/>. WebAssembly aims to 
>> execute at native speed by taking advantage of common hardware 
>> capabilities 
>> <https://webassembly.org/docs/portability/#assumptions-for-efficient-execution>
>>  
>> available on a wide range of platforms."
>>
>>
>> On Saturday, 23 September 2023 at 01:18:26 UTC+1 Robert Engels wrote:
>>
>>> Typically WASM performance is compared to JavaScript - ie. faster than 
>>> JavaScript usually 1.5-10x. 
>>>
>>> People don’t usually compare WASM with native apps. 
>>>
>>> On Sep 22, 2023, at 7:04 PM, Robert Engels  wrote:
>>>
>>> 
>>>
>>> WASM goes through the browser - so it is very different. Are you using 
>>> OpenGL or similar?
>>>
>>> On Sep 22, 2023, at 3:44 PM, Stephen Illingworth  
>>> wrote:
>>>
>>> 
>>> I'm comparing the results of a program compiled for AMD64 and WASM 
>>> architectures. The code is the same except for the change of architecture. 
>>> The size of the difference in performance is unexpected to me but maybe 
>>> it's normal.
>>>
>>> On Friday, 22 September 2023 at 20:16:20 UTC+1 Robert Engels wrote:
>>>
>>>> When you say negative performance are you talking about a native app 
>>>> running directly on the hardware what are you referring to exactly
>>>>
>>>> On Sep 22, 2023, at 1:03 PM, Stephen Illingworth <
>>>> stephen.i...@gmail.com> wrote:
>>>>
>>>> 
>>>>
>>>> I've been thinking some more about this problem this week. I found the 
>>>> performance profiler in Chrome and can see that the each frame is taking 
>>>> longer than the required 16.7ms to create. The duration for each frame is 
>>>> more like 100ms. The native performance meanwhile can reach about 7ms. I 
>>>> expected a drop in performance but not that much.
>>>>
>>>> If anyone can offer any insight or if these figures seem wrong then I'd 
>>>> love to take some advice.
>>>>
>>>> Regards
>>>> Stephen
>>>>
>>>> On Saturday, 16 September 2023 at 09:02:34 UTC+1 Stephen Illingworth 
>>>> wrote:
>>>>
>>>>> I have tried running it in Firefox and Chromium. The webserve.sh 
>>>>> script in the ebiten_test folder runs a small httpd server to serve up 
>>>>> the 
>>>>> binary to the browser.
>>>>>
>>>>>
>>>>>
>>>>> On Saturday, 16 September 2023 at 08:45:52 UTC+1 Brian Candler wrote:
>>>>>
>>>>>> What WASM runtime are you using to execute the code?
>>>>>
>>>>> -- 
>>>> 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/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%40googlegroups.com
>>>>  
>>>&g

Re: [go-nuts] Re: Help with WASM performance

[Stephen Illingworth]

Comparison to native speeds is the key attraction of WASM. From the go.org 
blog published 10 days ago: https://go.dev/blog/wasi

"WebAssembly (Wasm) <https://webassembly.org/> is a binary instruction 
format originally designed for the web. It represents a standard that 
allows developers to run high-performance, low-level code directly in web 
browsers at near-native speeds."

And from the front page of webassembly.org

"The Wasm stack machine <https://webassembly.org/docs/semantics/> is 
designed to be encoded in a size- and load-time-efficient binary format 
<https://webassembly.org/docs/binary-encoding/>. WebAssembly aims to 
execute at native speed by taking advantage of common hardware capabilities 
<https://webassembly.org/docs/portability/#assumptions-for-efficient-execution> 
available on a wide range of platforms."


On Saturday, 23 September 2023 at 01:18:26 UTC+1 Robert Engels wrote:

> Typically WASM performance is compared to JavaScript - ie. faster than 
> JavaScript usually 1.5-10x. 
>
> People don’t usually compare WASM with native apps. 
>
> On Sep 22, 2023, at 7:04 PM, Robert Engels  wrote:
>
> 
>
> WASM goes through the browser - so it is very different. Are you using 
> OpenGL or similar?
>
> On Sep 22, 2023, at 3:44 PM, Stephen Illingworth  
> wrote:
>
> 
> I'm comparing the results of a program compiled for AMD64 and WASM 
> architectures. The code is the same except for the change of architecture. 
> The size of the difference in performance is unexpected to me but maybe 
> it's normal.
>
> On Friday, 22 September 2023 at 20:16:20 UTC+1 Robert Engels wrote:
>
>> When you say negative performance are you talking about a native app 
>> running directly on the hardware what are you referring to exactly
>>
>> On Sep 22, 2023, at 1:03 PM, Stephen Illingworth  
>> wrote:
>>
>> 
>>
>> I've been thinking some more about this problem this week. I found the 
>> performance profiler in Chrome and can see that the each frame is taking 
>> longer than the required 16.7ms to create. The duration for each frame is 
>> more like 100ms. The native performance meanwhile can reach about 7ms. I 
>> expected a drop in performance but not that much.
>>
>> If anyone can offer any insight or if these figures seem wrong then I'd 
>> love to take some advice.
>>
>> Regards
>> Stephen
>>
>> On Saturday, 16 September 2023 at 09:02:34 UTC+1 Stephen Illingworth 
>> wrote:
>>
>>> I have tried running it in Firefox and Chromium. The webserve.sh script 
>>> in the ebiten_test folder runs a small httpd server to serve up the binary 
>>> to the browser.
>>>
>>>
>>>
>>> On Saturday, 16 September 2023 at 08:45:52 UTC+1 Brian Candler wrote:
>>>
>>>> What WASM runtime are you using to execute the code?
>>>
>>> -- 
>> 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/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/1123a2da-3862-4da8-baf5-bc67dd2b7e6en%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/1123a2da-3862-4da8-baf5-bc67dd2b7e6en%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2421e486-000d-4e6d-8177-2ca2f5174751n%40googlegroups.com.

Re: [go-nuts] Re: Help with WASM performance

[Stephen Illingworth]

I'm comparing the results of a program compiled for AMD64 and WASM 
architectures. The code is the same except for the change of architecture. 
The size of the difference in performance is unexpected to me but maybe 
it's normal.

On Friday, 22 September 2023 at 20:16:20 UTC+1 Robert Engels wrote:

> When you say negative performance are you talking about a native app 
> running directly on the hardware what are you referring to exactly
>
> On Sep 22, 2023, at 1:03 PM, Stephen Illingworth  
> wrote:
>
> 
>
> I've been thinking some more about this problem this week. I found the 
> performance profiler in Chrome and can see that the each frame is taking 
> longer than the required 16.7ms to create. The duration for each frame is 
> more like 100ms. The native performance meanwhile can reach about 7ms. I 
> expected a drop in performance but not that much.
>
> If anyone can offer any insight or if these figures seem wrong then I'd 
> love to take some advice.
>
> Regards
> Stephen
>
> On Saturday, 16 September 2023 at 09:02:34 UTC+1 Stephen Illingworth wrote:
>
>> I have tried running it in Firefox and Chromium. The webserve.sh script 
>> in the ebiten_test folder runs a small httpd server to serve up the binary 
>> to the browser.
>>
>>
>>
>> On Saturday, 16 September 2023 at 08:45:52 UTC+1 Brian Candler wrote:
>>
>>> What WASM runtime are you using to execute the code?
>>
>> -- 
> 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/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1123a2da-3862-4da8-baf5-bc67dd2b7e6en%40googlegroups.com.

[go-nuts] Re: Help with WASM performance

[Stephen Illingworth]

I've been thinking some more about this problem this week. I found the 
performance profiler in Chrome and can see that the each frame is taking 
longer than the required 16.7ms to create. The duration for each frame is 
more like 100ms. The native performance meanwhile can reach about 7ms. I 
expected a drop in performance but not that much.

If anyone can offer any insight or if these figures seem wrong then I'd 
love to take some advice.

Regards
Stephen

On Saturday, 16 September 2023 at 09:02:34 UTC+1 Stephen Illingworth wrote:

> I have tried running it in Firefox and Chromium. The webserve.sh script in 
> the ebiten_test folder runs a small httpd server to serve up the binary to 
> the browser.
>
>
>
> On Saturday, 16 September 2023 at 08:45:52 UTC+1 Brian Candler wrote:
>
>> What WASM runtime are you using to execute the code?
>
>

-- 
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/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%40googlegroups.com.

[go-nuts] Re: Help with WASM performance

[Stephen Illingworth]

I have tried running it in Firefox and Chromium. The webserve.sh script in 
the ebiten_test folder runs a small httpd server to serve up the binary to 
the browser.



On Saturday, 16 September 2023 at 08:45:52 UTC+1 Brian Candler wrote:

> What WASM runtime are you using to execute the code?

-- 
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/f3891ef0-c267-48b9-a99e-d4e26f29b1cfn%40googlegroups.com.

[go-nuts] Help with WASM performance

[Stephen Illingworth]

Hello,

I'm hoping for some help with a Go WASM project I am working on.

The project is based on another project of mine, which runs very well and I 
have no concerns about its performance. The WASM project however performs 
poorly. The help I need is to determine whether the performance of the WASM 
version can be improved.

I apologise in advance if this is an inappropriate topic for this mailing 
list, but I think it presents an interesting case study.


The main project is an Atari 2600 emulator and located on github: 
https://github.com/JetSetIlly/Gopher2600

The WASM project is also on Github: 
https://github.com/JetSetIlly/Gopher2600-Utils

The ebiten_test directory is the WASM project. It uses the core of the main 
project to load and display a running Atari ROM file. When compiled 
natively, this ebiten program performs well.

However the WASM targeted compilation of the same ebiten project is 
significantly slower. On my hardware, the comparative performance is more 
than 60 FPS for the native version and less than 10 FPS for the WASM 
version.


My questions are:

Is such a performance drop expected in a WASM project?

How can I analyse the performance of the WASM program? I have used Go 
profiling to identify bottlenecks but how do I do something similar for 
WASM?


As you can tell, I am all at sea when it comes to modern web development so 
any help and advice would be much appreciated.


Regards

Stephen

-- 
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/57da7e15-0126-438f-82e0-d59ac882e3den%40googlegroups.com.

Re: [go-nuts] Go Toolchain Management from 1.21.0 onwards

[Stephen Illingworth]

On Wednesday, 16 August 2023 at 10:15:50 UTC+1 Christoph Berger wrote:

I would assume that GOTOOLCHAIN=local does what you want. 

The doc  says,

> When GOTOOLCHAIN is set to local, the go command always runs the bundled 
Go toolchain.


That's the conclusion I came to. I wasn't entirely sure what was meant by 
"bundled" at first but in this context I think it means the go toolchain 
that has been manually installed.
 

The author of this proposal 
 in 
docker-library/golang also assumes that GOTOOLCHAIN=local preserves 
pre-1.21 behavior. 


 I'll take that as confirmation. Thanks

-- 
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/85124775-b026-4dbe-af2a-f8260bd31478n%40googlegroups.com.

[go-nuts] Re: Go Toolchain Management from 1.21.0 onwards

[Stephen Illingworth]

On Wednesday, 16 August 2023 at 08:47:36 UTC+1 Christoph Berger wrote:

Thank you for replying.
 

What prevents you from using the new toolchains mechanism?


Nothing really. I suppose it's just that I don't really understand what it 
is or what it's for.

The current method of dealing with the toolchain is as straightforward as 
it can possibly be. For me at least. Automatic downloading just seems 
unnecessarily complicated but I can accept that other people have different 
needs.

If GOTOOLCHAIN=local disables the automatic downloading and allows me to 
continue with my current workflow then I'm happy! The document on the 
change was extensive but not entirely clear on this point.

Regards
Stephen



-- 
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/e2540552-ddfb-4ce4-9db3-a4aa92ca0e95n%40googlegroups.com.

[go-nuts] Go Toolchain Management from 1.21.0 onwards

[Stephen Illingworth]

With regards to the new Toolchain Management feature introduced in 1.21.0

Currently, my toolchain management is: download the source; compile; set 
paths to point to the new version. I like this and it works for me.

Am I correct in thinking that the environment variable, GOTOOLCHAIN=local, 
will
disable the automatic downloading of new Go toolchains and allow me to 
continue
with my current system? 


I hope this isn't seen as a criticism of new developments. It's not meant 
to be.
But I don't believe I'm in the target audience for this new feature and 
want to
continue with my work as I am currently.

Regards
Stephen

-- 
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/72c5791b-3ad6-4509-ae02-09ba7e9f8bccn%40googlegroups.com.

Re: [go-nuts] binary.ByteOrder

[Stephen Illingworth]

Thanks. Although I'm not worried about the native byte order of my machine

I'm writing an ARM emulator. The endianness of the ARM I'm taking to be 
whatever the endianess is in the ELF file from which I'm loading the 
program. I'm using the debug/elf package in the standard library which in 
turn uses the binary package

Generally, the specifics of the byte order is irrelevant - I can just use 
Uint32(), PutUint32() etc. but in some specific instructions it's easier to 
handle the byte order manually and for that I need to know what the 
endianness is.

I can work around it but I just thought I might be missing something.


Regards
Stephen
On Thursday, 10 August 2023 at 14:16:53 UTC+1 Rob Pike wrote:

> First read 
> https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
>
> then see
>
> https://go.dev/play/p/4ESm6nOwgtY
>
> -rob
>
>
>
>
>
>
> On Thu, Aug 10, 2023 at 8:46 PM Stephen Illingworth <
> stephen.i...@gmail.com> wrote:
>
>> Hello,
>>
>> I want to detect the implementation of binary.ByteOrder. ie. whether it 
>> is Little Endian or Big Endian.
>>
>> Normally, you would do this with a type assertion or a type switch but in 
>> the case of the binary package the little/big endian implementations are 
>> not exported.
>>
>> The only way that I can see to distinguish between the implementations is 
>> to test the value returned by String(). Am I missing something here or 
>> should I continue to use String()?
>>
>> Regards
>> Stephen
>>
>> -- 
>> 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/67469c8a-b1aa-4976-8f4a-2b4458d28214n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/67469c8a-b1aa-4976-8f4a-2b4458d28214n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/618e2a97-670f-4df7-98f3-a9b576ad8971n%40googlegroups.com.

[go-nuts] binary.ByteOrder

[Stephen Illingworth]

Hello,

I want to detect the implementation of binary.ByteOrder. ie. whether it is 
Little Endian or Big Endian.

Normally, you would do this with a type assertion or a type switch but in 
the case of the binary package the little/big endian implementations are 
not exported.

The only way that I can see to distinguish between the implementations is 
to test the value returned by String(). Am I missing something here or 
should I continue to use String()?

Regards
Stephen

-- 
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/67469c8a-b1aa-4976-8f4a-2b4458d28214n%40googlegroups.com.

[go-nuts] Re: Error handling

[Stephen Illingworth]

On Tuesday, 1 August 2023 at 18:14:56 UTC+1 DrGo wrote:

Fair enough. But many would prefer shorter functions if there is no loss to 
explicitness or clarity. 


I don't think putting the assignment and return statement on the same line 
is very clear. I would prefer
the compiler to enforce something like the following:

func CopyFile(src, dst string) error {
r, err := os.Open(src) *orelse* {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
defer r.Close()

w, err := os.Create(dst) *orelse* {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
err := io.Copy(w, r) *orelse* {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

err := w.Close() *orelse* {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

What do you intend to happen to the error instances after the orelse block? 
Are they valid outside the orelse block?


-- 
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/6dd26b81-23b3-4226-9eb9-3bc47b2bee54n%40googlegroups.com.

[go-nuts] Re: Error handling

[Stephen Illingworth]

On Tuesday, 1 August 2023 at 18:06:25 UTC+1 DrGo wrote:

Compare the following; which one would you prefer to read a lot of?


You've asked a fair question so you deserve an honest answer. Looking at 
the two examples, I would prefer to read the code in the first example.

-- 
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/5c32bdce-b07c-4703-b445-4a2a2d95a0f5n%40googlegroups.com.

[go-nuts] Re: error handling thoughts

[Stephen Illingworth]

Hi Steve,

What's the compiler error that you're seeing?

Here's a go playground example of your scenario. It doesn't seem to cause 
any issues but maybe I'm misunderstanding.

https://go.dev/play/p/vvtrQTl7FSr

Regards, Stephen

On Thursday, 27 July 2023 at 16:04:19 UTC+1 Steve Roth wrote:

> The ongoing Go survey asked a question about satisfaction with error 
> handling in Go.  I'd like to express an opinion on it that I haven't seen 
> elsewhere, for which there was not room in the survey.
>
> I am generally a fan of the explicit error handling code in Go, but I get 
> frustrated by the interactions between error handling, := assignments, and 
> compiler warnings.  My preferred way of writing the standard clause is
>
> if err := fn(); err != nil {
>
> // handle error and bail out
> }
>
>
> However, often the function in question returns a result I want to work 
> with.  If it's something important for the whole rest of the function, I'll 
> probably just define it as a variable at function scope:
>
> var (
>
> result sometype
>
> err error
> )
> // ...
>
> if result, err = fn(); err != nil {
>
> // handle error and bail out
> }
>
> // act on result
>
>
> But often, the result is something I'm only going to use for one statement 
> and is not a variable of significance to the whole function.  Those are the 
> sorts of cases that := is best for, in my opinion.  In those cases, what 
> I'd like to write is
>
> if result, err := fn(); err != nil {
>
> // handle error and bail out
>
> } else {
>
> // act on result
> }
>
>
> Unfortunately, the compiler gives a warning on that.  Because the truth 
> clause bailed out (e.g., "return"), it insists that I remove the else and 
> turn the code into
>
> if result, err := fn(); err != nil {
>
> // handle error and bail out
>
> }
>
> // act on result
>
>
> But that doesn't compile because result is no longer in scope.
>
> What I often wind up doing instead is
>
> if result, err = fn(); err == nil {
>
> // act on result
>
> } else {
>
> // handle error and bail out
> }
>
>
> That works, but it leaves my code with a mixture of "handle error case 
> first, then success" and "handle success case first, then error" patterns, 
> which I find adds a lot to cognitive load.
>
> I have no idea whether others share my frustration on this admittedly 
> minor point.  But since the survey prodded me, I thought I would voice it 
> and see what reactions it gets.  For me, the ideal solution would be to 
> suppress the compiler warning about removing the else, when doing so would 
> break the code altogether.
>
> Regards,
> Steve
>
>

-- 
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/3a98bae6-8ca9-49d4-8a32-c95ae8863baen%40googlegroups.com.

[go-nuts] Re: testing whether two maps are the same object

[Stephen Illingworth]

I like that. I think it's is quite a smart way of doing it,

I don't think you need to check both maps when choosing a key. Once you've 
found a candidate key in one map, you can test the other map and if it 
*does* exist then the two maps aren't equal. You've then saved the 
insertion and deletion step. I would also prefer to use rand.Int() rather 
than a linear search. 

https://go.dev/play/p/ftBGgQMuvvC


On Tuesday, 18 July 2023 at 15:35:38 UTC+1 Jochen Voss wrote:

> Dear all,
>
> To implement the "eq" operator in a simple PostScript interpreter, I need 
> to determine whether two maps are the same object.
>
> This can be done by adding a new element to one map, and checking whether 
> the new entry also appears in the second map, but as you can imagine, the 
> resulting code is quite ugly.  See https://go.dev/play/p/AfembYDt3en for 
> an implementation of this idea.
>
> Is there a better way?
>
> Many thanks,
> Jochen
>
>

-- 
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/3217b6a4-5c22-43ba-b8a6-6c71745c6d65n%40googlegroups.com.

[go-nuts] Go Toolchains

[Stephen Illingworth]

Hello

I'm a little confused by what's being documented for the new "Go toolchain" 
feature.

https://tip.golang.org/doc/toolchain

Will this be downloading binaries or will it be downloading the source for 
the new toolchain and compiling it with the available Go version?

Stephen

-- 
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/ee3e8be1-ea75-4584-a032-55bc27f33fc0n%40googlegroups.com.

Re: [go-nuts] Detecting race conditions

[Stephen Illingworth]

But it does not introduce false positives. It exposes true positives. The 
race are still there, even if the race detector can not detect them. Note 
that the race detector is a heuristic. It will never find all race 
conditions, only the ones encountered in the actual run.


This is a great point. They are true positives. 

I wonder if it's possible for the -race detector (via an optional flag) to 
introduce random lag in order to change the execution profile. I'm thinking 
that this would help to flush out these true positives. Fuzz testing but 
specifically for race detection.

-- 
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/8ca3eef8-74b4-4ed3-b9fb-4cc63f5d0a86n%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[Stephen Illingworth]

Hello Alex. Thanks for your response.

On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:

> Once windows executable is built, go has no control over how this program
> executes.
>
> When command line program is executed by clicking in explorer window
> Windows automatically starts a new console window and the console is used
> for stdout output (I did not check that). If command line program is
> started from existing cmd.exe console, new process just uses the same
> console.
>
> When you click on GUI executable in Windows explorer, no console windows
> is started (I did not check that). Same for GUI executable started from
> cmd.exe console - new GUI process is not attached to parent console (I did
> not check that).
>

Right. So I have a GUI executable that might be launched from a console but
it will not be "attached" to that parent console.

Is there a way to attach the GUI executable to the parent console, perhaps
using a Windows system call?

-- 
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/CAPmHGLNS1QMVKqHrjoLskEy1SFhCYXc_Ra%2BnEiysHoA%3DV7Fw2A%40mail.gmail.com.

Re: [go-nuts] atomic.Value : inconsistent types

[Stephen Illingworth]

> How about just a 'container' type for the interface.
>>
>> https://play.golang.org/p/WSXVjVHj1Ya
>>
>
>> For what I need, that does the job nicely. The type being stored in the 
>> atomic.Value isn't changing so it satisfies the atomic.Value constraints 
>> but I have the flexibility of the contained type being able to change. Any 
>> pitfalls with this?
>>
>
> No, that should work fine. Though I'm not sure about "just", it requires 
> an extra type but leads to exactly the same memory layout and everything. 
> But yeah, if you prefer that, it's completely fine.
>

I'm happy with it. It feels reasonably clean and there are no special 
conditions. Although I should refactor the code so that I don't need 
atomics at all and communicate over channels. But this just happens to be 
how the code has developed.

Thanks for the 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/e58cb004-423a-4d8c-a652-c43eb6556723n%40googlegroups.com.

Re: [go-nuts] atomic.Value : inconsistent types

[Stephen Illingworth]

> I've found that the way around this is to create a new instance of 
>> atomic.Value whenever I have reason to believe that the type to be stored 
>> has changed.
>>
>
> That seems to be counter to the idea behind `atomic.Value`. Creating and 
> setting the new `atomic.Value` requires synchronization. If you need 
> synchronization anyway, it seems better to just use that synchronization to 
> serialize *all* read/writes.
>

Yes. I can see that now. The creation of the new atomic.Value could happen 
any time.

I've been leaning on the race detector and this technique has never 
triggered anything but that's probably just good fortune.
  

> In my program this can happen because I am storing an interface in the 
>> atomic.Value and the implementation of the interface may change.
>>
>
> I think the best way to address that might be to store a pointer to an 
> interface-type. That's similar to how you want to proceed if you want to 
> get an interface-typed reflect.Value, so you do 
> `reflect.ValueOf().Elem()` (if `r` is an `io.Reader`, for example).
>

How about just a 'container' type for the interface.

https://play.golang.org/p/WSXVjVHj1Ya

For what I need, that does the job nicely. The type being stored in the 
atomic.Value isn't changing so it satisfies the atomic.Value constraints 
but I have the flexibility of the contained type being able to change. Any 
pitfalls with this?

-- 
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/3f1d0c92-4ded-4096-95d9-069a9b5d78cen%40googlegroups.com.

[go-nuts] atomic.Value : inconsistent types

[Stephen Illingworth]

When using atomic.Values it is important that the type being stored is 
consistent. Trying to store a different type in an atomic.Value will cause 
a panic

panic: sync/atomic: store of inconsistently typed value into Value

I've found that the way around this is to create a new instance of 
atomic.Value whenever I have reason to believe that the type to be stored 
has changed. In my program this can happen because I am storing an 
interface in the atomic.Value and the implementation of the interface may 
change.

Choosing the moment to create the new atomic.Value however can be tricky so 
I am now trying the following method:

1) Check the type of the existing stored value and the type of the new value
2) If they are the same then atomic.Value.Store() can be used
3) If they are not the same, then create a new instance of atomic.Value and 
store new value in that
4) Give the new atomic.Value the name of the old atomic.Value

This method means I no longer have to worry about when I create a new 
instance of atomic.Value - the new instance is created when the type check 
fails.

Example code.

https://play.golang.org/p/1gmI5eMdOcl

Now, this obviously requires knowledge of how interface{} is represented 
internally, which isn't great, but in principle is this a correctly working 
solution? (It seems to be to me but that doesn't really mean anything)

Does returning an atomic.Value from a function count as "copying" after 
first use?

Is this going to bite me in the future?

-- 
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/8893475a-ec61-4f78-9dc0-b80dda9e675an%40googlegroups.com.

Re: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

Even when I remove all rendering and just run the Go WASM in a web worker, 
like this:

const go = new Go();
WebAssembly.instantiateStreaming(fetch("web2600.wasm"), 
go.importObject).then((result) => {
go.run(result.instance);
});

The binary is still performing a long way below native performance. I'm 
writing to the web console with println() to indicate progress but apart 
from that there is no communication between Go and the browser.

I haven't looked into RequestAnimationFrames yet but I did try the Ebiten 
option. The profile looks similar to the Doom profile (with 
RequestAnimationFrames) but even then the emulation is running slower than 
native.

Worth emphasising that in the case of my Ebiten version, exactly the same 
Go code is being compiled for native CPU and WASM.

My next step (which won't be for a few days at least) is to learn a bit 
more about WebAssembly and to take a look at the code that's being 
generated.


On Wednesday, 8 September 2021 at 03:47:42 UTC+1 da...@suarezhouse.net 
wrote:

> 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...@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
>  
> <https://groups.google.com/d/msgid/golang-nuts/6893845f-894b-4546-bb3e-f811e61c01ben%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
>
>
> 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/9ac08e0e-337e-4220-9274-b3aee4db4fe1n%40googlegroups.com.

Re: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

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 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/6893845f-894b-4546-bb3e-f811e61c01ben%40googlegroups.com.

Re: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

(Links to screenshots)

https://github.com/JetSetIlly/Gopher2600-Utils/blob/master/web2600/Doom_profile.png

https://github.com/JetSetIlly/Gopher2600-Utils/blob/master/web2600/Web2600_profile.png


On Sunday, 5 September 2021 at 15:13:32 UTC+1 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 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/6439a977-9f25-454a-bed1-c8d8cc1027ecn%40googlegroups.com.

Re: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

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 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/aa9b40d9-b154-48dd-bb52-62f139e3bceen%40googlegroups.com.

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

[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] Re: WASM Performance

[Stephen Illingworth]

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.illingwo...@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/CAPmHGLOk4Qmii%2BWZzszCbOJDz9PsMV3dQdfgvWTs-nfSmhjwkw%40mail.gmail.com.

Re: [go-nuts] Re: WASM Performance

[Stephen Illingworth]

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/CAPmHGLPh3Kt3gFeJ6e_W-kqfGsS03E8Ycr8-2dv2j%3Dhd80zrLA%40mail.gmail.com.

Re: [go-nuts] Makefiles for Go Programs

[Stephen Illingworth]

I use Makefiles with Go projects. For many of the reasons already given but 
it's especially useful for me for cross compilation to the target platforms 
at release time. So, when running "make release" I have "test" and 
"generate" targets as dependencies to make sure I've not missed anything.

I don't need a build system to do that but it's good to have a script for 
that kind of thing, IMO.

I also use it in the git pre-commit hook. For example, I have "make lint" 
in that script which runs whatever linter I'm using at the moment and I can 
be assured that it's the same linter I'm using at the command line.

As for why not another build system, for the same reason as other 
respondents have said. Make has been around forever and I don't need 
anything more sophisticated.

> Make does not come alone for end-users. Usually it comes bundled with 
several hundreds of megabytes of > the devel packages  user gets after 
issuing eg. `sudo apt-get install build-essential`.

Surely, you would just do: `sudo apt-get install make`


On Tuesday, 24 August 2021 at 12:14:50 UTC+1 ohir wrote:

> Dnia 2021-08-24, o godz. 07:54:35
> Reto  napisał(a):
>
> > It may be nicer, however the beauty of make is that it is ubiquitous,
> > everybody already has it.
>
> No, not everybody has it. Esp. on Windows host.
>
> > With mage, your installation instructions now need to contain how /
> > where to get mage in the first place, leaving the user with a random
> > binary somewhere which they probably never ever need nor update again.
>
> Nope. If user is going to compile from sources she also needs to install 
> Go compiler and tools. Once she has it the mage is a `go install` command 
> away. Shorter than typical line of "prerequisites" needed by non-developer 
> user on most of linux distros. (If she is about to install binary she does 
> not need mage at all - 99% deployments of Go based apps are just the single 
> executable.)
>
> > leaving the user with ... they probably never ever need nor update again.
>
> Make does not come alone for end-users. Usually it comes bundled with 
> several hundreds of megabytes of the devel packages
> user gets after issuing eg. `sudo apt-get install build-essential`. Then 
> she's left with a bit more more unused stuff than a single
> mage binary.
>
> TC,
>
> -- 
> 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/039b0cac-a81c-40ae-bb46-f12d11261707n%40googlegroups.com.

Re: [go-nuts] How to clear current line in terminal

[Stephen Illingworth]

This is how I would do it. Note that you must be careful not to insert 
newlines. If you do, terminal control becomes trickier.



package main

import "fmt"

// ClearLine is the CSI sequence to clear the entire of the current line.
const ClearLine = "\033[2K"

func main() {
// print a string that is comparatively long
fmt.Printf("hello world")

// clear line
fmt.Printf(ClearLine)

// the line is cleared but the cursor is in the wrong place. the 
carriage
// return moves the cursor to the beginning of the line.
fmt.Printf("\r")

// print a shorter string to show that the longer string has been 
cleared
fmt.Printf("bye")

// print a newline to move the cursor to next line of terminal
fmt.Printf("\n")
}

On Saturday, 19 September 2020 at 20:47:25 UTC+1 Alexander Mills wrote:

> Yeah sure so it looks like:
>
> clearCurrentLine()  // clears the previous status line
> fmt.Println("foo")
> writeStatusLine()   // writes new status line
>
> where clearCurrentLine() is just like
>
> func clearCurrentLine(){
> //fmt.Printf("\033[0;") // clear current line
> //fmt.Printf("\033[2K\r%d",0);
> //fmt.Fprint(os.Stdout,"\033[y;0H")
> //fmt.Fprint(os.Stdout, "\033[K")
> //fmt.Print("\x1b[2k") // erase the current line
> }
>
> I tried all those ANSI codes, nothing quite worked?
>
>
>
> On Saturday, September 19, 2020 at 12:36:04 PM UTC-7 iko...@gmail.com 
> wrote:
>
>> Can you give some example code?
>>
>>   *Joop Kiefte* - Chat @ Spike 
>> 
>> [image: owiru]
>>
>> On September 19, 2020 at 19:29 GMT, Alex Mills  
>> wrote:
>>
>>
>> Yeah I tried all those ANSI codes, nothing seems to work :(
>>
>> On Sat, Sep 19, 2020 at 11:59 AM Joop Kiefte  wrote:
>>
>>> I tend to do that with ANSI terminal codes, there are pages that explain 
>>> all codes
>>>
>>>   *Joop Kiefte* - Chat @ Spike 
>>>  [image: 
>>> owh4j]
>>>
>>> On September 19, 2020 at 18:44 GMT, Alex Mills  
>>> wrote:
>>>
>>>
>>> Using Node.js with several projects I can use these:
>>>
>>> const rl = require('readline');
>>> process.stdout.write('current line')
>>> rl.clearLine(process.stdout); 
>>> rl.cursorTo(process.stdout, 0);
>>>
>>> this will clear the current line in the terminal, so I can achieve 
>>> something like a status line, but I cannot figure out how to do this with 
>>> Golang, anyone know?
>>>
>>> -- 
>>> 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/d52c998b-bc1e-46fa-901d-f3f992ef4918n%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/370d5724-215b-4261-9181-7b368ec4a228n%40googlegroups.com.

Re: [go-nuts] Re: Is there a gui library for Go, like Gtk+ or similar, which can be used to build statically linked executables ?

[Stephen Illingworth]

I've been using the Go bindings for Dear Imgui with great success.

https://github.com/inkyblackness/imgui-go

On Saturday, 12 September 2020 at 01:05:11 UTC+1 pcha...@pcsw.us wrote:

> There is a gtk binding, but I'm not sure if it's fully cross platform. 
>
> https://github.com/gotk3/gotk3
>
> On Fri, Sep 11, 2020, 6:26 PM Kent Sandvik  wrote:
>
>> I tested fyne on my Mac, hey didn't crash, that's a big plus with these 
>> cross-platform GUI frameworks. The Look is somewhat different but with 
>> some tweaks it could be made manageable. But for any large text-based 
>> application with text styling and so forth  I would use Electron or a 
>> similar browser-engine framework. --Kent
>>
>> On Fri, Sep 11, 2020 at 2:58 PM Serge Hulne  wrote:
>>
>>> I had a look again at "Fyne". It seems to have improved a lot lately, in 
>>> particular the default size for fonts etc seems much better!
>>> Thanks again for the suggestion.
>>>
>>> On Sunday, 2 August 2020 at 23:43:56 UTC+2 ma...@eliasnaur.com wrote:
>>>
 On Sunday, 2 August 2020 at 23:24:20 UTC+2 jake...@gmail.com wrote:

> There is currently no 'clear choice' for GUI in go. It will depend on 
> you needs. Some to look into:
>
> https://bitbucket.org/rj/goey/src/master/
> https://gioui.org/
> https://github.com/andlabs/ui
> https://github.com/goki/gi
> https://github.com/lxn/walk
>

 There's also https://fyne.io.

 Elias

>>> -- 
>>> 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/729a782e-d87f-4ca9-9a08-740fd758d2a6n%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAHC_roHE9sTye127Gd%3DfxvDNXZU_R-yUdazpuskyxHfL9bkOiw%40mail.gmail.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/4f1e8d63-ea3a-4c00-8ffc-20c7135558c4n%40googlegroups.com.

[go-nuts] Re: Conversion to Complex numbers

[stephen . illingworth]

On Friday, 27 March 2020 16:16:18 UTC, Stephen Illingworth wrote:
>
>
>
> On Friday, 27 March 2020 15:58:19 UTC, Brian Candler wrote:
>>
>> On Friday, 27 March 2020 15:42:08 UTC, stephen.i...@gmail.com wrote:
>>>
>>> // float -> complex
>>>
>>> const constFloat = 1
>>>
>>>
>> Did you mean const constFloat = 1.0 ?
>>
>
> Yes. Results are the same. 
>

Corrected test program. Results are the same:

package main

import "testing"

// int -> complex

const constInt = 1

func TestConstInt(t *testing.T) {
_ = complex64(constInt)
}

const constIntExplicit = int(1)

func TestConstIntExplicit(t *testing.T) {
_ = complex64(constIntExplicit)
}

func TestVarInt(t *testing.T) {
varInt := 1
_ = complex64(varInt)
}

func TestVarIntExplicit(t *testing.T) {
varIntExplicit := int(1)
_ = complex64(varIntExplicit)
}

// float -> complex

const constFloat = 1.0

func TestConstFloat(t *testing.T) {
_ = complex64(constFloat)
}

const constFloatExplicit = float64(1.0)

func TestConstFloatExplicit(t *testing.T) {
_ = complex64(constFloatExplicit)
}

func TestVarFloat(t *testing.T) {
varFloat := 1.0
_ = complex64(varFloat)
}

func TestVarFloatExplicit(t *testing.T) {
varFloatExplicit := float64(1.0)
_ = complex64(varFloatExplicit)
}
 

-- 
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/3332e4d4-edb9-4948-9a32-ae035fd110ad%40googlegroups.com.

[go-nuts] Re: Conversion to Complex numbers

[stephen . illingworth]

On Friday, 27 March 2020 15:58:19 UTC, Brian Candler wrote:
>
> On Friday, 27 March 2020 15:42:08 UTC, stephen.i...@gmail.com wrote:
>>
>> // float -> complex
>>
>> const constFloat = 1
>>
>>
> Did you mean const constFloat = 1.0 ?
>

Yes. Results are the same. 

-- 
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/5432c674-a237-493d-924c-9337b074156b%40googlegroups.com.

[go-nuts] Conversion to Complex numbers

[stephen . illingworth]

Hello,

Conversion to complex numbers should be done with the complex builtin 
function, specifying a real and imaginary part. However, is casting to a 
complex type supported or not? Empirically, it seems to me that sometimes 
it is and sometimes it isn't. More confusing is that this behaviour changed 
between version 1.13.6 and 1.14.

Using this test program.

package main

import "testing"

// int -> complex

const constInt = 1

func TestConstInt(t *testing.T) {
_ = complex64(constInt)
}

const constIntExplicit = int(1)

func TestConstIntExplicit(t *testing.T) {
_ = complex64(constIntExplicit)
}

func TestVarInt(t *testing.T) {
varInt := 1
_ = complex64(varInt)
}

func TestVarIntExplicit(t *testing.T) {
varIntExplicit := int(1)
_ = complex64(varIntExplicit)
}

// float -> complex

const constFloat = 1

func TestConstFloat(t *testing.T) {
_ = complex64(constFloat)
}

const constFloatExplicit = float64(1)

func TestConstFloatExplicit(t *testing.T) {
_ = complex64(constFloatExplicit)
}

func TestVarFloat(t *testing.T) {
varFloat := 1
_ = complex64(varFloat)
}

func TestVarFloatExplicit(t *testing.T) {
varFloatExplicit := float64(1)
_ = complex64(varFloatExplicit)
}


Summary of results:


1.13.6  
1.14.1 
const int y y 
const int (explicit type) y n 
variable int n n 
variable int (explicit type) n n 
const float y y 
const float (explicit type) y n 
variable float n n 
variable float (explicit type)   
n n 


I wouldn't want to argue too strongly on this point but for consistency, 
should casting be allowed at all?


Regards

Stephen Illingworth

-- 
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/e09492c7-bbb0-4ff7-865f-d3d7ea57937f%40googlegroups.com.

Re: [go-nuts] Why Discord is switching from Go to Rust

[stephen . illingworth]

On Saturday, 8 February 2020 08:38:40 UTC, Eric S. Raymond wrote:
 

>  Go, on the other hand...I'm an old 
> hand from the same culture the Go devs exemplify. 
>

I'm glad somebody else has said that. For me, Kernighan and Pike's 
involvement was the clinching argument in favour of Go. Coding 
philosophy/culture is important.
 

-- 
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/68b716eb-3f70-4279-8cd8-8543c88ab47c%40googlegroups.com.

[go-nuts] Re: Go 1.13.4 and Go 1.12.13 are released

[Stephen Illingworth]

Build fails here. Using v1.13 to build:

go test proxy running at GOPROXY=http://127.0.0.1:41805/mod
go proxy: no archive rsc.io v1.5.2: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.1.0: file does not exist
go proxy: no archive rsc.io v1.5.1: file does not exist
go proxy: no archive example.com/newcycle v1.0.0: file does not exist
--- FAIL: TestScript (0.00s)
--- FAIL: TestScript/vendor_complex (0.57s)
script_test.go:191: 
# smoke test for complex build configuration (0.571s)
> go build -o complex.exe complex
> [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
[stderr]
package complex
imports runtime: cannot find package "runtime" in any of:
$WORK/gopath/src/complex/vendor/runtime (vendor tree)
/home/steve/Go/go1.13.4/src/runtime (from $GOROOT)
$WORK/gopath/src/runtime (from $GOPATH)
[exit status 1]
FAIL: testdata/script/vendor_complex.txt:5: unexpected command 
failure

--- FAIL: TestIssue7573 (0.01s)
go_test.go:3048: running testgo [build -n -compiler gccgo cgoref]
go_test.go:3048: standard error:
go_test.go:3048: package cgoref
imports runtime: cannot find package "runtime" in any of:
/home/steve/Go/go1.13.4/src/runtime (from $GOROOT)
/tmp/cmd-go-test-589579455/gotest023101038/src/runtime (from 
$GOPATH)
package cgoref
imports syscall: cannot find package "syscall" in any of:
/home/steve/Go/go1.13.4/src/syscall (from $GOROOT)
/tmp/cmd-go-test-589579455/gotest023101038/src/syscall (from 
$GOPATH)

go_test.go:3048: go [build -n -compiler gccgo cgoref] failed 
unexpectedly in /home/steve/Go/go1.13.4/src/cmd/go: exit status 1
FAIL
FAILcmd/go91.345s

-- 
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/d43f9dd9-9cdf-4234-8ab2-0bf8085ba090%40googlegroups.com.

[go-nuts] Watches / Data breakpoints

[Stephen Illingworth]

Hi all,

I have an awkward bug I'm trying to understand and I'm missing something in
my toolbox. Is there any way of monitoring a variable for changes made to
it? For example, I have a pointer type and I want a debugger to break
whenever its value (ie. what it points to) changes.

I call this a "watch" but I believe it's sometimes referred to as a "data
breakpoint".

I've looked at delve and can't see anything like it. I've had a quick look
at VSCode and Goland and I can't see anything there either. Is there
anything I've missed?

Help

Stephen Illingworth.

-- 
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/CAPmHGLPa0sgU9NkewBmZKhqVV-fZaaAni8Uaq%2BY_aUQstSEeYA%40mail.gmail.com.