I’m not a compiler expert, an assembly expert or an ARM expert, so this may be wildly wrong, but this looks optimized to me.
The trick is that it’s doing both the add and the left shift in parallel then selecting which to use based on a compare of the two values with csel.
(To see this, rather than reading the code sequentially, think of every instruction as being issued at the same time until you hit an instruction that needs a destination register from an earlier instruction)
The add is stored in W9 but only read if the two arguments are unequal.
If the compare succeeds and the lsl retires before the add, the add is never read, so nothing stalls waiting for it and the answer can be returned while the add is still in flight. The result of the add would then be quietly discarded assuming it ever started (maybe there’s some magic where it doesn’t even happen at all?).
It’s not clear to me that this is power efficient, or that on many real cpus there’s a latency difference to exploit between add and lsl, so it may not be faster than just unconditionally doing the addition.
That said, it is definitely faster than the code as it was written which if translated to asm verbatim stalls on the compare before executing either the add or the left shift.
It's not. Why would lsl+csel or add+csel or cmp+csel ever be faster than a simple add? Or have higher throughput? Or require less energy? An integer addition is just about the lowest-latency operation you can do on mainstream CPUs, apart from register-renaming operations that never leave the front-end.
In the end, the simple answer is that scalar code is just not worth optimizing harder these days. It's rarer and rarer for compilers to be compiling code where spending more time optimizing purely scalar arithmetic/etc is worth the payback.
Far outside of my lived experience, but, here’s a take anyway.
Your priorities sound out of line with your current financial reality.
Concretely, you’re struggling with $890 in car costs that your current income depends on and asking how to escape homelessness. The crappy reality is that you need to maximize the safety of your one existing income stream ahead of nearly everything else. That means building up an emergency fund for car repairs.
Free cash flow, a well maintained car and a savings/emergency fund are the biggest lifelines you will be able to give yourself in the near term.
If you can get a programming job or a cheap laptop (sub $200 old Thinkpad on eBay) and start picking up some freelancing work you can do in a public library or similar, that’s amazing, but for now you’re really all in on your car and it sounds like you need to focus on that until it’s safe and stable.
Hopefully if you’re frugal, not too unlucky and do your best you’ll have more options in a few months.
This sucks and I really hope things get better for you.
I have actually done something like the situation that the earlier commenter described, and would still go back and give this advice to myself of back then.
I could add more examples that touch on these extreme situations, but I was trying to give examples familiar to most of HN.
I agree that some of the times people might not take good advice about a situation is when they're overextended, beyond the ability to reason about the situation, nor to have energy to invest in the research/legwork to get out of it.
And maybe it seems like there's no good option or way out -- but they're too overextended to reason about whether that's actually true.
In those times, if you're in the position of advice-giver, one of the best things you can do is to also help relieve some of that overwhelming/unsolvable pressure that's the most immediate barrier. Maybe the most common example is to offer crash space.
With the immediate barrier relieved, then you can pair that with now-viable advice, like they need to quit that toxic environment minimum-wage job, or do couples-counseling or break up with that troubled relationship, or move out of that bad locale, or try out for this better job opportunity you can refer them to, or whatever the bigger problem is.
“Markov Decision Process (MDPs)” appears on the first page of the table of contents and is defined on the page indicated there.
The term is also used/linked in the fourth paragraph of the Wikipedia page for Reinforcement Learning.
It’s much more a table-stakes for talking about what problems the field tries to solve term than an exclusive preserve of the deeply immersed term.
It’s a bit like a primer on machine learning using the word “regression” casually a few times before actually defining it. Good editing practice? No. An actual road block to learning? Also no.
The trick is that it’s doing both the add and the left shift in parallel then selecting which to use based on a compare of the two values with csel.
(To see this, rather than reading the code sequentially, think of every instruction as being issued at the same time until you hit an instruction that needs a destination register from an earlier instruction)
The add is stored in W9 but only read if the two arguments are unequal.
If the compare succeeds and the lsl retires before the add, the add is never read, so nothing stalls waiting for it and the answer can be returned while the add is still in flight. The result of the add would then be quietly discarded assuming it ever started (maybe there’s some magic where it doesn’t even happen at all?).
It’s not clear to me that this is power efficient, or that on many real cpus there’s a latency difference to exploit between add and lsl, so it may not be faster than just unconditionally doing the addition.
That said, it is definitely faster than the code as it was written which if translated to asm verbatim stalls on the compare before executing either the add or the left shift.