karenw has quit [Quit: Deep into that darkness peering...]
<zid>
isn't that just gentoo
<zid>
-O3 and -march
<nikolar>
No zid, that's the fastest Linux distribution
<nikolar>
Pay attention
<mjg>
fastest linux distro still loses to openbsd
<mjg>
so
<mjg>
who gives a fuck
<heat>
not openbsd
<heat>
but solaris
<mjg>
that's like saying the water is wet
<mjg>
ofc solaris always wins
karenw has joined #osdev
Left_Turn has joined #osdev
Turn_Left has joined #osdev
innegatives has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
<heat>
solaris doesn't need LTO or PGO
<zid>
what's the fastest solaris, -O1?
jcea has quit [Ping timeout: 272 seconds]
Pixi` has joined #osdev
<mjg>
i heard they literally added false sharing to solaris to only keep it 50% faster than linux
Pixi has quit [Ping timeout: 260 seconds]
Pixi` is now known as Pixi
karenw has quit [Quit: Deep into that darkness peering...]
<heat>
solaris is optimal at -O0 because the code is already so damn optimized
<heat>
anything else just pessimizes the compilation
<heat>
i found a great performance problem where for $LEGACY_RAISINS i was fully syncing an inode before freeing it
<heat>
which resulted in super slow rm -rf
<mjg>
some windows vibes
<mjg>
also the term is hysterical
<mjg>
raisins
<mjg>
speaking of fsync 'n shiuto
<mjg>
i normally bench on tmpfs ye for reproducibility and vfs focus, ye
<mjg>
but one day i decided to sanity check zfs is not fucking up
<mjg>
i found total real time to be in the toilet
<mjg>
because someone tweaked a tunable with an unrelated commit
<mjg>
resulting in massive fucking stalls on writes
<mjg>
or to put it differently, as per usual, anything not benchmarked has to be assumed slow af
itrsea has quit [Quit: leaving]
<kof673>
clear linux says it does reordering of functions and based on profiling and probably other stuff, layout of functions is "optimized" and not sure that is all "upstreamed" to toolchains yet
<kof673>
it also says cloud stuff, so..................meh
<kof673>
point being, they can likely be generic optimizations, but might be linux only for now
<zid>
heat: You like football manager right?
<heat>
yeah
<zid>
Have you considered horse manager, it's the same thing but they wear thigh socks instead of ankle socks
<heat>
mjg: speaking of fsync, i spent a little bit this week understanding the fsync data guarantees
<heat>
namely with regards to the write cache
<mjg>
:O
<mjg>
and
<heat>
linux fsync tends to be pretty strong and does a full cache flush for each fsync
<mjg>
did you get inspired by that failing fsync fiasco
<mjg>
is that for all fs
<mjg>
not that i intend to dunk on bcachefs
<heat>
not sure, but the generic helper and ext4 for sure
<heat>
(and a bunch of others)
<heat>
i was wondering why FUA could not be used on the individual writes themselves
<heat>
but you really don't know if any page was written back before you fsync'd, so it could sit stale in the write cache
<heat>
the other fun bit is that linux elides those flushes if you don't have a write cache, or if the drive gives you strong guarantees
<heat>
oh and linux force disables SATA FUA because it results in data corruption in a lot of drives :v
<heat>
around 2012 they went "oh surely the drives now aren't this crap, lets give it a shot" and yeah they were still that crap
<mjg>
lol
<mjg>
i thought it is well established that drives lie
<FreeFull>
Alternate reality where linux is a microkernel
xenos1984 has quit [Read error: Connection reset by peer]
<FreeFull>
Surely 2025 is the year of the microkernel
<mjg>
project 2025
<kof673>
wikipedia makes it sounds like microkernels are just the spawn of the macrokernel > This strategy was to be implemented by a hierarchy of running programs in which parent processes had complete control over child processes and acted as their operating systems.
<mjg>
ukernel linux
<kof673>
lol
<kof673>
the raptors have figure out how to open doors
<mjg>
trump would support microkernels
<mjg>
that tells you something
<mjg>
epstein kernels
<heat>
in this case i don't think it was the drives lying, but actually having a buggy FUA implementation (I presume this was happening when mixing it with normal writes)
xenos1984 has joined #osdev
<heat>
you didn't really need weird edgecase power cutoffs, just normal system usage
<mjg>
fun fact is that overall storage corner caes are a shitshow
<mjg>
firmware bugs in drives and raid controllers a pretty common
<mjg>
but even if you ignore that and dig into kenrel dreivers
<mjg>
you will find botched error handling all over
<mjg>
for kmalloc 'n shit
<mjg>
basically your true fsync is your offsite backup
<mjg>
:d
c0co has joined #osdev
freakazoid332 has quit [Ping timeout: 276 seconds]
<heat>
sadly
<heat>
at least for Normal People
<heat>
i'm sure google copes with -EIO's much better
<mjg>
i got no -EIO on tmpfs
<mjg>
also i would like to remind you that close() whacks the fd even if the final write failed
<mjg>
and you have no way of doing anything about it
<mjg>
you are just told "lol btw it is not synced LOL"
<heat>
what final write?
<heat>
that's some ext4 shit
<mjg>
for example if you are fucking with nfs here
<mjg>
you can get ENOSPC
<heat>
oh ok yeah
<heat>
ext4 has similar weirdness there, closing a file you created will fsync
<mjg>
"lol btw it's literally not even there btw go fuck yourself"
<heat>
(or created + rename'd, whatever, i don't recall the deetz)
<mjg>
ye there is some fuckery there
<mjg>
i ran into it with vfsmic
<mjg>
vfsmix
<mjg>
bottom line though, fs-specific weirdness aside, the OS API for file handling is utter shit
<mjg>
in unix anyway
<heat>
data safety is PESSIMAL
<mjg>
fsync? not even once
* geist
yawns at all of you
<mjg>
lemme guess
<mjg>
fuchsia does not have the problem
<geist>
hah, no i'm sleepy
<geist>
ENOTABOUTYOU
<heat>
roasted
<geist>
zing!
<geist>
i slept a pessimal amount of time last night
<mjg>
7:59?
<geist>
pretty much
<geist>
i need a lot of sleep to be fully rested, alas
<mjg>
i got a friend who was operating on liek 6 hours of sleep for few weeks
<mjg>
one day he finally got 8
<mjg>
he arrived looking like absolute shit
<geist>
well also i tend to be sleepier on the weekend. i think it's because i dont wake up and immediately have to do something
<geist>
if you get up and then laze about for an hour or two it doesn't really help you wake up
<mjg>
i hear "snoozing" is PESSIMAL
<geist>
i think so. but if i lived in spain and it was hot...i think siestas are a damn good idea
<mjg>
meh @ siestas
<mjg>
power naps are the shit tho
<mjg>
albeit it may be it's the same thing in this nomeclacture
<mjg>
how long is "siesta"
<jimbzy>
I like those naps where you wake up dehydrated 14 hours later not sure about what year it is.
<mjg>
oh man
<mjg>
i was reovering from a poor fucking sleep period
<mjg>
got that 14+ hours with a piss break
<mjg>
i realized i did not drink anything for a long time only because i got a massive headache after waking up
<geist>
yah i sometimes do that too, sort of forget to drink for a day and then feel crappy
<kof673>
there's a japanese turtle story about falling asleep but i'm not going to paste it :D
<kof673>
at autumn the alchemy earth was sometimes a white saturnian/mercurial old man
<mjg>
i fuck up my hydration when i get into the zone
<mjg>
i don't feel hungry or thirsty at all
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<heat>
i keep finding awful problems with a multi-monitor linux setup
<heat>
awful.
<mjg>
:)
<mjg>
use windows
<mjg>
fwiw i3 worked for me :d
<nikolar>
why do you have more than one monitor
<nikolar>
smh
<heat>
i have problems with fucking games
<heat>
and hidpi scaling
<heat>
oh and when i'm booting for some reason my secondary monitor is detected but doesn't actually get output
<mjg>
have you tried a distro with an unbreakable multimonitor setup?
<heat>
🤔
<Ermine>
my friend's monitors get messed up after suspend
<heat>
I can't even suspend
<zid>
how well does uma musume work heat
<mjg>
unsuspendable distro user
<mjg>
is that arch btw
jcea has joined #osdev
<heat>
It's nvidia's fault
<heat>
driver borked on suspend
<FreeFull>
Classic
<Ameisen>
I've realized something. Most of my instructions that I emulate have 0-1 branches - usually just checking, if it's enabled, if the current instruction count is the target and if it needs to escape. Some have more, especially if they can signal exceptions, and memory accesses can have several for bounds checking and such. Since these are all inlined... how problematic is that going to be for the branch predictor to handle since there are then a _lot_
<Ameisen>
of branches? Would it be more sensible to put some of these instructions into their own routines and just `call` them instead, so those branches have just a single address? I'd expect them to be trivially-predicted.
<mjg>
if the branches are truly trivially predictable, you can presumably annotate them as such
<mjg>
then you are still paying for evaluating the branch ofc (+ i-cache footprint), but not for misses
<mjg>
however, i don't think this is the kind of question which warrants asking
<mjg>
what you should do is check how many misses are you getting and where
<mjg>
if you are on linux perf can do it
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<heat>
if you have a lot of instructions and those are all inlined... yeah
<heat>
your icache is going to be crap anyway
<heat>
but as mr guzik said, use perf to get actual data
<heat>
and then try to slap some noinlines around or something, and see how that changes
<mjg>
note that branch predictor can work based on the call stack to the branch
karenw has quit [Quit: Deep into that darkness peering...]
innegatives has left #osdev [#osdev]
PapaFrog has quit [Remote host closed the connection]
PapaFrog has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 248 seconds]
AmyMalik is now known as Ellenor
Lucretia has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
PapaFrog has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
PapaFrog has joined #osdev
Left_Turn has quit [Ping timeout: 276 seconds]
<Ameisen>
there is no callstack to the branch. When things enter recompiled code, it's a single `call` into a chunk and offset where it begins executing a stream of generated instructions.
<Ameisen>
I suppose it would see that callstack, but it'd be identical for everything.
<Ameisen>
but yeah, I need to profile it.
<Ameisen>
It would, however, be very difficult to tell where such misses are happening, as this is dynamically-generated code. There's no debug database or anything, and the offsets wouldn't reflect anything in the binary.
Matt|home has joined #osdev
fedaykin has joined #osdev
<heat>
if it's JIT then you're probably okay
<heat>
just make sure your branch polarity isn't all screwed up
<heat>
and avoid adding more/remove some
<heat>
like the instruction count one. do you really need it? probably not, unless someone is debugging