4 ms·
The Zig build system is now able to run tasks in parallel. To avoid overloading the system (ie to prevent OOM) it asks you to define MaxRSS for each task, resul
by kristoff_it 4y ago
The Zig build system is now able to run tasks in parallel. To avoid overloading the system (ie to prevent OOM) it asks you to define MaxRSS for each task, resulting in pretty sweet usage consumption: https://ibb.co/FW9kpxT https://ibb.co/FW9kpxT
On a M1 Ultra studio (the same from my screenshot above) it takes me 6 mins to run the entire compiler test suite for arm64-linux (I do development in a Linux VM), which is pretty sweet.
Note that this is one stepping stone for getting good performance from Zig, but it's not yet incremental compilation with in-place binary patching [1]. That's still a work in progress.
[1] https://kristoff.it/blog/zig-new-relationship-llvm/ https://kristoff.it/blog/zig-new-relationship-llvm/
- ksec 4y agoJust want to say your first link trigger fraud protection alert.
- bonzini 4y agoIs it possible to use zig without the zig build system, in order to slowly integrate a new language in an existing program? For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?
- acqq 4y agoIf I understand your question it is: Is it possible to write zig modules which would be liked to the bigger project otherwise written in C, C++ & c? And moreover, to produce C "blobs" from zig sources which would be then part of the bigger project written in other languages? I'd also like to know the answer to both!
- e4m2 4y ago> For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file? It's possible, but: 1. The C backend isn't 100% there yet. You won't be able to use all features and might run into bugs. 2. The generated code won't be very readable, it's arguably not too different from just using Zig-compiled object files directly in terms of "opaqueness" and legibility. If neither of these are a big problem for you (both points are likely to improve with time), then yes, you could do that.
- bonzini 4y agoReadability is not an issue, as long as there are #line directives and symbol names are preserved so it is possible to use gdb. The idea would be that if C files are reproducible across multiple environments (esp. 32 vs 64 bit) the end user would not need a zig toolchain.
- AndyKelley 4y agoTo supply a data point: As of Zig 0.11.0-dev.2615+0733c8c5c, on an x86_64-linux host, the C backend is passing 1568 behavior tests compared to 1587 behavior tests passed by the LLVM backend on the same host. So, yes, it is not 100% there yet - it is 99% there :-)
- e4m2 4y agoAh, good to know! My main sources were the release notes and occasionally your tweets (the account seems to have gotten suspended?), so my information was understandably a bit out of date. Glad to see progress being made though.
- therein 4y agoI feel like Zig can dominate the shellcode space, especially with pluggable allocators and minimalism. Is there any work towards outputting a naked payload for the lack of a better word? Given just the ISA, calling convention etc., producing something that starts from main() and does nothing but what is contained within main?
- kristoff_it 4y agoTotally, just use `zig cc` as an in-place replacement for clang and move forward from there as you feel comfrotable. I wrote a blog post about this approach: https://kristoff.it/blog/maintain-it-with-zig/ https://kristoff.it/blog/maintain-it-with-zig/
- bonzini 4y agoI am asking for the opposite, i.e. keep everything as is and only add 2-300 lines of zig. In particular, I explicitly don't want to rewrite 15000 lines of build system code, so anything that uses build.zig is a nonstarter.
- gpanders 4y agoYou can invoke Zig without build.zig: zig build-obj file.zig And then include the object file along with your other sources. How you do this will of course depend on your build system.