can it run Doom?
Frame – Linux X server in Assembly
41–50 of 115 posts
Re: Frame – Linux X server in Assembly
#42Interesting. I've never quite found that Linux is more optimized on battery-powered machines for energy savings, even though supposedly there is a lot of room to tweak and optimize settings -- from selecting a low resource window manager/DE to turning off various services to switching up power management utilities. But this does seem like an approach that might produce that kind of fruit?
Kernel option nohz_full in grub config.
Also disable hardware SMT as a kernel option in grub config. Then the cores can clock down way more often and L1 data cache size doubles.
XFCE and X11 tripled my laptop battery life vs. whatever Wayland+GNOME Ubuntu (2024?) brought by itself.
Powertop and tlp also help.
Happy camping.
EDIT: the lower heat dissipation also halved boot time. That one surpised me the most.
EDIT2: Disable "atime" with ext4 option "noatime". Saves a lot of power, heat, trimming, and re-writes on your SSD/NVMe.
For "faster shutdowns" manually run systemctl start fstrim.service. Not exactly sure why fstrim.timer seems unreliable.
Re: Frame – Linux X server in Assembly
#43How many times have people posted here about how software is no longer optimized because CPUs keep evolving, making programmers lazy? It seems things have changed.
The question is: will LLMs manage to squeeze the most out of this hardware, better than compilers do?
In the few tests I’ve run, yes, a lot.
Re: Frame – Linux X server in Assembly
#44Earlier quoted context omitted.
Claude has surprisingly good knowledge of X11 protocol. The other day, colleague showed me a (pretty basic) terminal emulator written in one-shot by Opus. Kicker is - that was compiled to a 30 KB static binary. That's right. No libX11, no libXfont, not even libc.
No libc? It used inline assembly routines?
It's quite easy to get it to do syscalls directly, I even got Fable to do a simple standalone TLS implementation (in C). Not really useful since it hardcoded a set of supported algorithms etc., but it's fun to see how "simple" you can force it to go.
Re: Frame – Linux X server in Assembly
#45It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler.
There is evidence that LLMs are capable of making assembly that runs a great deal more efficiently than the compiler can manage on its own.
Re: Frame – Linux X server in Assembly
#46I would like to see a similar project that fixes Wayland. Like, can someone vibe-code window positioning, add SSD to GNOME (damage was already done, but still), and add the ability to send events so you can automate and drive the app offscreen for testing.
One of the issues with Wayland is that it forces every compositor to reimplement the X server, badly.
So you can't really "fix it", short of patching e. g. Gnome's compositor, with patches that will never be accepted upstream.
Re: Frame – Linux X server in Assembly
#47It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler.
There is evidence that LLMs are capable of making assembly that runs a great deal more efficiently than the compiler can manage on its own.
There are a ton of optimization opportunities that hinge on the intent of a piece of code which static compilers can never detect at scale. LLMs can actually navigate that and write surprisingly optimal assembly.
I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective.
Re: Frame – Linux X server in Assembly
#48When first looking at the source code, I wondered why one would waste so much time to write 25k lines in raw assembly language, but then I saw that it was generated with Claude, for whom it does not matter much how expanded is the written text. If someone had written this program manually, the strategy would have been very different. With a good macro-assembler (and nasm is good enough) one should define a great numb…
It’s an interesting strategy, but I question how much it pays off, if at all. Very few parts of a program benefit from manually tuned assembly compared to the naive C implementation. Writing everything in assembly adds an extra layer of thought, which even for an LLM is additional effort that could have been used for targeted optimizations instead. It makes it harder to notice patterns that have been trained into the data set, from security problems to performance opportunities.
On a long enough time frame with enough tokens invested there’s probably not a difference, but being written in assembly by an LLM doesn’t imply optimal to me. I’d almost prefer having an LLM rely on higher level abstractions offered by a programming language rather than rolling everything itself. After reviewing a lot of LLM code, even at Fable and Sol levels, I just don’t trust that LLMs are writing optimal code. Assembly makes it harder to even review.
I do it find it very fun and entertaining. This is a component and I’m grateful that it was shared.
Re: Frame – Linux X server in Assembly
#49Earlier quoted context omitted.
It's the GuC and HuC firmware. https://wiki.gentoo.org/wiki/Intel#GuC.2FHuC_firmware
Thanks! Aha this is for gen 9ish onwards, my GPU is gen 3.
Exactly -- not sure I have many machines new enough for this to apply to.
The machine I'm typing on is the 2nd newest in the fleet -- it's a work box -- and it's an i7-8550U, an 8th gen "Kaby Lake" chip.
Re: Frame – Linux X server in Assembly
#50It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler.
There is evidence that LLMs are capable of making assembly that runs a great deal more efficiently than the compiler can manage on its own.
Do you have references ?