#Astral
1 messages ยท Page 23 of 1
I have only booted 2.8 like once so I dont remember that
also, now there is 2.8.1 too
i must confess this is the first time in my life i have touched gtnh
monkuous on their way to vanish for a year the moment they start playing gtnh
its a fun modpack

can't wait to start my first ever gtnh playthrough and do it all on astral
Yess
i have never played minecraft with mods
only optifine
/sodium
am i missing stuff
Depends on the level of complexity you enjoy
Are you sure that the cache manager ever unmaps the cached MFT views?
Luv*
omg i hated fusion and waterline
- monaline
gtnh is the insane man's modpack
Never made it that far
bonus points if gog
i'm in UHV rn
a YTuber is doing that
the goat
last run was like 1k
The process that mapped a specific MFT view may have closed, leaving some MFT views still mapped
but stopped at UV
Why?
i imagine it would at unmount time
Lol
also, they doing a multiblock change now
Should've just finished on the old one
they are changing basically all the structures
Yep
oh wtf
That's good
damn
(i was also working on a new multiblock)
Because every multiblock is a fucking rectangle
oh true lmao
Or a lot of them
centrigure ebf turbines etc
Yep
Then they waste some memory on that
Also I unironically learned some chemistry from gtnh, I knew literally nothing
Since a lot of recipes and alloys are literally exactly as irl
Even like the way u get titanium via ebf with magnesium and stuff
mm greg petrochem
Lmao
NO FUCKING WAY
@sharp carbon that EMFILE error earlier could have been some dns bullshit
mlibc was leaking fds when a dns error happened
oh possibly
I'm gonna test rq if the timeout code works and then upstream the patch to astral + open a mlibc pr
and that fixes the fd leaking as well
seems to be working
dns patches are up
I have gone to bed
im enjoying monkuous' role as an angel going around doing miracles for our projects randomly
it's honestly kinda funny
my favorite kind of person is the anonymous green discord profile picture person with an uncanny amount of knowledge in a topic
and by anonymous i mean they don't have many connections on other platforms
actually it can help for cpu rendering
it increased 10-20 fps on my raspberry pi when it was doing cpu rendering
yeah it could be that the missing shared memory stuff is making it slower to a point where sodium doesnt have much of an impact(?)
and about the xorg shared memory stuff, it seems like it can use /dev/shm and mkstemp
which might not be the best option but works lol
or rather, /run/shm
hm
const char *shmdirs[] = {
"/run/shm",
"/var/tmp",
"/tmp",
};
one of these
/tmp is already mounted as a tmpfs
but I would muuch rather it use /dev/shm
well it seems to be enabled now
that is pushed as well
didnt seem to make that much of a difference on my laptop but I am also missing a lot of perf work monkuous did
plus running under wsl
I changed the xorg patch so you'll have to rm rf the xorg-server sources btw
and rebuild for the shm extension
the base game mechanics are pretty complex already, you don't need mods for complexity
huh lol
which minecraft mechanic is complex
the base game is piss easy
if you think its complex gtnh is definitely not for you
it has processing lines needing hundreds of machines
like kevlar etc
no impact on performance for me either
are you sure that log message indicates that SHM is actually used rather than just the extension being enabled? because that message was there before i applied the patch too
Well okay I guess were talking about different types of complexity
If you wanna beat Minecraft base game you dont need any of these things
@grand shadow I looked into it and using X11 SHM with Mesa requires shm* syscalls
this is in mesa
it has no fallback methods
if this function fails it disables shm use
would you look at that
what the heck is a shmget 
why do you need shm anyway
is it that important for x11 performance?
yeah
what is done differently if you don't provide shm?
presumably it sends the image data over the socket to xorg
idk the details I just know it's very inefficient
well so u can share the framebuffers with the window manager/compositor
otherwise it has to memcpy every frame
yeah that somehow did not cross my mind immediately
shmget is probably the worst shared memory interface on Linux though
files on tmpfs are literally better
yeah but that doesn't change that mesa seems to require it
isnt that an abstraction on top?
i don't think it's possible to implement shm* as an abstraction
not without a central server at least
hmm yeah it is
and the semantics are incredibly stupid (not linux's fault) since it uses a single global space for shm names
so it requires some private instance of ramfs or something
lol i almost forgot about that
imagine using a namespace for something like that and having it be a global flat namespace and not just using the filesystem you already organized everything else around
someone was lazy
Lol yeah on linux it does
shmem_kernel_file_setup - get an unlinked file living in tmpfs which must be
* kernel internal.
it calls it sprintf(name, "SYSV%08x", key);
should've been a libc function
i don't think you can implement it as a libc function
hmm why?
the only issue i guess is it may collid with some existing file in tmpfs but other than that seems doable
the value returned by shmget is not an FD
it's really a globally valid number
Look at the example in https://man7.org/linux/man-pages/man2/shmat.2.html
who came up with that
unix system v apparently
what if you also created a file with that number as its name
kill them
younguns always dunk on certain mainframe/minicomputer boomers like the VMS guys for hating on Unix back in the day
they have to remember
this is the unix they were hating on
it deserved hatred in the 80s
Why is that a problem?
As long as your shmat can find it
why is that?
because if you're on new versions of linux you can just use memfd_create
and on old ones you can use O_TMPFILE
and if you don't even have that, you can fall back to a file in /tmp
says who
see discussion above
There are other subtleties, for example shmdt cannot be implemented just on top of munmap
i implemented shm* to the extent that is necessary for x11 shm to function but the improvement is much worse than i expected
glxgears fps went from 1400-1500 FPS to 1800-1900 FPS (on my host with llvmpipe it's 3500-3600)
in minecraft the improvement was unnoticeable
So strange
What could be bottle necking it so much
i've done some more testing and the mc improvement seems highly situational instead of just all out unnoticeable
btw when i switched from using mlibc to doing linux binary compat my glxgears fps magically doubled from like 1400 to 2800
when there's a lot of non-full blocks around (like in the overworld where i initially assessed the impact) it's unnoticeable
idk what caused it
but in the end where there's basically only full blocks it went from 10-15 to 45-60
nearly 60 FPS in minecraft on astral
no, because it doesn't take a size. but couldn't you store the size somewhere else
glibc is super fast probably
huge
btw whats the state of gtnh starting a game?
still the same error with gadomancy
some internal object being null?
i tracked it down to a gadomancy research item not being registered with thaumcraft for some reason
but i haven't investigated further than that
this looks very similar to the current difference between astral and my host system
might just be mlibc perf issues then
that'd be surprising though if mesa relied that heavily on libc calls
memcpy maybe?
even basic stuff like memcpy etc
iirc mlibc memcpy is about as optimized as you can get while still having it be written in c++ but it is c++
it uses avx for that
whereas glibc uses handwritten asm that takes advantage of whatever features the actual running cpu has
^
oh yeah i'm not saying it's not impressive, sorry
i doubt that that's a problem
it's just that memcpy probably is insignificant in this case
i think to go further a proper profile is needed yeah
and i don't think astral has anything near the needed infrastructure for that
wasnt there a way to profile the entire vm
it sucked iirc
sampling yeah
but for stuff like this where sub-millisecond stuff matters it's not that great
A 2x improvement would mean that even if glibc memcpy was 4x as fast (it isn't), the overall time in memcpy would need to be way > 50%
So I'm skeptical that these numbers are correct (and attributed to mlibc) unless somebody does an apples to apples comparison
i.e. linux glibc vs. linux mlibc
A program can also be sped up significantly by libc improvements if it already spends a lot of time in libc which sounds unlikely for this workload
Glxgears is only 550 fps on my cpu on astral insane difference damn
huh, that's... interesting
I mean when its single threaded it doesnt have to send tlb shootdowns
how many threads does it use w/o an explicit setting?
1
Yeah and I dont have sysconf so 1
makes perfect sense
But yeah I think thats mostly tlb shootdown overhead
Since I only send shootdowns on userspace when theres >1 thread
might be related, i noticed that glxgears constantly mmap's then munmap's the same piece of memory
why does it do that?
I remembered testing that on linux as well and when setting lp num threads it also slowed down
It probably allocates / deallocates frame buffers
having a set number of framebuffers is alien technology
for me on linux it definitely helps $ LIBGL_ALWAYS_SOFTWARE=true LP_NUM_THREADS=1 glxgears 11824 frames in 5.0 seconds = 2364.768 FPS 12447 frames in 5.0 seconds = 2489.235 FPS Terminated LIBGL_ALWAYS_SOFTWARE=true LP_NUM_THREADS=1 glxgears $ LIBGL_ALWAYS_SOFTWARE=true LP_NUM_THREADS=8 glxgears 20418 frames in 5.0 seconds = 4083.596 FPS 20365 frames in 5.0 seconds = 4072.906 FPS Terminated LIBGL_ALWAYS_SOFTWARE=true LP_NUM_THREADS=8 glxgears
same in my testing
Weird
maybe it was wsl being funky
cant even repro it because LIBGL_ALWAYS_SOFTWARE doesnt work with wsl for some reason without passing some more envs which I forgor ๐
and I changed it to use proper gpu a while back
why do you use wsl anyways ๐
r/linuxsucks 
cba to install linux
so you make your own os instead 
maybe the reason I got so far with astral is because I didnt install linux who knows 
Wait you're actually developing Astral from Windows?
Why hurt yourself like that ร
but still
[iretq@DESKTOP-TAQSOFJ ~]$ LIBGL_ALWAYS_SOFTWARE=1 LP_NUM_THREADS=1 glxgears -info | grep -E 'GL_RENDERER|frames in'
GL_RENDERER = llvmpipe (LLVM 21.1.5, 256 bits)
14234 frames in 5.0 seconds = 2846.708 FPS
14279 frames in 5.0 seconds = 2855.724 FPS
14534 frames in 5.0 seconds = 2906.710 FPS
[iretq@DESKTOP-TAQSOFJ ~]$ LIBGL_ALWAYS_SOFTWARE=1 LP_NUM_THREADS=8 glxgears -info | grep -E 'GL_RENDERER|frames in'
GL_RENDERER = llvmpipe (LLVM 21.1.5, 256 bits)
14954 frames in 5.0 seconds = 2990.709 FPS
15041 frames in 5.0 seconds = 3008.050 FPS
15133 frames in 5.0 seconds = 3026.420 FPS
[iretq@DESKTOP-TAQSOFJ ~]$ LIBGL_ALWAYS_SOFTWARE=1 LP_NUM_THREADS=24 glxgears -info | grep -E 'GL_RENDERER|frames in'
GL_RENDERER = llvmpipe (LLVM 21.1.5, 256 bits)
9761 frames in 5.0 seconds = 1952.070 FPS
9759 frames in 5.0 seconds = 1951.615 FPS
9772 frames in 5.0 seconds = 1954.358 FPS```
lol
probably because the other cpus are being shared with windows
but 1 to 8 is negligible for me
well you have a trillion cores I have 8 cores on my laptop
so even less cores makes it slow down ๐
but yeah there is defo something bottlenecking smp in astral
and since it seems to slow down when running with >1 thread on glxgears it seems to be tlb shootdown?
I already only send that shit only to cpus that are running in the same address space and once per munmap so I'm not sure what more can be done on the userspace side
I know kernelspace I still dont do that lazy shootdown thing
i wonder if you could do the tlb shootdown asynchronously
(i dont do smp at all so i might say something stupid)
well with RCU u kinda do that
You mean in the sense of sending shootdown ipis but deferring freeing until they finish?
yea
Not that I should be discussing any of this w/ my kernel that doesn't shoot down tlbs 
managarm does this
managarm does this
(so yes you can do that)
That's cool
because managarm kernel is coroutine driven
does that really matter
makes it very easy
You can still do this is a kernel that isn't inherently coroutine based
but u can make a completion callback when all cores finish the ipi
well astral having proper profiling infrastructure is way overdue at this point and I can look into how to do it later unless monkuous wants to do it
nah i'm probably gonna move on to non-astral stuff
monkuous just going around randomly helping projects 
what are you doing next
nice
Do you have a post for that I can follow?
whats the current state of xarch btw
i do not
haven't worked on it in a while, but iirc it's unstable but functional and gets to a bash prompt
nice
the 32-bit one?
That sounds like pain
as always
pls dont delete the current branch
i won't dw
name it after a different hydrogen isotope every rewrite
Deuterium
hydrogen-16 doesn't exist
add a new component every time, so hydrochloric acid this time
gregtech refenrencencnecne
send a disk image for this
i might put it up on the demo web page
chemistry was invented as a meme to reference gtnh
No... ? That's a gas that exists in oil processing. Like. In the real world.
thats the joke lmao
It's like one of the big dangers they have shittons of sensors for.
no... reality copied gregtech....
no stupid its a factorio reference
lolol just electrolyze it for free sulfur and hydrogen duh
Factorio basegame doesn't have any references to chemistry like that
The most you get is U-235 and U-238
And maybe sulfuric acid
the oxygen molecules just vanishing
real
boot-args = root=/dev/xrdisk0p1 rw console=tty0 oops=panic
it has bash and coreutils installed
can you make a version that has the bootloader send that command line automatically
actually
can you do that and make the disk /dev/xrdisk3p1
so i can attach it as dks3 in the web demo
for me it works more often than not
it works if i crank up the cpu speed crazy high
it consistently crashes with a lower speed
i dont think i will put this up as a web demo yet bc it will just demo that xrstation crashes a lot
maybe on its own sub-page
understandable
so profiling basically boils down to:
set up a ring buffer
set up a pmc
set up a nmi handler for it that writes to that ring buffer
expose that via a device or some other way
pretty much, yes
seems simple enough
nmis in astral letsgo
probably just gonna expose that via a /dev/prof or something and have some application be able to attach to it
sorry i stole your thunder in #esoterics lol
i moved cuz mathewnd came back
ah
hmm and I could make it so that profiling is disabled/enabled by writing into it
@marsh sparrow in managarm, do you add any more info like pid/tid and do you only log instructions in the kernel
Alright
amazing nickname
ASIDs
that doesnt help with shootdowns
ASIDs only make a TLB invalidation less expensive
They're not magic (i.e. if the process had filled the entire TLB then it wouldn't do anything)
nvm youre right
they only make switching address spaces cheaper
Anyways savinf this here for later https://forum.osdev.org/viewtopic.php?p=305959#p305959
Yes I am gonna shamelessly steal managarms profiling :p
Its simple and seems to work well enough for managarm
What's a pmc
Pentucky mried chicken
performance monitoring counter
The Professional/Managerial Class
did some mlibc stuff now starting the profiling stuff
at one point I also should create a python script that generates a graph of the init dependencies in the kernel
shouldn't be that complicated since dependencies get defined on the same macro as the routine is defined
the macro soup is worth
instead of doing profiling I do this :P
damn this pmc shit crazy wtf was intel cooking
thats gonna take a while to learn how to do
how did u produce this
python script that greps the source code for all init routine defines and processes it
its upstream
its a really hacked together thing but it works lmao
bro I have had that for monmths
oh i missed that rework
yeah it was one of the first things I did when I woke up from my slumber
anihilate all _init from main
ahh
now I have an init system fueled by macro soup
managarm larp
real
unlike managarm's this is 100% organic macro soup
no industrialized goods here!
How can I run Astral on the real hardware with all pre-installed programs and games?
not real initgraph tho...
Theres no real hardware nic support so youll have to do an initrd with everything, and idk if itd even fit in memory at this point
That's sad(
Maybe next year Ill add more driver support, I have much more important stuff to do in the kernel than write more drivers
Prs always welcome :)
dang that's a lot of packages
ah
How are you hosting it btw
Some random ass vps I have had for a while now
Ah
when will this vps run astral?
I would need to implement like xen hypervisor disk and network stuff ๐
virtio ain't enough?
Idk if they expose virito
I could run lspci to see
But they do allow you to run your custom os image
๐ฅ
Terrible
would astral as a container os have the same performance issues when used to host a Minecraft server without graphics?
why the fuck do they not -M q35
no idea
and worst case I finish the profiler and profile it
I already have the architecture independent side of it done
its just that the architecture dependent part differts between amd and intel and sucks
The AMD one is quite sane
The Intel one not so much
On intel, don't forget to unmask the PMI in the lapic LVT since it auto masks itself 
It's very intuitive because no other lapic LVT irq does that 
Consistency is key at intel
intel and amd have builtin stuff for profiling?
they have performance monitoring features
with performance monitoring counters you can get an interrupt on every X instructions / cache misses / branch mispredicts or similar metrics
Nice
https://repos.managarm.org/repos/amd64/ (yes it has multiple versions of packages, but so does astral)
jeeeeesus
We keep every version ever around (for now)
But the total amount of unique packages registered in the repo is 448 last I checked
we should also keep doing that, it's useful for bisecting
we can potentially put it onto cheaper storage though if needed
but for now it's not a problem
Yeah I have no plans to change it at this point. And it is useful so itโs fine to keep around
when astral os-test btw
Soonโข
Currently working on the mlibc demo os and book but when Im done with that and the profiling stuff I can pick between doing ostest or page cache work
highly based
So the Awawi is still working on this 
Yup
A lots been going on
I can tell ^^
A few days ago monkuous beat minecraft 1.12.2 in astral
Now I am working on profiling and a page cache rework
Whoa that's actually amazing
Damnnn
Speaking of, when do you think youll be able to upstream the work? @sharp carbon
it's already pretty much ready to be upstreamed, it's split up into individual commits and everything
i'm just waiting for ftpmirror.gnu.org to go back up so i can test it
gnu mirrors trying to not be down 99% of the time (impossible challenge)
for reference, these are the new commits
not included is the rtld mlibc pr that was upstreamed but that's only necessary for 1.13+
Good stuff, thanks
Least unstable gnu.org moment
on astral? or when I tried it on managarm
on managarm it ran to the zero-length truncation assert or whatever it was (and it did run into this first too but I already fixed this locally when I tried it)
Astral, apparently one of the mods did not want to load properly
its probably that then if it happened very early
The game loaded but couldnt open a world because of gadomancy not loading properly
ah then its likely not the same thing
Yeah I doubt it's the same thing
btw @grand shadow the kernel doesn't compile with a new copy of limine.h (like what gets downloaded by the recipe on a clean build), seems like some names have been changed since the code was written
i remember when limine used to have revision based defines
seems like they were removed
really i think astral should just have vendored limine.h
this specific header is bsd0 licensed
yeah they were seemingly removed when the limine major version was increased
which, you know, fair enough since major version increases indicate breaking backwards compatibility
but annoying
damn thats annoying
if you can include fixing the header to an older version in the pr I'd be grateful
4607d68cbdbe653885937fb3178449588addb799 is the last commit with the api revision thing, i'll fix it to that
thanks
@grand shadow do you want me to make this one giant pr or should i split it up?
Can be a big one idm
alright
isn't the mlibc patch upstream?
Thanks, Ill look into it in a bit
I meant it as in not tracking upstream
It is but I am running an older mlibc version because of abi break + openjdk didnt have a patch
astral is on an old commit of mlibc because updating needs a world rebuild
ah
I might update it either today or tomorrow if I feel like it
I am not sure if waiting for leo's locale pr would take too long
Oh thats good, I thought it would
Then I should update it soon
Maybe after I finish the mlibc guide thing
nice
You mean having to rebuild all your cross compilers or smth?
Or is it an ABI thing
I mean that literally everything would need rebuilding
(So yes, it's ABI)
There's been an ABI break since the commit it's on right now, and since it's the libc, that affects literally everything
I hope you have build scripts for everything in the distro
Fair
merged, tysm!
'tism
:P
anyways, I am currently still mostly doing the mlibc demo os work and writing the guide but once I am done with the first part of it (at some point in the future I will implement the stuff needed for dynamic linking in that kernel) I will go back to working on astral
not yet dead project ๐
plus intel pmcs are bullshit and I will have to implement a driver for that
but the drivers are the only thing left to do
aside from the userspace program which is simple and a python parser which is also simple
then I probably try profiling a bit and making astral faster and after that its back on the page cache grind
I still have the nvme prp work to finish
did you look at the Managarm code the intel pmcs?
speaking of, can somebody give that PR a thorough review pls? it seemed to work for dennis IF you comment out the freelocale function body
can i somehow change keyboard layouts
Not yet supported
I want to do that at some point since I also use a different one than en us
can you not change the xkb layout
Oh I thought he was talking about the console
idk if he is
btw does it sound plausible that handling of VMIN/VTIME et al messes with OpenSSH on managarm?
I mean it could, IIRC I implement those correctly
But idk if openssh passes there
These*
those settings for vmin/vtime seem like what any implementation that doesn't support them would comply with
allow read to unblock when 1 byte is available, no timeout
I am thinking of how I am going to handle NMIs
mostly the "before swapgs and after userspace irq/syscall" part
the only ideas I had so far were "checking if KERNEL_GSBASE points to a valid user address and swapping if not" and "checking if it happened on a specific range of instructions"
but both of these seem hacky
nmis are hacky grrr
or I ignore gsbase at all and use a combination of local apic id and iterating over every cpu struct 
The solution is obviously to pretend NMIs never happen
I am going to have a pmc nmi profiler so kinda cant
and I have to access cpu local data for that
Check out how Linux does it
if you have a dedicated stack for NMIs you can store some stuff on it, like the kernel gs base. You can swap it with whatever's currently in the msr, and restore it before exiting. (I think this was monkuous's idea?)
ah I didnt mean to ping you for that, sorry
Managarm does it by storing kernel GS on the NMI stack
And then it's loaded into current GS
Not through swapgs (because you can't be sure if the previous gs is kernel gs or user gs) but through wrmsr
And the previous GS is saved on the stack just like any other register
so what do NMIs mean except "your hardware's fucked"
who fires NMIs
Managarm uses NMIs for kernel profiling
i guess those are software NMIs? and also, what about real hardware?
no, the local apic performance monitoring interrupt triggers these
this also works on real hw
its not even "hardware fucked"
a lot of nmi events are used to notify the kernel about a corrected error
like memory/pci express
depends on whether you count MCs as NMIs
usually hardware errors are reported as MC but some would say MCs are NMIs
watchdog timers and profiling are big ones
well yeah other than MCs the only uses of NMIs that I'm aware of are software configured
so if your os doesn't configure anything that uses NMIs then the only ones applicable are MCs
super useful imo
to detect lockups
i see
Yeah thats smart
i have an nmi button on my machine
same shit
whats that for-
causing an nmi presumably
makes sense
some servers have this (or have ways to trigger that from a management interface) so that you can test whether the server is still responding or not
@grand shadow https://www.reddit.com/r/osdev/comments/1oyuwpo/c_running_on_my_16_bit_operating_system/ what are your thoughts on this getting more upvotes than astral
ts pmo
you just didn't have the word "skibidi" in the picture
so I am now rewriting astral it will be a 16 bit 8086 os that will have tralarero tralala and a liriliri larila app
based
I am thinking of how I am going to implement that NMI stuff without having per cpu idts
as it currently is I have a per cpu array of isrs and a single idt used for every cpu
so far my only idea that might work is checking if EFLAGS has interrupts disabled and doing the gs stuff if so
why do you need per CPU idts?
same
I dont
I mostly need to figure out how to figure out I am running in a nmi before acessing per cpu data
and the only way I thought of was being interrupted with interrupts off
and the only places before swapgs have ints disabled anyways
i'm not sure if i understand the problem
in your NMI handler you obviously know that you're in an NMI
and you only need the load-gs-to-known-good logic in the NMI handler
yeah but that would need per cpu idts no? unless I have a fixed interrupt number in each cpu be the profiling nmi
since at start I set up each idt entry pointing to a small stub that saves one register and puts the int number there and then jumps into the rest of the interrupt ocde
and the per cpu interrupt stuff is handled in the architecture independent stuff
I guess I could do that but that feels hacky
oh it is?
well TIL
so to figure out if a profiling irq is happening I gotta check some apic registers there
oh I am blind
I had the intel sdm open and didnt notice it said that
๐
Oh hmm
Hm? What's that
builtin profiler
looks pretty good
saw it over at serenity os discord
looks pretty good
no need for any sort of kernel support
I developed mine ( https://github.com/maestro-os/kern-profile ) which generates a flamegraph, but it's broken rn and the above seems to look better so I guess I'll have a try
Oh thats cool
Those Reddit fucks are so dumb
:)
turns out the issue wasn't in astral or mlibc or anywhere else
the mod in question was just badly written and expected process work dir == game dir
adjusting the launch script fixed it
@analog berry CHECK THIS OUT
yeah but 1-3 FPS on the literal lowest settings possible in a fresh world?
I mean yeah
I should get the kernel profiler finished already
or use the qemu one
i ran it on my host with the same settings as a comparison
radeon: 2800-3100 FPS
llvmpipe (16 threads): 100-110 FPS
llvmpipe (1 thread, aka same as astral): 20-40 FPS
hmm yeah something is defo messing it up
I plan on doing some profiling once all that infrastructure is done
but it might be memory stuff, my vmm is kinda shit
linked list vmm ๐ฅ ๐
Daaamn
Naah its not that bad until late game
This
I plan on writing an iterative rbtree implementation at some point to use in the vmm
what about 16 thread llvmpipe on astral? or is there a problem with it
on astral llvmpipe gets slower with more threads
the theory is that it's caused by tlb shootdowns
ah okay :D
I do one shootdown per munmap(), does linux do something else?
I know you can batch them kernel side but user side is not safe
and only on multithreaded processes and only when there are cpus running those threads etc
Early game should be fine, a fresh world's only lag should be the chunk generation initially
is this only on minecraft or all software using llvmpipe
i tested it with glxgears
#1061407633745125397 message
i doubt its tlb shootdowns as i literally do one on all cores on all mmaps/munmaps and at least on halflife gets significant boost when multithreaded
ughh Id have to rebuild qemu to use that
yeah I will only know for certain if I profile it
I dont think I will have a lot of time this weekend
looked at gtnh performance with mc's builtin profiler and it looks like ~70% of the frame time is journeymap and the hud text
galacticraft astral when
when hiding the hud with f1 i get what feels like 30-40 FPS
wtf
how is text so expensive
gtnh has that
minecraft does have a notoriously terrible font renderer
you were saying?
๐คฏ
Ah yes tier 8 rocket, only 2k hours to reach
Check out the crafting recipes for each component
galacticraft experience is pain
Gnth galacticraft is basically rewritten from scratch
Every planet is useful since it contains new tier ores etc
Wonder if some of the lag could also be me missing something like sched_yield
Since I have seen mc complain a lot about it missing
At least a1.2.6
The syscall not the scheduler function
i made that a no-op in mlibc a while ago because it was printing an error message each frame
but it shouldn't affect performance
well the removal of the error message would affect performance but i'm not sure by how much
does that work on kvm?
Good question
That needs a qemu recompile I think?
Idk if distros ship that
They dont seem to mention if its compatible with kvm I think
If you're on arch its bleeding edge
Or wait
Yeah idk
it seems to be a plugin, not part of core qemu
Yeah it needs building separately it seems
@sharp carbon are you running with the same amount of memory in xmx and xms?
When I ran it with the same it got much faster on alpha
Or at least felt like so
I'm not explicitly passing either
it's auto detecting xmx as 8G (1/4th of total guest memory) but I'm not sure what it's using as xms
I wish I had more free time to work on stuff Im gonna be out until sunday ๐
I can maybe get a thing or two done maybe
Since I still have to do more work on the mlibc demo os
I envy the kids who have 5 trillions hours of free time to do this shit
Just make astral that os

So true
I somehow got myself into maintaining an os written in a language I dont know for an architecture I dont know 
Which one is that
mlibc-demo-os
Just a basic super bare bones thing
Written in rust for rv64
all i'm hearing is: i got to the opportunity to step outside my comfort zone 
to be fair rv64 is way simpler than x86
RV64 is way easier to deal with than x86
Its entire privilege model is so much simpler
wtf nice
nice
can you find out why astral minecraft is so slow now 
what is this exactly?
a flamegraph
a flamegraph
i mean of course
but what program visualizes and creates said flamegraph
qemu/uftrace/perfetto
how much you give processor time to processes
how does this work
my guess is that it integrates with TCG to add profiling hooks to ebp changes
or to call/ret instructions maybe
you can also use clang profiling in your kernel directly
and send data via serial
i gotta try this
Like 10 I think
10 what?
gigaseconds
Ms
then implement sys_yield
But I dont think it matters unless java implements their own locks in userspace
Maybe
That sounds like it would make things worse
Oh dude implement a yield, if its using it there's probably a good reason
tbh 10ms means 100 threads can execute code. 1ms means 1000 threads can execute code, but they have less time per quantum which could affect performance
I guess, I have it in kernel so its just hooking it up to userspace
If you're in a situation where this matters you're fucked
No scheduler is designed to deal with 1000 simultaneous ready threads with good responsiveness for all of them
You're not supposed to use the OS like that as an application programmer
true
yes
#nocputimewaste
You're supposed to have 1000 blocked threads and like, a couple dozen ready threads tops and that's on a system with lots of cores
I agree
you mean sched_yield? minecraft just calls this for no reason in the middle of the game loop
it's not used for locks or anything
No way
great now the bar for when ill feel comfortable making a post about my thing anywhere is when it runs minecraft too
otherwise thyll just go
"but does it run minecraft? did you hear about the one that runs minerat?"
(thats a compliment, youve raised the bar from just having a pretty window server to running something grand like this)
Kernel shells are not enough any more? That's news
Would be good news if true
But it isn't 
This chat feeling like accidentally entering nvidia instead of Microsoft
I truly am a master baiter
upvoted!
do you have one for Ironclad? :p
Well ironclad is already pretty well known on HN no?
probably
@grand shadow hey do you handle arrow keys in your kernel terminal? (so that you write to different positions within the line buffer)
nope, that is userspace's job if they want it
at most it does cooked mode
yeah, in cooked/canonical mode I mean
im sorry what
i guess you only handle backspace/vkill/veol/veof
in canonical mode i believe you're supposed to implement the entire line reading logic including arrow keys and vkill/vwerase/verase
nope
type cat in a shell with no arguments, thatll give you a pure cooked mode input
type arrow keys and see what happens
the shell goes into raw mode and handles the arrow keys itself
wow
implements its own line editing
i actually didnt think it worked like that
so the normal canonical mode line buffering ONLY implements backspace/vwerase/vkill
what if i implement it anyway
(nah jk)
yeah its why libreadline exists 
Wait does mlibc build with debug by default
If so I have been running on debug mlibc with O0 this whole time
i actually wanted to make a PR to change that to debugoptimized by default
which is like -O2 -g
all of my meson projects (and autotools) default to that
how fast is mc with release?
No idea havent tested currently getting a riscv64 toolchain to build mlibc
Which is where I noticed the O0
Probably will do that then
i am doing it rn
Oh I meant like on astral's meson recipes
@grand shadow in your 1528 PR, is it actually related to the PR's aim to use sys_ioctl instead of ioctl, or is it just an optimisation?
actually related
because i thought ioctl() was POSIX?
sys/ioctl.h is under the glibc option
is it supposed to be? that's weird
wait what the fuck? ioctl() isn't POSIX? literally unironically unusable
posix_devctl
yeah it just so happens everyone implements ioctl() but its not standardized
what's the diff between mempcpy and memcpy again?
is it really just that mempcpy returns the end of the buffer?
what a useless function
Yeah
dest it returns a pointer to the byte following the last written byte.```
who unironically uses the return value of a memcpy anyways
you could probably return void and not break like 98% of software
99.9%*
it was but it was removed replaced by posix_devctl in the latest issue (in stropts.h)
or well it was an extension or whatever (OB XSR)
oh true they define what happens on ioctl on STREAMS
and anything else is undefined as usual 
and not a lot of people implement STREAMS so 
it breaks compiler-generated code, I have seen the compiler use the return value of the mem functions
well it kinda makes sense like if the variable is in rdi or whatever before then it gets clobbered by the call so then the compiler can just continue using the variable as rax without needing to save it to the stack
why does astral need debootstrap to build
i dont want debian packages on my arch system
the latest Jinx version fetches debootstrap on its own, and also, what's the issue? the packages are kept locally confined to a directory (usually inside the repo itself)
namely .jinx-cache
will it extract to my root
no
ah
obviously not
it doesn't even have root permissions
it creates a container, kind of like Docker
interesting
Yeah I am still on a super old jinx
Last time I tried it just would not work
But its been a while so that weird bug might be fixed
I do wonder hiww much difference building with O2 will do compared with O0 ๐
Insane that I never noticed that
what wouldn't work?
Usually yes but you add -O2 with CFLAGS in Jinxfile
it used to be until posix 2024
posix_devctl can be made a wrapper around it with size = 0
i don't get it either
Ninja -v didnt show O2 weirdly enough
My build.ninja lists every source file as being compiled with -O0 ... -O2 and checking the disassembly the O2 is what's actually being used
@sage locust this
Oh huh interesting
Maybe I missed it then
i mean if your CFLAGS have -O2, then that should override the -O0, yeah
I also should probably update my gcc I am still on 12.1 
hope eventually jumping to gcc 15 doesnt expose some evil ub in the kernel that gcc 12 did not catch
bad news: GCC 15 starts building stuff with a newer C standard by default
everything breaks
(unless you specify -std= manually)
might not expose UB specifically, but likely stuff will break
my jump to gcc 15 exposed compiler bugs in it :)
what was the bug btw
internal compiler error on valid code
let me look it up
some c++ mess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120800
insane ๐
make sure to remove dbxelf.h from your patch
they removed it sometime between 12.1 and 13.1
hmm I know I have a lot of stuff to do but I should try tdoing something very funny
trying to compile binutils + gcc + mlibc + whatever other packages I want into a sysroot and see how far it gets
currently git cloned mlibc + astral and downloading gcc and binutils tarballk
it died while extracting the gcc tarball when syncing a page ๐ฅ
Im tempted to port Qt to this
Shouldnt be too difficult, prs always welcome :)
weren't you able to do that in the past?
I put the source in the sysroot in the past but this time its actually extracting it
It git cloned astral mlibc and downloaded and extracted bintuils and then died when extraccting the gcc tarball
Mine is probably a page cache race condition
I thought I had fixed it but doesnt seem like it
Gdb didnt help cuz it optimized it out
to be specific the latest qt
Qt builds fine on mlibc and is portable (assuming Qt6, source: managarm has it)
Oh yeah if managarm has it astral can probably run it
how much qt6 require dependencies
- mlibc
- zlib
- zstd
- pcre2
- double-conversion
- libiconv
- icu
- glib
- libxkbcommon
- libinput
- libevdev
- mtdev
- mesa
- freetype
- fontconfig
- libpng
- harfbuzz
- libx11
- libjpeg-turbo
- libsm
- libice
- libdrm
- libxcb
- xcb-util-image
- xcb-util-keysyms
- xcb-util-wm
- xcb-util-render-util
- xcb-util-cursor
- openssl
- wayland
- wayland-protocols
- libxcursor
- libxinerama
- libxrender
- libxi
- sqlite
- brotli
- dbus
- at-spi2-core
and the transitive stuff
now the good part, big chunks are optional
so
i thought there will be a much more dependencies
dbus can be turned off, the entire X stack and graphics can be removed if not building GUI, same for wayland. sqlite is optional, glib and icu can be turned off, we dep on systemd for udev, but that can be turned off, so libinput, libevdev and mtdev likely have replacements / support replacing it, pcre2 is technically optional too, openssl is optional too
you must note that anything that they depend on is available too, so iirc its like 90ish packages that are installed for managarm?
and this is only qtbase of course
so if you want qml and friends, you need qtdeclarative too
(which pulls in some more qt parts but not massive pain)
and maybe the deps have changed, this is accurate for Qt 6.8.1
dead project xd
(yesterday I wrote some more stuff for the profiling stuff)
since the mlibc demo pr is now in reviewing and I think I'm done with that until I want to add dynamic loading support
i wanna make a package manager for astral
wait.
does astral even have networking
lmao
i'm pretty sure it does
wdym
i kinda wanna port pipewire and pulseaudio to astral too
but since those rely on ALSA i think i may have to do workarounds
theres no working audio driver :P
qwinci was working on hda + oss at one point but I think that got lost in branch limbo
I've gotten the nmi out of intel pmcs and I just gotta finish the nmi logic (ist + shoving the cpu pointer there)
i know im like asking alot but like can i port ALSA
ik ALSA's specifically for linux
ill port alsa and then miniaudio
then pipewire
and wyaland
im just obsessed with astral ig :3
I mean if u can make it work sure
:3
can i fork astral though because those 3 are gonna be tedious to port
might aswell test it on my own astral fork and then see if its cool to release to the main astral pkgs
I think you should list all the required tools to build Astral in the README, such as building Astral requiring the host to have fakechroot and debootstrap. Not necessarily needed, but I think it's nice to have
Yeah, I should put a link to the jinx dependencies of the commit I use at one point
๐
They aren't really bad at all, the bad part is that alsa fucking sucks and writing the driver part for it is a huge pain (because of the parameter refining stuff alsa has, if you get that incorrect the userspace alsalib will complain)
or well idk about miniaudio but alsa isn't bad, libpulse should require no porting and pipewire only light patching
Not sure if you're aware of that or not but you do need drivers in the kernel to make ALSA etc work
oo
i know
@marsh sparrow on the managarm profiler, is there a reason other than simplicity as to why you chose to only trace the rip and not a full stack trace?
only simplicity. Taking a full stack trace would also be nice
Ahh I might just do a full trace then