this post was submitted on 20 Mar 2025
523 points (98.5% liked)
Greentext
5900 readers
1077 users here now
This is a place to share greentexts and witness the confounding life of Anon. If you're new to the Greentext community, think of it as a sort of zoo with Anon as the main attraction.
Be warned:
- Anon is often crazy.
- Anon is often depressed.
- Anon frequently shares thoughts that are immature, offensive, or incomprehensible.
If you find yourself getting angry (or god forbid, agreeing) with something Anon has said, you might be doing it wrong.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This isn't really true on modern systems anymore. Lower level languages like C and Rust are more or less just as performant as handmade assembly.
Sure, compilers have come a long way since then and there is vanishingly little you'd write in assembler now-a-days, and you'd probably drive yourself mad trying to do so on anything more complex than a microprocessor.
No disrespect, but I love that folks from the UK always say "assembleuh" like they were on their way to saying "assembly" and got spooked halfway through
Yup. And our processors are a lot more powerful, so the tricks you'd do in assembly to eek out performance just don't matter anymore.
I know it's a typo but "eek out performance" has made me picture someone programming a little ghost to spook the rest of the code into running faster
I think it was a subconscious letter swap. :) I'll keep it because ghosts.
That's not because of hand-written assembly vs compilers, that's because everyone and their dog wants abstractions up the wazoo. You have frameworks on top of frameworks, and no compiler can efficiently sift through that nonsense.
I'd really like to see a shift back toward compiled languages like Rust to cut through the bloat.
Yup. I feel that so much at my day job. We use Python on our BE, and we have so much waste on top of that
For example, we have some low level code for a simulation (not Python), and we ported it to Python, and we noticed the code spent a ton of its time doing bubble sort. So our Python implementation ended up being competitive by just making reasonable high level choices. We had a paginated sort + filter that loaded all possible records into RAM and did the logic in Python instead of SQL (fixing that dropped request time like 80% on larger queries).
We have so much more crap like that, it's not funny. But I'm ticking them off one by one by inflating my estimates a little to allow for refactors.
Yes that's what I was referring to.
It's some sort of out of order execution and branch prediction that does it. The thing you're usually waiting on the most is IO.
If you need to precisely know exactly how many instructions are running in a loop (ie super duper embedded)