ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
tyler569 has joined #zig
qazo has joined #zig
qazo has quit [Ping timeout: 260 seconds]
zolk3ri has quit [Quit: Lost terminal]
return0e has quit [Quit: Leaving...]
tobbez has quit [Ping timeout: 240 seconds]
tobbez has joined #zig
<MajorLag1>
How to make yourself really confused about why your inflate implementation doesn't work: step 1: refuse to believe anyone is foolish enough to mix LSB and MSB. step 2: Accidentally break your symbol lookup *before* trying to fix step 1, without noticing. Step 3: misread the spec such that you think "extra bits" means "append these bits to the base" instead of "add the value of these bits to the base".
<MajorLag1>
Which reminds me, `const x = u8(255) & u16(0xFF00);` results in u16(0). Which makes sense since addition would act similarly, but I'm wondering if bitwise operators should ensure operands are the same type?
return0e has joined #zig
kristate has joined #zig
kristate has quit [Ping timeout: 244 seconds]
<andrewrk>
hmmm. it's a good question
<andrewrk>
in your case what was the intended result?
qazo has joined #zig
qazo has quit [Ping timeout: 244 seconds]
kristate has joined #zig
MajorLag1 has quit [Ping timeout: 244 seconds]
qazo has joined #zig
kristate has quit [Ping timeout: 276 seconds]
kristate has joined #zig
stratact has joined #zig
kristate has quit [Ping timeout: 255 seconds]
lqd_ has joined #zig
lqd has quit [Read error: Connection reset by peer]
lqd_ is now known as lqd
dpk has quit [Ping timeout: 240 seconds]
kristate has joined #zig
dpk has joined #zig
zolk3ri has joined #zig
kristate has quit [Ping timeout: 255 seconds]
kristate has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
very-mediocre has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
kristate has quit [Ping timeout: 240 seconds]
davr0s has joined #zig
kristate has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
strmpnk has quit [Remote host closed the connection]
l1x has quit [Remote host closed the connection]
tracernz has quit [Remote host closed the connection]
tyler569 has quit [Ping timeout: 240 seconds]
tyler569 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
very-mediocre has quit [Quit: Page closed]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
strmpnk has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<kristate>
andrewrk: good morning!
Dirkson has joined #zig
qazo has quit [Ping timeout: 244 seconds]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
very-mediocre has joined #zig
MajorLag has joined #zig
bheads has joined #zig
qazo has joined #zig
qazo has quit [Ping timeout: 260 seconds]
<andrewrk>
good morning kristate
<andrewrk>
you've been busy
<kristate>
andrewrk: yeah, trying to take care of some of this low hanging fruit
<kristate>
about to push Call RtlGenRandom() instead of CryptGetRandom()
qazo has joined #zig
qazo has quit [Ping timeout: 240 seconds]
<kristate>
andrewrk: by the way, resume @handle(); works now after your coro cancel commits;
<andrewrk>
kristate, brilliant - even that case you mentioned that was broken before?
<kristate>
Yes! I am quite happy
<andrewrk>
amazing
<andrewrk>
I read the RtlGenRandom issue
<andrewrk>
that is quite unfortunate, that the deprecated API is more desirable
<kristate>
Well, Microsoft is trying its best to unify its cryptoAPI, but for random bytes everyone is calling SystemFunction036();
<andrewrk>
hm maybe that's fine. Do we really need to use LoadLibrary and GetProcAddress? why can't we just put `extern "advapi32" fn SystemFunction036...` and call it?
<andrewrk>
one moment, I'm almost done merging @handle()
<kristate>
cool beans
<Dirkson>
Hey all. Coming from C, one thing that I think would help me pick up Zig faster is some information on where it diverges from C most radically. Are there any writeups for that yet?
<andrewrk>
hi Dirkson
<Dirkson>
andrewrk: Hi person making a cool thing!
<kristate>
comptime and that there are built-in functions that pull LLVM closer to your app
<Dirkson>
Interesting
<kristate>
I would dare say that zig is more low level than C -- and safer because there is less ambiguity about what it will compile to.
<Dirkson>
I could see that.
davr0s has joined #zig
<MajorLag>
That's not an unreasonable assertion.
<Dirkson>
From my perspective, what I've seen so far suggests that it fixes a bunch of stuff I hate about C while potentially reducing complexity, rather than increasing it.
<kristate>
Dirkson: I was starting to write a lot of Rust, but got discouraged for a number of reasons. Zig feels at home and its internals are simple enough that its easy to hack on
<andrewrk>
kristate, @handle() is merged. thanks for your great work!
<kristate>
andrewrk: yay!
<Dirkson>
kristate: I never got started with Rust. I kept finding weird corner cases just trying to learn the damn language. The first set of corner cases was around how the semicolon functions. They eventually fixed the worst of that, but the *very* next thing I looked into ended up having a bizzare corner case too. Literally surprised one of the IRC-active rust devs.
<kristate>
Dirkson: yes, I ran into a number of those too. Zig has some rough edges, but there is no magic hand waving
<kristate>
granted, once we get through 0.4.0, I am pretty sure that most rough edges will be rounded
<andrewrk>
kristate, for `_`, I think we should handle it in the semantic analysis, not the parser
<kristate>
andrewrk: which path does less work / less CPU cycles?
<andrewrk>
probably semantic analysis, because we need that code anyway for |captures|
<Dirkson>
https://github.com/tiehuis/zig-benchmarks-game - Ok, I just tried to compile and run this random guy's zig benchmarks suite to get an idea how fast zig currently is. Zig example compiled fine, and the first test I ran took about 23 seconds. Cool. Get the C example to compile, which takes a lot more effort, and finally get it to run... returns in 0.001s. Wait, what? Oh. "Segmentation fault". That's not exactly
<Dirkson>
the information I was trying to find, but you know, I feel like it really does highlight something important :D
<andrewrk>
I'm guessing the solution will be in create_local_var / add_variable
<andrewrk>
Dirkson, ah yeah, I wonder what tiehuis got stuck on
<Dirkson>
Ouch. Spectral-norm, though, returns some 20x slower than the C example. Although it does return a slightly different value
<kristate>
andrewrk: okay, I retooled around create_local_var
<andrewrk>
Dirkson, I'll look into that. there's no reason the LLVM IR of clang and zig for spectral norm should be radically different
<Dirkson>
andrewrk: Potentially debug-related stuff? I haven't worked out how to make zig produce release binaries yet.
<Dirkson>
andrewrk: Thanks! I had assumed that --release-fast would work with 'build' not just 'build-exe'. That brought it up to about 3x slower than the C example.
<Dirkson>
But there's a note in the source that it used to segfault on --release-fast, so you appear to have fixed whatever issue was causing that at some point
<andrewrk>
3x slower is still fishy. I'll look into it at some point
<kristate>
andrewrk: is there a macro to breakpoint in the cpp code?
<andrewrk>
BREAKPOINT;
<kristate>
cool
<Dirkson>
Well, the other thing I think is fishy is that they return different results: C: 1.274224152 Zig: 1.27422606e+00 . Although the C version appears to use doubles, and the zig f32.
<andrewrk>
unless the C version is compiled with -ffast-math, zig would need some @setFloatMode(FloatMode.Strict) in there too
<Dirkson>
Oh, neat.
<Dirkson>
You seem to have some expectation of how fast Zig should be compared to C. Mind if I ask what that expectation is?
<andrewrk>
it should be as fast or faster
<andrewrk>
in all cases
<andrewrk>
as long as by C you mean clang
<andrewrk>
because it's the same backend
<andrewrk>
and zig isn't doing any extra hidden cost stuff
<kristate>
andrewrk: I actually think that var _: should be handled in the parser because we have a lot of false positives with ir_create_var -- plus, there is already special code in ir_gen_symbol to deal with the static nature of _
<kristate>
I actually got it so that for for ([]void{}) |_, i| { for ([]void{}) |_, j| { will work, so I will push that too.
<andrewrk>
kristate, in that case I think it should go in ir_gen_var_decl
<andrewrk>
we know how to parse the code if a variable has a _ for a name - we just want to make it a semantic analysis error
<kristate>
andrewrk: hmm, interesting
<andrewrk>
you can see there are a few other checks there that technically could have gone into the parser but are here instead
<andrewrk>
consider: if you're in an IDE and it's going to highlight all the errors with red squigglies
<andrewrk>
better for the parsing to complete and then we highlight all the variables that have _ for names, rather than give up parsing after the first one
<Dirkson>
Ah, there we go. build-exe drops its exe someplace different than build does.
<andrewrk>
Dirkson, yeah the output path(s) of artifacts is something I haven't settled on yet
<Dirkson>
andrewrk: Operating in strict mode with a f64, like the C example, the Zig example runs about 7x slower than the C example, but actually produces the same result now.
<Dirkson>
andrewrk: Even when the C is built using "-fno-vectorize", it still runs at around 1 second to zig's 7.
<andrewrk>
Dirkson, the next step is to look at the LLVM IR difference between the clang code and the zig code
<andrewrk>
both pre- and post- optimization
<Dirkson>
The slowest I can get the C version to go is about 1.6seconds at -O0. I've not tinkered with LLVM much before, but I'll see what I can't figure out
<andrewrk>
they might be different implementations
<andrewrk>
e.g. tiehuis might not have made a direct port
very-mediocre has quit [Quit: Page closed]
<Dirkson>
I did consider this. There's one major change, and it'd be fairly easy to undo. That's probably easier than figuring out LLVM IR
<Dirkson>
Theoretically the change should be compile time, buuuut
<Dirkson>
Ok, the obvious change didn't do much. Everything else is zig-specific stuff that I don't fully understand yet
<Dirkson>
Got it.
<Dirkson>
The default argument provided was different in each of the programs. Stupid thing to not notice, but it doesn't appear to affect the output. The zig implementation does appear to be roughly as fast as the C implementation. Huzzah!
<andrewrk>
good to know
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<unique_id>
Vulkan is extra, extra verbose. The Khronos people really want it to run on MacOS and it's looking like the solution will be MoltenVK. I believe it was bought by Valve and open sourced, and Dota 2 runs better on MoltenVK than OpenGL on MacOS
<unique_id>
(I should really sign up for a twitch account, this is looking pretty out of place here)
qazo has joined #zig
<unique_id>
this is going to take forever, glGenBuffers doesn't use up video memory IIRC
qazo has quit [Ping timeout: 244 seconds]
<Dirkson>
unique_id: Hey, I missed the earlier video. Why'd you mention Vulkan?
<unique_id>
nvm don't remember what glGenBuffers does
<unique_id>
andrew is streaming
<Dirkson>
I noticed that bit. I also noticed opengl code going up on the screen
<unique_id>
My last comment on the stream: I don't know what the heck you're supposed to do on OpenGL. Can you can call glGetError and check for GL_OUT_OF_MEMORY? I don't know. Is the documentation missing this? But your application just deadlocked? I don't know. All I know is that Vulkan is not lacking in this regard, in fact you can take care of CPU-side allocation for the driver via VkAllocationCallbacks.
<unique_id>
So it's got it all
<unique_id>
andrewrk: glGenBuffers doesn't actually allocate gpu resources, it just "reserves" a name. You'll have to call glBindBuffer for that. GL_OUT_OF_MEMORY can be 'returned' from any command, it's implicit. That's what the spec says. As you can see, OpenGL likes implicitness :)
<andrewrk>
unique_id, ah, thanks for the comments
<andrewrk>
sounds like I should ditch OpenGL immediately
<Dirkson>
Having worked in both opengl and vulkan, I am strongly of the opinion that vulkan is better. Lots more boilerplate, but you can actually get meaningful errors out of it reliably. And tell it stuff like "Use this graphics card, not that one."
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]