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

How I turned Zig into my favorite language to write network programs in

lalinsky.com

Post reply on HN
Print view View original

41–50 of 150 posts

Re: How I turned Zig into my favorite language to write network programs in

#41

Post by lukaslalinsky »

loeg wrote: post #39
messe wrote: post #21

Earlier quoted context omitted.

> I’m actually not sure if Zig’s async design even uses hardware call/return pairs Zig no longer has async in the language (and hasn't for quite some time). The OP implemented task switching in user-space.

Even so. You're talking about storing and loading at least ~16 8-byte registers, including the instruction pointer which is essentially a jump. Even to L1 that takes some time; more than a simple function call (jump + pushed return address).

Only stack and instruction pointer are explicitly restored. The rest is handled by the compiler, instead of depending on the C calling convention, it can avoid having things in registers during yield.

See this for more details on how stackful coroutines can be made much faster:

https://photonlibos.github.io/blog/stackful-coroutine-made-f...

Re: How I turned Zig into my favorite language to write network programs in

#42

Post by lukaslalinsky »

sriku wrote: post #35

The article says it was created to write audio software but I'm unable to find any first sources for that. Pointers?

See the first example in Andrew's introduction: https://andrewkelley.me/post/intro-to-zig.html

Re: How I turned Zig into my favorite language to write network programs in

#43

Post by scuff3d »

tonyhart7 wrote: post #32
samtheprogram wrote: post #28

Earlier quoted context omitted.

Bun is 100% fine in production. And you should be using it instead of transpiling TypeScript unless there’s some other barrier to using it.

I am not trying to dunk on this project all of these project is great but we cant ignore that Zig is not enter phase where we can guarantee stable API compability

Nobody is denying that? Andrew Kelly and the Zig team have been extremely clear that they are okay making break changes. So if you're choosing to use it in large projects, as some have, you're taking that risk.

I think it speaks volumes that these projects chose to use it, and speak very highly of it, despite the fact that it's still pre 1.0.

Re: How I turned Zig into my favorite language to write network programs in

#44

Post by messe »

lukaslalinsky wrote: post #41
loeg wrote: post #39

Earlier quoted context omitted.

Even so. You're talking about storing and loading at least ~16 8-byte registers, including the instruction pointer which is essentially a jump. Even to L1 that takes some time; more than a simple function call (jump + pushed return address).

Only stack and instruction pointer are explicitly restored. The rest is handled by the compiler, instead of depending on the C calling convention, it can avoid having things in registers during yield. See this for more details on how stackful coroutines can be made much faster: https://photonlibos.github.io/blog/stackful-coroutine-made-f...

> The rest is handled by the compiler, instead of depending on the C calling convention, it can avoid having things in registers during yield.

Yep, the frame pointer as well if you're using it. This is exactly how its implemented in user-space in Zig's WIP std.Io branch green-threading implementation: https://github.com/ziglang/zig/blob/ce704963037fed60a30fd9d4...

On ARM64, only fp, sp and pc are explicitly restored; and on x86_64 only rbp, rsp, and rip. For everything else, the compiler is just informed that the registers will be clobbered by the call, so it can optimize allocation to avoid having to save/restore them from the stack when it can.

Re: How I turned Zig into my favorite language to write network programs in

#45

Post by attila-lendvai »

geysersam wrote: post #7
quantummagic wrote: post #6

Isn't this a bad time to be embracing Zig? It's currently going through an intrusive upheaval of its I/O model. My impression is that it was going to take a few years for things to shake out. Is that wrong?

What's a few years? They go by in the blink of an eye. Zig is a perfectly usable language. People who want to use it will, those who don't won't.

following upstream is overrated since we have good package managers and version control.

it's completely feasible to stick to something that works for you, and only update/port/rewrite when it makes sense.

what matters is the overall cost.

Re: How I turned Zig into my favorite language to write network programs in

#46

Post by flimflamm »

messe wrote: post #44
lukaslalinsky wrote: post #41

Earlier quoted context omitted.

Only stack and instruction pointer are explicitly restored. The rest is handled by the compiler, instead of depending on the C calling convention, it can avoid having things in registers during yield. See this for more details on how stackful coroutines can be made much faster: https://photonlibos.github.io/blog/stackful-coroutine-made-f...

> The rest is handled by the compiler, instead of depending on the C calling convention, it can avoid having things in registers during yield. Yep, the frame pointer as well if you're using it. This is exactly how its implemented in user-space in Zig's WIP std.Io branch green-threading implementation: https://github.com/ziglang/zig/blob/ce704963037fed60a30fd9d4... On ARM64, only fp, sp and pc are explicitly restored;…

Is this just buttering the cost of switches by crippling the optimization options compiler have?

Re: How I turned Zig into my favorite language to write network programs in

#47

Post by brabel »

grayhatter wrote: post #10
quantummagic wrote: post #6

Isn't this a bad time to be embracing Zig? It's currently going through an intrusive upheaval of its I/O model. My impression is that it was going to take a few years for things to shake out. Is that wrong?

IMO, it's very wrong. Zig's language is not drastically changing, it's adding a new, *very* powerful API, which similar to how most everything in zig passes an allocator as a function param, soon functions that want to do IO, will accept an object that will provide the desired abstraction, so that callers can define the ideal implementation. In other words, the only reason to not use zig if you detest upgrading or im…

> Code you write today will still work tomorrow.

Haha no! Zig makes breaking changes in the stdlib in every release. I can guarantee you won’t be able to update a non trivial project between any of the latest 10 versions and beyond without changing your code , often substantially, and the next release is changing pretty much all code doing any kind of IO. I know because I keep track of that in a project and can see diffs between each of the latest versions. This allows me to modify other code much more easily.

But TBH, in 0.15 only zig build broke IIRC. However, I just didn’t happen to use some of the things that changed, I believe.

Re: How I turned Zig into my favorite language to write network programs in

#48

Post by lukaslalinsky »

flimflamm wrote: post #46
messe wrote: post #44

Earlier quoted context omitted.

> The rest is handled by the compiler, instead of depending on the C calling convention, it can avoid having things in registers during yield. Yep, the frame pointer as well if you're using it. This is exactly how its implemented in user-space in Zig's WIP std.Io branch green-threading implementation: https://github.com/ziglang/zig/blob/ce704963037fed60a30fd9d4... On ARM64, only fp, sp and pc are explicitly restored;…

Is this just buttering the cost of switches by crippling the optimization options compiler have?

If this was done the classical C way, you would always have to stack-save a number of registers, even if they are not really needed. The only difference here is that the compiler will do the save for you, in whatever way fits the context best. Sometimes it will stack-save, sometimes it will decide to use a different option. It's always strictly better than explicitly saving/restoring N registers unaware of the context. Keep in mind, that in Zig, the compiler always knows the entire code base. It does not work on object/function boundaries. That leads to better optimizations.

Re: How I turned Zig into my favorite language to write network programs in

#50

Post by zozbot234 »

vlovich123 wrote: post #34
aidenn0 wrote: post #30

I am still mystified as to why callback-based async seems to have become the standard. What this and e.g. libtask[1] do seems so much cleaner to me. The Rust folks adopted async with callbacks, and they were essentially starting from scratch so had no need to do it that way, and they are smarter than I (both individually and collectively) so I'm sure they have a reason; I just don't know what it is. 1: https://swtch.…

The research Microsoft engineers did on stackful vs stackless coroutines for the c++ standard I think swayed this as “the way” to implement it for something targeting a systems level - significantly less memory overhead (you only pay for what you use) and offload the implementation details of the executor (lots of different design choices that can be made).

Yup, stackful fibers are an anti-pattern. Here's Gor Nishanov's review for the C++ ISO committee https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13... linked from https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10... . Notice how it sums things up:

> DO NOT USE FIBERS!

Post reply on HN