Live data from Hacker News

Frame – Linux X server in Assembly

isene.org

111–115 of 115 posts

Re: Frame – Linux X server in Assembly

#111

Earlier quoted context omitted.

It will make the code slower. Writing maintainable assembly is at odds with writing fast assembly in most circumstances. A key optimization that's hard to pull off is inlining. An optimizing compiler can see that a method is small enough that it can be pulled into the caller, it can then further eliminate from that smaller method branches that can't be executed due to the nature of the caller (Imagine calling a funct…

Simply no. This is a catchphrase, a buzzword from compiler companies. We have seen here on HN time and time again many articles showing the truth to be the opposite of what you've said. It's time to put to rest the nonsense that compilers optimize better than humans. Here a few examples I've talked about: https://news.ycombinator.com/item?id=8508923 https://news.ycombinator.com/item?id=36618344 https://news.ycombinat…

Simply yes.

It's true that in specific functions a human can do better than a compiler at optimizing for a target platform (sometimes, not always). That's a place where someone could reasonably drop down to assembly and get better performance.

But the case I'm specifically pointing out, one of inlining, is something that compilers do better than humans. This isn't "propaganda from compiler companies" (btw, not a thing. The most common and popular compilers are opensource and not owned by any single company). There are other cases like this where compilers are just more likely to get things right than humans are. They have a lot of heuristics about common assembly patterns that few humans can be expected to have memorized.

Each of the cases you pointed out are cases where the compiler does a bad job at optimizing a single function for whatever reason. They are not examples of a whole application written in assembly outperforming compiled high level languages. And each of the cases almost certainly took the human a considerable amount of time to figure out and prove their solution was better than the compilers.

What you've done is cherry pick when compilers fail and you are using that as evidence that they always fail.

Compilers sometimes fail, something I'm happy to admit. But on the whole for a whole application the compilers will get a lot more right than a human possibly could because they can output unmaintainable assembly.

Re: Frame – Linux X server in Assembly

#112

Earlier quoted context omitted.

It's just you. Everything that can be done with LLMs is better than without. Why use tooling at all when you just can use a LLM? Maybe just make the LLM generate machine code for your tager directly. Just like making digital systems that are "better" than analog ones from the past because of digital.

That hasn't been my experience at all. The quality of these things is absolutely terrible. Maybe if you have no taste and no actual skill, you can't tell the difference. The fact that you have chosen to say this about generated amd64 assembly is telling. This is a terribly pointless exercise. Further, the llms are bad at more niche languages especially. Even experimenting with having them write C, which is quite a bi…

Your sarcasm detector is defective.

Re: Frame – Linux X server in Assembly

#113

Earlier quoted context omitted.

That hasn't been my experience at all. The quality of these things is absolutely terrible. Maybe if you have no taste and no actual skill, you can't tell the difference. The fact that you have chosen to say this about generated amd64 assembly is telling. This is a terribly pointless exercise. Further, the llms are bad at more niche languages especially. Even experimenting with having them write C, which is quite a bi…

Your sarcasm detector is defective.

It's probably just that I've seen too many weird comments on here lately.

Re: Frame – Linux X server in Assembly

#114

It'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.

"Congratulations! You've reinvented compilers, except slower, unpredictable, hopelessly proprietary, and you have to pay to use it." (Oh, and the "compiler" will also refuse to generate certain types of programs.)

This "hopelessly proprietary, and you have to pay to use it." is what scary me most.

How often there are stories "Google/Apple/Microsoft [but mostly Google] deactivate my account for some stupid reason and I lost everything: my business, my tax data, my client data, my developer account and access to my apps, everything".

With LLM/Coding agent providers it will be worse!

Re: Frame – Linux X server in Assembly

#115
post #83
post #30

Earlier 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.

Yeah, I've had it work on an X11 server using a Ruby X11 protocol implementation instead of libX11, and it just rushed ahead and added support for a bunch of missing requests and responses. None of that is hard - it's all very well documented - but it's tedious. My terminal emulator using the same binding also started out hand-written but Claude overhauled that too recently and it knows vtxx escape codes far better t…

You wrote your own terminal emulator?
Post reply on HN