Performance issue without -prod option

[nixpare]

I was doing some Advent of Code in order to learn some V, when I noticed that it was taking a long time to run the program, so i decided to rewrite the same program in Go (the program is just using some slices and ranging over them, so it should be fair to compare them in this way). Go was 6x faster than V! After some browsing, I tried to compile with the -prod option and things turned around: now V was more than 2x faster than Go. So the question is: why is there such a difference (more than 12x) from the develop build and the production build?
This is the output of the benchmark I make (if you want to see the sources I will post them):

[2024-03-03 12:41:56.00] -    Info: Process .\go-version\go-version.exe started
        [   0.039s] - Seeds ranges: 10
        [  17.123s] - Finished seed range 1
        [  18.637s] - Finished seed range 2
        [  73.086s] - Finished seed range 3
        [ 115.665s] - Finished seed range 4
        [ 118.259s] - Finished seed range 5
        [ 123.522s] - Finished seed range 6
        [ 124.613s] - Finished seed range 7
        [ 149.486s] - Finished seed range 8
        [ 155.540s] - Finished seed range 9
        [ 165.824s] - 84206669
        [ 165.824s] - Finished seed range 10
[2024-03-03 12:44:41.87] -    Info: Process exited in 2m45.8260826s with code 0

[2024-03-03 12:44:41.88] -    Info: Process .\v-version\v-version-noprod.exe started
        [   0.053s] - Seeds ranges: 10
        [  84.314s] - Finished seed range 1
        [  92.457s] - Finished seed range 2
        [ 377.347s] - Finished seed range 3
        [ 583.153s] - Finished seed range 4
        [ 596.139s] - Finished seed range 5
        [ 623.185s] - Finished seed range 6
        [ 628.586s] - Finished seed range 7
        [ 755.614s] - Finished seed range 8
        [ 784.956s] - Finished seed range 9
        [ 836.519s] - Finished seed range 10
        [ 836.519s] - 84206669
[2024-03-03 12:58:38.44] -    Info: Process exited in 13m56.5205331s with code 0

[2024-03-03 12:58:38.46] -    Info: Process .\v-version\v-version.exe started
        [   0.041s] - Seeds ranges: 10
        [   6.887s] - Finished seed range 1
        [   7.587s] - Finished seed range 2
        [  33.196s] - Finished seed range 3
        [  50.003s] - Finished seed range 4
        [  51.012s] - Finished seed range 5
        [  53.347s] - Finished seed range 6
        [  53.748s] - Finished seed range 7
        [  64.745s] - Finished seed range 8
        [  67.094s] - Finished seed range 9
        [  71.402s] - Finished seed range 10
        [  71.403s] - 84206669
[2024-03-03 12:59:49.91] -    Info: Process exited in 1m11.4042422s with code 0

I understand that the default build is much faster to compile, but considering that the default took 0.3s to compile while the production one took 4.0s, I don't think it's a fair tradeoff for 12x slower execution times.
So the second question is: is there a way to mitigate this problem and find a middleground?
Thanks for your time.

[kbkpbot]

In default, V use tcc as the C compiler, which compile speed is very fast, but the generated binary is not well optimization.
In production mode, V use gcc as the C compiler, and set -O3 -flto optimization flags, this will cause a huge optimization, but with a slower compile speed.

So, for develop process, you need a faster compile time and debug, you'd better use default tcc compiler.
When you done, you can use -prod mode, this will generated a release version of binary.

Maybe you can try with:

v . -cc gcc

or

v . -cc clang

[JalonSolov]

@nixpare Yes, this huge difference is expected, for now.

The new version of the compiler will give you the "not so optimized" version you want, but it will be at least several months before it is even ready to test.

Go does give you the "not so optimized" version now, as it does do optimizations, just not as well as most C compilers (since they've been around longer) other than tcc (which does none at all).

You can improve the speed now with tcc by changing your algorithm and/or your command line options to V, but that is a more advanced solution.

For example, if you have written a function that works on an array, and you know that the function won't try to access outside the array bounds, then add the @[direct_array_access] attribute on the line above the function declaration and the you will see a speed increase.

In other words, explore all the things V can do to help you, and the code will improve no matter what else you do.

[MCausc78]

If you don't care about portability and want boost performance: -cflags '-march=native'

[JalonSolov]

V does that by default.

[nixpare]

Thanks everyone for the suggestions, @JalonSolov I will wait for the new compiler, along with the windows support for coroutines.

[Wajinn]

Maybe you can try with gcc compiler instead of the default tcc:

Good that you have pointed this out. It seems various people are overlooking the different compilers that are available, with the different flags and optimizations levels possible. From what I've read, the point of tcc was for rapid development. Sorry to digress, but think vtcc might be something to keep an eye on. If the person is trying to get every possible ounce of size reduction and/or performance, then one can try the other compiler options (gcc, clang...).

[Wajinn]

From time to time, there are such "speed threads" of V versus other languages that come up. Often the situation is the person is not aware of different flags and compiler options that they can use or the way in which the code can be written or algorithm used can be changed.

Possibly some links to check:

(build) Compilation commands for the V language
On the benefits of using C as a language backend
strings need an efficient way to check if they contain a char
Note: last one started with a claim that an equivalent go program was 145x faster, then after some suggestions, V was revealed to be just as fast and possibly faster.