laaron has quit [Remote host closed the connection]
laaron has joined #zig
earnestly has quit [Ping timeout: 258 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 240 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<fengb>
Casts are noops: u8 in a register == u32
<Tetralux>
That seems strange.
<Tetralux>
Wouldn't the endianness make no difference at all to casts.
<fengb>
LE: loading u8 would be u8 + mask
<fengb>
BE: loading would be u8 + mask + shift
<fengb>
It’s probably trivial but you could chain upcasts and it’d be slightly simpler on LE
<Tetralux>
Remind me
<Tetralux>
If BE is 0x44332211
<Tetralux>
Is LE 0x11223344 ?
<fengb>
Like if you chained instructions like load u8, add u8, mult 16, add 32, there’s multiple casts that’d sorta disappear
<fengb>
Yep
<Tetralux>
So why can't BE just do the same as LE, but from the other end?
<Tetralux>
LE = take first byte, mask off the rest
<fengb>
Because LE: 0x11 = 0x1100 = 0x11000000
<Tetralux>
BE = take 4th byte, mask out the rest.
<fengb>
So bytes never shift when you upcast
<fengb>
So upcast is literally a noop in the register
<Tetralux>
Ah I see what you're saying.
<Tetralux>
But...
<Tetralux>
The registers are in bytes are they.
<Tetralux>
aren't*
<Tetralux>
They're all usize.
<fengb>
Yes, but load also doesn’t need a shift if it’s usize aligned
<fengb>
Again, it’s theoretical and probably doesn’t matter a whole lot
<Tetralux>
My point is
<Tetralux>
Unless I'm not getting how this works
<Tetralux>
They can do the exact same thing as LE, just from the other end.
<Tetralux>
Casts can be noop
<Tetralux>
Because the registers are the same size regardless of endianness.
<fengb>
Ah but we have different register sizes too
<fengb>
u32 vs u64 is more apparent since both exist natively
<fengb>
Oh wait
<Tetralux>
You mean how on most x64 chips, all registers are u64, but you can address a part of them; whereas on your particular BE chip, you have some that are only u32?
<fengb>
So here’s where I sorta learned the difference:
<fengb>
[]u8 == []u32 for LE
<fengb>
Given regular padding, the pointers start at the same address and the data is “aligned” naturally
<Tetralux>
Huh?
<fengb>
Address are offset by byte count. &[0]u32 == &[0]u8, &[1]u32 == &[4]u8
<Tetralux>
with ya so far xD
<fengb>
The more I think about it... the less I feel like it matters lol
<Tetralux>
XD
<fengb>
On BE, &[0]u32 == &[3]u8 if you’re byte casting
<fengb>
But I’m not sure why you’d do that
<fengb>
Or rather, the 4 bytes of the u32 are reversed if you drill into the bytes
<fengb>
I got that backwards -_-
<fengb>
&[0]u8 is (&[0]u32 + 3 bytes)
<fengb>
This matters for... something...
<Tetralux>
Oh I think I see what you mean
<Tetralux>
Basically, on little, the ptrs are at the "front" of the type, but on big, their at the back
<Tetralux>
back = far end
<Tetralux>
front = near end
<Tetralux>
So, 0x11223344 => &u32 gives you a ptr aligned to the 44, but to 11 for u8.
<Tetralux>
Like
<Tetralux>
The pointer reads to the left.
<Tetralux>
Whereas on little it reads to the right
<Tetralux>
As it were.
<Tetralux>
Is that what you mean?
<Tetralux>
XD
<mikdusan>
i still don't think it matters for casting given equally implemented instruction sets on either machine
* Tetralux
shrugs
<Tetralux>
XD
<fengb>
Historical reason: little endian reads faster because the ALU can operate on lowest byte immediately after fetch >_>
<fengb>
Totally relevant right?
earnestly has joined #zig
<daurnimator>
fengb: assuming you want to operate on the lowest byte first. In reality you want to work on the highest byte first... that's why network protocols are mostly big endian (and big endianess is called "network byte order")
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 276 seconds]
abbiya has joined #zig
avoidr has quit [Quit: leaving]
reductum has joined #zig
<stratact>
After thinking about a project to do in Zig, I'm going to write an mtpfs-like implementation using fuse3 instead of fuse2 with libmtp because the original mtpfs and simple-mtpfs are broken on FreeBSD
<stratact>
hopefully that will solve my problem...
_whitelogger has joined #zig
kristoff_it has joined #zig
samtebbs has joined #zig
wilsonk_ has quit [Ping timeout: 245 seconds]
chemist69 has quit [Ping timeout: 246 seconds]
wilsonk has joined #zig
<samtebbs>
Is there a premade allocator made available to tests or do I have to create my own?
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
reductum has quit [Quit: WeeChat 2.6]
<samtebbs>
Scratch that, I can just use the std.heap.direct_allocator
chemist69 has joined #zig
alexander92 has joined #zig
mahmudov has joined #zig
marmotini_ has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Client Quit]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
<dimenus>
scientes: I got a garbled stderr print out when using your PR against current master
waleee-cl has joined #zig
<andrewrk>
oh, brilliant. I can merge async-std-lib into master. it's just not advised to use until #3069 is solved
<dimenus>
andrewrk: awhile back you recommended linkers and loaders, would you still recommend that for learning more about the topic?
<dimenus>
or do you have another go-to resource>
<andrewrk>
yes I would recommend it
<andrewrk>
the main thing that it helps with is it gives you the idea of "oh, this isn't some fancy thing, this is just what I would do if I were solving the same problem"
<andrewrk>
so then if you want to understand what a linker or loader is doing, you can just think, "how would I make it work?"
laaron has quit [Remote host closed the connection]
mahmudov has quit [Ping timeout: 246 seconds]
laaron has joined #zig
Akuli has joined #zig
earnestly has joined #zig
firefox317 has joined #zig
<firefox317>
LemonBoy is on fire fixing all those bugs, nice work!
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 276 seconds]
<Sahnvour>
andrewrk: just became aware that snsystems is doing something kinda similar to zig-cache on a fork of llvm, see https://github.com/SNSystems/llvm-project-prepo/wiki, might be interesting to look at it
<andrewrk>
indeed that does look to share many of zig's stage2 goals
Tetralux has joined #zig
donallen has joined #zig
stratact has joined #zig
<donallen>
Sqlite3 has a function sqlite3_bind_text. It takes 5 args, the last two of which are almost always the same. So in C, I define a preprocessor macro, BIND_TEXT, that accepts the first three args and supplies the last two in calling sqlite3_bind_test. I suppose I could do the same in zig by defining a bind_text function and then calling it inline.
<donallen>
But all those @inline calls clutter the code. Is there a better way?
<Tetralux>
Are the last two things basically the same variable throughout the code?
<Tetralux>
Like
<Tetralux>
Can you wrap them into a SqlContext or something?
<andrewrk>
donallen, how about making a function that has all the args except the last 2, and calling that everywhere?
<Tetralux>
I thought of that too, but where do you store the last two args?
<andrewrk>
if you are compelled to make it inline, you can mark it inline at the declaration. But I don't think you should even do that
<donallen>
Andrew -- yes, that would work, at the expense of function call overhead, which I don't incur with the C macro.
<Yardanico>
donallen: you can define an inline fn
<andrewrk>
zig does not recognize "function call overhead" as a valid concept
<Tetralux>
Huh
<Tetralux>
?
<Tetralux>
Can you elaborate on that? :D
<andrewrk>
absent explicit syntax, zig is free to inline, outline, tail call, sibling call, or otherwise completely re-arrange the logic of programs to optimize the runtime performance. functions are just to communicate semantics, they are not a performance barrier
<donallen>
If I can mark a function "inline" at the fn def site, that's the solution. Except I want to learn more about Andrew's last comment.
<donallen>
Andrew -- I think what you are saying is I should not worry about just calling an ordinary function and leave these little optimizations to the compiler?
<Yardanico>
donallen: instead of "fn" use "inline fn" and zig docs say: "The inline specifier forces a function to be inlined at all call sites. If the function cannot be inlined, it is a compile-time error."
<donallen>
Yardanico -- thanks. I have been playing with zig for all of 2 days, so have not digested all the documentation yet.
<andrewrk>
donallen, yes. putting "inline" on a function definition or callsite is actually *restricting* what the optimizer may do. Perhaps someone else is compiling your library with release-small, for example, and it would have been better to not inline
<andrewrk>
in practice, sometimes `inline` can improve performance. It's reasonable to do this when one is maintaining a performance benchmark. But without testing perf, don't do these kind of things
<Tetralux>
I'll just point out that in general, inlining it the primary source of optimization.
<donallen>
Andrew -- ok, got it. I can't tell you how many times I've told other people exactly your last sentence, which amounts to premature optimization. I'll take your advice and leave it to the compiler.
<Tetralux>
That, and being more careful about the cache etc.
<Tetralux>
But yeah, it's no silver bullet.
<Tetralux>
It's just a fairly safe bet, so it seems to me.
wootehfoot has joined #zig
<Tetralux>
Also of course, optimizing for speed is not the same as code size, obviously - so if restricting the optimizer gets better speed, but greater code size... you probably want that a decent chunk of the time.
<Tetralux>
Besides, giving the compiler fewer complicated things to optimize, the better, for compilation speed.
<Tetralux>
.. in debug mode. In release, you obviously don't care quite as much.
<Tetralux>
Though still - giving it loads of work to do - kinda like the linker - the less the better.
<Tetralux>
Inlining is trivial AFAIK - I haven't looked into much of the other fancy things - I imagine tail calling it relatively simple too?
<Tetralux>
Well - either way - I'd probably inline something that simple, but YMMV. Obviously you wanna measure at some point and figure out where the slow parts are.
avoidr has joined #zig
laaron has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
<fengb>
If it's really simple, Zig tends to inline automatically
<scientes>
dimenus, can you send me the code to reproduce. The current PR is running into lots of stuff now that it is rebased, some my bugs (and present before), some latent bugs.
<fengb>
How does subarchitecture optimiziation work? Like targeting an Intel family
<Yardanico>
fengb: I think it's like "-march=native" with GCC
<fengb>
Right, but does it prevent executing on other archs?
<mikdusan>
andrewrk: what do you think about splitting out all test-* steps from $REPO/build.zig into their own build files, and have main spawn to call them? it should allow us drop from (4.7G) to about (1.0GB + 1.0GB) of VM requirement. it may complicate build-failure understanding tho.
<fengb>
Or is it just a special arrangement of instructions that goes faster depending on arch
<mikdusan>
i already did a manual trial of test-std, and if that's broken down to 6 groups, we can limit it to 1.0GB
<andrewrk>
mikdusan, separating into their own build files will save memory in running the build script itself, which I don't think is the problem. they're already executing in child processes
<andrewrk>
splitting std lib tests into multiple could be valuable
<andrewrk>
the first thing I want to do is add a memory profiling configure option so that we can do expensive checks and data collection and present a useful report of what is taking up the most memory
<Tetralux>
Test allocator anyone? :p
<mikdusan>
i admit not having watch test _execution_ resource usage; the standout to me seems zig compiling build.zig. but you're right we need to understand _execution_ resource too. i was just looking for low-hanging fruit
<mikdusan>
sorry. zig compiling something, not build.zig .
<andrewrk>
I also think that there is probably lots of low hanging fruit in the compiler itself, such that we wouldn't need to do any splitting
<fengb>
Has anyone played with Github actions?
mahmudov has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
<andrewrk>
Yardanico, I did some basic RISC-V support in the llvm9 branch
<Yardanico>
andrewrk: well, also another thing (not related to Zig though) is that Clang 9 will be able to build the linux kernel, so you potentially (some people might like this) create a fully working non-GNU distro without any usage of GNU programs
<Yardanico>
sadly the xtensa patch didn't get merged to llvm yet
<andrewrk>
Yardanico, it is related to zig because it means you can build the linux kernel with zig :)
<Tetralux>
O.O
<Tetralux>
Sounds good.
donallen has left #zig [#zig]
Akuli has quit [Quit: Leaving]
return0e_ has joined #zig
return0e has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
batok has quit [Remote host closed the connection]
kristoff_it has quit [Ping timeout: 258 seconds]
<l1x>
:)
<l1x>
andrewrk: i would like to build a non-linux kernel
<l1x>
how about that
<companion_cube>
andrewrk: and when will you be able to run translate-c on linux successfully? 😇
<Yardanico>
companion_cube: wdym? I run it on linux fine
<andrewrk>
probably never. I'm guessing they use macros in silly ways
<companion_cube>
I mean, on the linux source code :p
<companion_cube>
yeah probably
<andrewrk>
oh, actually that doesn't matter for translating source. I actually think we could potentially get that to work
laaron has quit [Remote host closed the connection]
laaron has joined #zig
Ichorio has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<Yardanico>
hmm, why does Zig compiles with gcc on linux? :D I thought it always used clang even for C++ sources (if clang is available ofc)
<Yardanico>
ah, it seems that the compilation with clang fails because of "undefined reference to symbol '_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE7compareEPKc@@GLIBCXX_3.4.21'" (at least on my arch linux)
<Yardanico>
ah nvm it seems it used the linker from gcc
<dimenus>
scientes: I'll work on a MRE tonight
<andrewrk>
Yardanico, due to c++ compilers not being ABI compatible, one must use the same compiler to build LLVM/clang and zig
<andrewrk>
I believe this is noted in the readme
<Yardanico>
andrewrk: oh
<andrewrk>
so if you use a system LLVM package you must use the system compiler toolchain to build zig
<Tetralux>
By 'system', you mean if you install LLVM/clang from the system's package manager?
<Yardanico>
well yeah, in my case LLVM and clang were installed from official arch repos (and they use GCC in arch for their packages)
<Yardanico>
it seems the only somewhat working linux distro which uses clang by default is OpenMandriva
<Tetralux>
By 'use', do you mean "compile's their C code with" ?
<Yardanico>
Tetralux: they use clang whether they can in compiling all packages and stuff
<Tetralux>
And where they can't, they use gcc?
<Yardanico>
Tetralux: either try patching the src, or in the most extreme case gcc (e.g. for architectures not supported by LLVM)
<Yardanico>
although I didn't try that distro
* Tetralux
wishes it was not this complicated
<Tetralux>
.. and that LLVM/clang builds more quickly for that matter.
<Yardanico>
although that info is a bit outdated, I'm really tempted to try that distro rn
* Tetralux
sets about making a VM with it.
<Tetralux>
Never tried this one.
Tetralux_ has joined #zig
Tetralux has quit [Ping timeout: 268 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
earnestly has quit [Ping timeout: 244 seconds]
<Snektron>
LLVM and clang are built with gcc and zig with gcc on my sytem
<Snektron>
No problems
earnestly has joined #zig
<andrewrk>
that's fine you used the same compiler for both
<Snektron>
Eh sorry, i meant to write clang for zig
<Snektron>
Though clang and llvm are built by the package maintaners
<andrewrk>
you're doing something unsupported. it's fine if it works for you but no help if it breaks
<Snektron>
Haven't run into anything yet
<Snektron>
Afaik clang tries to remain somewhat gcc compatible
<andrewrk>
it can manifest as confusing segfaults
<Sahnvour>
andrewrk: what was the reason to build libuserland unconditionnally again ? instead of depending on std/ and src/ ?
<andrewrk>
Sahnvour, it's unconditionally running `zig build` according to cmake. but `zig build` has its own caching which is correctly resolving the dependencies
<Sahnvour>
the thing is, when you build zig in debug, it's not instant
<andrewrk>
a debug llvm?
<Sahnvour>
both llvm and zig for me
<Sahnvour>
but since it hits the cache, I assume that's only zig-cpp code and llvm is not involved
<andrewrk>
I don't think a debug llvm build of zig is viable for anything other than one-off debugging tasks and the occasional test suite run overnight to catch llvm assertions (as I'm doing now in the llvm9 branch)
daurnimator has quit [Ping timeout: 250 seconds]
<andrewrk>
depending on what you're debugging, you can avoid the libuserland step by making target zig0 instead of zig
<Sahnvour>
with msvc, there's little choice
<andrewrk>
on windows I've been developing with a release build, and switching to debug build only when I need to use the debugger
<Sahnvour>
I mean I could #pragma optimize("", off) every file, or hack CMakelists.txt to turn off optimizations but ...
<andrewrk>
I see zig0.vcxproj
<andrewrk>
msbuild zig0.vcxproj
<andrewrk>
looks like it goes into <build-mode>/zig0.exe
<Sahnvour>
hmm that's OK as long as I don't need features implemented in zig yeah
<andrewrk>
long term, self-hosted zig will let us mix llvm-release with debug-zig
<andrewrk>
short term we're at the mercy of microsoft
<andrewrk>
we could also look into supporting building with clang rather than MSVC on windows
<andrewrk>
idk how complicated that is compared to the msvc instructions
<Sahnvour>
here's the thing : I'm debugging within VS, which will trigger a rebuild of libuserland everytime I start the executable
<Sahnvour>
so, sure, it will hit the cache of previously compiled libuserland
<Sahnvour>
but even that is slow
<Sahnvour>
because it's a debug executable of zig
<Sahnvour>
and llvm is irrelevant here, we're not even calling it
<andrewrk>
it should not trigger a rebuild every time you start the executable
<Sahnvour>
msbuild does
<andrewrk>
running `zig build` makes sense but are you saying zig is actually recompiling libuserland?
<andrewrk>
there's another thing that build step is doing which is installing lib/* files. is that perhaps what is taking the time?
<Sahnvour>
ah ? I thought this was done in the install target
<dimenus>
the install target is the default target now iirc
<andrewrk>
it changed when we moved to zig build doing the install rather than cmake
<Sahnvour>
ok, so that might be it
<Tetralux_>
Sahnvour: Do you mean how, if you run msbuild in a shell, it pauses on "InitializeBuildStatus:
<Tetralux_>
Creating "x64\RelWithDebInfo\zig_build_libuserland\zig_buil.1C4529A9.tlog\unsuccessfulbuild" because "AlwaysCreate" was specifi
<Tetralux_>
ed." ?
<Tetralux_>
Only mine does that every time.
<andrewrk>
Sahnvour, it's avoiding file copy operations if the destination is up to date. but it has to check many files, maybe that is still taking a while
<Sahnvour>
anyways I'd consider it cleaner that the native build system (what cmake generated) be able to tell if there is something to do or not, because in this case it could
<Sahnvour>
andrewrk: would not bu surprised, it's NTFS after all :)
<Tetralux_>
andrewrk: Windows is really slow at enumerating files if you have a lot of them in a directory.
<andrewrk>
Sahnvour, that's not quite correct - previously the instructions were "you have to do the install target after any change, in case lib files are modified". Now the instructions are the same, except it happens in `make` and zig is actually faster at doing the install step than cmake was, according to my timings
<andrewrk>
the difference is that previously it let you avoid the file copying step if you chose the non-install target
<andrewrk>
we often had people here wondering why their changes weren't getting picked up
<Tetralux_>
.. Probably because cmake prints out a line to stdout for every file - notoriously slow on Windows too.
<andrewrk>
Sahnvour, I agree that, for advanced users such as yourself, it would be nice to break the rules and avoid file copies, if you know you didn't modify anything
<Sahnvour>
ok, I see that was error prone
Tetralux_ is now known as Tetralux
<andrewrk>
*avoid testing whether file copies need to be made*
<andrewrk>
on linux it's quite fast - `make` with nothing to do is 0m0.669s for me
<Tetralux>
Yeah - in my linux VMs, make with nothing is very fast.
<Sahnvour>
I'm paying much attention to this as I'm deep down into it at work too at the moment ;)
<andrewrk>
and that's checking every single file in lib/* and std/* to see if it is outdated
<Tetralux>
I don't know enough about linux filesystems to know why it's that much faster.
<Tetralux>
Jon Blow ran into the slow Windows file problem before - IIRC it was around ~10,000 files in one directory tree where enumerating them became really slow.
<Tetralux>
lib + std has 8,000.
<Tetralux>
And that's only counting the one's in the root of the repo.
<Tetralux>
(not the build dir)
<andrewrk>
I solved an issue with it being even slower on windows when I made this change
<Tetralux>
Did you have everything in _one_ folder before? xD
<Sahnvour>
I guess i'm just not used to work with 'install' targets, instead of having one main target that builds and run directly
<Tetralux>
Maybe we have the executable look up a directory for it's lib/std folders, and have the install step just copy zig into root/bin or something.
<andrewrk>
I think building zig0 is a good workaround for this advanced use case
<andrewrk>
--override-std-dir and --override-lib-dir are also available
<Tetralux>
I'm guessing zig0 uses the buildfolder/lib/std for its stdlib?
<Tetralux>
And you could do `--override-std-dir ..` to use the root ones.
<Tetralux>
Is that how that works?
<Sahnvour>
speaking of which, where should --override-lib-dir point to ?
<andrewrk>
lib
daurnimator has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
halosghost has quit [Quit: WeeChat 2.5]
Ichorio has quit [Ping timeout: 250 seconds]
qazo_ has joined #zig
qazo has quit [Ping timeout: 246 seconds]
Ichorio has joined #zig
qazo has joined #zig
qazo_ has quit [Ping timeout: 245 seconds]
<Tetralux>
Is that how that works?
<Tetralux>
Oops
<Tetralux>
Wrong window again lol
Ichorio has quit [Read error: Connection reset by peer]
<Tetralux>
Hmmm.
<Tetralux>
Does anyone have a good example of struct inheritance in Zig?
<Tetralux>
Like, you have a base struct which you embed as the first field in the others.
<Tetralux>
And an enum to tell you which sort you have?
<stratact>
Hmm, does Zig have algebraic enums? If so that could work.
<stratact>
With algebraic enums, you can use the values to emulate dynamic dispatch in an inheritance-like fashion
<stratact>
Awesome, Zig does have them, they're called Unions.