I wonder what the additional power draw of these features would be. Parenthetically, I wonder often about the energy impact of all these HTTPS localhost links, and is there a point where defense-in-depth has to give way to other concerns?

But yeah 95% of the consumer market don't care about this and it's only adding unnecessary costs

Consumers were always capable of disabling it themselves if they didn't need it. The performance impact seems to be ~3% on average, impact on power consumption is probably similar or less since any extra delay idling can destroy performance while not having as big impact on power consumption. https://www.phoronix.com/review/amd-memory-guard-ram-encrypt...

Any extra cost would be mostly due to power consumption and testing that the feature works (which they probably don't do for consumer skews anyway). The area of silicon used by the feature is probably negligible, from the manufacturing cost perspective it's cheaper to avoid any unnecessary design differences between skews.

Despite it being hardware accelerated I've always wondered what the energy cost for HDCP encryption on HDMI connections is.

Just whitelist the caller ID and have the originating network guarantor

The second part is the hard part and requires coordination

It wouldn’t be expensive or especially hard to do but there is no payoff for the network. Remember they make money off scam calls too

Since as long as I can remember these organisations have been optimised for profit, not for GAF and that’s why they’re being savaged by regulation and OTT competitors now

There has been no market forces compelling them to do this and until recently when it got really bad, no political or regulatory forces

tl;dr na bro

> not really sure what would one win

Internet pointz

I have an old, slow GPU setup that has nearly 100gb of VRAM

I had been trying to fill this up with big models but it doesn’t seem like these give a good return per Gb

I’m looking at that and wondering would I be better off running multiple such models in parallel. It would probably be a better way to load balance across SLI.

My guess is the scaling will be more “mythical man month” than “no more free lunch” - the interaction of models resembling social dynamics moreso than multi-core setups.

Given that these actors are largely homogenous in culture and incentivising, and coordination overhead is drastically reduced.

Commonly we consider optimal team size to be between 3 and 7 and Brookes’ maximum team size is around 10 or so before the system fails. It should be possible to blow way past those numbers and still experience increased gains in productivity as long as you can keep all your instances stoked.

The shortest distance between two points is a straight line?

A sheet of paper approximates a Cartesian plane probably more closely than most things we can fold

Therefore a fold will always be in line with the theoretical 2D plane and thus will be the shortest (straight) line.

Arguably cache concerns are distributed computing concepts moving closer to the core. Same with concurrency semantics. These were far more exotic concepts when the fallacies were first written.

Very easy to hit the 3GB limit imposed by 32-bit architecture for any non trivial data processing app but luckily 64-bit is firmly established for at least 10 years

Indeed, the Java mobile platform had power consciousness baked in 25 or so years ago.

Was big before the AMD athlon. First commodity GHz processor was also the first to make obscene power demands.

> No mention of cause and effect, or the order in which different nodes perceive things happening?

8. The network is homogeneous

Often misconstrued as a recapitulation of “there is one administrator”

A homogenous system, such as a single node Java application, for instance usually provides very clear semantics for this.

Micoserices or Monolith. It’s like being caught between the devil and the deep blue see. It’s a pity domain sockets never took off but I guess TCP/IP is the only truly cross platform IPC mechanism …

Aren't Windows's named pipes very similar?

I believe so.

I don’t think either that or domain sockets are quite as ubiquitous as TCP sockets though.

The issue I see with domain sockets is that although they may be supported for example by spring, you can’t rely on a consistent cross platform experience which is perhaps (anachronistically?) a core ethic of the Java community.

I would favour domain sockets as to make a component go from being embedded to networked would require a small but significant implementation step.

But established best practice unfortunately disagrees with me.

The more interesting thing on Windows would actually be COM, which is something like Java interfaces but for native code, that are optionally cross-process.

In my recollection COM became ActiveX which fell down the distributed objects hole along with CORBA because it embodied many of these fallacies.

COM still exists. That is like saying Java fell down the Spring framework rabbit hole. It did, but you can still use Java without using Spring.

It still exists? Like Java still exists

It still exists and it's used by windows APIs, even recently designed ones