will have a size of 3 and an alignment of 1. Alignment is always power of 2, and size modulus alignment will always be zero. But alignment can be less than size, and size need not be a power of two, just have one power-of-two factor.
Struct of arrays have the potential to be much more memory efficient if the original struct had padding.
struct Foo {
int64_t i;
int8_t c;
// 7 bytes of padding for alignment.
};
A Foo array will have seven bytes of wasted space per element. That can add up, and can even blow away what would be nice caching effects if looking at both elements.
Access patterns do matter a lot to this, but it isn't as easy as describing one. Always profile.
All of those things are real problems with Google, and its decisions, but they don't seem to be signs of technical debt. I suppose they _could_ be, but they could all have plenty of other causes, many of which seem more plausible to me.
1. Decreasing quality of search and poor SEO technique responses may be caused by technical debt, but they also might be the results of strategic product decisions to make more money. That isn't technical debt, that's enshittification for money.
2. Similarly. If Google chooses to do worse spam filtering in order to get more advertising in front of its customers (for example), that's a bad product decision, not technical debt.
3. Constant drops on projects are simply resource allocation decisions, unless of course, they are dropped because they are too expensive to maintain. But there are a myriad of other reasons a product might be dropped.
4. A million more things.
There are numerous valid reasons to dislike Google these days (and I say that as an employee!), but tracing them all back to technical debt is finding the wrong reason for real problems.
Similarly with worse spam filtering.
Honestly I don't know how much the decrease in search quality is not just a reflection of the decrease in web quality in general. The web used to be full of indepent writers in publicly accessible websites like blogs and forums. So much of that has moved into walled gardens that are just not crawlable.
A lot of the walled gardens are recent. Scarping massively increased due to the LLM era. There's always been mitigations, but the scale of the issue was different.
But the problem I'm talking about is SEO (search engine optimization). It is the reason for things like a page telling you about a recipe also has a long story about their grandma and how this recipe brings back all those memories in vivid details they share with you. Is it dwell time that matters? Is it more words? More "context"? I don't know, but I know that those sites get better traction. It's no surprise that writing a good search algorithm is extremely difficult. Especially as what's a measure of something useful in one context may also be a measure of shittiness in another. But ultimately would that not fall under tech debt? Making the wrong decisions, making poor approximations, etc. It's also a constant battle as websites want to get their results to the top. I'm not trying to say it is an easy task, but I think Google is on the losing side of the battle and decisions like LLM generated answers don't seem to be addressing the underlying issues and more seem like short term solutions that help the stock go up "because AI". Hell, this is CS, how often do we praise someone for being a pioneer in VR, and in blockchain, and in AI? Why is having those three things on your CV seen as a green flag instead of a red one?
> but they don't seem to be signs of technical debt
> they also might be the results of strategic product decisions to make more money. That isn't technical debt, that's enshittification for money.
> that's a bad product decision, not technical debt.
| technical debt refers to the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one.
- Wiki[0]
I think these suggestions fall under this category. At the core, technical debt is myopia. "Technical" refers to more than code. Ultimately, the bad code is generally the result of poor decision making. "Tech debt" is a broad word, but I don't think the things I mentioned here are in direct contention with the wiki definition nor the examples they give under "Frequent causes of technical debt". It's all about planning, and that process begins even before any code is written.
If you have never tried to collect on a judgement from small claims, it is extremely difficult if the target just doesn't want to play ball. I have tried, and they were just like, "Yeah. No. Go get the court to enforce it."
Filing those claims is time consuming and expensive, and if they fight or ignore, it ends up costing more than your claim is worth, even not including time.
"Even Apple’s LLVM fork lacks scheduling annotations for Apple Silicon. How am I supposed to write efficient code when Apple doesn’t bother to tune their own compiler?"
In addition to its public fork of LLVM, Apple also keeps a very private fork where (one assumes) they keep all the really juicy stuff.
I agree that it is frustrating not to have the data, but don't confuse "I don't have the data" with "no one has the data".
There are multiple types of warrants. All types are "real", but they convey different authority and different requirements upon both the arrestee and the arresters.
It is both rational and legal to insist that law enforcement stay within the bounds of the authority the specific type warrant they obtained. ICE civil warrants grant different authority than every-day federal arrest warrants. That ICE is abusing that authority is no reason to capitulate to it.
> the parts that need rebuilding are the parts that read those files when they were last built...
...and the transitive closure of those parts, which is where things get complicated. It may be that the output didn't actually change, so you can prune the graph there with some smarts. It may be that the thing changed was a tool used in many other rules.
And you have to know the complete set of outputs and inputs of every action.
struct Foo {
};will have a size of 3 and an alignment of 1. Alignment is always power of 2, and size modulus alignment will always be zero. But alignment can be less than size, and size need not be a power of two, just have one power-of-two factor.
reply