weilawei

weilawei, 1 day ago

@LouisIngenthron I find it super hard to get motivated about games that require intense, careful strategizing to succeed.

Caveat that I play mostly strategy/tactics when I play anything at all these days, but I play fast and loose.

It becomes less interesting if I -have- to work at it; I'd rather be programming if I'm going to put in that kind of effort.

weilawei, 1 day ago

@JapanProf We've been deskilling our workforce for decades. That's a management decision, by design, and even the word that the head honcho types like to use for it.

weilawei, 1 day ago

@StillIRise1963 It's not like they had to take money from a foreign government. And it's a little weird about the seeming lack of concern and fire under the butts of the rest of the, presumably "honest", politicians.

weilawei, 1 day ago

tl;dr: corporations will steal your shit, piss on you, insist it's raining, and then try to rent you the poncho they stole from you, but only after they cut telemetry holes in it.

weilawei, 2 days ago

When I say that our continued existence is incompatible with their remaining billionaires, it's stuff like this. Just one example of so many.

weilawei, 2 days ago

This shows how toxic billionaires are:

"The next morning, she read the results to him and several colleagues — positive for PFOS. As Hansen remembers it, Olsen looked triumphant. “Those samples came from my horse,” he said — and his horse certainly wasn’t eating at McDonald’s or trotting on Scotchgarded carpets. Hansen felt that he was trying to humiliate her. (Olsen did not respond to requests for comment.) What Hansen wanted to know was how PFOS was making its way into animals."

weilawei, 2 days ago

"Almost as soon as Hansen placed her first transparency on the projector, the attendees began interrogating her: Why did she do this research? Who directed her to do it? Whom did she inform of the results? The executives seemed to view her diligence as a betrayal: Her data could be damaging to the company."

This is how they think. These people are sociopaths, and we need them out of power.

weilawei, 5 days ago

I threw together a godbolt example with the sample code from that link to count instructions. Pretty nice.

(Ignore the unsafe stuff; I'm just counting instructions in the one function decode(), and wouldn't put all that unchecked stuff in production code.

EDIT: Which is probably good since my code--not theirs--has a pretty bad bug in it that doesn't affect instruction count. That's what you get without tests.)

https://godbolt.org/z/48j1bjnce

weilawei, 5 days ago

Where SHTF is when you run out of physical RAM to page in the virtual allocations. Until then, it's all gravy.

For instance, this box has no swap. It's disabled. If I actually ran out of memory for the kernel, it would panic and hard lock.

Fortunately, this is very unlikely in modern systems, and the OOM killer will terminate misbehaving userland apps--and this is a good thing, because it rescues the part of the system that matters for continued operation.

weilawei, 5 days ago

One of the things you should do when stress-testing code is deliberately run it up against the OOM killer. Make sure there's no landmines for future runs.

For testing, I want to use completely unreasonable workloads that nobody would ever actually want to run in practice and make sure it runs fine anyway.

If they do, then they probably have bigger issues than the performance of my code.

weilawei, 5 days ago

Writing fast code doesn't have to be rocket science. It mostly consists of

a) doing things in a direct way, in as straight a line as possible, and

b) measuring to make sure something really round-about isn't being done.

I'd argue that's just the basics, not premature optimization (an overabused quote, imo).

After measurement, if the direct way is still too slow, then you can write a faster version. Just don't sacrifice basic efficient movement.

weilawei, 5 days ago

Most modern compilers will optimize away simple inefficiencies in your code, if it's very direct/straight-line. It's when you get really clever (and don't get it right) that the compiler starts spitting out terrible code.

It is, in fact preferable, to write the less efficient version iff it's that much clearer and you have checked the output to make sure it was optimized.

That also implies you should understand the layers below the language you're working in. The stuff your code runs on.

weilawei, 5 days ago

Anything that's too clever to be turned into the clever form by an optimizing compiler should probably have more documentation comments than actual code.

I can tell you that comparing bytes to -65 is a fast way to differentiate UTF-8 leading bytes from continuations; but that's a trick no compiler will do for you, because it involves treating one kind of data as another, seemingly unrelated type. So that code warrants a big comment explaining how it works.