What's the plan with the "native" backend?

[rempas]

I was just wondering what's the general plan with "native". When outputting C, we can use "TCC" to get crazy fast compilation times and "GCC"/"Clang" to get great runtime performance. So what's the idea of having "native"? What purpose it curves? Do you plan to make it something in between or do you plan make the performance of "GCC"/"Clang" but make it as fast as possible (which make sense as they'll be no intermediate code and assembly).

If compile times is important, I would also suggest a mode (compiler switch) where the compiler will parse every file and create the executable at once rather than creating objects files and then link them.

This will be great for production builds when the end users want to compile software from source and don't want to keep the object files.

If you ask me, native is the way to go! Thanks for your work regardless!

[JalonSolov]

The native backend directly generates executables, no linking is done.

The plan is for the native backend to become the default backend (once it is fully working), with C as an optional backend. TCC will no longer be distributed with V.

At first, there will likely be very little optimization done in the native backend... it needs to work, first, so if you want fully optimized code you'll still want to use the C backend. However, by default, the native backend will likely always produce less code, which may be enough of a boost that you only need the C backend for truly performance critical code.

Once everything is working as it should, people can invest time in optimization for the native backend.

[rempas]

Thank you! That sounds awesome and makes a lot of sense to me! So, I should report every bugs I find when using the "native" backend right? I have actually find one right away!

[JalonSolov]

Well, it can't hurt, but the native backend is still in very early stages, so you may run into a lot of problems.

[srackham]

@JalonSolov The proposed move to native-by-default is concerning because the the benefits of using C as a language backend are huge — IMO it's the best design decision the V languages designers made. It's the reason V and C types map one-to-one and that C interoperability is so seamless and it sets V apart from other languages.

What exactly is the rationale for adding another way to do the same thing? The only one I've seen seems to be compiler performance, but the default V-with-TCC performance is stellar and the lack performance doesn't seem to rank high on the concerns of users.

Will code that wraps C code and libraries still work out of the box?

One thing's for certain: going native will divert a lot of valuable developer time and energy, create confusion, and Balkanise V code bases into C and native code.

[JalonSolov]

Most people seem to discount the amount of time developers spend compiling... and compiling... and compiling... ad nauseum.

Anything that reduces that time is a good thing.

One advantage of having a native backend is that no C compilers will be necessary, and as long as you don't call external (as in non-V) libs, no linker, either.

Of course you can still call those external libs, and your code will link just fine, but you still won't need a C compiler. So yes, it will still work "out of the box" to wrap C.

Once your code is developed, and you're ready to release, you can then compile with the C backend, and take advantage of the optimizations, etc., they have spent years working on.

In other words, the C backend isn't going away, it just won't be the default.

Another advantage of the native backend is that you don't have all the overhead of C... as an example of both the speed and size savings:

$ time v examples/hello_world.v

real    0m0.092s
user    0m0.092s
sys     0m0.042s
$ ls -l examples/hello_world
-rwxr-xr-x 1 jamie jamie 814688 Oct 11 19:20 examples/hello_world
$ time v -native examples/hello_world.v

real    0m0.005s
user    0m0.005s
sys     0m0.005s
$ ls -l examples/hello_world
-rwxrwxr-x 1 jamie jamie 189 Oct 11 19:20 examples/hello_world
$ 

So... a tiny fraction of the time to get an executable that is a very tiny fraction of the size.

In this case, it also runs faster, both because it loads faster (being so much smaller), and there is less excess "drek" for the CPU to wade through before it executes your code.

Another advantage is, as mentioned, not every program has to be optimized. If it runs fast enough with the -native version, there's no reason to waste the time on an "optimized" build with the C version.

$ time v -prod examples/hello_world.v

real    0m3.467s
user    0m3.342s
sys     0m0.093s
$ ls -l examples/hello_world
-rwxr-xr-x 1 jamie jamie 188728 Oct 11 19:22 examples/hello_world
$

Sure, the code is now only ~1/8th the size of the unoptimized build, but look at the difference in time to build it... and it is still magnitudes larger in size than the -native version... and still runs slower than the native version on a lot of code.

There's no reason we can't add optimization into the -native builds. It won't be there at first, but it can be added.

As for "balkanization"... why do you think so? The goal is that the same V code compiles no matter which backend you use. The only difference is in the final executable/lib/javascript/whatever.

Finally... it's all volunteer. If nobody wanted to work on a native backend, we wouldn't have one. I, however, think it'll be worth it.

[srackham]

@JalonSolov Thank you for your prompt and informative reply.

"as long as you don't call external (as in non-V) libs"

This was one of my concerns and the reason for my use of the term "Balkanisation":

• Modules like https://github.com/vlang/pcre and https://github.com/vlang/markdown will no longer compile unless you install a C compiler and include a command-line -cc option?
• Native is all-or-nothing i.e. you can't specify native or C on a module by module basis?

The performance gains you quoted are impressive, most notably the executable sizes, and they will certainly make headlines, but it still strikes me as a solution in search of a problem.

Wishing you all the best with this endeavour (so long as the baby doesn't get thrown out with the bath water).

[JalonSolov]

Well, we (I, at least) would prefer to have pure V versions of those pieces. But yes, to use some current modules, you will need a C compiler.

It can be module by module, if you compile the modules separately with -shared and link with them, instead of doing a simple import.

There is a very real need for the native output right now, in embedded systems, where size of the program is paramount over speed.

In any case, we'll see how it all pans out.

[srackham]

@JalonSolov I'm reassured, and you're right about embedded systems — get that right and you'll be well along the path to world domination :-)

I'm sure it'll all pan out if V's progress to date is anything to go by.

[Wajinn]

I'm also very concerned about it being considered to ditch TCC (at least keep that one around). The ability for V to compile to C, as well as strong interop with C, is very important. Don't get me wrong, totally want a native backend too, but not at the expense of dropping the C backend and V's modified TCC.

[bogen85]

The C backend will not be dropped. That was not what was said.

The plan is for the native backend to become the default backend (once it is fully working), with C as an optional backend. TCC will no longer be distributed with V.

./v help build
Usage: v [build flags] ['run'] <target.v|target_directory> [run options]

   -b <backend>, -backend <backend>
      Specify the backend to use while building the executable.
      Current list of supported backends:
      * `c` (default)       - V outputs C source code which is passed to a C compiler to be compiled.
      * `interpret`         - Same as `v interpret` to run the V program
      * `js`                - V outputs JS source code which can be passed to NodeJS to be ran.
      * `js_browser`        - V outputs JS source code ready for the browser.
      * `js_node`           - V outputs JS source code to run with nodejs.
      * `js_freestanding`   - V outputs JS source code with no hard runtime dependency.
      * `native`            - V outputs native executable (see -arch x64|arm64 and -os linux|macos) (EXPERIMENTAL).

What was said was C would not be the default backend.

The default backend will be native.

v -b c ... will use the C backend

Other backends will be added, and they will be available as well via -b

[Wajinn]

Thanks for clarification. Though, still think V's TCC should be distributed with V, for greater convenience. Oh, and your FPC backend project looks very interesting as well.

[yerlaser]

I would disagree on these. On the contrary, having TCC bundled is a concern to me. For one thing, it's another piece that needs to be maintained, patched etc. taking away valuable resources. And for users of V compiler it's also another piece of binary blob running on their systems.

[Wajinn]

I would disagree on these. On the contrary, having TCC bundled is a concern to me. For one thing, it's another piece that needs to be maintained, patched etc. taking away valuable resources. And for users of V compiler it's also another piece of binary blob running on their systems.

V will always have a C backend as one of its options, as bogen85 clarified for us. TCC is very small, compile times are very fast, and is often an easy to directly use once downloaded and doesn't require additional setup. Additionally, various V users will be doing some level of C interop or in need of a C compiler. Such that they may want to compile their V program to C first, to be used with other C files.

I think the better route, once the pure V backend is mature, is to have some optional switch or ask whether or not to download TCC.

[JalonSolov]

The only reason tcc is included now is for fast dev compiles.

Once the native backend is complete, there will be no need for tcc - if you want to use the C backend after that, you will be much better served using gcc, clang, zigc, fil-c, or any of the other C compilers that give you all the advantages over tcc (except for speed of compiles).

There is also nothing stopping someone from installing tcc on their own, and using -cc tcc, but it simply won't make sense for V to include tcc after the native backend works.

[programmingkidx]

We need to make improving the native backend a Google Summer of Code project.

https://summerofcode.withgoogle.com/programs/2026

[JalonSolov]

The native backend is already being heavily improved via the v2 change Alex has been working on.

[Jengro777]

The native backend is already being heavily improved via the v2 change Alex has been working on.

Looking forward to