On Tue, Jan 28, 2020 at 7:33 AM nilsocket <nilsoc...@gmail.com> wrote:
> Attached two files main.c and main.go, > both try to compute fib(40), 20 times on `x` no.of threads/goroutines. > fib(40) is recursive. > > *Prerequisites for C:* > > 1. libuv (https://github.com/libuv/libuv) > > > > *Compile*: > > - *C :* > - *Unoptimized:* > > * gcc main.c -lpthread -luv * > > > - *Optimized:* > gcc-O3 main.c -lpthread -luv > > > - *Go :* > - go build > > > *Run:* > > - > > *C:time UV_THREADPOOL_SIZE=x ./a.out // substitute `x` with physical core > count * > - > > *GO:./temp x // substitute `x` with physical core count * > > > Results: > > Thread CountC (Optimized)C (Unoptimized)GO > 1 4.38s 11.36s 11.7s > 4 1.12s 3.1s 2.9s > 8 1.1s 2.9s 2.7s > > > Laptop with 4 physical cores(8 logical cores). > > Why can't go provide Optimization flag? > I understand go developers want compiler to be simple, but the difference > seems too big to leave it out. > > But isn't there any possibility to abstract the complexity and provide > optimization flag? > Go doesn't provide an optimization flag because it always optimizes. Your program amounts to a microbenchmark of the tail recursion optimization. The Go compiler doesn't optimize tail recursion, because it confuses stack traces and breaks runtime.Callers. The C compiler has no such constraints. You might be interested in https://golang.org/issue/22624 . There will always be microbenchmarks in which C code executes faster than Go code. Microbenchmarks can be useful if analyzed with care, but the real question for performance is always how a real program behaves. Ian -- 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/CAOyqgcVVGXCQssZ%3Dowgfuv_z1OBMv_8sdG36PER7BcLFsrAtxw%40mail.gmail.com.
