[go-nuts] Re: Strange benchmark results

2021-05-15 Thread peter so
For your sliceinsert microbenchmarks, you don't provide the Go version, you 
don't provide memory allocation statistics, and you only provide results 
for a single data point.

My results for several values of N:

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

There are significant differences in CPU performance for different values 
of N, ranging from 1:1 to 2:1 for append versus precise implementations.

I am unable reproduce your result.

Peter


On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:

>
> package main
>
> import "testing"
>
> const N = 1615119
> // It is strange that if N is large enough,
> // the one line implementations are fast as the others.
> // And if N is odd number, the InsertOneline_Disassemble
> // implementation is about 10% faster than the others.
>
> func init() {
> println(" N =", N)
> }
>
> func InsertOneline(s []int, k int, vs ...int) []int {
> return append(s[:k], append(vs, s[k:]...)...)
> }
>
> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
> z := append(vs, s[k:]...)
> return append(s[:k], z...)
> }
>
> func InsertVerbose(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, len(s) + len(vs))
> copy(s2, s[:k])
> copy(s2[k:], vs)
> copy(s2[k+len(vs):], s[k:])
> return s2
> }
>
>
> func InsertVerbose_b(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, 0, len(s) + len(vs))
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> func InsertVerbose_c(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> var s1 []int
> func Benchmark_InsertOneline(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/5
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1 = InsertOneline(x, k, y...)
> }
> }
>
> var s1b []int
> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1b = InsertOneline_Disassemble(x, k, y...)
> }
> }
>
> var s2 []int
> func Benchmark_InsertVerbose(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s2 = InsertVerbose(x, k, y...)
> }
> }
>
> var s3 []int
> func Benchmark_InsertVerbose_b(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s3 = InsertVerbose_b(x, k, y...)
> }
> }
>
> var s4 []int
> func Benchmark_InsertVerbose_c(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s4 = InsertVerbose_c(x, k, y...)
> }
> }
>
>
> The result:
>
> $ go test -bench=. -benchtime=3s
>  N = 1615119
> goos: linux
> goarch: amd64
> pkg: a.y/bench/sliceinsert
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> Benchmark_InsertOneline-4693   4741509 ns/op
> Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
> Benchmark_InsertVerbose-4764   4627334 ns/op
> Benchmark_InsertVerbose_b-4  769   4958537 ns/op
> Benchmark_InsertVerbose_c-4  661   4855514 ns/op
>

-- 
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/89741678-c394-4ec7-8d7d-adb083e9e4e1n%40googlegroups.com.


[go-nuts] Re: Short Variable Declarations Are Oversold

2023-04-22 Thread peter so
I disagree. I don't have your problem. Most (just about all) Go code I read 
uses short variable declarations.

There are several popular assistive technologies that you should try. For 
example,

Visual Studio Code
https://code.visualstudio.com/   

GoLand
https://www.jetbrains.com/go/

peter
On Saturday, April 22, 2023 at 6:31:11 PM UTC-4 jlfo...@berkeley.edu wrote:

> As a beginning Go programmer, I was initially attracted to the short 
> variable declaration syntax.
>
> It’s great for declaring variables of a simple type. What could be wrong 
> with letting the Go compiler infer a variable type by looking at what’s 
> being assigned to the variable, such as:
>
> func main() {
>
> x := 10
>
> }
>
> Nothing. This is trivially the same as
>
> func main() {
>
> var x int
>
> x = 10
>
> }
>
> I didn’t have to waste my precious time by entering an explicit type 
> declaration for “x” when the compiler already knew what it was.
>
> But what about something like
>
> import “os”
>
> func main() {
>
>  file, _ := os.Open(os.Args[1])
>
> }
>
> Again, nothing is wrong, at least not until I have to pass “file” to 
> another function. For example
>
> import “os”
>
> func main() {
>
>  file, _ := os.Open(os.Args[1])
>
> myfunc(file)
>
> }
>
> func myfunc(file ???) {
>
> }
>
> What type should I use to declare “file” in the parameter list for 
> myfunc()? As a new Go programmer I have to admit that I haven’t memorized 
> all the types used in the Go standard library. So, I have to break off 
> working on myfunc() to look up the type returned by os.Open(). This isn’t a 
> huge deal, but it’s a distraction and can waste time. I suppose that as I 
> gain experience with Go, I’ll have to do this less and less.
>
> But, it doesn’t matter how experienced I am with Go when I start using 
> user-defined types from packages that aren’t in the Go standard library. 
> For example (from Ben Hoyt’s excellent goawk program):
>
> import "github.com/benhoyt/goawk/parser"
>
> func main() {
>
> prog, err := parser.ParseProgram(fileReader.Source(), parserConfig)
>
> myfunc(prog)
>
> }
>
> func myfunc(prog ???) {
>
> }
>
> Since I’m going to have to look up the returned types of 
> parse.ParseProgram anyway, what’s the advantage of using a short variable 
> declaration? They just delay the inevitable.
>
> Short definitions detract from one of Go’s primary goals - readability. I 
> started using Go in the first place because I wanted a strongly typed 
> language with explicit type declarations. 
>
> As a result of all this, I’ve started to avoid short variable 
> declarations, except when I’m initializing a variable inside an "if" 
> , "for" 
> , or "switch 
> ” statement, such as
>
> if v := math.Pow(x, n); v < lim {
>
> }
>
> for i := 0; i < 10; i++ {
>
> }
>
> switch os := runtime.GOOS; os {
>
> }
>
> In these cases I have no choice if I want to declare local temporary 
> variables since long declarations aren’t syntactically allowed.
>
> I doubt if this note will change anybody’s mind but it’s something to 
> think about.
>

-- 
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/f73aeed2-7784-47a8-9978-dc1b2178a24dn%40googlegroups.com.