2 questions that are relevant to Vox's compile and runtime performance

[rempas]

First of all I want to say that I'm watching Vox with great interest and I'm glad you can work on it and I hope you are having fun with it. Now, I wanted to make two 2 question about the current state of Vox. Both of them has to do with performance. Here I go!

1. What is the current runtime performance of Vox. How many optimizations (if any) Vox does? In this issue, you said that it is planned to have a couple of more optimizations and intrinsics (I don't even know what's that, lol) so we can have 1x-2x the performance of GCC/LLVM. So I'm just wondering what's the current situation and if these optimizations (and the other thing) are a priority.

2. Why is Vox ~5 slower than TCC? So you also told me that in the same issue. Now the reason this seems really weird to me is that both TCC and Vox are a full toolchain consist of a compiler/assembler/linker. So how can TCC be so much faster when both of them do the same thing? Also it should actually being that Vox would be not only as fast but even faster than TCC as TCC is also way way older so probably older and worse practices where used there and alos TCC is a compiler to C which is know for being slower at compilation because of their preprocessor. Do you think that D's phobos is a slow library (on runtime) versus libc so this is why this is happening? Now this question may be stupid to you cause you know how things work but I became interested on learning assembly lately and low level programming so I really thought about that and I would like to know how things work if you have some time to tell me 1 or 2 things of course. In any case, thanks for your work on Vox and thanks for reading though here.

[MrSmith33]

1. Optimizations are not a priority atm. I want to make the compiler much more robust first and fix as much corner cases as possible.
2. Vox is slower due to higher number of passes and higher number of Intermediate Representations used. TCC is closer to a single-pass compiler, because C doesn't need to support forward references. There are of course ways to speed things up a bit, but going to simpler compiler means cutting more corners (which I already cut too many of). Now I am moving towards more systemic solutions instead of hacky ones.
   Atm we are at ~1.2M LoC/s.
   Frontend has big problems with analysis order, which leads to bugs. This is very hard problem to solve. I'm would be ok with trading some speed to gain correctness in the frontend.
   Now, backend can be run in multiple threads, and that is something I want to do in the future.
   phobos vs libc is not really at play here, cause I mostly do not use them in the compiler.
3. Some resources for learning assembly
   • https://godbolt.org/
   • https://www.felixcloutier.com/x86/
   • https://defuse.ca/online-x86-assembler.htm
   • Try reading what assembly is generated for your high-level code. You can do this by pasting code at godbolt site, or by looking in the debugger. If you want to know what each instruction does, consult the felixcloutier site or intel manuals

[rempas]

TCC is closer to a single-pass compiler, because C doesn't need to support forward references

Interesting! I though about this problem myself too and how we could solve it. If I understand correctly and If I'm not forgetting about something, we can solve this with a simple design of having lists to check what is missing and what not. For example, there is a list with all the symbols that exists (different for each symbol), when someone calls/uses a symbol, we check the list and if the symbol doesn't exist, then we add the function to another list that has symbols whose definitions were not found. Every time we define a new symbol, this list is also checked and if we defined a symbol from that list then it is simple removed. So this will be like a simple dependency system for symbols. If what's happening now is doing a pass just to find the symbols that exist then I think what I said will make things much faster! I don't know if I explained it great and you got it but if you didn't and you are interested, tell me so I can make an example.

I'm would be ok with trading some speed to gain correctness in the frontend.

Totally agree!! Keep in mind that while super fast compilation times are important (and not only for me), having a compiler that works is top priority like you said yourself so yeah, glad you see it that way!

Atm we are at ~1.2M LoC/s.

Interesting! I though that this number was 1M (unless I'm confuse it with Vlang or something else idk) so does this mean that Vox is getting even faster without changing its design??? WOW!!!!

phobos vs libc is not really at play here, cause I mostly do not use them in the compiler.

What do you mean? I'm talking about the compiler implementation (the one written in D). If you not mostly using the system's libc or D's std phobos than what are you using? Do you write assembly to create the compiler? Or is there something I don't get?

Also thanks a lot for the sources! I already read one so these extra sources will come in handy, especially the "godbolt"!

[MrSmith33]

What do you mean? I'm talking about the compiler implementation (the one written in D). If you not mostly using the system's libc or D's std phobos than what are you using? Do you write assembly to create the compiler? Or is there something I don't get?

I'm using stdlib ofcourse, but what I'm saying is that those aren't used on hot paths

[rempas]

Oh! Ok, It now makes sense! Not that you couldn't write you own assembly of course but I don't find the reason to do that In this case

[MrSmith33]

It's actually been a while since Vox has been doing 8.65s for 10M LoC, I usually just round number up to a round number of 1M LoC/s. And it is on AMD 3950x.

[rempas]

The performance is amazing however what I'm afraid of is the fact that there is no linker so everything must be compiled again and again. So for bigger projects this will be a pain because most of the times, huge projects, have hundreds of thousands LoC but they also have libraries that are also huge. So you may see a huge project with a codebase of 500K Loc but with each dependencies, it may be 2-3M LoC that will have to get recompiled again and again for every small change to any of the files. However you said that you want to implement a linker so I trust you on that one