<mq32>
andrewrk: does that mean that zig now compiles 1 Mio LOC/s
<mq32>
?
<mq32>
:D
<andrewrk>
now all we have to do is not introduce a perf regression :P
<andrewrk>
shachaf, I think it's built into fish shell?
<mq32>
yep ^^
<shachaf>
Oh, fish, I see.
<andrewrk>
I think there is a lot of room for improvement because clang does this faster with a respective .c file
<shachaf>
I wrote my own time replacement to get some of this information because none of the system commands did it.
<shachaf>
(Though a lot of those numbers are just always 0 on Linux anyway...)
<mq32>
andrewrk: do you have optimizations enabled on that build? :D
<andrewrk>
zig compiler optimizations, yes
<andrewrk>
interesting, about 50% of the time spent is in the parser
<mq32>
but nice to see that it's acceptably fast already
<andrewrk>
wait... I think zig is emitting memset to undef even in release-fast 🕵️♂️
<mq32>
this is probably a huge handbreak :D
<andrewrk>
especially considering there is a call in every allocation
<mq32>
ouch
<andrewrk>
that was a small improvement, not a breakthrough
<andrewrk>
it's good to know that (1) gains can be made in the parser, and (2) gains can be made by parallelizing parsing and analysis, since these are easy to separate
* mq32
is hyped
<mq32>
this is gonna be good
<andrewrk>
looks like some gains to be made with a better hash table impl, been meaning to check if it would be better to have arrays of keys / arrays of values rather than arrays of entries
drp has quit [Remote host closed the connection]
drp has joined #zig
<mq32>
i think it's actually worth the split
<mq32>
for larger tables especially
<mq32>
and i think the compiler will gain some huge hashtables
<andrewrk>
yeah, makes sense
<mq32>
cache locality isn't our friend D
<andrewrk>
ok, yeah wow the parser is the bottleneck in this example
<mq32>
*grin*
<mq32>
i love such optimization stuff
<mq32>
you find a bottleneck
<mq32>
you improve that
<mq32>
you repeat
<ifreund>
this is a fairly abnormal example though tbh
<andrewrk>
agreed
<mq32>
and at one point, you're back to the original bottleneck :D
<andrewrk>
totally agree it's a dumb example, but still having fun with it: this is currently 7x faster than clang and clang is using 3x the memory for the equivalent source
<mq32>
neat
<andrewrk>
and this is still with the ability to do incremental updates btw
<andrewrk>
I need to wire some more things up to demo that but you'll be able to e.g. change the message and have it update instantly
<afontain_>
sweet
<ifreund>
this is super cool
<mq32>
neat
<mq32>
except for the parse taking so long :D
<andrewrk>
I haven't looked critically at the relevant parser code, maybe some ideas will turn up
<andrewrk>
could be a fun area to contribute to as well; we already have a solid gotta-go-fast benchmark for the parser
<Cadey>
oh no
dddddd has joined #zig
frett27_ has joined #zig
Patrice_ has joined #zig
frett27 has quit [Ping timeout: 260 seconds]
frett27_ has quit [Ping timeout: 264 seconds]
ur5us has quit [Ping timeout: 260 seconds]
VojtechStep has quit [Ping timeout: 246 seconds]
frett27 has joined #zig
Patrice_ has quit [Ping timeout: 264 seconds]
gazler__ is now known as gazler
st4ll1 has quit [Ping timeout: 258 seconds]
st4ll1 has joined #zig
Zannzen has quit [Ping timeout: 258 seconds]
waleee-cl has joined #zig
blinghound has joined #zig
<blinghound>
Hi all! I'm a zig noob and trying to test the c compilation capabilities. I'm attempting to compile sqlite3 into an object file on windows, but I get an error 'conflicting types for '_m_prefetchw''
<blinghound>
my compilation command was 'zig cc -I{sqlite3.h location} -c sqlite3.c -o sqlite3.o -DSQLITE_ENABLE_FTS5 -O2
blinghound has quit [Remote host closed the connection]
blinghound has joined #zig
<afontain_>
it would help if you showed the two files
<afontain_>
I've already got an idea what the cause could be
<blinghound>
sqlite3.c and sqlite3.h?
<blinghound>
they are the source files straight from the sqlite site
<blinghound>
In file included from .\sqlite3.c:26721:In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\..\um\windows.h:171:In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\..\shared\windef.h:24:In file included from C:\Program Files (x86)\Windows
<blinghound>
Kits\10\Include\10.0.18362.0\ucrt\..\shared\minwindef.h:182:C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt\..\um\winnt.h:3324:1: error: conflicting types for '_m_prefetchw'_m_prefetchw (^C:\Portable Apps\zig-windows-x86_64-0.6.0+2bb3e1aff\lib\zig\include\prfchwintrin.h:50:1: note: previous definition is
<blinghound>
here_m_prefetchw(void *__P)
<blinghound>
sorry for the formatting, I'm a noob!
Akuli has joined #zig
xackus_ has joined #zig
<blinghound>
ok this command successfully compiled 'zig cc -o .\sqlite3.o .\sqlite3.c -DSQLITE_ENABLE_FTS5 -c -O2 -target x86_64-windows-gnu'
<blinghound>
was it because I didn't specify a target?
<blueberrypie>
zig might be using musl as the default target
<blueberrypie>
maybe that isn't compatible? i don't know.
<ifreund>
blueberrypie, blinghound: i think msvc is the default target
<ifreund>
iirc there's an open issue for this
ask6155 has joined #zig
<ask6155>
hello!
<ask6155>
what does this return type mean?
<ask6155>
?(NextError![]u8)
<ask6155>
it is from the argiterator
cole-h has joined #zig
<mq32>
that's an optional error union of either NextError or a slice of unsigned 8 bit integers
<ask6155>
can you um.. dumb it down? :)
<mq32>
[]u8 is a range of u8
<mq32>
NextError!T is an error union which is either one of the errors in NextError contains a range of u8
<mq32>
and ?T is an optional type
<mq32>
so it might be null or a value of T
<ifreund>
to unwrap it you can do const argval = try (arg orelse @panic("no more args"))
<ifreund>
except probably don't panic :D
<alva>
In Rust and other languages it would be something like Option<Result<[]u8, NextError>> (except the slice type would be written differently)
<ask6155>
if arg is a argiterator do i use .next in a loop to get all values?
ask6155 has quit [Remote host closed the connection]
doublex has quit [Ping timeout: 264 seconds]
doublex has joined #zig
blinghound has quit [Remote host closed the connection]
wootehfoot has joined #zig
<mq32>
andrewrk: does zig right now mmap the code files or does it use read syscall?
wootehfoot has quit [Ping timeout: 265 seconds]
jmiven has quit [Quit: reboot]
<leeward>
What are people's idioms for "value that hasn't been unwrapped yet?" like ifreund's maybe_arg above? It seems like there should be a consistent pair that people expect to use: one for optionals and another for error unions.
<leeward>
I've used _opt and _err, but don't particularly like them.
jmiven has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
<greenfork>
some people don't like Hungarian notation at all and prefer to use just usual words
<leeward>
Hungarian would be like oe_value
<greenfork>
for me Hungarian means that you encode the type of variable in its name
<leeward>
Yeah...there's an old Joel Spolsky post about that with systems vs apps Hungarian at Microsoft in the '90s.
<greenfork>
it also doesn't seem as a common case when you don't want to unwrap it immediately or close to it
<ifreund>
yeah i don't usually use any special name for optional variables
<fengb>
foo vs the_foo 🙃
<ifreund>
only in rare cases where the name actually adds more clarity
<ifreund>
e.g. a global variable that starts null but might get set by a callback
<fengb>
I don’t usually make variables for optionals or error unions
<ifreund>
(this is not something I do in programs over 100 loc to be clear)
<leeward>
So in ifreund's example above, "maybe_arg" only exists to be unwrapped. You can't call it "arg" because that's the name of the thing it wraps.
<ifreund>
sometimes I just use a leading underscore in cases like this
<leeward>
With optionals, the pattern is `if (wrapped_thing) |unwrapped_thing| {}`
<greenfork>
I go with C-style for short names in this case
<greenfork>
`if (thing) |t| { ... }`
<ifreund>
where I need a different name but don't really want to spend the energy to think about it
<leeward>
I kinda like the leading underscore. It doesn't run the chance of being a reserved word in Zig, unlike C.
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
doublex has quit [Ping timeout: 246 seconds]
ifreund has quit [Quit: WeeChat 2.8]
ifreund has joined #zig
cvoges12 has joined #zig
riba has joined #zig
<cvoges12>
Getting https://0x0.st/iW6q.log (build/CMakeFiles/CMakeOutput.log) when trying to build main branch. I'm using musl and on void linux
<cvoges12>
Dependencies are up to date
<leeward>
I see an example in the standard library of `if (opt_name) |name|`, but also `if (prev_path) |pp|`, `if (stdout) |s|`, and `if (alignment) |a|`. Looks like shortening the optional wrapper to its first letter is pretty common.
<ifreund>
yeah shortening definitely make sense to me, especially if the if block is short
<ifreund>
cvoges12: i assume you've got clang, llvm10, and lld-devel installed?
<leeward>
On the error union side, the vast majority of times "try" is used, it's on a more complex expression than a variable's name. In fact, the only one I see is in process.zig: `const arg = try arg_or_error` in argsAlloc.
<cvoges12>
ifreund: Not devel. Just installed. Works fine. Thanks
<leeward>
Hooray, problems solved!
<ifreund>
nice, if that didn't work i dont know what i would do, i tested the template for 0.6.0 on musl :D
cvoges12 has quit [Remote host closed the connection]
<andrewrk>
mq32, read()
<mq32>
oh
<mq32>
it might help to mmap the code, will make a huge speedup
dddddd has quit [Ping timeout: 260 seconds]
<andrewrk>
perhaps, but it does make it much harder to handle errors of reading the code.
<andrewrk>
you start getting SIGBUS instead of errno from read()
<andrewrk>
also this is doing fstat followed by, essentially a single read, so I'm not sure if mmap really has much to offer here
<mq32>
hm, performance-wise it's ultra-fast
<mq32>
but i have to go
<andrewrk>
does anyone know of a profiling tool that shows functions over a period of real time, like the one jblow demos in his videos?
<andrewrk>
kcachegrind, for example, does the bottom-up thing where it sorts everything by total instructions, which can be useful, but I want to see an overview of actual seconds and where the time is spent in each function
<frmdstryr>
@andrewrk what's the difference between context: void and context: var? From reading the docs on void it has no space so is zig doing some kind of magic with the stack or something to use it?
<andrewrk>
ifreund, looks like msp430 has them at 16 bits, and also we don't have the answer figured out for some of those OS's
jzelinskie has joined #zig
satchmo has quit [Ping timeout: 272 seconds]
<ifreund>
andrewrk: thanks, thats a great reference
<ifreund>
now I wish zig would disallow coercion between the two
<andrewrk>
it does disallow it on the msp430 target
<andrewrk>
frmdstryr, `context: var` lets you pass anything. `context: void` means you must pass the void value. in the case of passing void, it is a no-op at runtime
<ifreund>
yeah, but allowing it on targets where c_int is 32 bits makes the code less portable
<ifreund>
this is a very small problem in reality though
<ifreund>
i don't even know what msp430 is
<andrewrk>
well that's the thing though. you can already do `const foo = if (target_specific_thing) a else b;`
<andrewrk>
so we already have to factor in the target in order to produce correct compile errors
<andrewrk>
I don't think there is any other way to ensure portability other than testing for all the different supported platforms
<ifreund>
you're saying we can't just forbid coercion for all targets? or that forbiding it wouldn't be desireable?
<andrewrk>
started to draft out some code to see what implementing it would look like. I think it might just be too hard
<andrewrk>
*I started
<andrewrk>
ifreund, I'm saying that I think it makes sense to base the type coercion rules around the actual bit sizes of integers rather than the "name"
<andrewrk>
in the same way that u64 coerces to usize on 64 bit architectures but not on 32 bit architectures
<andrewrk>
I get what you're saying. You want it to be easier to have the compiler help writing portable code
<andrewrk>
but I think status quo is actually the best way to do it, with regards to this. we have to consider that a given project may be targeting only a specific set of targets
<ifreund>
yeah, I see your point
<andrewrk>
another thing to consider is that we want to support even more exotic architectures
<ifreund>
and so we don't want to make things weird for people who stick to mainstream archs
<andrewrk>
maybe on `-target brainfuck-crazyos-none` c_int is defined as 8 bits, but your project does not care about this particular target, for good reason
swills has quit [Ping timeout: 264 seconds]
<ifreund>
alright, i'm just gonna s/c_int/i32/ my code, c_int is an ugly name :D
<andrewrk>
c_int exists mainly for translate-c and the C ABI, so it makes sense to exist in the ABI boundary between your zig code and wayland.h or whatever, but that's about it
<frmdstryr>
@andrewrk, I'm really confused, what is the usefulness of passing void?
<andrewrk>
frmdstryr, it's not useful to pass void- but it's useful to pass something other than void
<andrewrk>
imagine that you are sorting by name, in a global string buffer. your objects are of type `string_index: usize` and you want to sort them
<ifreund>
is does translate_c do something special for c_int vs i32? i'm pretty sure it accepts a function signature on the ABI boundry with i32 where an int is expected
<andrewrk>
this way your items array does not need each element to contain the reference to the global string buffer, saving possibly many bytes in memory
<andrewrk>
it may help to consider this is the same pattern when spawning a thread
<frmdstryr>
So void is acutally type?
<frmdstryr>
or type id
<andrewrk>
have a look at the std.sort API. there is no void there. it accepts any type for the context
<andrewrk>
if you just want to fix your code, add `{}` to the call to sort() and `context: void` to your lessThan function
<andrewrk>
the generated code will be unchanged
<ifreund>
by the way, I'm pretty happy with where the std.log PR is right now, just waiting on a review to go through with the documentation updates before merge
<ifreund>
I could understand if you want to hold off to figure out what to do with #2029 though
<frmdstryr>
Yeah I fixed the code already, just trying to understand what the change is doing...
<frmdstryr>
A void arg is it's like a comptime var but it has no influance on acutal function signature?
<ifreund>
a void arg is nothing
<ifreund>
by providing a comparison function with a void arg you say that it doesn't take any context
<ifreund>
or the pattern used to make struct fields depend on a build option: my_field: if (build_options.foo) Foo else void,
<frmdstryr>
Yes looking at thread helped with that one. It would be nice if a few cases like those would be mentioned in the docs under the void section as it's really confusing :)
<ifreund>
feel free to open a PR :)
<Zannzen>
is there a way to limit the amount of resources a `zig build` can use?
<Zannzen>
(I'm assuming it's multithreaded internally but might be wrong there)