Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig ELF Linker Improvements Devlog

ziglang.org

Post reply on HN
Print view View original

71–80 of 105 posts

Re: Zig ELF Linker Improvements Devlog

#71

Post by flohofwoe »

pjmlp wrote: post #65
mattgrice wrote: post #43

Earlier quoted context omitted.

Definitely not true. Otherwise we would have really fast C++ compilers and no one would ever have implemented hacks like precompiled headers.

That hack is because of C. Definitely true when using VC++ with C++20 modules and MSBuild. It also helps not compiling everything from source as many UNIX folks do.

> Definitely true when using VC++ with C++20 modules and MSBuild.

Lol, sorry, but as soon as MSBuild is involved the compiler can be infinitely fast and you'd still need to be waiting for the build. Also the main problem of MSVC is the slow linker, and that isn't fixed by C++ modules. This is also the first time I'm hearing that C++ modules actually help with compilation speed in real world projects - the best I've heard so far is that they're a bit faster than precompiled header but not by much, which simply isn't good enough for typical C++ projects.

Re: Zig ELF Linker Improvements Devlog

#72

Post by cenamus »

flohofwoe wrote: post #70
pjmlp wrote: post #64

Earlier quoted context omitted.

Delphi, D, Nim, Go, C# / .NET Native / Native AOT, Oberon (any on the language family), Ada (depends on the compiler, 7 vendors),...

FWIW, IME at least Nim isn't particularly fast when building, at least when compared to C projects. E.g. in the sokol-nim bindings I'm seeing build timings like: 32743 lines; 0.953s ...building 32k lines of code in a second really isn't fast on an M1 Mac, and that's for a debug build without optimization.

I mean Nim just compiles to C or C++, so it's bound to be slower

Re: Zig ELF Linker Improvements Devlog

#73

Post by librasteve »

AndyKelley wrote: post #36
librasteve wrote: post #13

There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization. Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization han…

If you decide to try this, feel free to share your progress and struggles on IRC, ziggit, or ZSF zulip. Plenty of people would be interested in helping out. Good luck and happy hacking!

thanks! I have done a bit of work on Raku + Polars (ie the Pandas rewrite in Rust). This has been hampered by Rust lack of a binary FFI - so it has ended up running into unsafe keyhole surgery territory. My current feel is that we would need to move down to Apache Arrow and build a bunch of FFI / MOARMVM level scaffolding to keep it fast. Maybe take a look at COW at the same time.

Is any of that already lying around in Zig?

Re: Zig ELF Linker Improvements Devlog

#74

Post by pjmlp »

flohofwoe wrote: post #71
pjmlp wrote: post #65

Earlier quoted context omitted.

That hack is because of C. Definitely true when using VC++ with C++20 modules and MSBuild. It also helps not compiling everything from source as many UNIX folks do.

> Definitely true when using VC++ with C++20 modules and MSBuild. Lol, sorry, but as soon as MSBuild is involved the compiler can be infinitely fast and you'd still need to be waiting for the build. Also the main problem of MSVC is the slow linker, and that isn't fixed by C++ modules. This is also the first time I'm hearing that C++ modules actually help with compilation speed in real world projects - the best I've h…

Follow engineering principles and actually test it.

The company behind Cadifra UML Editor is quite happy with their migration, the owner keeps posting about their modules experience on Reddit C++.

Microsoft also has CppCon talks on the matter.

All my C++ hobby projects use modules, as I only care about VC++.

Re: Zig ELF Linker Improvements Devlog

#75

Post by pjmlp »

flohofwoe wrote: post #70
pjmlp wrote: post #64

Earlier quoted context omitted.

Delphi, D, Nim, Go, C# / .NET Native / Native AOT, Oberon (any on the language family), Ada (depends on the compiler, 7 vendors),...

FWIW, IME at least Nim isn't particularly fast when building, at least when compared to C projects. E.g. in the sokol-nim bindings I'm seeing build timings like: 32743 lines; 0.953s ...building 32k lines of code in a second really isn't fast on an M1 Mac, and that's for a debug build without optimization.

Depends on which compilation pipeline, I would say.

Re: Zig ELF Linker Improvements Devlog

#76

Post by librasteve »

nagaiaida wrote: post #15
librasteve wrote: post #13

There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization. Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization han…

minor correction, moar stands for metamodel on a runtime, not meta-object aware runtime

red face … thanks for the correction … I guess I should have looked at https://moarvm.org

Re: Zig ELF Linker Improvements Devlog

#77

Post by librasteve »

GuB-42 wrote: post #32
librasteve wrote: post #13

There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization. Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization han…

I am following Raku and Zig from afar, and they both share similarities in that both languages are "optimized for fun" in a way, so no surprize that they come together. Zig focus on compilation speed and give developers control (even more so than C). Raku, as a Perl descendant is a giant toybox and there is no one telling you not to use them. Both have in common that they give a lot of freedom to developers, which is…

lol … fwiw we are as bemused by the situation as anyone (well, I am, I can’t really speak for anyone else). My take is that Raku (née perl6) got the worst of all worlds … divided the perl community, was 15 years in the making, got dragged into the reputational suction as the unreconstructed perl Titanic sank. All the same, it’s a wonderful reimagining of all the great things of perl from all the community RFPs and the genius of Larry and Damian and co and fixes most of the negatives and is now there and steadily improving and what’s not to like!

Re: Zig ELF Linker Improvements Devlog

#78

Post by kllrnohj »

bpavuk wrote: post #68
kllrnohj wrote: post #44

Earlier quoted context omitted.

> that will let me iterate at the speed of JS or Python with performance of C or Rust. Didn't Go already do that? > I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement Yes, and it will still only be useful in the same niche that C is becau…

> Didn't Go already do that? no. GC pauses turn any serious systems work into hell. > Yes, and it will still only be useful [...] this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui

> no. GC pauses turn any serious systems work into hell.

did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter

> this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui

Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?

Re: Zig ELF Linker Improvements Devlog

#79

Post by onlyrealcuzzo »

keithasaurus wrote: post #60
onlyrealcuzzo wrote: post #49

Earlier quoted context omitted.

Cool - it sounds pretty similar. It's interesting that it looks so different. I'll have to investigate more. WRT to inference, yes. I infer everything in EASY mode. And the compiler give the user autofix via choice when a type is ambiguous (I don't default to huge union types - I assume no one wants to do that and make them choose a type - may potentially allow AutoUnion to allow that). I couldn't tell if you're usin…

How is compiling to zig? I considered doing it but chose C instead because of how much zig is still changing. I've considered using it's C compiler for targeting multiple platforms locally.

I would HIGHLY recommend transpiling to Zig.

Comptime is very powerful and awesome to use for a transpilation target.

Also, Io and how Zig handles allocation and gives you full control of the allocator make it super easy to do things you probably want to do in your language.

Re: Zig ELF Linker Improvements Devlog

#80

Post by onlyrealcuzzo »

keithasaurus wrote: post #59
onlyrealcuzzo wrote: post #49

Earlier quoted context omitted.

Cool - it sounds pretty similar. It's interesting that it looks so different. I'll have to investigate more. WRT to inference, yes. I infer everything in EASY mode. And the compiler give the user autofix via choice when a type is ambiguous (I don't default to huge union types - I assume no one wants to do that and make them choose a type - may potentially allow AutoUnion to allow that). I couldn't tell if you're usin…

No, blorp doesn't use affine types (one or zero uses). In blorp, ownership is not explicitly controlled by users at all, so it's opaque. Under the hood, it's perceus for compile-time ownership and borrowing and automatic reference counting with copy-on-write optimizations for the runtime. This is made reasonably easy for the compiler to reason about in blorp because semantically it doesn't _really_ have in-place muta…

Interesting.

How do you prevent data races in concurrent code?

Or do you not allow shared mutable memory?

Post reply on HN