ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
atk has quit [Quit: Well this is unexpected.]
atk has joined #zig
<Dirkson>
Hey all. It looks like zig binaries are nearly 10x the size of C binaries of similar code complexity. What's goin' on there?
<scientes>
use strip
<scientes>
and also --release-small
<Dirkson>
Oh, they shrink right down when you run 'strip' on 'em. I guess debugging info is included when building via --release-fast ? that seems odd.
<scientes>
that isn't odd at all, sometimes you have to debug optimized versions
<scientes>
what is kinda odd is that we should be using -gsplit-dwarf
<scientes>
but i guess you only switch to that when you need to
<scientes>
"dwarf" is the debugging format
<Dirkson>
Fair point
<Dirkson>
Hmm. Some of the binaries are still 10x the size of the C binaries, even after stripping.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Dirkson>
Even after using --release-small
<scientes>
hmmm, what are you calling?
<scientes>
and is your app really tiny?
<scientes>
cause zig std lib doesn't use glibc
<Dirkson>
scientes: I'm just grabbing some of tiehuis's code and compiling it.( https://github.com/tiehuis/zig-benchmarks-game ) Since most of them are translations of the C algorithm, I figured it'd be a good way to get several data points on several different programs of similar complexity. But they *are* all pretty small.
<scientes>
then what you are bringing in is standard library stuff
<scientes>
that would otherwise be in glibc
<Dirkson>
Gotcha. And this is all statically compiled in, rather than having a 'glibzig' dynamic lib on the OS?
<scientes>
correct
<Dirkson>
Why is that?
<scientes>
nono
<scientes>
zig doesn't use glib by default, and if it does it would link against it dynamically
<scientes>
the point is that the zig standard library (which does not depend on libc) is statically linked
<Dirkson>
Yes. Why is that? Why isn't it dynamically linked like the C equivalent is?
<scientes>
many reasons
<scientes>
one is that static libraries mean you have to maintain two languages, the API and the ABI
<scientes>
that is the biggest IMHO
<scientes>
and its only linking in what is used
<Dirkson>
You mean with dynamic libraries, you have to do that?
<scientes>
yes
<scientes>
maintaining ABI compatibility is a PITA
<Dirkson>
Interesting. Does that mean zig doesn't have dynamic libraries at all?
<scientes>
you can make a dynamic library
<scientes>
zig implements the C ABI, which will work even if you have zero C
<Dirkson>
Well, fair point : )
<scientes>
this is alot better than go, which has a runtime which means you can't write a shared library
<scientes>
zig has no runtime
<Dirkson>
But imagine you had a pure-zig OS for some reason. Would the Zig Way to do it be to statically compile every binary, or would you still have dynamic libraries via some mechanism?
<scientes>
probably dynamic libraries would develop eventually, but zig is far too young to want to have to maintain ABI compatibility yet
mnoronha has quit [Quit: Page closed]
<Dirkson>
Interesting! Thanks for the breakdown.
<scientes>
note i have not contributed to zig much
<Dirkson>
Me either. I'm just making some stumbling steps towards learning it when I have a few free moments : )
<scientes>
and I don't know C++, so I won't be working on the stage1 compiler at all
<scientes>
stage2 is a zig compiler
<Dirkson>
We're nearly to self-hosting, aren't we?
<tiehuis>
secondly the remaining larger examples (n-body/spectral-norm) are that large because of pulling in the float printing code
<tiehuis>
this requires ~25Kb of tables for the current implementation (errol3) to accurately print floats
<Dirkson>
Yeah, that's roughly what I was seeing. You were specifically using a debug allocator?
<Dirkson>
Interesting!
<tiehuis>
c doesn't have this issue of course since it dynamically links libc but in our Zig's view we should always statically link since it can be very beneficial regarding inlining
<tiehuis>
also, the float printing code will likely get much smaller shortly
<Dirkson>
Also interesting.
<tiehuis>
i've implemented another algorithm (ryu) over the past week which with --release-small only required ~800 bytes of tables for accurate f64 printing
<Dirkson>
That sounds like a lovely little improvement.
<tiehuis>
another small thing thay may account for ~10Kb or so as well is due to the linker and how it seems to place zig programs
<tiehuis>
i've tried a minimal hello world in zig but it pads the sections with a lot of zeros compared to c even though the actual
<tiehuis>
.text section with the code is < 500 bytes
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<tiehuis>
but i haven't explored that too much and you can probably reduce that with a custom linker script
<tiehuis>
in practice though it's only like ~10Kb so for every standard program it doesn't actually matter
<Dirkson>
Which linker is being user? Something made for zig, or some pre-existing bit?
<Dirkson>
*being used
<tiehuis>
zig uses lld the new linker from the llvm project
<tiehuis>
while c is just using the system linker
<Dirkson>
That makes sense.
<tiehuis>
but i haven't explored that much at all so don't know the particular reason for the difference
<Dirkson>
Say, you might know the answer to a worry I had the other day - Is implicit typing planned for function return types (or argument types, for that matter)
<tiehuis>
do you mean inferred generic return types?
<Dirkson>
I might mean that thing! The ability to create a function whose arguments or return types are inferred from distant sections of code, rather than being explicitly listed in the function definition.
<tiehuis>
yeah that is probably what you are after then
<tiehuis>
i'm personally not convinced on var return type's but i haven't yet thought about it in-depth either
<Dirkson>
I've experienced them in other languages, and torn my hair out because of them. This bug report appears to suggest that they'll become a thing, which, frankly, makes me want to drop zig instantly.
<tiehuis>
it has been a fair while since that has been brought up or discussed and i wouldn't be so sure it'll still stick
<tiehuis>
even thought it has the accepted tag of course, things change and the given use case is quite specific at this stage
<tiehuis>
you can make a comment on the issue if you have any specific complaints/arguments against it
<Dirkson>
Maybe I ought to write up a little "here's how this burned me in other languages" blurb and tack it onto the issue? Would that be useful, or just tilting at windmills, you think?
<Dirkson>
Well, you beat me to the suggestion anyway :D
<tiehuis>
that would definitely be helpful!
<Dirkson>
Thanks for all the info, by the by!
<tiehuis>
no problem, feel free to ask any other questions whenever, i usually read the logs
<Dirkson>
I am usually pretty liberal with my stupid questions, don't worry : )
tiehuis has quit [Quit: WeeChat 2.2]
qazo has joined #zig
qazo_ has joined #zig
jethron has quit [Ping timeout: 248 seconds]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
mahmudov has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
noonien has joined #zig
kristate has joined #zig
kristate has quit [Remote host closed the connection]
mnoronha has joined #zig
<mnoronha>
How do I run the tests in the compiler?
<mnoronha>
I ran `./../build/bin/zig build --build-file ../build.zig test`, copying the ci script, but no luck
<mnoronha>
jk, figured it out :)
mnoronha has quit [Ping timeout: 252 seconds]
bheads has quit [Disconnected by services]
bheads has joined #zig
mahmudov has quit [Ping timeout: 240 seconds]
kristate has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
return0e_ has quit [Quit: Leaving...]
return0e has joined #zig
mahmudov has joined #zig
unique_id has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Bas__ has joined #zig
Bas__ has quit [Client Quit]
Barabas has joined #zig
<Dirkson>
How do you maintain a codebase with zig-style generics? Imagine you follow a chain of calls down to a particular function. You change that function, in order to accomplish some goal. But, unbeknownst to you, that function is also called by other sections of code that pass completely different arguments.
<Dirkson>
And thus your new changes, while perfectly fine syntactically and logically, are actually compile errors, as far as zig is concerned.
<Dirkson>
Coming from C, this is a pretty new concept for me, so I'm trying to wrap my head around it.
<Barabas>
What's the problem? If you change a C function/macro to do something else you also get compile errors, right? Or worse it fails at runtime ^^
<Dirkson>
The problem is that you need to know all the places a function is called in order to know if you can change it in some manner, because any one of those places may call the function with arguments of a different type.
<Dirkson>
Whereas with C, you may need 157 nearly identical boilerplate functions for all of your types, but all you need to figure out what any individual function is doing is the trgument type information and the function definition.
<Dirkson>
*argument
<Barabas>
Hmm... yeah I see.
<Barabas>
I don't think that's a huge issue in Zig, as it doesn't have overloaded functions or operators. So generally the things it'll do will be quite specific to certain use cases.
<Dirkson>
That helps, but doesn't fix the issue.
<Dirkson>
I could see a function that takes some defined class of structs, that all have certain fields. You add a new field to one of the structs, and change the function to suit the new field... And suddenly 157 other sections of code are blaring errors at you, because their structs don't have this field.
<Barabas>
Then probably you should make a new function.
<Barabas>
Or do a comptime if for something.
<Dirkson>
Ok. This does mean that you can't tell a compilable change from a non-compilable change without handing it to the compiler. No amount of staring at the bits changed will allow you to work that out. Is that ok? I guess I don't have an explicit objection to it, it just feels wrong somehow.
<Barabas>
Well, in your example if you add a field and start using it then you can probably guess that any other place where it's called will break.
<Dirkson>
Well, you had no idea about the 157 other places it was called until you made the change. On large code bases, it's unreasonable to know all the places some function is called.
return0e has quit [Quit: Leaving]
<Barabas>
It's like if you change a function definition in C for the one time you call it. Then all other places where it's used will fail as well, right?
<Dirkson>
That's true.
<Dirkson>
I've used that behavior purposefully to track down stuff I need to change :D
<Barabas>
^^
<Barabas>
And you can be happy that it breaks at compile time rather than at runtime like in Python.
<Dirkson>
I like that analogy. That helps me come to grips with generics a bit better.
<Barabas>
Cool.
<Dirkson>
And yeah, I think we can all agree that compile time breakage is way better than runtime :D
<Barabas>
I still remember the times where my simulation results of several hours got lost due to me making a typo in the code that prints it's done or something.
<Dirkson>
Thanks for chatting that out with me!
<Barabas>
You're welcome!
Barabas has quit [Ping timeout: 252 seconds]
walac_ has joined #zig
Guest25371 has quit [*.net *.split]
dtz[m] has quit [*.net *.split]
odc has quit [*.net *.split]
walac has quit [*.net *.split]
walac_ is now known as walac
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
Barabas has joined #zig
return0e has joined #zig
davr0s has joined #zig
Barabas has quit [Ping timeout: 252 seconds]
kristate has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]