-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Each function to have its own file in order to speed up compilation #13
Comments
Hmm, that's a cool idea I hadn't thought about. (Although I suppose it'll only help in recompilations) |
@hugomg I implemented a WIP version on my fork of the project, the benefits are immense, speeding up compilation especially when using Make's jobs. If you think this is a good feature, I will create an implementation from scratch for Lua-aot |
Interesting! So if I understand correctly this is mostly to exploit more parallelism, right? That is, this isn't about speeding up recompilations by skipping over functions that did not change? |
Not only that, but with initial compilations its also extremely useful because of the fact it can be parallelised |
How does it work during recompilations? If I were to edit a single function in the Lua source file, how would LuaAOT know that it should not recreate the C files for the other functions? |
It does recreate them, but make can tell that the files are the same, so it only recompiles the file that changed (And also the file with the source array, the main generated file) |
Oh, how? I assumed it would only look at the timestamps. |
|
Nevertheless, just the parallelization would be super cool. How much faster did it get when compiling Teal? |
lemmie get the actual numbers, but it is much much faster... ...with the downside that for some reason teal, out of any lua module I have tried, has a "syntax error in module" |
this might be a lua-aot issue? I just tried it with a commit from master and it also failed |
Paralelised (this is tl.lua + argpsarse.lua + tl (the teal CLI thing)): real 35.88
user 181.62
sys 27.32
360148992 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
8005054 page reclaims
17099 page faults
0 swaps
0 block input operations
0 block output operations
0 messages sent
0 messages received
381 signals received
792 voluntary context switches
267447 involuntary context switches
38190257 instructions retired
40020550 cycles elapsed
593920 peak memory footprint and then standard:
That was with Paralelised: real 113.44
user 391.85
sys 36.62
973549568 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
10396353 page reclaims
7057 page faults
0 swaps
0 block input operations
0 block output operations
0 messages sent
0 messages received
402 signals received
728 voluntary context switches
418147 involuntary context switches
36537154 instructions retired
43363504 cycles elapsed
557056 peak memory footprint real 184.18
user 187.13
sys 7.34
1475518464 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
1498323 page reclaims
2391 page faults
0 swaps
0 block input operations
0 block output operations
0 messages sent
0 messages received
9 signals received
277 voluntary context switches
373720 involuntary context switches
41433463 instructions retired
45485784 cycles elapsed
565248 peak memory footprint This is with Clang, I will test with GCC soon |
GCC -O0:
Standard:
GCC -Os -flto: Paralellised:
standard:
|
Right now, especially for large projects (I tested with teal, which is currently 11012 lines) the generated C source files are MASSIVE (the source file for teal was nearly 600k lines long), and so compilation is very sluggish (see figure 1). Build systems such as Make allow for parallel execution in order to compile files, so if each function got its own file (possibly behind a flag) that system could be utilised.
The text was updated successfully, but these errors were encountered: