<traviss>
schme245, i got the time down from around 5.2 to 3.9 on my system using f64 vectors.
return0e has joined #zig
<schme245>
sweet! do you have a link to the code? :)
<traviss>
give me a few minutes. let me clean it up.
<schme245>
sure thing
<traviss>
does zig currently have any way to use SSE single precision reciprocal square root approximation instruction rsqrtss (_mm_rsqrt_ps from immintrin.h)
<andrewrk>
not sure if llvm will be smart enough to turn that into the instruction
<andrewrk>
making @sqrt SIMD-aware is a reasonably small task
<andrewrk>
hmm wait a minute, @sqrt is already supposed to have SIMD support
<traviss>
oh neat. maybe this is doable then.
<schme245>
traviss: nice! I love that the code shrinks, AND gets faster
<schme245>
faster than Rust on my machine! 2.
<schme245>
2.1 vs 2.4
<schme245>
suuuuweet
<andrewrk>
traviss, ok there is some code in here to support vectors in @sqrt and other float functions, but it's untested and broken. I've made a note to fix it in a bit, after I finish another task
<andrewrk>
schme245, one thing to consider is that rust may not be taking advantage of native CPU features by default
swoogan has joined #zig
<andrewrk>
make sure you're passing the equivalent of -march=native
<andrewrk>
for zig it makes sense to take advantage of native cpu features by default, because zig's cross compiling works out-of-the-box
<schme245>
yeah, just realized that I have no idea what the Rust equivalent of release-fast is
<schme245>
the benchmarks game build command was optimized for an old 2 core CPU I think
<andrewrk>
I put an example of some assembly there. Do you have an example with equivalent C code with that intrinsic?
<andrewrk>
I'm curious how llvm's optimization of @splat(1)/@sqrt(x) compares to the intrinsic you mentioned
<andrewrk>
oh, with @setFloatMode(.Optimized), llvm figures out to use the vrsqrtps instruction
diltsman has joined #zig
<traviss>
give me a minute i'll put one on godbolt
<daurnimator>
andrewrk: why do those builtins not take a type any more?
<diltsman>
Does anyone have experience getting a basic Windows program working? Closing the window I see PostQuitMessage(0) getting called correctly, but I never see WM_QUIT being dispatched.
<daurnimator>
It was only recently we added the type parameter to lots of other builtins for consistency
<daurnimator>
diltsman: are you using an alertable wait state?
<diltsman>
What do you mean by alertable wait state? I have a basic PeekMessageW, TranslateMessage, DispatchMessage loop. I implemented the same thing in C and it works.
<daurnimator>
diltsman: alertable wait state is windows-ism that means that the syscall you're using also adds in the hidden internal message EVENT. see the bAlertable argument of WaitForMultipleObjectsEx. But sounds like you're not using those APIs....
<andrewrk>
floating point operations such as sqrt operate on the type of the operand, same as mathematical operators. the functions where it makes sense to take a type parameter is e.g. @byteSwap where the type parameter decides the meaning of the endian swap operation
<diltsman>
I have a C program with the same loop. It sees WM_QUIT (0x12) after I close the window. The Zig program doesn't so then I am left with an infinite loop with no exit condition. I am at the point where I don't know where to look next. I have even started tracing system calls in assembly to verify that things are called the same in both languages.
<andrewrk>
diltsman, I wonder if libc is related? you could try linking libc in your zig application or not linking libc in your c application
<diltsman>
exe.linkSystemLibrary("c");
<diltsman>
exe.linkSystemLibrary("User32");
<diltsman>
Already linking those in...
<andrewrk>
I wonder if there is some c macro magic happening in the windows.h file?
<andrewrk>
I'm completely guessing here
<andrewrk>
this is an important use case though
<diltsman>
I can post my source, if you would like. Very basic Windows program that creates a single window and should exit when the window is closed.
<andrewrk>
sure
<andrewrk>
when you say you see PostQuitMessage(0) getting called correctly, what do you mean?
<andrewrk>
I need to quit for the day, I've been working too many hours in a row, see you fine folks tomorrow
<daurnimator>
andrewrk: cya :)
<diltsman>
I trace the call (in assembly) for both the C and Zig programs. Both do the DLL dispatch to PostQuitMessage with 0 in ecx, which is the correct register for the function parameter.
<daurnimator>
diltsman: check the waitformessage call to see if its alertable?
<daurnimator>
diltsman: without source I'm just guessing :P
<traviss>
andrewrk, this seems very hacky but maybe this is similar to what you're doing: https://godbolt.org/z/VxXfvD
<diltsman>
daurnimator: I am using PeekMessageW, which is non-blocking.
<diltsman>
So, it spins on it superfast because there will never be another message.
ur5us has quit [Ping timeout: 260 seconds]
<traviss>
ah, sorry i forgot all the compiler options. this one is closer at first glance to what you got: https://godbolt.org/z/cdmGKt
swoogan has quit [Ping timeout: 240 seconds]
diltsman has quit [Ping timeout: 260 seconds]
daex_ has quit [Ping timeout: 268 seconds]
darithorn has joined #zig
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
ur5us has joined #zig
dozn has joined #zig
schme245 has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
Aransentin has joined #zig
return0e_ has joined #zig
darithorn has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 260 seconds]
_Vi has joined #zig
dozn_ has joined #zig
dozn has quit [Ping timeout: 265 seconds]
goldenbooooooooo has joined #zig
goldenbooooooooo has quit [Remote host closed the connection]
sammich has quit [Ping timeout: 265 seconds]
sammich has joined #zig
_whitelogger has joined #zig
dddddd has joined #zig
<xeno>
hi, how do you open a file in Zig? the stdlib documentation doesn't seem to be complete or match reality?
<bgiannan>
xeno, see std.fs.File and std.fs in general
<bgiannan>
don't hesitate to look at the actual zig file which contains tests that are most of the time self explanatory
<lupine>
are you still using 0.5.0? could definitely be a mismatch between docs and compiler version
<xeno>
I'm using latest snapshot, but that's 0.5.0-<somestring>
<mq32>
daurnimator: is the sub_path a relative path?
<daurnimator>
mq32: yes. its a method on Dir
<mq32>
okay, so zig now has "discarded" absolute paths?
<daurnimator>
no if sub_path starts with a / its absolute
<mq32>
okay, weird
<mq32>
how do i obtain a Dir handle?
<daurnimator>
mq32: you can use `fs.cwd()` to get a reference to the current directory.
<mq32>
i can only find cwd()
<mq32>
so using fs.cwd().openRead("/foo") is the way to open "/foo"?
<daurnimator>
mq32: yeah. or fs.openFileAbsolute which does exactly that
<mq32>
ah
<daurnimator>
mq32: from fs.cwd() you can also use `openDirList`
<mq32>
ah and i have to close dirs
<daurnimator>
except for the cwd
<mq32>
hmm, kinda unusual but i can see the appeal
<daurnimator>
mq32: that's how most OSes work at the syscall level these days
<mq32>
yeah it also makes a lot of stuff much easier
<mq32>
var dataDir : std.fs.Dir;
<daurnimator>
on e.g. linux its just a wrapper around `openat` and fs.cwd() just returns `AT_FDCWD`
<mq32>
dataDir.openFile("foo/bar/bam", …#)
<lupine>
⎄
_whitelogger has joined #zig
dozn_ has joined #zig
dozn has quit [Ping timeout: 258 seconds]
<wilsonk>
hey daurnimator: is --verbose-cimport working for you? I don't get any different output with --verbose-cimport...even when I know there is an error that should throw a warning
<daurnimator>
wilsonk: the --verbose- flags only do something if the output isn't cached I think. delete your zig-cache and try again
<mikdusan>
also `--cache off`
<wilsonk>
hmm, nope that didn't change anything
<daurnimator>
wilsonk: was the warning just one that got added to the cimport file as a comment?
<daurnimator>
find zig-cache | grep cimport.zig
Aransentin has quit [Remote host closed the connection]
<wilsonk>
ok, I removed all zig-cache directories (didn't seem to make a difference) and re-ran 'zig translate-c m.c --verbose-cimport'. This outputs to stdout and the output includes 'pub const main = @compileError("unable to translate function");'. I thought it was just dying there and backing out but I also ran that command in gdb and set a breakpoint at translate_c.zig:1763...zig makes it there and should warn with 'unsupported initlist type' bu
<wilsonk>
'
<wilsonk>
just looking at #3752 (simple code to run in that issue)
FireFox317 has joined #zig
<wilsonk>
alright, it looks like even though zig reaches 1764 the warning isn't actually output...just the @compileError
FireFox317 has quit [Remote host closed the connection]
<andrewrk>
most common response to people discovering this option for the first time: "why is this not the default?"
<fengb>
I wonder how much user friendliness can be obtained by going beyond old Unix conventions
<andrewrk>
TheLemonMan, try passing `-target x86_64-macosx` to your test case
<andrewrk>
I'm also adding to the test harness to properly emit compile errors from clang
<fengb>
How was everyone's break?
<andrewrk>
TheLemonMan, yes, I can reproduce on linux with `./zig translate-c test.c -target x86_64-macosx`
<andrewrk>
fengb, it was nice to have a break, but now I need a break from the break
<fengb>
We welcome you back with open arms :)
<shakesoda>
before i try, is there any fundamental reason i shouldn't try to build zig on armv6 (rpi zero)
* shakesoda
wishes there were an aarch64 pi zero
<TheLemonMan>
andrewrk, thanks, I'll try later to find out what's wrong
<andrewrk>
shakesoda, it should mostly work, although we don't have CI coverage for arm32 yet
<andrewrk>
drone CI does provide it though, this is a good area to improve- once the issues are fixed we could add ci coverage and another download .tar.xz on the download page
<andrewrk>
don't you get that error where a function's frame is inside itself?
<fengb>
Oh
<fengb>
I guess I didn't handle that
<fengb>
Well crap, that'd require allocation
<TheLemonMan>
andrewrk, do you want me to rebase #3977 ?
<andrewrk>
fengb, yeah I ran into that when I tried it
<andrewrk>
still thinking about how to solve it
<andrewrk>
fengb, in theory we should be able to allocate some static number of bytes which corresponds to the maximum recursion depth, and use that buffer
<andrewrk>
we already have a max recursion limit on printing structs
<andrewrk>
but that might depend on a lot of bugs being solved :)
<andrewrk>
TheLemonMan, if you're up for it, that would be helpful, but I wouldn't mind doing the work either
<andrewrk>
I will certainly get to it faster if you do it
<fengb>
Well arguably it's more futureproof for recursion to require allocation right? :P
TheLemonMan has quit [Read error: Connection reset by peer]
<andrewrk>
yeah I mean it's a legitimate problem to solve. we want zig to be able to figure out at compile-time how much stack space each format() needs
<andrewrk>
this is not currently the case
<andrewrk>
so solving this recursion problem is actually accomplishing something
<andrewrk>
people will probably want to use format() on embedded devices
<andrewrk>
where being able to compute stack size is extra important
TheLemonMan has joined #zig
_Vi has joined #zig
marmotini_ has joined #zig
Snetry has joined #zig
Snetry is now known as Sentry
return0e_ has quit [Remote host closed the connection]
marmotini_ has quit [Ping timeout: 260 seconds]
mahmudov has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
nofmal has joined #zig
<nofmal>
hello, i just got this compiler error: `error: invalid character: ';' pub const CSTATUS = '\x00;`
<andrewrk>
nofmal, are you missing a single quote there?
<nofmal>
that happened every time i tried to compile with c library
<nofmal>
andrewrk: no, the generated `cimport.zig` did that
<nofmal>
i'm using the latest build from the website by the way
<nofmal>
upon further inspections, both variable _POSIX_VDISABLE and CEOL are also missing a single quote
<andrewrk>
nofmal, the next step to fix this is to find the C code that this comes from
<andrewrk>
or guess, to create a reproducing test case
<nofmal>
the problematic c code apparently comes from `termios.h`
<nofmal>
that's weird, it compiled just fine using a previous build a few days ago...
<andrewrk>
nofmal, as of yesterday, we switched to self-hosted translate-c
<andrewrk>
it makes sense that there would be a few regressions
Akuli has joined #zig
<nofmal>
i see, that kinda explains it
<andrewrk>
yes and unfortunately the case you ran into did not have test coverage, so that's why it regressed
<TheLemonMan>
it seems that parseCPrimaryExpr is emitting the correct tokens but in the wrong order
<nofmal>
well just to clarify a bit more, i tested using a simple c printf
<TheLemonMan>
you can reproduce it with `#define FOO ((unsigned char)'\377')`
<nofmal>
and the generated `cimport.zig` didnt contain variable CSTATUS, _POSIX_VDISABLE, and CEOL
<andrewrk>
nofmal, thanks for the report, I recommend now to stick with the older version of zig that worked, until you get the email that #4042 is solved
<nofmal>
andrewrk: it's all good, i'm gonna stick with the stable build for now. thanks for the fast response!
byron_heads has joined #zig
return0e_ has joined #zig
return0e_ has quit [Ping timeout: 260 seconds]
nofmal has quit [Remote host closed the connection]
THFKA4 has quit [Ping timeout: 260 seconds]
return0e_ has joined #zig
return0e_ has quit [Remote host closed the connection]
<TheLemonMan>
I have a fix for that but nofmal left :(
byron_heads has quit [Remote host closed the connection]
<andrewrk>
likely fix is ir_analyze_struct_field_ptr at ir.cpp:19978 needs to call type_resolve for the alignment of the element type before calling get_pointer_to_type_extra
<andrewrk>
get_abi_alignment asserts that the alignment of the type is resolved
<protty>
looks like that was it. adding a custom `align(N)` on fields was causing the bad assert
mahmudov has quit [Ping timeout: 265 seconds]
<fengb>
andrewrk: what if we preallocate `default_max_depth * @sizeOf(@Frame(formatType))` in the root function
mahmudov has joined #zig
<fengb>
That should give us enough recursion space
<fengb>
Oh wait, it doesn't account for arbitrary format functions :(
ur5us has joined #zig
<fengb>
I think it'd be possible to recursively calculate the max depth, but that requires comptime allocation
<fengb>
No wait, I can use a non-async function to figure out the depth. This might work 🤞
jjido has joined #zig
protty has quit [Ping timeout: 260 seconds]
adamkowalski has joined #zig
Aransentin has joined #zig
spenced has joined #zig
spenced has quit [Client Quit]
FSX has quit [Quit: WeeChat 2.3]
adamkowalski has quit [Remote host closed the connection]
Aransentin has left #zig [#zig]
adamkowalski has joined #zig
<hryx>
Is Twitch stream happening today?
Akuli has quit [Quit: Leaving]
<andrewrk>
fengb, yep I went through that same thought process
<andrewrk>
hryx, yes! starting in 50 minutes
<andrewrk>
not sure what the topic will be yet
<hryx>
yey~
<fengb>
How do I limit tests to one file only?
<adamkowalski>
fengb: you can zig test src/file.zig
<andrewrk>
yes and then probably also need --test-filter
_Vi has quit [Ping timeout: 246 seconds]
FSX has joined #zig
FSX has quit [Client Quit]
FSX has joined #zig
<andrewrk>
the topic will be adding a new kind of test to zig's test suite: translating C code to zig, and then compiling & running it