channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=3&d=4

Saturday, 4 March 2023

00:01:00 <heat> mjg, hello mr pessimal, thank you for popping up, quick question: in a slow path should I hint towards "unlikely" (as in unlikely to succeed and break out the loop)?
00:03:00 <heat> i would assume either "yes" or "doesn't matter" because you're expecting contention anyway
00:03:00 <mjg> that one is funky
00:04:00 <mjg> the way you are doing shit right now is you are training the predictor to take the branch
00:04:00 <mjg> and you are going to suffer a misprediction once the lock is free
00:04:00 <mjg> unfortunately there is no "this is the shit to expect" clause
00:04:00 <mjg> tl;dr don't hint
00:05:00 <heat> ok sgtm
00:05:00 <heat> thanks
00:05:00 <mjg> nothing can be done there afaics
00:06:00 <moon-child> when does reset not work?
00:06:00 <moon-child> o.o
00:06:00 <mjg> i'll note your debug unlock should validate cpu number
00:06:00 <mjg> moon-child: i don't remember specific cases but i got some over the years
00:06:00 <mjg> moon-child: the only tried and true method was to kill the terminal
00:06:00 <moon-child> sure not term bug?
00:07:00 <mjg> no
00:07:00 <mjg> but whoever is at fault, see above
00:20:00 <heat> mjg, im kinda wondering now, shouldn't pause serve as a "next branch is mispredicting" hint?
00:20:00 <heat> this sounds like a legit idea
00:25:00 <moon-child> doesn't communication cost dominate mispredict?
00:25:00 <moon-child> btw I realised transactions can be (ab)used to implement mwait
00:26:00 <moon-child> start transaction; read check lock is still held. Then spin forever. Once the other guy releases it, he has to write it, which will kick you out of the transaction since it was in your read set
00:26:00 <moon-child> can wait on as much stuff at a time as you want in this way
01:54:00 <heat> apprently linux inlines all spinlock code by default
01:55:00 <heat> at least on the ticket spinlock side, have not looked at the mcs spinlock
03:21:00 <Jari--> hi all
03:21:00 * knusbaum waves
03:24:00 <Jari--> knusbaum: howdy
03:24:00 <Jari--> have to reboot this server soon, to get new Ubuntu revesion up and running
03:24:00 <Jari--> revision
03:26:00 <knusbaum> fun
03:26:00 <knusbaum> I don't know why, but upgrading a linux always makes me happy.
03:37:00 <heat> mjg, feel my spinlocks: https://github.com/heatd/Onyx/blob/89e4d0e81e543cbd6c9a3978f546feddf8840e7f/kernel/kernel/spinlock.c#L18
03:37:00 <bslsk05> ​github.com: Onyx/spinlock.c at 89e4d0e81e543cbd6c9a3978f546feddf8840e7f · heatd/Onyx · GitHub
03:37:00 <heat> spinniest of the locks
03:37:00 <heat> there is absolutely NOTHING wrong with them
03:45:00 <heat> i think old onyx really has an old UNIX vibe of "really half assed, fuck this shit, spaces please?"
03:46:00 <heat> also has the right dose of tutorial copy-paste
03:47:00 <heat> (I still remember where I took those bits from)
04:04:00 <geist> heat: that checks out. with armv8.1 theres' even a cas instruction
04:22:00 <heat> geist, what does?
04:23:00 <heat> funnily enough I was just now looking at lr/sc
04:23:00 <heat> on riscv
04:50:00 <geist> armv8.1, the new atomic instructions
04:50:00 <geist> has a straight CAS instruction
04:51:00 <geist> FEAT_LSE i think
05:54:00 <kazinsal> gods help me, I'm considering learning rust
05:57:00 <kazinsal> entirely amazed the osdev branch of the RESF hasn't appeared en masse yet like a gaggle of mormons I accidentally invited into my house
06:04:00 <zid> have you heard the word of our lord, graydon hoare/
06:09:00 <kazinsal> I was looking at that dude's "writing an OS in rust" blog thing thinking "maybe I can just bogart this dude's early bringup shit and rewrite it in C because I'm too lazy to do it myself", then it eventually turned into "huh rust is kinda elegant lookin"
06:11:00 <kazinsal> now I'm looking at the whole async/await thing and thinking, dang this would make some shit easier
06:14:00 <Mutabah> kazinsal: Joooiiiin ussss
06:23:00 <geist> kazinsal: it happens. i have to agree
06:33:00 <geist> it's a bit of symbol soup the first while, but then the compiler has *fantastic* error codes
10:31:00 <mrvn> kazinsal: don't you want the async/await to put threads to sleep in the kernel?
10:49:00 <immibis> async/await doesn't put threads to sleep at all
10:50:00 <immibis> it remembers what operation was on-going and then goes away and does something else in the meantime. You might notice the relationship between async operations and threads is very similar to the relationship between threads and processors and then wonder what the difference is.
10:50:00 <immibis> turns out that async/await is just cooperative multitasking with short-lived threads and small stacks
10:51:00 <immibis> if I had time to redesign computing from the ground up I might try making threads into what async/await is, instead
10:52:00 <immibis> another thing about async/await is that you have linked list stacks that can branch
11:27:00 <zid> good news, think I have sorted out a new PC
11:27:00 <kazinsal> :toot:
11:28:00 <zid> going to need a cooler and some other small bits, but a friend has a modern mobo + cpu going spare after upgrading
11:28:00 <zid> I have ram spare and so does he
11:32:00 * mjg snorts coke
11:36:00 <moon-child> zid: nice
11:36:00 <moon-child> mjg: not very nice
11:36:00 <kazinsal> who doesn't love staring at their ceiling at 4am counting their own heartbeats
11:39:00 <mjg> you a fentanyl kind of guy?
11:41:00 <gog> i'm just a rock n roll clown i do a lot of cocaine
11:44:00 <lav> cat sound
11:44:00 <kazinsal> phenazepam or gtfo
11:44:00 <lav> cat emoticon
11:45:00 <zid> You guys are fucking weird.
12:08:00 <mrvn> immibis: async/await is just coroutines
12:09:00 <mrvn> except sometimes you can send them between threads and sometimes you can't.
12:09:00 <mrvn> and no recursion
12:10:00 <qookie> worth noting is that in some cases (e.g. C++20 coroutine) you have stackless coroutines, which don't have their own stack and instead store their locals (ones that must live across suspensions anyway) in a separate coroutine frame object
12:17:00 <sham1> Poor man's objects or poor man's closures. Take your pick
12:17:00 <mrvn> One big problem there is that that is compiler magic. It sometimes can optimize away the allocation or stack. But you never know if that will keep happening in the future or not.
12:18:00 <sham1> That's why you compile to continuations and don't worry about the stack, because the stack doesn't exist
12:18:00 <mrvn> what's a stack?
12:18:00 <mrvn> waste of a good register if you ask me.
12:18:00 <sham1> What's a computer - Apple
12:18:00 <sham1> Still one of the most infuriating ads of all time for me. Although it means that it was successful
12:23:00 <mrvn> https://www.youtube.com/watch?v=3S5BLs51yDQ ?
12:24:00 <bslsk05> ​www.youtube.com: İpad pro— What's a computer– Apple - YouTube
12:27:00 <gog> what is computer
12:28:00 <gog> hvað er tölvu
12:28:00 <Ermine> Good question
12:29:00 <lav> how is coputer
12:36:00 <kazinsal> *why* is computer
12:36:00 <gog> when is compter
12:36:00 <Ermine> where is comper
12:38:00 <zid> everybody asks how is computer, but never how computer is
12:47:00 <immibis> mrvn: and coroutines are just threads
12:48:00 <mrvn> immibis: no, they never run in parallel
12:54:00 <mrvn> Computer - one of the first jobs obsoleted by, aehm, computers.
12:58:00 <nikolar> Poor computers
13:02:00 <mrvn> They can get a job solving captchas now.
13:10:00 <kof123> i just imagine "i'm a pc" "i'm a mac" (i forget to mention these are star wars ghosts) ....and then shows up <cow tools guy removes his mask, revealing seymour cray> "use the plow, luke"
13:10:00 * kof123 shows himself out
13:19:00 <immibis> mrvn: threads never run in parallel... for most of the history of computing
13:23:00 <mrvn> I fee so secure: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
13:23:00 <bslsk05> ​www.welivesecurity.com: BlackLotus UEFI bootkit: Myth confirmed | WeLiveSecurity
13:29:00 <ALowther> Hello all, happy Saturday! Any recommended books/articles talking about design patters for error/exception handling?
13:30:00 <zid> return -E
13:32:00 <mrvn> ALowther: https://www.youtube.com/watch?v=WjTrfoiB0MQ&t=3640s
13:32:00 <bslsk05> ​www.youtube.com: CppCon 2015: Andrei Alexandrescu “Declarative Control Flow" - YouTube
13:33:00 <ALowther> mrvn: Woah! I opened it on Youtube and apparently I'm already an hour in(7 minutes from the end). I'll have to give it another watch. Thank you :)
13:33:00 <zid> That's a lot of video just to say return -E
13:40:00 <mrvn> zid: that's not about saying "return -E". That's about e.g. closing a file automatically when you say "return -E"
13:41:00 <mrvn> much nicer imho than "goto fail1; ... goto fail2; ... goto fail3;"
13:41:00 <lav> if(thing()==-E)close(file); QED
13:42:00 <mrvn> ALowther: there are also some talks about using std::expected instead of exception and about turning/implementing exceptions via std::expected / std::variant
13:43:00 <mrvn> lav: but then you have to remember to "close(file)" at every point you catch an error.
13:43:00 <mrvn> and if anything throws an exception you don't handle the file still doesn't get closed.
13:44:00 <mrvn> He also has some examples that aren't better solved with RAII
13:49:00 <immibis> pros of RAII: EVERYTHING is closed automatically. Cons of RAII: everything is closed AUTOMATICALLY
13:50:00 <immibis> if you want to carefully order your closing for some reason, RAII is not an ideal fit
13:52:00 <ALowther> mvrn: As I am watching this video and affirming to myself that I've never seen this before, I realized that the link you shared is timestamped. :)
14:00:00 <mrvn> immibis: huh? RAII closes in the exact reverse order of opening.
14:00:00 <mrvn> ALowther: ups. I just searched on youtube. must have remembered where I was last.
14:02:00 <mrvn> immibis: also, if you need you can always call raii.close() prematurely, assuming you implement that method.
14:06:00 <heat> henlo
14:06:00 <lav> hewwo
14:07:00 <heat> uwu cowon thwee
14:07:00 <lav> mew
14:08:00 <zid> I need a 240mm aio
14:08:00 <zid> do you have one in your back pocket heat
14:08:00 <heat> no
14:09:00 <heat> my ass is not that thicc
14:10:00 <zid> what's the big lump thn
15:38:00 <zid> Why are aios so expensive, I can build one for way less than they're charging
15:39:00 <zid> Radiator from a ford focus is £32, fish pond pump is £4
15:39:00 <zid> corsair want £180
15:41:00 <epony> imagine what the corsair penis pump costs
15:44:00 <immibis> because it'll cost you more than £144 to make those work together. But you can use them if you want. Nobody's forcing you to buy the corsair one.
15:44:00 <immibis> free market economics says: if you are choosing to buy the corsair one, obviously you find corsair's work more useful than £144
15:45:00 <epony> it's a cheap part with a paintjob
15:45:00 <epony> there are so many naive people out there
15:45:00 <zid> It bloody won't
15:46:00 <epony> don't cut yourself where someone with a disease has cut their hand already
15:46:00 <zid> My guess is just that they're changing the models around so frequently they're doing tiny runs
15:46:00 <zid> and it's all CNC'd on-site in their offices or whatever
15:47:00 <epony> it's a logo paintjob
15:47:00 <moon-child> £4 for a pump? Idk, your mom will provide a lot of suction for just half that
15:47:00 <zid> rather than using the same radiator body for a couple of years and buying a machine to spit them out or such
17:43:00 <mjg> check out galaxy brain on gcc
17:44:00 <immibis> zid: they are going after the Gamely Gamers with unlimited money to spend on their Gaming Rig?
17:45:00 <mjg> wtf, how do i share an url from godbolt
17:46:00 <mjg> found it
17:46:00 <mjg> https://godbolt.org/z/re5e5eTWG
17:46:00 <bslsk05> ​godbolt.org: Compiler Explorer
17:48:00 <heat> mjg, wtf
17:49:00 <heat> ew
17:49:00 <Ermine> woah
17:50:00 <heat> man, i'm going to say the P word
17:50:00 <heat> this shit is PESSIMAL
17:50:00 <heat> there, I said it
17:50:00 <mjg> PESSIMAL A.F., Inc.
17:50:00 <mjg> is who wrote this
17:51:00 <Ermine> If you remove memset declaration gcc still compiles that
17:52:00 <mjg> i'm aware
17:52:00 <mjg> only added because clang comlpained
17:53:00 <Ermine> I was not aware
17:54:00 <heat> mjg, seems to really prefer rep stos for zeroing
17:54:00 <mjg> yes, it is part of my complaint
17:54:00 <mjg> this shows up somewhere past 32 bytes
17:54:00 <mjg> and it is *CRAP*
17:54:00 <heat> does stosq have a perf penalty like stosb does (or I assume it does, like movsb)?
17:54:00 <mjg> even ignoring the massacre above
17:54:00 <mjg> yes
17:54:00 <mjg> it is all from the rep prefix
17:55:00 <mjg> anyhowy ourl inxu kernel is full of it
17:55:00 <heat> fyi the codegen varies wildly per march=
17:55:00 <mjg> i intentionally did not use one to match closer what ends up being used when compiling the kernel
17:55:00 * Ermine wants clang compiled kerne
17:55:00 <Ermine> kernel
17:55:00 <mjg> the above massacre lines up with what lands in vmlinux
17:55:00 <heat> Ermine, LLVM=1
17:56:00 <mjg> Ermine: clang has its own woes
17:56:00 <heat> LLVM=1 make x86_64_defconfig
17:56:00 <heat> then LLVM=1 make bzImage modules and yer done
17:56:00 <heat> it replaces the CC with clang and all the normal tools with llvm tools
17:57:00 <zid> heat this is boring, fix my guaruaruard shading
17:58:00 <heat> this is kewl
17:59:00 <Ermine> heat: thank you
17:59:00 <mjg> Ermine: he is bullshitting
17:59:00 <mjg> Ermine: if you want a clang-compiled kernel run openbsd
17:59:00 <Ermine> Nah
18:00:00 <heat> doesn't free also use clang?
18:00:00 <heat> yeah it does
18:00:00 <heat> i think out of those 3 only netbsd still uses gcc for some stuff
18:01:00 <Ermine> Fwiw, Minix uses gcc for arm build because there are bugs in clang build
18:02:00 <heat> i'm honestly a bit sad that people are starting to forget gcc
18:02:00 <heat> it's a venerable toolchain
18:02:00 <zid> can I use clang with msvcrt
18:02:00 <heat> yes
18:02:00 <nikolar> that's true, i don't think they are forgetting it
18:02:00 <nikolar> just avoiding gnu i guess
18:03:00 <zid> can it deal with gcc static libraries
18:03:00 <zid> that'd be super rad
18:03:00 <heat> I don't know
18:03:00 <zid> I had a bunch of random .a files for sdl and stuff
18:03:00 <Ermine> libgcc?
18:03:00 <heat> clang has a cl.exe emulation mode, clang-cl
18:03:00 <zid> fuck cl I want clang-gcc.exe
18:03:00 <heat> that would be clang
18:03:00 <zid> -l:SDL.a
18:04:00 <heat> mjg, how stupidly unfair is my spinlock on NUMA systems?
18:04:00 <heat> I would expect "very"
18:04:00 <Ermine> You mean SDL.a built with gcc? And you want to have it to be linked with clang-built code
18:04:00 <Ermine> ?
18:04:00 <mjg> heat: that depends on the cpu
18:05:00 <mjg> heat: what it is first and foremost is pessimal af
18:05:00 <heat> dude what
18:05:00 <heat> it's pretty optimal?
18:05:00 <mjg> for a numa setting
18:05:00 <heat> you're not getting anything better out of a test-and-set spinlock
18:06:00 <mjg> i remind you that with correct lock you either get high lock/unlock rate *or* low tail latency
18:06:00 <mjg> your lock provides neither
18:06:00 <mjg> s/correct/optimal depending on usecase/
18:07:00 <mjg> once more i refer you to the mcs paper
18:07:00 <heat> what's incorrect about my lock?
18:07:00 <heat> it's a fucking test-and-test-and-set lock
18:07:00 <heat> plain and simple
18:07:00 <heat> it's not optimal but it's a thing
18:07:00 <mjg> 19:06 < mjg> s/correct/optimal depending on usecase/
18:07:00 <mjg> you specifically askd for numa
18:07:00 <mjg> it is shit on numa
18:07:00 <heat> yes, I'm just asking how unfair it is on numa
18:08:00 <mjg> 19:04 < mjg> heat: that depends on the cpu
18:08:00 <heat> since farther cores will just always be late to cmpxchg right (when under heavy load)?
18:08:00 <mjg> what will endu p happening once more depends on how cpus decide to deal with it
18:09:00 <mjg> normally the line will roam a little on one socket, get out to another one and roam there
18:09:00 <mjg> and that will keep happening back and forth
18:10:00 <mjg> consider the following:
18:10:00 <mjg> you grabbed the lock
18:10:00 <mjg> everyone else keeps polling on it
18:10:00 <mjg> once you release it, for all you know all the cpus will spot it at the same time
18:10:00 <heat> "Test-and-set suffices when using a backoff scheme; test-and-test-and-set is not necessary. " <-- why?
18:11:00 <mjg> that *mass* fucking armageddon is what makes the lock suck
18:12:00 <heat> right
18:12:00 <heat> and in the exponential backoff case since you're unlikely to have all CPUs spot it at the same time you can just test-and-set
18:12:00 <heat> ok
18:13:00 <dh`> but while you're holding it, test-test-and-set reduces bus traffic
18:15:00 <dh`> so it probably doesn't matter if it's a lock where you grab it and do three or four things, but if you need it for a bit longer it might help
18:16:00 <dh`> I suppose that's balanced against: when you do get the lock you incur two cycles of bus traffic instead of one (first to get a readonly copy, and then to claim it exclusively)
18:31:00 <mrvn> What do you mean by test-and-test-and-set? test, atomic test-and-set?
18:32:00 <mrvn> .oO(Can't we just have a wait queue for cores in hardware?)
18:41:00 <mrvn> dh`: On a system where exclusive access locks down (the bus for) all CPUs you wants to first test without exclusive.
18:43:00 <heat> mjg, i've read the relevant mcs paper bits
18:43:00 <heat> what now
18:45:00 <heat> 1) this was written in 1991 and I don't know if this holds up 2) apparently getting a good mcs lock for weakly ordered systems is a PITA 3) as far as I've heard, mcs is still slower than something like ticket, etc for lower CPU counts
18:45:00 <mjg> welcome to the suck
18:45:00 <mjg> there is *NO* such thing invented as an optimal spinlock
18:46:00 <mjg> see my previous remark about throughput vs latency
18:46:00 <mjg> the pragmatic thing todo by default isto be fair, thus mcs, clh or whatever else with fariness
18:46:00 <mjg> with understanding it does sacrafice performance for most cases
18:46:00 <moon-child> mrvn: maybe, but are you prepared for your snoop traffic to go up an order of magnitude? Now you have to discover not only who owns a cache line but also who else wants it too
18:47:00 <moon-child> mrvn: this is something I've been thinking about lately, because if you could solve that problem, you could solve a much more interesting problem with wait-free algorithms
18:48:00 <moon-child> say n different cores figure out they all want to fetch-and-add to the same location, and they somehow manage to get themselves into some order. Then they can compute a prefix sum of the value they want to faa, and then just the last guy in line grabs the location, does an add, and also broadcasts the value there to all the other cores in line
18:49:00 <moon-child> this would allow you to have n cores swarm a single location with faa, and have it complete in only log~ish time
18:50:00 <heat> mjg, something cool is that linux qspinlock acts more or less like a test-and-set in uncontended cases
18:51:00 <mjg> burp maybe i shoud also add there is other concerns, like lock size
18:51:00 <mjg> it's all tradeoffs
18:51:00 <heat> they also somehow compressed the whole mcs thing in 4 bytes
18:52:00 <mjg> i don't know what they did, but there is not much 'somehow' to it probably
18:52:00 <heat> i've read some comments on the thing and understood very little
18:52:00 <mjg> the stock standard idea is to compress kernel pointers by cutting of half
18:52:00 <mjg> and filling the rest
18:52:00 <mjg> which is whati m guessing they did
18:52:00 <heat> nope, no pointers
18:52:00 <mjg> alternatively they guarantee all threads come from a specific va range
18:52:00 <mjg> so you don't need 8 bytes for it either
18:53:00 <heat> you can just use cpu numbers
18:54:00 <heat> part of it I think is that they use cpu numbers-ish (not exactly I think??)
18:54:00 <heat> plus the qnodes get suck in percpu space
18:54:00 <heat> stuck*
18:55:00 <heat> it's confusing honestly
18:57:00 <mjg> again tradeoffs
18:57:00 <mjg> there is funzies in there
18:57:00 <mjg> for examle how do you know you got the right thread address should you want to inspect the state
18:59:00 <heat> why thread?
18:59:00 <heat> these are CPUs dawg
19:00:00 <mjg> you want to know which thread got there
19:03:00 <mjg> meanwhile https://lore.kernel.org/all/CAGudoHH8t9_5iLd8FsTW4PBZ+_vGad3YAd8K=n=SrRtnWHm49Q@mail.gmail.com/
19:03:00 <bslsk05> ​lore.kernel.org: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible - Mateusz Guzik
19:04:00 <mjg> thanks gcc
19:04:00 <mrvn> moon-child: The point of the non-atomic first test is to not own the cache line.
19:05:00 <mrvn> moon-child: This assumes that the test in an atomic test-and-set takes longer or blocks other uninvolved cores from progressing.
19:05:00 <moon-child> I was responding to 'Can't we just have a wait queue for cores in hardware?'
19:06:00 <mrvn> moon-child: oh, right. But that would mean all fetch-and-add pause the cores and then as each core releases the cache line the next core wakes up and continues.
19:08:00 <bnchs> hi osdev
19:08:00 <lav> hi bnchs
19:08:00 <bnchs> mew
19:08:00 <lav> mew
19:09:00 * bnchs pets lav
19:09:00 <moon-child> mrvn: my point is: for a lock, the best we can do is to have each core sequentially acquire it; a hardware wait queue might help with this. But if we had the machinery to implement a hardware wait queue, we could use it to implement fetch-and-add which is _faster_ than having every core acquire the location and add to it sequentially
19:10:00 <mjg> whoa -mstringop-strategy=alg
19:10:00 <mrvn> moon-child: not really. Unless you have a special queue for just fetch-and-add
19:10:00 <mjg> Override the internal decision heuristic for the particular algorithm to use for inlining string
19:10:00 <mjg> operations. The allowed values for alg are:
19:10:00 <mjg> reps, byte loops, unrolled...
19:10:00 * mjg likes gcc ngl
19:10:00 <moon-child> 'special queue for just fetch-and-add' is exactly what I mean to have
19:11:00 <moon-child> that's easy. The hard part is building up any type of queue at all
19:11:00 <mrvn> moon-child: and how should that become better than linear?
19:11:00 <moon-child> like I said, you can compute a prefix sum in log time
19:11:00 <heat> mjg, why are you doing linux dev?
19:11:00 <moon-child> and you had to do linear work anyway
19:12:00 <mrvn> not with fetch-and-add returning the value of the operation
19:12:00 <moon-child> yes, with fetch-and-add returning the value of the operation
19:13:00 <mjg> heat: lulz
19:13:00 <moon-child> mrvn: c0 through c3 want to faa v0 through v3 to l. They work this out and arrange themselves into a queue. c0 computes v0; c1 compute v0+v1; c2 computes v0+v1+v2; c3 computes v0+v1+v2+v3. Then c3 acquires l, adds v0+v1+v2+v3 to it, and broadcasts the previous value at l to c0 through c2
19:13:00 <mjg> heat: i did something faster than linux in freebsd, so fixed that in linux
19:14:00 <mjg> heat: gonna fix up some other shit so i can go back to claiming linux being faster
19:14:00 <moon-child> c0 through c2 then add the intermediate sum they computed to the value c3 broadcasted to them
19:14:00 <heat> mjg, btw what do you think of linux being inline happy?
19:14:00 <mjg> is it
19:14:00 <mjg> lemme disasm
19:14:00 <mrvn> moon-child: and that's wrong. You need to broadcast l, l+v0, l+v0+v1, l+v0+v1+v2
19:15:00 <heat> i noticed yesterday that the whole test-and-set and ticket spinlock stuff is fully inlined
19:15:00 <heat> and so is the kzalloc stuff you were looking at
19:15:00 <heat> qspinlock ofc isn't due to non-trivial amounts of code
19:15:00 <moon-child> mrvn: depends on whether it's a post-increment or a pre-increment. But that's an irrelevant detail; you get the idea, right?
19:15:00 <mrvn> moon-child: and v0+v1+v2+v3 takes linear time
19:16:00 <mrvn> moon-child: my values where pre-increment
19:16:00 <mrvn> aeh, post-increment I mean. sorry
19:16:00 <mrvn> pre-increment would be l+v0, l+v0+v1, l+v0+v1+v2, l+v0+v1+v2+v3
19:16:00 <moon-child> mrvn: v0+v1+v2+v3 takes logarithmic time
19:17:00 <mrvn> You don't get around computing all 4 additions.
19:17:00 <moon-child> remember we have n cores to work with here
19:17:00 <heat> mjg, fyi i think you and linus are soulmates
19:17:00 <mjg> https://dpaste.com/AT42H2CHS
19:17:00 <bslsk05> ​dpaste.com <no title>
19:17:00 <mjg> i don't see spinlocks inlined if that's what you meant
19:17:00 <moon-child> linear work, but logarithmic span. And we had to do linear work anyway
19:17:00 <heat> mjg, do you have qspinlocks on?
19:18:00 <mjg> yes
19:18:00 <mrvn> moon-child: You want the cores to compue l+((v0+v1) + (v2+v3)) distributed?
19:18:00 <mjg> perhaps the qspinlock stuff inlines into the fast path
19:18:00 <mjg> which is a func of its own
19:18:00 <mrvn> moon-child: that would be O(n * log n) then. worse than linear.
19:18:00 <mjg> i intentionally did not look at any of that code
19:18:00 <mjg> heat: disasm your own kernel dawg
19:18:00 <mrvn> moon-child: remember you need a 4 values, not just the last
19:18:00 <mjg> close_fd is a short consumers
19:19:00 <heat> i think the qspinlock stuff is all in .c because it's just too damn large
19:19:00 <heat> why should I disasm my code?
19:19:00 <moon-child> mrvn: it is perhaps counterintuitive, but we can do this in parallel in only O(logn) time steps
19:19:00 <mrvn> moon-child: I think your idea only works for atomic_add, the case where you don't return the value.
19:19:00 <heat> (fyi I usually do)
19:19:00 <moon-child> mrvn: https://developer.nvidia.com/gpugems/gpugems3/part-vi-gpu-computing/chapter-39-parallel-prefix-sum-scan-cuda iirc this explains a method for work-efficient scan
19:19:00 <bslsk05> ​developer.nvidia.com: Chapter 39. Parallel Prefix Sum (Scan) with CUDA | NVIDIA Developer
19:20:00 <mrvn> moon-child: maybe, O(n*log n) work on n cores can work out that way.
19:20:00 <moon-child> no. linear work
19:20:00 <moon-child> https://www.youtube.com/watch?v=33ZrIt-iGM4 guy steele explains it here also iirc
19:20:00 <bslsk05> ​www.youtube.com: Data Parallel Algorithms - YouTube
19:20:00 <heat> guy steal
19:20:00 <mrvn> moon-child: it's not linear work since you need all 4 results.
19:21:00 <heat> or guy steel
19:21:00 <heat> or girl steel really
19:21:00 <moon-child> we can compute sum scan with linear work and logarithmic span
19:21:00 <moon-child> promise :P
19:21:00 <mrvn> moon-child: must be some clever way to share sub terms
19:21:00 <moon-child> yes
19:22:00 <heat> mjg, anyway I wanted to know what's your opinion on that. if its too excessive or whatever
19:22:00 <mrvn> moon-child: All of that assumes though that all involved cores do fetch-and-add in the same cycle. So basically never. :)
19:22:00 <moon-child> like I LITERALLY SAID
19:22:00 <moon-child> the challenge is actually building the queue
19:22:00 <moon-child> :P
19:22:00 <mjg> heat: on inling what
19:23:00 <mjg> heat: they *don't* inline spinlocks at call sites
19:23:00 <heat> simple spinlocks, kzalloc, etc
19:23:00 <heat> they do man
19:23:00 <mrvn> moon-child: My idea was that locking a cache line would build a queue and all atomic operations would then happen fairly across all cores.
19:23:00 <mjg> i shown you disasm which shows otherwise
19:23:00 <moon-child> mrvn: they don't have to be on the same cycle though
19:23:00 <mjg> ffffffff81452470: e8 db d0 b2 00 call ffffffff81f7f550 <_raw_spin_lock>
19:23:00 <mjg> no branches prior to it
19:23:00 <heat> but that's qspinlock
19:23:00 <mrvn> moon-child: without having to loop and test over and over
19:23:00 <moon-child> they just have to be within the same 100 or whatever cycle window while somebody else holds the lock
19:23:00 <heat> I don't care about qspinlock right now
19:23:00 <moon-child> mrvn: which if they aren't, then you actually don't have any contention so there's nor eason to bother
19:23:00 <heat> the ticket lock stuff, the test-and-set stuff, all inlined
19:23:00 <mjg> so i don't know if they really have any case which truly inlines anything of that sort
19:24:00 <mjg> it is not inherently bad but it comes with limitations
19:24:00 <mjg> freebsd geezered into that state
19:24:00 <heat> and the kzalloc stuff you were looking at, all inlined
19:24:00 <mjg> kzalloc inlined?
19:24:00 <heat> yes
19:24:00 <mjg> are we looking at the same code
19:24:00 <mrvn> moon-child: I would propose that you will have lots of contention on the cache line but very few cases of fetch-and-add colliding.
19:25:00 <heat> yep
19:25:00 <heat> https://elixir.bootlin.com/linux/latest/source/include/linux/slab.h#L718
19:25:00 <bslsk05> ​elixir.bootlin.com: slab.h - include/linux/slab.h - Linux source code (v6.2.2) - Bootlin
19:25:00 <zid> ur a slab
19:25:00 <mjg> you do realize this expands to __kmalloc
19:25:00 <heat> https://lore.kernel.org/all/CAGudoHH8t9_5iLd8FsTW4PBZ+_vGad3YAd8K=n=SrRtnWHm49Q@mail.gmail.com/ <-- your patch explicitly touches the func too
19:25:00 <heat> yes, because half of this stuff is inlined
19:25:00 <moon-child> mrvn: what do you mean?
19:25:00 <mjg> and if you check the disasm, you will see it is not inlined
19:26:00 <mjg> which i did post btw
19:26:00 <mrvn> moon-child: one core does cmpxchg, the next does faa, the next test-and-set.
19:26:00 <moon-child> you can do 'prefix sum' on cas, or even mixed cas and faa
19:26:00 <heat> yes, i'm not saying anyone is inlining core bits of slab
19:26:00 <mrvn> moon-child: solving this for just faa is rather limited.
19:27:00 <heat> just saying that linux seems to be agressive on inline lots of little snippets of code
19:27:00 <moon-child> it works for any associative operator
19:27:00 <mjg> it is a tradeoff, whether it is worth it it depends
19:27:00 <heat> including the whole of spinlocks for anyone that doesn't use qspinlock
19:27:00 <mjg> i do concede people like to inlene without justification
19:27:00 <mjg> once more see freebsd, which literally inlines in a way which defeats the point(!)
19:27:00 <mrvn> mjg: and clang is worse
19:28:00 <heat> why?
19:28:00 <mrvn> heat: isn't the whole spinlock (without contention) faster than the function call overhead?
19:29:00 <moon-child> probably not 'faster'
19:29:00 <moon-child> but I would guess smaller
19:29:00 <moon-child> in the j interpreter lock fastpath is inlined
19:30:00 <mjg> today's episode is sponsored by letters T, R, A, D, E, O and F [two of them]
19:31:00 <mjg> wanna geezer, here is freebsd which does inline spinlocks
19:31:00 <zid> Can I have R and E
19:31:00 <mjg> it starts with spinlock_enter()
19:31:00 <heat> today's episode is sponsored by the letters P, E, S (double donation), I, M, A, L
19:31:00 <mjg> ... which on every arch is already a function call
19:31:00 <zid> pissemal? is that a new number base?
19:31:00 <mjg> which defeats the point of inling squat
19:31:00 <moon-child> lol
19:31:00 <mjg> you literally got increased i-cache use with 0 benefit for it
19:32:00 <mjg> and no, it did not have a 'good erason' at any point in time in any universe
19:32:00 <heat> aw man grok deaded
19:32:00 <heat> dragonflybsd pessimalest of the pessimals
19:33:00 <moon-child> so is freebsd using outlined functions for all its atomics
19:33:00 <moon-child> a la libatomic_ops
19:33:00 <mjg> no
19:33:00 <moon-child> rather than inline asm or intrinsics?
19:33:00 <mjg> it used to!
19:33:00 <moon-child> I mean at some point I'm sure that was reasonable
19:33:00 <Amorphia> any of y'all ever try OpenIndian
19:33:00 <mjg> it might have been
19:33:00 <Amorphia> OpenIndiana*
19:33:00 <Amorphia> it's the hipster BSD
19:33:00 <mjg> hey man, do you have a bet with geist?
19:33:00 <Amorphia> (it's also shit)
19:33:00 <heat> OpenIndian least racist washington american football team
19:34:00 <moon-child> lmao
19:34:00 <Amorphia> lmao
19:34:00 <heat> fyi hipster BSD is already getting into dangerous levels of fedora usage
19:35:00 <heat> at that point you also grow a second ponytail on your neckbeard
19:35:00 <mjg> heat: anyway fstat on linux sucks terribly, i'm gonnna fix it
19:35:00 <Amorphia> heat: lmao
19:35:00 <mjg> but there is a rabbit hole of perf loss all over
19:35:00 <mjg> very bsd-esque of linux
19:37:00 <dh`> solaris is bsd? that's ...creative
19:38:00 <heat> i only use enterprise UNIX distributions like UnixWare
19:39:00 <moon-child> UUUUUUUUUUUUUUUUUUUNNIIIX
19:39:00 <moon-child> UNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIXUNIX IOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOCTL
19:39:00 <CompanionCube> Amorphia: iirc sortie did a twitter thread on installing openindiana and ome other one
19:39:00 <Amorphia> when i tried it it couldn't mount my fuckin disk and partition it not even kidding
19:40:00 <moon-child> tbf
19:40:00 <moon-child> you have to give respect to the people who brought us dtrace and zfs
19:40:00 <CompanionCube> iirc there's a fancy graphical installer and everything
19:40:00 <mjg> want some fun?
19:40:00 <Amorphia> CompanionCube: yea but it couldn't detect my hardware :V
19:40:00 <mjg> lemme show you something
19:40:00 <Amorphia> disk hardware i mean
19:41:00 <heat> moon-child, sun was a great company
19:41:00 <heat> they did a lot of cool shit
19:41:00 <CompanionCube> moon-child: even though it's funny that the zfs upstream is a renamed zfsonlinux repository
19:41:00 <mjg> here is an email i sent to oracle in 2016 https://dpaste.com/ARFDB2NNC
19:41:00 <bslsk05> ​dpaste.com <no title>
19:41:00 <mjg> shows a critical vuln and an exploit
19:41:00 <mjg> i also notified illumos folk,it is all sorted out for years now
19:41:00 <CompanionCube> mjg: STOP REVERSE ENGINEERING OUR CODEQ
19:41:00 <mjg> the vuln found itself by running trinity on illumos +_linux emul
19:42:00 <mjg> want a lul project -- do it again, guaranteed finds
19:42:00 <heat> i need to run that on Onyx
19:42:00 <mjg> trinity is kind of lame mate
19:42:00 <mjg> try syzkaller if you can
19:42:00 <mjg> i suggested trinity above caues 0 prep
19:43:00 <heat> but syzkaller is a good bit harder
19:43:00 * CompanionCube doesn't have the link to the deleted oracle rant, alas
19:43:00 <heat> i have an In Progress(tm) port of syzkaller but that'll take some time to get working ofc
19:43:00 <moon-child> heat: yeah
19:43:00 <moon-child> CompanionCube: what oracle rant?
19:43:00 <mjg> oh man
19:43:00 <mjg> "xor %rsi, %rsi;"
19:43:00 <mjg> fuckin embarassing
19:44:00 <CompanionCube> moon-child: the one titled like my allcaps message
19:44:00 <sham1> Sun did a lot of cool stuff
19:44:00 <moon-child> mjg: lol
19:44:00 <sham1> Speaking of that
19:44:00 <moon-child> nasm will optimise that automatically but gas will not
19:44:00 <sham1> heat: when will Onyx have OpenJDK
19:44:00 <mjg> really?
19:45:00 <heat> sham1, One Day
19:45:00 <heat> I did look into it for a bit and it seemed non-non-trivial
19:46:00 <mjg> port SortixJDK
19:46:00 <mjg> mr contributor
19:46:00 <heat> no such thing
19:46:00 <mjg> then contribute and port
19:46:00 <heat> i need to get my own mask
19:46:00 <geist> yah the xor rsi thing is pretty stupid. honestly i've written it as rsi before simply to be more clear
19:46:00 <heat> with blackjack and hookers
19:46:00 <geist> make it more obvious you're zeroing out the whole thing. and on r8-r15 there's no disadanvatage because you already need the rex prefix
19:46:00 <moon-child> but the bytes geist the precious bytes
19:47:00 <geist> YOULL NEVER GET THEM BACK
19:47:00 <mjg> ya man life ruined
19:47:00 <mjg> RUINED
19:47:00 <geist> that's more like blame the stupid architecture
19:47:00 <CompanionCube> moon-child: if you haven't seen it before: https://archive.is/7KZ30
19:47:00 <bslsk05> ​archive.is: archive.is
19:47:00 <sham1> Not the bytes!
19:47:00 <moon-child> https://www.hpl.hp.com/techreports/1999/HPL-1999-78.pdf hax
19:47:00 <mjg> think of the bytes!
19:47:00 <heat> GOOGLE ENGINEER BRUTALLY SLAMS INTEL AND AMD ENGINEERS by calling THEIR architecture STUPID
19:48:00 <mrvn> What's the solution for a 'volatile std::bitset<16u>'?
19:48:00 <geist> yah this one is on AMD
19:48:00 <mjg> :]
19:48:00 <mjg> AMD ENGINEERS DESTROYED BY FACTS AND LOGIC
19:48:00 <geist> there's a new fun one i've been dealing with on riscv: using registrs when writing asm that let it use the compressed forms
19:48:00 <moon-child> sometimes I wonder how far you could get if you just cleaned up the x86 encoding moderately and did a thing to translate binaries in place
19:48:00 <heat> i'm ready for thesun.co.uk
19:49:00 <geist> it's difficult, and the assembler is free to replace instructions as it sees fit
19:49:00 <mrvn> heat: Single Transation UPdate Instruction Descriptor?
19:49:00 <moon-child> maybe wider decode, smaller insns
19:49:00 <CompanionCube> heat: The Register, surely?
19:49:00 <moon-child> compressed insns are interesting. One thing I kinda wonder though is to what extent you have to trade off scheduling to get the pairable insns next to each other
19:49:00 <mrvn> moon-child: it would fail the first time you have self modifying code or code and data mixed together.
19:50:00 <sham1> Here comes TheSun
19:50:00 <geist> yah duno. and how much does the compressed isns matter on current riscv hardware vs futire tuff
19:50:00 <heat> CompanionCube, i'm more versatile than that
19:50:00 <geist> it would only reallym atter because it'd increase icache hits presumably, but that may not be the bottleneck
19:50:00 <sham1> Uuugh, I have to do machine learning model performance estimation
19:50:00 <heat> i can BRUTALLY SLAM keir starmer as well
19:50:00 <moon-child> mrvn: yes, but can be worked around. Trampoline to os to re-translate or w/e
19:50:00 <mrvn> geist: how much icache do modern cores have?
19:51:00 <geist> in general, usually 32 or 64k
19:51:00 <mrvn> moon-child: somehow you can. Don't ask me how but that x86 emulator for AArch64 seems to handle it really well.
19:51:00 <geist> the apple silicon is the outlier that i know abut with 192k
19:51:00 <heat> geist, i think they're refraining from doing too much optimization work on linux riscv because of exactly that problem
19:51:00 <heat> Who Knows how things will look like in real good riscv implementations
19:51:00 <geist> heat: yeah i ca see that. the curret cores are mostly in order implementations that you can't do much with
19:52:00 <zid> quick, lock the hardware into exactly the optimizations linux happens to support for it
19:52:00 <moon-child> geist: oh interesting have a ref for that?
19:52:00 <moon-child> wiki only has the d$
19:52:00 <geist> moon-child: hmm, yeah i've seen it referred a few times in some deep dives
19:52:00 <geist> and folks have probed it pretty easily
19:52:00 <geist> but now i say that i dunno if they changed aythig on M2
19:52:00 <geist> this was for M1
19:52:00 <mrvn> geist: must be a reason why icaches haven't grown much. *hint* *hint*
19:53:00 <moon-child> didn't see any cache info in dougallj's docs. Might be in maynard handley's manual; haven't looked too closely in a bit
19:53:00 <heat> a good one is qspinlock (mcs locks). no one knows how atomics will actually work in real hardware
19:53:00 <heat> they (the riscv people) say that the current SMP implementations are stupidly bad
19:53:00 <GeDaMo> sham1: https://arxiv.org/abs/2302.01107 ?
19:53:00 <bslsk05> ​arxiv.org: [2302.01107] A Survey on Efficient Training of Transformers
19:53:00 <moon-child> current as in current riscv, or current everything?
19:54:00 <sham1> GeDaMo: Too bad Python is terrible
19:54:00 <sham1> And not sure sklearn has or even will adopt any stuff like that
19:54:00 <geist> heat: yeah i think that may be true. i've been wathcing the visionfive 2 do some stuff and it seems to spend an inordinate amount of sys% time doing what seems liek regular stuff
19:55:00 <GeDaMo> https://arxiv.org/abs/2203.15556
19:55:00 <bslsk05> ​arxiv.org: [2203.15556] Training Compute-Optimal Large Language Models
19:55:00 <geist> but that's when i got to looking at the dmesg of linux and what it detected, and noticed it gave up on ASIDs
19:55:00 <geist> so it's doing the full context switch
19:56:00 <mrvn> weather prediction for tomorrow: snow. *winter is coming*
19:57:00 <heat> moon-child, current riscv yeah
19:57:00 <heat> top tier $500 sifive boards, etc
19:58:00 <Cos-Dever> You people must updating your Wiki, I disagere with what it is saying
19:58:00 <mrvn> Sure, that's $10 per word changed.
19:59:00 <Cos-Dever> It say "Do not invent a Filesystem, because it will be like FAT" https://wiki.osdev.org/File_Systems#Rolling_your_own That is wrong
19:59:00 <bslsk05> ​wiki.osdev.org: File Systems - OSDev Wiki
19:59:00 <sham1> For better or worse, a FAT-like file system is probably the most "obvious" type of FS, which is why that page even exists
19:59:00 <sham1> To warn exactly about that
20:00:00 <Cos-Dever> sham1: FAT is not obvious
20:00:00 <Cos-Dever> I try to understand that shit last week and it make no sense at all
20:00:00 <zid> sham1: I AM DOING THE DISAGREE
20:00:00 <immibis> inventing your own fliesystem is not obvious, either
20:00:00 <immibis> once you make inventing your own filesystem make sense, it will be like FAT
20:00:00 <mrvn> Cos-Dever: have you implemented FAT or ext4 or something else?
20:01:00 <sham1> Not obvious? It's a linked list of clusters for files. That's like the most obvious you can do
20:01:00 <sham1> While having it be a meaningful file system
20:02:00 <Cos-Dever> Mrvn: I have not implement the FAT and I think I will never because it is crazy FS. No one would ponder up that design on their own. I did do Ext2 driver.
20:02:00 <mrvn> Cos-Dever: when you do your own it will be like FAT, crazy.
20:02:00 <Cos-Dever> sham1: Linked list in a file system!!! It is crazy... Any Liceum student will find a linked list, not the proper datastructure for file system
20:03:00 <zid> sham1: please be doings the improving of your brain
20:04:00 <Cos-Dever> mrvn: I already do my own, I have it reading and not yet writing. It is mostlike UFS, except I substitute the pre-allocated inodes for a special Inode 3, which contents of that file are inodes
20:04:00 <sham1> Right, a linked list isn't the best thing one can use for it, but it is very simple which is why Bill Gates (allegedly) created it in the first place like this
20:05:00 <Cos-Dever> The files are boringly made the traditional way of direct blocks, indirect blocks, doubly indirect blocks, triply indirect blocks... Now this is one thing the OS Dev Wiki should complain about that, your file system will probably be block based instead of utilising some kind of extent B-Tree like the clever filesystem is using
20:07:00 <geist> keep in mind that this channel has really nothing to do with the wiki
20:07:00 <geist> except we link to it as a source of info (or misinfo)
20:08:00 <sham1> Misinfo
20:08:00 <geist> that being said i think the FAT part of the FAT file system is kinda reasonable, just not ideal. it's thel ayout of the rest of the structures that are very 70s and could be done much cleaner
20:08:00 <geist> possibly as exfat has done, though i haven't looked too closely into exfat yet
20:09:00 <Cos-Dever> Yes, I see no one want to take responsibility for that wiki. I complain to OS Dev Discord Server also. They dismissed the wiki, they say it is too x86 and they laugh about its wrongs. I only read File System article so far
20:09:00 <geist> ie you could build something with proper dirs and inodes and a FAT for the chaining of blocks and that'd work alright
20:09:00 <geist> that's the point of a wiki, it's maintained by volunteers
20:09:00 <geist> we dont 'own' it at all
20:09:00 <heat> hello its me the owner of the wiki
20:09:00 <geist> no one does, except the guy that actually runs it, but i think he's mostly AWOL
20:09:00 <heat> my property
20:10:00 <sham1> > it is too x86
20:10:00 <Cos-Dever> Then which keeps the institution of the wiki? I thought, it would be here or OSDev DIscord, since they share the brandname
20:10:00 <sham1> Well, the Discordians here aren't exactly wrong
20:10:00 <geist> nope. the wiki simply exists because someone made it and folks added to it over time
20:10:00 <geist> same with the osdev.org forums and whatnot
20:11:00 <geist> the irc channel predated all of those by some number of years
20:11:00 <geist> sham1: agreed
20:11:00 <moon-child> ♥ fragmented ecosystems
20:11:00 <geist> i've found the wiki is reasonably good at dissiminating stuff you could look up but is nice to put in one spot (x86 bits, some info about legacy PC peripherals, etc)
20:11:00 <heat> moon-child, cringe ASCII heart
20:12:00 <moon-child> fuck x86, but also I'm gonna be sa dwhen it dies
20:12:00 <zid> I like the pci parts of the osdev wiki
20:12:00 <Cos-Dever> Why will there not be new wiki which is more corrected? I think you gentlemen sound honorable and knowledged, and not proudy and wrong as the Wiki
20:12:00 <geist> but it's bad at opinions and whatnot, which is what Cos-Dever seems to have found
20:12:00 <zid> it's hard to find the real specs
20:12:00 <heat> ❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️ chad unicode heart emoji
20:12:00 <sham1> It'd be nice to have someone clean up the wiki and clearly separate the x86-specifics from the general concepts. But ain't nobody got time for that
20:12:00 <geist> Cos-Dever: it's a public wiki, you can edit it yourself
20:12:00 <Cos-Dever> It is true of OSDev Discord also, even if the language they use - foul
20:12:00 <moon-child> zid: https://files.catbox.moe/2nuyal.pdf
20:12:00 <FireFly> well, as geist mentioned a wiki is a product of its editors, so why start a new wiki instead of improving the existing one?
20:12:00 <geist> Cos-Dever: yes, that's generally why i dont hang out there
20:12:00 <FireFly> but yeah, I guess feel free to edit it
20:13:00 <geist> but yeah i think things like 'design your own fs' shouldn't have a bunch of opinions in it and be more of a facts based page
20:13:00 <geist> ie, here are some things to consider
20:13:00 <heat> moon-child, some of them are easy to get to fall off a truck
20:13:00 <Cos-Dever> But in either community I see that the people, they have knowledge, they are not proudy in wrong opinions
20:13:00 <sham1> I like this IRC channel/Matrix room more than the Discord channel. Of course a big factor is that the latter is absolutely proprietary
20:13:00 <heat> other, niche ones? impossible
20:14:00 <geist> sham1: aww thanks. yeah i've been trying to maintain some level of decorum here so that we're at least 'better' than the discord in one way
20:14:00 <geist> it's probably inevitable that discord or whatever replaces it will eventually 'win' but <shrug>
20:14:00 <Cos-Dever> And I read this wonderful free book which help me to design the filesystem. It is called Giampaolo's Practical Filesystem Design. But on OSDev Wiki? Not mention this wonderful book
20:14:00 <moon-child> heat: ?
20:14:00 <geist> yah dbg's book is great
20:14:00 <moon-child> FireFly: wait you're here too o.o
20:14:00 <geist> i worked for dbg at Be back in the day
20:15:00 <geist> he actually ran the draft by me at some point before publishing it
20:15:00 <FireFly> moon-child: y-yes? I've been here for ages :p
20:15:00 <heat> moon-child, ?
20:15:00 <geist> hi FireFly
20:15:00 <Cos-Dever> Indeed you are honourable gentleman, BeOS is called excellent
20:15:00 <FireFly> hiya geist
20:15:00 <sham1> I do sometimes like to read the OSDev forums, but especially the general OS development subforum is a bunch of people being like "why this no work". And the OSDev Reddit is… well, it's Reddit
20:16:00 <geist> yah the trick is to teach folks how to find the information they need, and get them on a good path to learn
20:16:00 <geist> since you can't just fix everyones problems all the time
20:16:00 <heat> but getting newbs to make their own filesystem is silly
20:16:00 <sham1> The screenshot thread is fun, though
20:16:00 <heat> so saying "probably a bad idea" is a good idea
20:17:00 <geist> yeah, i didn't look at the page they linked but it's probably worth at least mentioning that it may not be a good use of time
20:17:00 <Cos-Dever> I do not like the Reddit. They argue, saying, Microkernel is bad, and the others they argue, saying Microkernel is good, and both of the side, they argue like two men who claim support of rival cricket clubs, but their behaviour isnot worthy of the game, and their argument is not about the technical skill of the cricketer
20:17:00 <geist> and they dont even take tea time like in cricket!
20:18:00 <sham1> smh the wiki doesn't even mention btrfs
20:18:00 <Cos-Dever> But then I go here, I find BeOS person, on OSDev Discord is VMware person. It is good, that there is some communitys where you can speak to someone who can say: I am speaking from my experience
20:20:00 <Cos-Dever> And this is what is good in Giampaolo's Practical Filesystem Design. He is not the lecturer who talk about conceptual design of an OS like two blind man arguing what the beautiful painting is. No, that is indeed the way of one who cannot help you
20:21:00 <geist> the only real downside of his book is it's written in 1999 and is tech of the era. nowadays more modern designs tend to be much more snapshotting/tree based
20:21:00 <geist> even his next fs (APFS) is a completey different design
20:22:00 <heat> microkernels suck
20:22:00 <sham1> heat: how dare you
20:22:00 <moon-child> ukernels are gonna kick your ass
20:22:00 <moon-child> ukernels are totally gonna win the championships this year
20:22:00 <Cos-Dever> geist: Yes, I see that now under the sun there is mostly B-Tree filesystems where the write is always a copy
20:23:00 <heat> lets have a usenet argument over this
20:23:00 <geist> now now heat
20:23:00 <moon-child> let's not let things get heated
20:23:00 <sham1> hah
20:23:00 <Cos-Dever> I do not think there is a book like Giampaolo's Practical Filessytem Design about this modern kind of filesystem, but if anyone will write it, I will buy it gladly
20:25:00 <heat> geist, fwiw extent-based filesystems are still the best ones IMO, particularly when it comes to stability and perf
20:25:00 <heat> no one beats trusty ext4
20:26:00 <sham1> But btrfs is better. It's in the name
20:26:00 <heat> no, it's butter fs
20:26:00 <moon-child> butterface
20:27:00 <Cos-Dever> I look at btrfs, they are the radicalest filesystem of the everything as B-Tree persuasion
20:27:00 <geist> heat: yeah mostly agree
20:28:00 <geist> even old designs ie NTFS are still forward extensible, because they're solid extent based designs
20:29:00 <Cos-Dever> But the ZFS, they have a design unlike it, very radical unique. I see they refuse the extents, it seem they use the traditional blocks, but the blocks, the size varies between files
20:37:00 <mrvn> Is there any new FS (post ext3) that doesn't use B-trees?
20:38:00 * mrvn would say that zfs uses extends. The size is just limited to 128k per default.
20:44:00 <gog> hi
20:44:00 <lav> hii
20:45:00 <gog> :3
20:45:00 <dh`> if you're going to have key lookup, btrees are generally the best way to do it
20:45:00 <vdamewood> Hi
20:45:00 <dh`> and there are usually things with key lookup in a fs somewhere
20:46:00 <dh`> the alternative is going back to e.g. linear search of directories and nobody thinks that's a good idea
20:46:00 * vdamewood gives gog a fishy
20:46:00 <heat> dh`, linear search on dirs is not a bad idea for small ones
20:46:00 <gog> :o
20:46:00 * gog chomp fishy
20:47:00 <dh`> eh
20:47:00 <Ermine> gog: may I pet you
20:47:00 <gog> yes
20:47:00 * Ermine pets gog
20:47:00 * vdamewood loves to see people ask for consent
20:47:00 <heat> i think linux itself only creates the htree on a dir once it goes past a block in size
20:47:00 * lav is fishy
20:47:00 <heat> (on ext4)
20:47:00 <dh`> for ordinary small dirs that are frequently accessed it wastes noticeable amounts of cpu because the block's in memory
20:47:00 <vdamewood> ha ha ha, gog go prrr
20:48:00 <heat> if they're frequently accessed, you're not hitting the fs
20:48:00 <dh`> and for large dirs linear search is terrible
20:48:00 <dh`> that depends on how your namecache works
20:49:00 <vdamewood> Is a checking account L2 cash?
20:49:00 <heat> i wish i went to clown college
20:50:00 <vdamewood> heat: You didn't? You seem so good at it.
20:50:00 * vdamewood runs.
20:50:00 <heat> heheheheheh ehe he he he he
20:50:00 * heat cries
20:50:00 <vdamewood> PikachuAndCaterpie.jpg
20:51:00 <gog> sorry
20:51:00 <gog> i'm sorry
20:51:00 <Ermine> vdamewood: professionals have STANDARDS.
20:52:00 <vdamewood> Ermine: Andf I thought my joke was cruel
20:52:00 <dh`> e.g. with a more or less conventional namecache if you open a directory and stat every file in it, you do N lookups in the fs and cache all the results (then probably never use them again)
20:53:00 <heat> yes
20:54:00 <heat> and I would guess that going through a linear search on a single block (4KB tops) is better than doing a fancy data structure for such a small dir
20:55:00 <dh`> apart from it's not unusual to use larger blocks, especially on SSDs, probably not
20:55:00 <heat> well im talking from a Linux POV, no such thing as a block size > PAGESIZE
20:55:00 <dh`> if there's 100 entries, that's 10000 strcmps
20:56:00 <dh`> well, that's an architectural bug in linux, hadn't realized it was still true
21:06:00 <mrvn> dh`: directories you can easily use a hashtbl.
21:06:00 <mrvn> They really are way too small for a B-tree except the one that isn't.
21:07:00 <mrvn> Also the way you handle dentries in memory and directories on disk doesn't have to be the same.
21:09:00 <mrvn> dh`: Note: 100 entries is ~5000 strcmps. N * (N - 1). Or just one readdir2 call for all 100 entries in one go.
21:14:00 <heat> dh`, i don't think its an architectural bug honestly
21:14:00 <heat> unless you completely switch up the way struct page -> struct buffer_head works
21:16:00 <mrvn> heat: I think that block size > PAGESIZE only holds for the block cache. And ext2/3/4 has no support for blocks > PAGESIZE because it maps file data directly to the block cache. Although with extends that's different.
21:17:00 <heat> tbf I have no idea how any of the BSDs approach this problem
21:18:00 <mrvn> heat: I think that problem is an artifical design shortcut Linux did. Nothing more.
21:25:00 * mrvn hands out burgers and fries.
21:27:00 <bnchs> is it okay to be obsessed with something?
21:27:00 <mrvn> breathing?
21:29:00 <heat> yes and no
21:31:00 <bnchs> mrvn: yes breathing is important
21:33:00 <gog> hi
21:33:00 <bnchs> hi gog
21:33:00 * bnchs patpatpat gog
21:33:00 * gog prr
21:35:00 <Ermine> Our cat likes being patted with a fist. This is strange
21:35:00 <bnchs> uhhh
21:35:00 <bnchs> i pat gently with paw :3
21:35:00 <Ermine> With claws deactivated I guess
21:43:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/1071205396313800704/image.png
21:44:00 <netbsduser> it was once reported to me that some people like to use their filesystem in a role where people would typically prefer a relational database
21:44:00 <netbsduser> this includes filling folders with millions of entries (each representing one record)
21:44:00 <zid> that's called "phone users"
21:44:00 <zid> they have no idea what a filing system is
21:44:00 <zid> they just search by metadata
21:45:00 <bnchs> zid: sus
21:45:00 <bnchs> and it has a red tint
21:45:00 <bnchs> is that a hint?
21:45:00 <netbsduser> phones do make an interesting argument for going beyond the traditional hierarchical filesystem
21:46:00 <netbsduser> and at least they now exist so we are getting valuable lessons that will hopefully stop the ambitious from rushing into throwing away the good-old-way without considering what they're losing in doing so
21:46:00 <sham1> Database filesystems are not exactly a new idea
21:46:00 <netbsduser> bnchs: i assume it's about the Sus Law
21:47:00 <bnchs> didn't the wikipedia article about the Sus Law get edit-locked?
21:47:00 <bnchs> or something
21:48:00 <lav> It's got pending changes enabled currently
21:48:00 <bnchs> yeah
21:48:00 <netbsduser> probably, i suspect it's a hot button issue now that there are people who probably want it to return
21:49:00 <bnchs> i like looking at the vandalism revisions
21:50:00 <heat> it's edit locked because amogus sus
21:50:00 <bnchs> >In England and Wales, the sus law (from "suspected crewmate"[1]) was a stop and search law that permitted a police officer to stop, search and potentially eject people on suspicion of them being impostors. Preventing impostors from venting had a marginal impact on crime in the UK.[2]
21:51:00 <heat> hahahahaha
21:53:00 <bnchs> you want it? it's yours my friend
21:53:00 <heat> mjg: ^^ this is genz humor
21:55:00 <mrvn> netbsduser: Bioinformatic users split DNA sequences into 3 letters + metachar per file.
21:56:00 <netbsduser> mrvn: this is exactly the use case i heard about, geneticists love this approach for some reason
21:56:00 <mrvn> netbsduser: it's the most stupid approach possible.
21:57:00 <bnchs> heat: gen z humor is still humor
21:57:00 <heat> absolutely
21:58:00 <netbsduser> mrvn: probably a fair judgment
21:58:00 <netbsduser> i understand some genes got renamed because Excel enthusiastically parses them into dates
21:58:00 <mrvn> netbsduser: they still do that on a network filesystem with 1MB block size.
21:58:00 <mrvn> netbsduser: hehe, heard about that problem too
21:59:00 <zid> I believe the glass is second of january full.
21:59:00 <mrvn> but it's the 4th of march
22:00:00 <bnchs> the joke is that the glass is 2/365 full...... it doesn't make any sense
22:00:00 <bnchs> that's my guess
22:01:00 <zid> wat
22:01:00 <bnchs> cat
22:01:00 <mrvn> dog
22:01:00 <bnchs> meow
22:01:00 <mrvn> wuff
22:02:00 <Ermine> *stoat noises*
22:02:00 * mrvn says BOO to a fainting goat
22:02:00 <zid> https://preview.redd.it/iasok3poony81.jpg?auto=webp&s=ebd78c719a495a7f492e5831902549a521bd478a
22:02:00 <bnchs> i keep seeing cdi zelda everywhere
22:02:00 <bnchs> just like 2008
22:02:00 <zid> https://media3.giphy.com/media/jgVXeRc0Jvv4QFghcz/giphy.gif
22:04:00 <heat> https://grok.dragonflybsd.org/xref/netbsd/sys/uvm/uvm_pgflcache.c?r=6b672424#94 look ma I found undefined behavior
22:04:00 <bslsk05> ​grok.dragonflybsd.org: uvm_pgflcache.c (revision 6b672424) - OpenGrok cross reference for /netbsd/sys/uvm/uvm_pgflcache.c
22:04:00 <heat> which, funnily enough, is completely ignored by gcc and clang for backwards compat reasons
22:05:00 <zid> where
22:05:00 <zid> a struct declaration is ot UB
22:05:00 <mrvn> heat: where is the UB?
22:06:00 <netbsduser> have you ever read the c spec? even the way you close a door is technically undefined behaviour
22:06:00 <zid> Relatively little is UB
22:07:00 <zid> just some surprising things if you've never considered how you'd design a language like C
22:07:00 <heat> zid: 93 /* Variable size, according to # colors. */
22:07:00 <zid> a lot is IDB though
22:07:00 <heat> but then } color[1];
22:07:00 <zid> heat: You mean that later they do color[>0] somewhere else?
22:07:00 <heat> yep
22:07:00 <mrvn> heat: I would say lines 131, 177, 216, 253, ... are UB
22:07:00 <zid> yea that's just old, and was defined by the compiler they used
22:08:00 <mrvn> heat: comments are always wrong, they aren't UB
22:08:00 <heat> no, it's recent
22:08:00 <heat> but still defined by the compiler they use
22:08:00 <heat> because people write bad code like this
22:08:00 <zid> they did this *recently*? dumb
22:08:00 <mrvn> heat: make a patch to "color[]"
22:08:00 <heat> "Copyright (c) 2019 The NetBSD Foundation"
22:08:00 <zid> although if they've gone -fno-vla or whatever
22:09:00 <zid> but the pre-vla way to do that was [0] which is less ambiguous
22:09:00 <mrvn> heat: and then deal with the fun of calculating the size of that struct for alloc.
22:09:00 <heat> structs have no vlas I think?
22:09:00 <zid> They're called FAMs
22:09:00 <zid> flexible array members
22:09:00 <mrvn> heat: sure they do. It's C
22:09:00 <zid> I'm not sure if disabling VLAs also disables FAMs in gcc
22:09:00 <zid> But both were added in C99
22:10:00 <heat> no
22:10:00 <heat> and yes the standardized version is [];
22:10:00 <zid> I've had to deal with the [] vs [0] vs [1] crap before
22:10:00 <heat> [0] is a GNU extension
22:10:00 <zid> it breaks my HID code sometimes
22:10:00 <mrvn> zid: Are you thinking of void foo() { int x; ... char bla[x]; }?
22:10:00 <zid> that's what I said
22:10:00 <netbsduser> the standard is just a bizarre compromise designed to allow C as it traditionally was to fall within (but frequently in the boxes of 'UB') a category that could also fit C for IBM AS/400 with its strange notions
22:10:00 <zid> It's defined by their compiler, but before C99 it was defined via [0]
22:10:00 <zid> it's now defined by the standard as []
22:11:00 <netbsduser> and a lot of GNU extensions appear to be in traditional C compilers (as in Unix ones)
22:11:00 <zid> C hasn't been updated since C89 as far as I am concerned, they just backported crap from C++ and never fixed anything
22:12:00 <zid> still no way to get the length of an array, to test for endian, or thousands of things that actual C programs do, but now we have.. nullptr? thanks.
22:12:00 <zid> C23 really saved C
22:12:00 <mrvn> zid: there is no array. It decays. :)
22:12:00 <heat> you do have a way to get the length of an array?
22:12:00 <zid> no you do not
22:12:00 <heat> sizeof(arr)/sizeof(arr[0])
22:12:00 <zid> exactly
22:13:00 <zid> you have a macro you write into every fucking project
22:13:00 <heat> what's your proposal?
22:13:00 <heat> _Length(arr)?
22:13:00 <zid> it's been 30 years and compilers still aren't allowed to just provide it under a standard name
22:13:00 <mrvn> zid: how is that going to work with arrays passed to functions?
22:13:00 <zid> I don't care what it's called as long as it's standard, I can learn it a priori
22:14:00 <zid> and not have to learn the specific name used in every single codebase
22:14:00 <netbsduser> i forgot what C++23 is
22:14:00 <zid> Yea that's called braindamage, it's what happens after you read C++ specs
22:14:00 <netbsduser> is that the one with anonymous functions?
22:14:00 <zid> The memory loss is permanent, sorry
22:14:00 <mrvn> netbsduser: it's the one with nullptr
22:14:00 <netbsduser> C23 rather not C++23
22:14:00 <heat> netbsduser, no, lambdas have been present since C++11
22:14:00 <heat> and C has no lambdas
22:15:00 <netbsduser> i'm sure i heard somewhere they wanted to put them in C23 but maybe it got rejected
22:15:00 <zid> C23 does have some good in it, but it was trivial things that should have happened in 991
22:15:00 <zid> 1991*
22:15:00 <zid> removing K&R decs
22:15:00 <heat> C23 is full of good value adds
22:15:00 <mrvn> are trigraphs still a thing?
22:15:00 <zid> then adds some silly C++aboo crap
22:16:00 * Ermine wonders what trivial things should have happened in 991 but haven't
22:17:00 <Ermine> zid: like which
22:17:00 <zid> Ermine: After pope john XV ratified the truce of god he should have sent a thank you note
22:18:00 <heat> nullptr is an obvious one
22:18:00 <zid> oh I meant 1991 right, trivial C shit should have been removing 0 being legal for NULL
22:18:00 <zid> K&R decs, implicit int return values
22:18:00 <mrvn> remove implicit declaration, type defaults to int
22:18:00 <zid> enum storage size
22:18:00 <zid> make enum types incompatible
22:18:00 <heat> you can't remove 0 being legal for NULL, hence nullptr
22:18:00 <zid> You totally can.
22:18:00 <mrvn> enum storage size?
22:18:00 <heat> and you break half of software
22:19:00 <zid> If you can remove K&R decs, you can remove 0 being legal for NUL.
22:19:00 <zid> You do not break half of software
22:19:00 <mrvn> zid: a lot of software does ptr = 0;. But you can start with requiring NULL as ((void*)0)
22:19:00 <zid> *no* fucking implementation do it that way, all it does is cause you to code around potential bugs if they *happened* to have done it that way, because the implementation is allowed to do it
22:19:00 <zid> but they don't
22:20:00 <zid> and if they do, they're shit and dumb, because it causes bugs
22:20:00 <Ermine> So I have to use NULL instead of 0?
22:20:00 <heat> the point of C is to support shit and dumb because C is shit and dumb
22:20:00 <mrvn> Ermine: or cast
22:20:00 <zid> no, the problem is using NULL for invalid pointers in varargs
22:20:00 <zid> The C spec allows either 0, or (void *)0 as the value for #define NULL
22:21:00 <zid> and varargs can't tell if you mean pointer or integer unless you tell it, so printf("%p", NULL); is just an outright bug
22:21:00 <mrvn> ^^ and that part they could have easily fixe3d
22:21:00 <zid> if #define NULL 0, then varargs sees an *integer* zero there
22:21:00 <zid> happily pushes a 32bit int to your stack or whatever, then %p pops a 64bit pointer
22:22:00 <zid> so you have to do printf("%p", (void *)0); for literally no reason other than to prevent that bug, which won't even happen, because anybody who writes stdlib.h is *aware* of that issue
22:22:00 <zid> because the spec is being stupid there
22:22:00 <mrvn> zid: Most of the time though that works because archs where int != ptr tend to pass args in regs.
22:23:00 <\Test_User> printf takes unlimited args, which comes out to be more than the number of registers
22:23:00 <mrvn> \Test_User: and how often do you actually have that and pass NULL?
22:23:00 <zid> \Test_User: You don't know my life! Maybe I have infinite registers! :(
22:24:00 <\Test_User> could also come up with a function you'd be more likely to pass NULL to that does the same
22:24:00 <mrvn> \Test_User: only happens with varargs though
22:24:00 <\Test_User> mrvn: was saying printf bc that was the example there
22:24:00 <mrvn> (or implicit prototypes)
22:24:00 <zid> main reason you end up passing NULL to varargs is via macro expansion
22:25:00 <zid> and it's handy to not have to special case it for printing out a linked list or whatever
22:25:00 <mrvn> The sad part is that gcc / glibc even now still has a "#define NULL 0"
22:25:00 <zid> where not every member might be filled out
22:25:00 <zid> or just any random struct I guess
22:26:00 <mrvn> Check the headers, it has some #ifdef picking one of 3 defines and one is 0
22:26:00 <\Test_User> structs have a type attached, so no problem there?
22:26:00 <\Test_User> or passing null as the "ptr to struct"
22:27:00 <mrvn> \Test_User: implicit prototypes still fail
22:27:00 <\Test_User> ah right
22:27:00 <zid> void print_bob_debug(struct bob *b){ printf("Left: %p\n", b->left); printf("Right: %p\n", b->right); printf("Value: %d\n", b->value); }
22:27:00 <mrvn> type deduces to int -> *FAIL*
22:28:00 <zid> much nicer than if(b->left) printf("Left: %p\n", b->left); else printf("%s", "Left: (NULL)\n");
22:29:00 <mrvn> luckily glibc printf() prints "(NULL)" for nullptr for you
22:29:00 <mrvn> printf("Left: %s", b->left);
22:30:00 <mrvn> *hide*
22:30:00 <sham1> Please don't rely on that
22:30:00 <mrvn> sham1: obviously, it's also a type error
22:31:00 <zid> Now you wrap that shit in x-macros with the original declaration <3
22:31:00 <zid> what do they call that, reflection? idk.
22:31:00 <mrvn> inspection?
22:31:00 <mrvn> introspection?
22:37:00 <sham1> mrvn: it's not obvious. If it was obvious, people wouldn't rely so much on unportable stuff and undefined behaviour and suxh
22:38:00 <mrvn> sham1: there is a big chasm between correct code and code that doesn't compile.
22:39:00 <sham1> Yes, and we call that code shit, as we ought to
22:40:00 <mrvn> sham1: ever done: struct DList { struct DList *next, *prev; void *data; } head; memset(head, 0, sizeof(head)); ?
22:40:00 <mrvn> (or other struct with pointer)
22:41:00 <sham1> Not that specifically, but I have used calloc to basically have that happen, and I'm not proud of it
22:42:00 <mrvn> uhoh. I never thought of this with calloc.
22:42:00 <mrvn> calloc() on a struct with pointers is UB.
22:42:00 <geist> how so?
22:42:00 <\Test_User> eh? is DList->next = 0 also UB?
22:42:00 <zid> no
22:42:00 <mrvn> the 0 bit pattern might not be the NULL pointer, nor a valid pointer at all
22:42:00 <zid> but memset to 0 is
22:43:00 <\Test_User> ah...
22:43:00 <mrvn> \Test_User: no, 0 gets cast to pointer type and that's fine
22:43:00 <zid> C converts assignment by 0 to 'the null pointer constant'
22:43:00 <zid> which may or not be all bits 0
22:43:00 <geist> hmmm, you *might* be right, but then that implise that also memsetting a structure with a pointer in it is UB
22:43:00 <sham1> Yeah, because memset to 0 is not the same as pointer 0
22:43:00 * geist nods
22:43:00 <geist> of course in practice this isn't the case at all
22:43:00 <sham1> Yes
22:43:00 <zid> you wanna do blah = {0} basically
22:43:00 <mrvn> geist: that's the example I showed before calloc
22:43:00 <zid> it's shorter than memset anyway
22:43:00 <mrvn> zid: didn't used to work in C
22:44:00 <geist> oh reminds me, i should try to write an asm riscv memcpy/memset
22:44:00 <\Test_User> doesn't work well with ptr to array of structs either
22:44:00 <geist> proibably will beat the shitty C version i use for fallbacks
22:44:00 <zid> riscv has optimizations?
22:44:00 <\Test_User> bc you'd need to loop and blah[i] = {0} for each
22:44:00 <netbsduser> i think it is a mistake to view "relying on UB" as bad or even in any way unusual
22:44:00 <geist> that's the interesting question right?
22:44:00 <mrvn> geist: aren't compilers smart enough to optimize that?
22:44:00 <zid> I thought you just wrote it like it was risc, -Os and done
22:44:00 <geist> can you write a asm version better than the compiler, since there's not much the arch lets you do
22:45:00 <netbsduser> the simple fact is that ISO C is a subset of the actual tradition of the C programming language
22:45:00 <zid> Given that we know the environemnt has null pointer == all 0 bits
22:45:00 <zid> it isn't actually UB
22:45:00 <geist> i mean there are faster versions on pretty much every other arch in hand written assembly, so stands to reason even on riscv you could too
22:45:00 <zid> unless you compile for a platform where it's not true, which you're not, ever
22:45:00 <mrvn> zid: implementation defined what the representation of NULL is
22:45:00 <geist> but there's less options of fancy instructions yet
22:45:00 <sham1> And does the right thing. You might also want to use memcpy to use that to initialize an allocated struct
22:45:00 <mrvn> zid: ARM with tagged pointers won't have 0 bit pattern
22:45:00 <mrvn> (possibly)
22:46:00 <zid> it's relying on IDB to remain not UB though :P
22:46:00 <sham1> memcpy(ptr_to_struct, &(struct s){0}, sizeof(struct s));
22:46:00 <zid> like how writing to an int via a char * then actually using the int might cause a trap, as long as you *know* the representation of int, it's fine
22:46:00 <netbsduser> if GCC changed this they would basically be declaring open war on C as in the language that linux, freebsd, windows, etc are implemented in
22:46:00 <sham1> Look ma, no undefined behaviour
22:46:00 <zid> sham1: just assign it if you have compound literals
22:47:00 <zid> rather than memcpying
22:47:00 <mrvn> sham1: the compiler converting a = {0} to memset relies on the implementation knowledge of what a NULL is
22:47:00 <zid> like I said, it's shorter anyway
22:47:00 <sham1> With an allocated instance? Eh, could also do that I suppose
22:47:00 <zid> I do it when I remember to care
22:48:00 <sham1> mrvn: but the implementation does know what it is, because the implementation imposes it
22:48:00 <\Test_User> mrvn: #if NULL != 0 #error "Get a saner compiler/cpu" #endif, UB avoided
22:48:00 <\Test_User> er right...
22:48:00 <\Test_User> hmmmm
22:48:00 <zid> new_s(void){ p = malloc(); *p = (struct p){0}; return p; }
22:48:00 <\Test_User> how do you #if with bit representation
22:48:00 <sham1> You don't
22:48:00 <\Test_User> sad
22:48:00 <zid> there's an annoying macro you can write
22:49:00 <zid> it ends up looking like #define ICE_P(x) _Generic((1? (void *) ((x)*0) : (int *) 0), int*: 1, void*: 0)
22:49:00 <mrvn> What really screws you is the compiler chaning: void * memcpy(void *dst, void *src, size_t len) { char *d = dst, *s = src; for (size_t i = 0; i < len; ++i) { d[i] = s[i]; } return d; } into a memcpy call.
22:49:00 <zid> you need to rely on 0 being an integer constant, and (void *)0 not being one somehow, and cause a bifurcation in the behaviour because of it, have fun
22:50:00 <sham1> Ah yes, that is a funny thing. At least it can be suppressed, but it only needs to be done in one translation unit anyway
22:50:00 <mrvn> sham1: memcpy, memset, bzero, memcmp, strcpy, strcmp, possibly malloc/calloc too
22:50:00 <zid> Another thing C could just add in 1991, an endian / integer representation etc macro set
22:51:00 <mrvn> zid: endian.h?
22:51:00 <zid> I've written *so* many probably incorrect ifdefs to try to detect endian at compile time
22:51:00 <heat> geist, I did briefly think about that but I don't know how much leeway you really have there
22:51:00 <mrvn> /* Copyright (C) 1992-2022 Free Software Foundation, Inc.
22:51:00 <mrvn> missed it by a year
22:51:00 <heat> I know musl doesn't have an optimized string impl for riscv
22:51:00 <geist> heat: yeah i guess the real question is if there's value in having a version that assumes unaligned vs aligned
22:52:00 <geist> since it's defined by the arch as supporting unaligned accesses, but firmware may trap and emulate
22:52:00 <geist> and thus you probably want an aligned version
22:52:00 <mrvn> heat: why do you care about endianess?
22:52:00 <sham1> Do I have to link Rob Pike's essay here again
22:53:00 <mrvn> Write your code in such a way that the endianness is not a factor and let the compiler optimize the NOP cases.
22:53:00 <zid> Is it that comments are bad
22:54:00 <heat> comments are bad mkay
22:54:00 <mrvn> no, no, no. Comments are always right, the code is bad. We have to remove that.
22:54:00 <zid> comments are bad
22:54:00 <zid> They're a code smell for poorly named variables and lack of static functions
22:55:00 <mrvn> Lets make source files just comments that gets passed to chatgpt | gcc
22:55:00 <heat> no
22:55:00 <zid> If it needs an explanation regardless, Documentation/design_goals_of_banana_layer.txt
22:55:00 <heat> comments are useful in moderation
22:55:00 <sham1> Oh I was thinking about the byte order fallacy one
22:55:00 <sham1> I don't think Mr. Pike has any special thoughts about comments
22:57:00 <sham1> But yeah, comments are more often than not bad. Even if it's not just repeating what the code is saying, a problem is keeping the comments from drifting away from relevance
22:58:00 <mrvn> The worst is when comments describe the contract instead of the code doing it.
22:58:00 <geist> yeah this nonsens about comments are bad is silly
22:58:00 <zid> What the issue is is that we use text files for source code, without things like references and links to diagrams and shit, if needed
22:58:00 <geist> obviously bad comments are bad, but helpful comments are a godsend
22:58:00 <zid> geist: missing the point slightly there though
22:58:00 <geist> probably
22:58:00 <zid> the point is that the helpful comments aren't *needed* in good code
22:58:00 <sham1> Emacs can do hyperlinks from comments. Just saying
22:58:00 <geist> yeah disagree
22:58:00 <heat> that's not true
22:59:00 <zid> if it has comments, it's teaching you how bad code operates because it isn't clear from the code
22:59:00 <zid> Not saying it's always possible
22:59:00 <mrvn> sham1: or embed source sniplets in org more.
22:59:00 <mrvn> mode
22:59:00 <zid> but what you said wasn't what I was talking about
22:59:00 <geist> good comments help bootstrap whomever is reading the code to avoid having to process it in their head
22:59:00 <geist> even if it's 'good code'
22:59:00 <heat> imagine i write a spinlock impl and don't comment it. now you want to figure out why things are done in the way they are
22:59:00 <geist> still a lot easier to read a few sentences over overview to avoid you having to deal with parsing some code in your head, even if it's good
22:59:00 <sham1> This is a topic which is very opinionated. However, comments have and will always have and get bugs
23:00:00 <sham1> Problem is that comments aren't checked for semantic correctness
23:00:00 <heat> 1) git blame 2) comments 3) ask me 4) read a bunch of pages of spinlock theory
23:00:00 <zid> geist: yea ideally that wouldn't be a comment, but definitely available somewhere, like Documentation/
23:00:00 <zid> but easier to actually reference
23:00:00 <mrvn> There is always as case why you should comment why, what or how your code does. Just hardly ever all at the same time.
23:00:00 <zid> Like git blame yea
23:00:00 <geist> maybe? Documentation/ is even easier to get out of sync since it's not right next to the code. but of course depends on the context here
23:01:00 <heat> Documentation/ is harder to cross reference
23:01:00 <geist> but at *least* put it in the same repo
23:01:00 <heat> I would only consider that for external interfaces (i.e I'm documenting a new system call)
23:01:00 <zid> '1000ft view' stuff in git blame, 20ft view is 'function names'
23:01:00 <zid> 1ft view is 'variable names'
23:01:00 <geist> yah, or some overall thing, like memory layout of the kernel, etc
23:01:00 <zid> inch view is comments
23:02:00 <geist> also re: the 'good code' argument. you're not always i the position of writing good code, or working with good code that self documents
23:02:00 <zid> If you can't figure out at least enough about a piece of code to successfully ignore if it isn't what you were looking for from the function names, or at worst the variable names, the code is doing something overly complicated in a single function most likely
23:02:00 <mrvn> geist: I'm annoyed by the .c/.h split already. Makes important stuff be far to far away.
23:02:00 <geist> so in that case helping out with soe comments is a godsend
23:03:00 <geist> mrvn: 100%. also one of those RUUUUUUUUST things
23:03:00 <zid> geist: nod, but, <zid> Not saying it's always possible
23:03:00 <sham1> Of course, there's a difference between having a documentation comment like for doxygen, and your in-code //
23:03:00 <geist> mrvn: it's much worse in C++ when half the class is declared in the header
23:03:00 <mrvn> .h files should be compiler output from the .c
23:03:00 <zid> *ideally* we'd live in an ideal world
23:03:00 <geist> but rarely do we
23:03:00 <mrvn> geist: do c++ modules fix that?
23:04:00 <geist> problem is some of us know this, but not everyone does. so you end up with folks dogmatically applying rules
23:04:00 <zid> But like, the platonic ideal version of a piece of code probably has fewer comments rather than more comments
23:04:00 <mrvn> Can you put templates in the .cc file and build a module for it?
23:04:00 <geist> and you end up with stuff like 'no comments in any code' as a literal rule
23:04:00 <geist> i know of actual companies that do that. literally.
23:04:00 <geist> because someone dogmatically applied the logic that 'comments are bad' and thus you end up with a fucking disaster
23:04:00 <zid> yea that needs to stay in sync with heavy code review, mandatory git blame split-views, or whatever
23:04:00 <zid> not just be an arbitrary rule with no support
23:05:00 <mrvn> sham1: +1 for doxygen style commenting
23:05:00 <geist> mrvn: good question, i honestly dont know how the C++ modukle stuff works
23:05:00 <geist> i know theres some talk about using it at work, but have to pull everything up to c++20 before you can start to use it, i think
23:05:00 <geist> though i dont know precisely why
23:05:00 <mrvn> sham1: -1 for for doxygen style commenting as well, because just listing the function prototype with one sentence does not make documentation
23:06:00 <geist> but i tell ya i really hate it when i open some file i didn't write, and you just get pages of code, no comments
23:06:00 <geist> even if it's great stuff, it puts the onus on *you* to interpret it
23:06:00 <mrvn> geist: You do "import stl;" and it's faster than "#include <iostream>". That's about my experience level.
23:06:00 <geist> doesn't mean i can't figure it out in 5-10 minutes or whatnot, but a simple paragraph at the start would really really help
23:06:00 <zid> yea it's a problem if you don't know *where* to look for the missing comments
23:07:00 <zid> like, if it doesn't have comments because internally it's all tracked in dot files or git or whatever
23:07:00 <zid> and you don't have that setup
23:07:00 <geist> most of the time it's simply because the author understood it, so they didn't comment it
23:07:00 <mrvn> geist: the module shouldn't be able to say what was in the header or the .cc file. You could compile it with an external cpp. So header should be optional.
23:07:00 <geist> which makes sense. if you wrote it, it's in your mind, you understand it, so comments dont help you
23:08:00 <mrvn> geist: have someone else write the comments and then sign off on them.
23:08:00 <zid> I comment assembly a lot, because I am too lazy to make enums :P
23:08:00 <geist> but usually for code reviews if i'm reviewing it and something isn't intrinsically obvious i'll ask the author to leave a sentence or two at the point where it's tricky
23:08:00 <mrvn> only way to make code review
23:08:00 <zid> lots of magic numbers (stack offsets etc) with magic comments to explain them
23:08:00 <geist> and i dont see that as a failure to the author at all, sometimes things are just tricky for efficiency purposes, or the alternative is worse, et
23:09:00 <geist> oh 100% re: assembly. i comment the shit out of that, since it's almost never intriniscally obvoius what's happening
23:09:00 <zid> It'd be nice if "named block" idioms weren't just so unused in C as to look wrong
23:09:00 <mrvn> zid: named block?
23:09:00 <zid> Sometimes I just wanna start a fucking naked block with a comment at the top of it, but it looks sooo unnatural
23:09:00 <zid> even though it'd be a great tool
23:10:00 <geist> i have had the curse of using a lot of my code i wrote 10-15-20 years ago on a daily basis, and all the places where i left myself a breadcrumb is nice
23:10:00 <mrvn> { // set font to bold, 10pt and Times New Roman .... }
23:10:00 <mrvn> zid: ^^ like that?
23:11:00 <mrvn> zid: I think naked blocks are something people that use IDEs that can fold sources use.
23:11:00 <zid> https://zid.godbolt.org/z/MTodjvvh4
23:11:00 <bslsk05> ​zid.godbolt.org: Compiler Explorer
23:11:00 <sham1> mrvn: doxygen does indeed have that problem where people don't always write all the docs and just regurgitate the prototype. Same thing with a lot of javadocs I've seen at work and elsewhere
23:12:00 <geist> rust has some sort of notion of named blocks, but that's so you can do an inner exit sort of thing
23:12:00 <zid> Named blocks ^
23:12:00 <geist> basically 'break out of the named block'
23:12:00 <mrvn> sham1: what pisses me off is when they do that across the whole project and call that documentation. Even have a separate foo-doc debian package.
23:12:00 <zid> like, the 'proper' way to do it is to make a static function, but then you lose access to your locals that you might want, so now you're passing in a fuck load of args
23:12:00 <dh`> <zid> comments are bad
23:13:00 <dh`> are you mad?
23:13:00 <zid> that way is tidier, but nobody does it
23:13:00 <zid> dh`: at what?
23:13:00 <sham1> It's basically the same as bad comments except it's even worse because comments are supposed to be something I shouldn't need to look at as a user. Docs on the other hand… trrrible
23:13:00 <mrvn> zid: waste of a good line to have the { on it's own. :)
23:13:00 <zid> and because nobody does it, you look like a lunatic if you do it
23:13:00 <heat> what's that zid.godbolt.org stuff
23:13:00 <geist> well, you can also use whitespace to make a pseudo block. i do that in all of my code
23:13:00 <zid> godbolt saves the current layout to a cookie
23:13:00 <mrvn> zid: another reason for naked blocks is to have local variables with RAII
23:14:00 <zid> domains all get different cookies
23:14:00 <mrvn> and call the destructor in a timely manner
23:14:00 <zid> so your layout doesn't get fucked up when someone links you some code if you use a random subdomain
23:14:00 <zid> unless they link you code from *your* made up subdomain, but with a fucked up layout
23:15:00 <heat> ah cool
23:15:00 <mrvn> .oO(Who would be that evil?)
23:17:00 <sham1> But yeah, comments can be helpful, but most of the time the code should have the clarity to stand without them. I won't claim that they're not useful for some things, but yeah. When you get something silly like /* add 5 to a */ a += 6; that's just life
23:17:00 <sham1> Life with commentary
23:18:00 <zid> more often than not it's like, /* Furble the janket */ furble(janket); though
23:18:00 <heat> but /* add 6 to a */ a+=6; is just a bad comment
23:18:00 <zid> which seems like less of a bad comment
23:18:00 <zid> but is still basically just /* x++ */ x++
23:24:00 <gog> furble the janket
23:24:00 <geist> more like // jankets need to be furbled to ensure ...
23:25:00 <dh`> consider this one: https://github.com/wiredtiger/wiredtiger/blob/develop/src/session/session_dhandle.c#L410
23:25:00 <bslsk05> ​github.com: wiredtiger/session_dhandle.c at develop · wiredtiger/wiredtiger · GitHub
23:26:00 <geist> also sometimes comments are useful for someone in the future that might want to refactor things
23:26:00 <geist> so something like
23:27:00 <geist> // this is done before X below beacuse ...
23:27:00 <heat> i think im going to write an ebpf interpreter
23:27:00 <heat> and then jit it
23:27:00 <mrvn> sham1: I've done this for ocaml C code: a += 6; // add 3 to a
23:28:00 <mrvn> sham1: I've done this for ocaml C code: a += 6; // add 3 to a, it's already tagged
23:28:00 <heat> the only bit im scared of in ebpf is that I may need fancier verification
23:28:00 <heat> cuz its a good bit more powerful
23:29:00 <mrvn> sham1: ocaml integers are shifted by 1 and have a 1 tag added. So adding a constant to a value isn't that obvious.
23:31:00 <gog> what's ebpf again
23:31:00 <gog> oh right
23:31:00 <gog> berkely packet
23:33:00 <dh`> hmm I guess the conversation couldn't stand an injection of reality
23:34:00 <zid> ebpf gets used for other thingsI found out
23:38:00 <heat> bpf or cbpf are mostly for packet filtering and seccomp
23:38:00 <heat> ebpf does fucking everything because ofc
23:38:00 <mjg> burp
23:38:00 <theWeaver> blorp
23:38:00 <heat> mjg, is that a rick and morty reference
23:39:00 <heat> are you transforming yourself into a pickle
23:39:00 <mjg> no
23:39:00 <mjg> i'm too old to watch that
23:39:00 <theWeaver> pickle mjg :o
23:39:00 <mjg> i am however relieving high school years
23:39:00 <heat> pickle rick and pessimal mjg
23:39:00 * theWeaver pickles heat
23:39:00 <heat> sounds dirty
23:40:00 <mjg> i ran into seriously weird videos on youtube
23:40:00 <mjg> to the point where i wont tell you what it is
23:40:00 <gog> i have stress dreams that i'm in high school
23:40:00 <zid> Time to watch a man solve a puzzle while I fall asleep
23:40:00 <gog> and i'm always late for class
23:40:00 <moon-child> mjg: well that's no fun
23:40:00 <gog> there was even one dream i had where i was like "wtf am i even doing here i went to university"
23:40:00 <mjg> gog: i recnetly had a dream i was at my old job
23:41:00 <geist> gog: yep i get those still
23:41:00 <mjg> gog: and my boss was giving me shit for not staying past 7 pm
23:41:00 <gog> ooof
23:41:00 <geist> usually in the form of 'oh shit i forgot i signed up for a class and now it's finals'
23:41:00 <mjg> really
23:41:00 <geist> or, job related ones i get a stress dream, i think not 2 nights ago, that i somehow accidentally accepted two jobs at the same time, and am trying to juggle one while the other one doesn't know
23:42:00 <mjg> i had one dream i was in college, twards the end of the semester, and i realized i studied nothing
23:42:00 <mjg> :s
23:42:00 <mjg> geist: lol
23:42:00 <heat> typical tech worker during the pandemic
23:42:00 <geist> basically
23:43:00 <mjg> tech asshole!!
23:43:00 <geist> another college stress dream i get sometimes is 'i need to go back to school because i missed a class'
23:43:00 <geist> and then it's like 'how the fuck am i gonna do that?'
23:43:00 <heat> sometimes i have dreams that im in college, then wake up, and im still in college
23:43:00 <theWeaver> gog: my stress dreams are usually that i'm back in the UK for some reason (visiting family, whatever) and have no plane ticket back to Germany, have work next week, and no money to buy a flight
23:43:00 <heat> its a true nightmare
23:44:00 <geist> hmm, what's that top secret scene...
23:44:00 <heat> theWeaver, which city
23:44:00 <heat> that determines the level of t o r t u r e
23:44:00 <geist> https://youtu.be/lvDFJVUaXUI
23:44:00 <theWeaver> heat: oddly it's often unclear to my dream brain
23:45:00 <theWeaver> i'm just *somewhere in England*
23:45:00 <heat> worst "dreams" are the ones where you start falling
23:45:00 <heat> fuck, that shit is creepy
23:45:00 <theWeaver> i don't fall in my dreams i fly
23:46:00 <theWeaver> but i've had weird sleep paralysis shit where im falling into my bed
23:46:00 <geist> or where you try to fly but you cant
23:46:00 <theWeaver> that freaks me the fuck out
23:46:00 <geist> like, you know you can, but for some reason today you cant
23:46:00 <geist> it's a variant of can't run fast enough
23:46:00 <theWeaver> geist: that's what you get for sleeping during the day :v
23:46:00 <theWeaver> smh
23:50:00 <gog> i had a recurring theme in my dreams where i could levitate
23:50:00 <gog> been a minute since that happened
23:50:00 <gog> but i'd just hop and lean forward and nyoom
23:51:00 <heat> i have recurring day dreams where im a wildly successful football player for my club
23:53:00 * theWeaver can fly at will if she becomes lucid while dreaming
23:53:00 <theWeaver> occasionally this happens
23:54:00 <heat> i don't really want to fly
23:54:00 <heat> flying is cringe
23:54:00 <theWeaver> nah, flying is baller
23:54:00 <theWeaver> football is cringe
23:54:00 <heat> worst case you get held by air traffic control
23:54:00 <heat> YOU WOT M8
23:55:00 <theWeaver> yeah i said it
23:55:00 <theWeaver> fite me
23:55:00 <heat> no i said footballer not mma fighter
23:55:00 <theWeaver> pussy
23:55:00 <heat> i'll dribble you to death
23:55:00 <theWeaver> im glad we're at least talking about real football
23:55:00 <theWeaver> the american sport is definitely a lot more cringe
23:55:00 <heat> ofc
23:56:00 <heat> we're not talking about Concussions Inc.
23:57:00 <theWeaver> tbf there are other sports more cringe than football
23:57:00 <theWeaver> like for example, cricket
23:57:00 <theWeaver> and golf
23:58:00 <heat> baseball
23:58:00 <heat> baseball is very cringe
23:58:00 <theWeaver> actually it doesn't get much more cringe than cricket or golf
23:58:00 <theWeaver> heat: ok wait
23:58:00 <theWeaver> what's cringer
23:58:00 <theWeaver> cricket?
23:58:00 <theWeaver> or rounders?
23:58:00 <theWeaver> er
23:58:00 <theWeaver> baseball or rounders i meant
23:59:00 <theWeaver> obviously cricket is the cringiest
23:59:00 <gog> rounders
23:59:00 <heat> baseball
23:59:00 <heat> everyone that's into baseball is always VERY into baseball
23:59:00 <theWeaver> heat: ok but what about handball
23:59:00 <heat> and how tf can you be VERY into baseball? just makes no sense
23:59:00 <theWeaver> handball is MEGA CRINGE
23:59:00 <heat> handball is legit