> Most developers, in Java and in most other languages, do not consider the cost of every field
Are you saying most developers are bad? It’s the equivalent of most employees don’t consider the cost of every action to the employer and is how company spend blows up.
I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance. Even in performance-sensitive applications, only a minority of the team are working on the hot spots.
And speaking about costs, knowing what to optimise is the key to software performance. Improving the performance of an operation by 10000x will improve the performance of your program by less than 1% if the operation is only 1% of the profile to begin with. So I'm only saying that most developers don't work on code where the layout is very significant, but some certainly do.
> I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance.
I've heard this theory before. This isn't just about performance and I don't buy it.
I've seen too many examples of this is just a temporary solution so it doesn't matter. >3 years later that "temporary solution" was still there and at the heart of many operations yet it's now to hard and too costly to fix.
I've also seen the this is a quick hack. No 1 uses it. It doesn't go through any hot paths. All good. You know what happens? Years later, every service literally goes through it. Again, it's too hard to fix.
In the real world these "theories" are really loose. The only fix is every should be aware of what they are doing and do it properly. The it might not happen, etc mindset is dangerous.
This has absolutely nothing to do with what I said. I wasn't referring to people who think that program performance doesn't matter (although I'm sure there are many of those) but to people working on code that either doesn't impact the overall program's performance much or it does but not due to layout. The number of developers working on code where layout is a major contributor to performance is relatively low, and this includes people working on programs where layout does impact performance significantly (because even in such a program, that particular hot path is not touched by every developer).
> but to people working on code that either doesn't impact the overall program's performance much or it does but not due to layout
And that's the problem. Who decides that? How do you know and that's my problem with it. Things always change. It's always temporary, not in the hot path, doesn't matter etc until it does.
So what is considered "doesn't impact" often comes back to bite.
That is why profiling is the only way to good performance. It's what lets you know what matters, and it's the only thing that does or can. I've been doing low-level (as well as high level) programming for more than 25 years, and I don't know in advance what is more efficient than what. An operation that was inefficient in the program I wrote yesterday under high contention or bad branch prediciton could be efficient in the program I'll write tomorrow. I can only know that if I profile my specific program (and when writing code for different architectures, I need to profile my program on all of them, because what's efficient on x86-64 may be inefficient on Aarch64 or vice-versa). The days we could tell that something is efficient or not, except for the obvious cases, are gone. Computers, at both the hardware and software infrastructure layers, don't work like that anymore.
If your profile shows you a hot path that's responsible for 90% of the time your program spends, any second optimising anything outside of it harms your performance, as it's a second spent on low ROI instead of high ROI.
Then what is it that you are saying? That I should use JMH to determine the best layout for my helper class that will be initialized 3 times? Like most of the software (by line of code) is boring plumbing from one service to another with some dumb business logic sprinkled in. Something like a single config option for your database driver matters orderS of magnitude more in many types of applications.
It's much more niche to work on stuff where such changes actually matter, like much much more people write boring CRUD backends than those who write physics simulators and audio processing pipelines combined.
Consider the cost of every field, of every action.
Understand the language, the memory model, etc. Don't do "it works on my machine". Understand the architecture, layout, implications etc.
E.g. if you need an int and not a long you should clearly use an int. Wait until you do this every time and things blow up and it's too "hard" to change.
It's called be aware of your actions. Take responsibility of what you do.
> It's much more niche to work on stuff where such changes actually matter,
Not true and that's why there's so much wastage.
A lot of things matter. I've seen more times than the other way that simple awareness and changes can pay for my salary, e.g. not updating to newer EC2 instances when they get released in AWS. Even in a mid size company that was hundreds to thousands in savings.
I've seen CI/CD pipelines where the developers never considered caching and it takes hours to run. It's not free. When every PR and update (hundreds a day) triggers a run it's a cost and a cost not just on machines but developer time waiting.
I can list a lot more examples and everyone in the chain can contribute.
> Consider the cost of every field, of every action.
This runs counter to most modern software performance principles. Thanks to modern hardware optimisations (cache hierarchy, ILP, branch prediction), modern compiler optimisations (aggressive inlining that leads to a much wider view), and increased concurrency, the notion of some action having a cost lost most meaning about 20 years ago, and increasingly since. Because how fast some action is now depends on a much broader context of what else is going on in the program (and the machine), action X can be faster than Y in one program and the same or slower than Y in another.
Because it's nearly impossible to generalise (and so what was true in your previous program may not be true in your current one unless they're nearly identical), the advice is to first profile your program so that you know how fast or slow different parts are in the context of your particular program and then to focus the optimisation efforts on the hot paths in your program. Otherwise, you may end up spending effort where it makes no difference, and this comes at the cost of optimising what matters, overall harming performance.
Taking responsibility means being smart about directing your resources to where they can have the most impact.
And java uses very little CPU compared to most other languages. It's right after manual memory managed languages like C/C++, and is the first managed language according to a paper about how "green" each language is.
But there is a semi-fundamental tradeoff here, you either use more CPU to use less memory or the reverse. Java can be dynamically configured for either end (though defaults to less CPU by not running the GC unnecessarily).
> For example, AWS is still not part of the Bandwidth Alliance
Why would they be. That list hasn't really been growing. It's not too useful and gets tied to Cloudflare.
Names like Azure and Google you see there don't really offer free bandwidth either.
> I wonder why they would only do this for private networks
It is not just private networks but those they specifically peer with = has physical cables / networks connecting. This makes it well maintained and "cheap".
Do you hire people to do work or pretend to do work?
Give them the tools. Measure normally i.e. did they work faster with new tools?
If things are good and there's support people will use it to make their lives easier. That should be natural. Forcing them on it with arbitrary rules will just give you fake results.
Fair - but I did not mean this as in "control the team". It's more around how can we can push the boundaries. We came up with a framework internally. But I was asking muyself if that is the right / best way. Maybe we share what we have.
> Kimi 2.6 is a 1 trillion total / 32B active parameter model that's something comparable to Sonnet.
No it's not. On some rigged paper maybe. Some such benchmarks say all models group together, which they clearly do not.
> Sonnet's API pricing is $5 in, $15 out per million tokens. Deepinfra serves Kimi at $0.75 in, $3.50 out, and about the same at openrouter. So you're looking at a 4-7x multiple that Anthropic is charging compared to market rates that any plebe can get with a credit card.
That's not saying much. You can get "cloud" at AWS and you can get a VPS. There is likely a 10x difference. It's not "same". Whilst AWS costs more they also don't have 7x margins similarly.
Step 2, don't use "leaving the company" as a euphemism for "getting laid off", as the former implies employee agency and choice they don't actually have.
The entire post is a green-beige sludge of corpspeak, euphemisms, and AI slop. Who fucking talks like this anyway?
Just had to read few more paragraphs : "the use of disused former industrial areas is favoured. In this case there are no additional burdens, but rather the law proposes bureaucratic simplifications."
It's even in bold "the use of disused former industrial areas"
Indeed, I don't quite understand the issue. I get that the data centers are big and expensive, but they must be nothing compared to any ordinary heavy-industry site right? In all aspects: space, pollution, energy, water...
reply