V should warn if -prod used and only tcc is available.

[highfestiva]

V version: V 0.2.2 5d653a3
OS: Windows 10

What did you do?
v -prod run examples/nbody.v

What did you expect to see?
I had hoped to see improved performance compared to the original go implementation.

What did you see instead?
A three (3!) magnitudes slower execution time than the original. Is this to be expected? I thought v was performant, especially compared to a language with a runtime, or did I miss something?

[ntrel]

What C compiler are you using?

[dumblob]

@highfestiva could you also run current nbody written for Go on your machine with the same setup as you did with V's nbody? The Go benchmark you referenced is very old and I suspect it wasn't run on your machine (both HW-wise and SW-wise). So it's far from being comparable.

For actually curated and current benchmarks (which I personally find very informative and useful) I'd strongly recommend looking at https://github.com/kostya/benchmarks (though they use only V releases and not the latest master branch which might slightly vary).

[highfestiva]

@ntrel I'm pretty sure I don't have any installed at the moment. v comes with thirdparty/tcc/tcc.exe, is that what v uses to build executables? @dumblob 3.3 magnitues! I'm pretty sure no sensible computer is 1700 times faster than my high performance machine.

[highfestiva]

@dumblob My computer is ok:

$ time /c/prog/go/bin/go run nbody.go 50000000
-0.169075164
-0.169059907

real    0m6.136s
user    0m0.047s
sys     0m0.187s

I.e. 4% faster than the computer @ language shootout.

[dumblob]

@ntrel I'm pretty sure I don't have any installed at the moment. v comes with thirdparty/tcc/tcc.exe, is that what v uses to build executables?

Yes, but it's not being used for -prod builds (and if accidentally is without issuing any warning to the user about consequences, then it's a bug).

@dumblob 3.3 magnitues! I'm pretty sure no sensible computer is 1700 times faster than my high performance machine.

LD_PRELOAD=/path/to/my/lib/with/sleeps/everywhere.so v -prod run examples/nbody.v

This can be much more than "just 3.3 magnitudes" 😉. And this is a sensible computer (i.e. standard HW and standard SW equipment). So thanks for the actual measurement on your machine!

But fun aside, the problem seems to be really the compiler as noted above. @ntrel any hints? Maybe simply installing any Visual Studio (assuming Windows) or GCC (assuming any platform) should solve it.

[medvednikov]

When benchmarking you should benchmark the binary, not v run

Most of v run's time is taken by the compiler.

[ntrel]

v comes with thirdparty/tcc/tcc.exe, is that what v uses to build executables?

Yes, but it's not being used for -prod builds

If there's no other C compiler installed, tcc has to be used, it does do some light optimization. A warning message probably should be printed though.

[medvednikov]

With correct measurement I get expected results:

v nbody.v && time ./nbody 34.11
v -prod nbody.v && time ./nbody 2.87

[highfestiva]

Aha, so I need to install a C compiler to get some performance under Windows! Perhaps that should be mentioned so it's not missed. Many Windows users might do like me and completely miss this. What is the recommended C compiler for Windows 10? @medvednikov Note that it takes over four minutes to run with -prod on Windows with the default thirdparty compiler.

[JalonSolov]

msvc is probably the best for windows specific code, but it is a disk and memory hog.

You can get the latest version of gcc for Windows from http://winlibs.com/

[ntrel]

@highfestiva see https://github.com/vlang/v/wiki/Installing-a-C-compiler-on-Windows

[medvednikov]

I agree -prod should print a warning if only tcc is available.

[spytheman]

I get these results with gcc-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0:

0[13:02:49]delian@nemesis: /v/vmaster $ go build -o nbody.go-3.go_run nbody.go && xtime ./nbody.go-3.go_run 50000000
-0.169075164
-0.169059907
CPU: 6.26s      Real: 6.27s     Elapsed: 0:06.27        RAM: 1876KB     ./nbody.go-3.go_run 50000000
0[13:03:04]delian@nemesis: /v/vmaster $ v -cc gcc-10 -prod examples/nbody.v && xtime examples/nbody
-0.169075164
-0.169059907
CPU: 6.61s      Real: 6.61s     Elapsed: 0:06.61        RAM: 1852KB     examples/nbody
0[13:03:20]delian@nemesis: /v/vmaster $ v -d no_bounds_checking -cc gcc-10 -prod examples/nbody.v && xtime examples/nbody
-0.169075164
-0.169059907
CPU: 5.66s      Real: 5.66s     Elapsed: 0:05.66        RAM: 2064KB     examples/nbody
0[13:03:30]delian@nemesis: /v/vmaster $

[highfestiva]

Although a lot better, I still found V's performance only about 2% faster than the go implementation (got the same performance from mingw-64 as msvc). The only way I see V being an alternative to Rust (for me, and probably many like me) is if its performance is on par. Are there plans to enhance performance? (Rust n-body is twice as fast as V and Go.)

[dumblob]

@highfestiva there are basically no optimizations in the compiler (as it's still pre-alpha quality and everybody works on correctness first). But feel free to check out some opened issues regarding "low level" performance: #1839

[medvednikov]

@highfestiva V compiles to C, so the perf should be the same. On this page C/C++ are 25% slower than Rust.

So it's either a different algorithm or a bug/performance issue in vlib, which should be fixed.