[go-nuts] Re: Tooling experience feedback

2016-10-18 Thread ondrej . kokes
go tool trace was nicely explained here https://groups.google.com/forum/#!topic/Golang-Nuts/Ktvua7AGdkI and had no proper documentation at the time. Would be good if it had a high level overview like that On Tuesday, 18 October 2016 19:54:49 UTC+1, Jaana Burcu Dogan wrote: > > Hello gophers, >

[go-nuts] Re: Generating execution trace diagram for a go program

2016-08-04 Thread ondrej . kokes
This is excellent, really helpful. The -help flag only mentions testing and casual searching only again pops up with info on more testing, I couldn't see anything on actually using it for running a generic binary. Perhaps it would be worth adding this to the documentation? + things like not

[go-nuts] Re: Data locality in large slices

2016-08-03 Thread ondrej . kokes
(I have now recreated it on my Mac, under 1.7rc5, the runtime differences are still there.) I thought the compiler was removing these as you suggest, but then StartEnd and EndStart had wildly different running times, despite using the very same values. So I added dummy assignments to double

[go-nuts] Re: Data locality in large slices

2016-08-03 Thread ondrej . kokes
Downgrading to 1.6.3, I'm also getting consistent benchmark results. I'll try 1.7 on my Mac at home later today, to see if it's a 1.7 thing or a Windows thing or...? On Wednesday, 3 August 2016 14:55:20 UTC+1, C Banning wrote: > > PS - that's with Go v1.6. > > On Wednesday, August 3, 2016 at

Re: [go-nuts] Re: An efficient runtime expression evaluation

2016-07-18 Thread ondrej . kokes
I think this pretty much covers it _, err := VirtualProtect(fn.body, 0x40) if err != nil { panic(err) } // OH GOD WHAT HAVE I DONE??? type callstub struct{ fn func(*Memory) } Excellent and worrying work :-) A 2x difference between interpreted and native is pretty rad. It strongly

[go-nuts] Re: An efficient runtime expression evaluation

2016-07-17 Thread ondrej . kokes
Cheers, I tried replicating my endeavours (https://play.golang.org/p/Qxoo2ASac6), sorry if it's still too verbose. It's essentially rewriting the inbuilt ast.Node into a simpler nested struct and then walking it. In testing the performance, I started adding algebraic expressions, which make