joha4270

You're not the first person to say so (and I don't mean to dispute it), but I have never been able to find a clear answer for /why/ those processes are incompatible.

Is it built in different silicon, is it physical steps that's incompatible (ie its actually incompatible), is it different physical preparations that needs to be made (making it economically infeasible to combine)

I cannot help but wonder, even if the answer doesn't change anything in my life.

That's a negative framing and while I'm not going to call it /wrong/, but world population is increasing so of course our energy usage is going to increase too.

If you scroll a little further down on your linked page, you will encounter another[1] graph, with renewable fraction of primary energy production and its steadily falling everywhere but the gulf states.

We're probably doing too little, too late, but my read is actually that we're moving in the right direction even if there is significant inertia to overcome before emissions actually start decreasing.

[1] https://ourworldindata.org/grapher/fossil-fuels-share-energy

Could you point me towards the kind of code people programming in dynamically-typed languages produce?

I have lived in statically typed languages almost all of my life, and even when I don't, I pretend I do, just without having a typechecker. So I'm very curious about what I'm missing.

Not going probably never even crossed his mind. Social status in Roman society was very strongly influenced by military success. He was a previously successful general.

Historically (with all the accuracy you get when you summarize all of history) raising an army and not leading it was effectively telling everyone that you should be replaced by whoever did lead it.

Yes and so we use HBM for AI (among other things), but that's an exception. For things like games or displaying webpages, its not very important and we generally don't put HBM into things for that.

I think you have misplaced a unit somewhere, because that would be a truly absurd amount of corn.

A quick trip past wikipedia [1] suggest the figure was 383.6 million tonnes in 2021, which is still approximately a thousand kilograms of corn per person, which is still a lot (more than my annual consumption, that's for sure)

[1] https://en.wikipedia.org/wiki/Corn_production_in_the_United_...

Your feelings are obviously your own, but a Starlink terminal isn't that big and can transfer quite a lot of tokens.

Every single satellite has sufficient cooling for its power production, otherwise they would be frying. Waste heat from a GPU is not materially different from waste heat from an amplifier. That's not cooling entire racks, but I don't think anybody talks about putting entire racks in space anymore.

I'm very much pro nuclear, but a solar cell in a sun synchronous orbit is pretty great too and eliminates most battery requirements

I very much doubt the economics of this makes sense, but I don't think a lot of your criticism is valid.

The satellite moves, so every orbit it captures a globe spanning strip that is 50 miles wide (here uncritically accepting the 50 miles figure).

And the carrier isn't going to be in the middle of the pacific, its going to want to launch strikes, so its going to be within (say 500 miles) of Chinese military targets, which does narrow down the size of the haystack somewhat.

But yes, this is a significant challenge. On the modern battlefield it is usually significantly harder to find something than to kill something after you have found it.

So, is there anything about GPU's in here right now?

I didn't actually finish Act 2, but it seems to end in a conventional processor with the GPU first coming after another two acts currently under construction.

What is so unbelievable about that?

Sure, its going to take decades to actually make the transition and the UH-60 will remain in service for decades more after that in less demanding roles. I expect by the time this finishes, the MV-75 will be considered another workhorse, if maybe slightly fuzzier and the UH will be an antiquated platform.

But ultimately they both solve the same problem, moving stuff from A to B in rough terrain fast. But with the ever increasing amount of reconnaissance assets, A needs to be further behind the frontline and so range and speed needs to increase beyond what you can manage with a pure helicopter.

The L2 already keeps track of what lines are somewhere in L1's for managing coherency.

Divide the cache into "meta-caches" indexed by the virtual bits and treat them as separate from the L2's point of view. Duplicate the data and if somebody writes back invalidate all the other copies. The hardware already exists for doing this on any multicore system. Sure, you will end up duplicating data sometimes and it will actually be slower if you're actually writing to aliased locations. But is this happening often enough to be a problem compared to generally having a bigger cache?

It sounds to me like an engineering tradeoff that might or might not make sense, not a hard limit which at least was what I think was being asserted. But as I also said, L1 sizes hasn't increased in a while and smart people are working on it, so there is probably something I don't know.

Can you not take some of those virtual bits and get more buckets that way? I am sure it will make things more complicated if nothing else by them possibly being mapped to the same physical page, but it doesn't sound like an impossible barrier. Maybe something terrible where a cache line keeps bouncing between different buckets in the rare case that does happen, but as long as you can keep the common case as fast...

Otoh L1 sizes hasn't increased since my first processor, those CPU designers probably know more than I do.

I'm sorry, I'm clearly missing something but why would page size impact L1 cache size?

Alas, no matter how the bits that makes up my bank balance looks, in practice its still a single point of failure where I might simply lose access to my money if the right service is down. Cash has much better uptime stats, even if it can be inconvenient to carry around.

The guts of a LLM isn't something I'm well versed in, but

to get the first N tokens sorted, only when the big model and small model diverge do you infer on the big model

suggests there is something I'm unaware of. If you compare the small and big model, don't you have to wait for the big model anyway and then what's the point? I assume I'm missing some detail here, but what?

More or less, yes. Of course, defects are not evenly distributed, so you get a lot of chips with different grades of brokenness. Normally the more broken chips gets sold off as lower tier products. A six core CPU is probably an eight core with two broken cores.

Though in this case, it seems [1] that Cerebras just has so many small cores they can expect a fairly consistent level of broken cores and route around them

[1] https://www.cerebras.ai/blog/100x-defect-tolerance-how-cereb...

Whatever our human laws and morality says about right and wrong and fault, the laws of physics usually judges the car a winner when it hits somebody.

Placing yourself somewhere where pedestrians are not expected (non-residental road) mostly hidden from oncoming traffic for an extended period is putting yourself in undue risk.

All of Mr. Devereaux's work is wonderful including the series you linked, but I think that one its overly focused on the household. I think his two part series on "Lonely Cities"[1][2] is a lot better at giving you a feeling for a city. It is both less in depth and in that one he spends half his time complaining about how Hollywood gets it wrong, so of course YMMV.

[1] https://acoup.blog/2019/07/12/collections-the-lonely-city-pa... [2]:https://acoup.blog/2019/07/19/the-lonely-city-part-ii-real-c...

While this PDF might be new, Akin's Laws of Spacecraft Design dates back to 2003.

https://web.archive.org/web/20031101212246/https://spacecraf...

At least in my case, I got curious about the strength of /u/dustbunny's denouncement of Godot+C#.

I would have have put it as a matter of preference/right tool with GDScripts tighter engine integration contrasted with C#'s stronger tooling and available ecosystem.

But with how it was phrased, it didn't sound like expressing a preference for GDScript+C++ over C# or C#++, it sounded like C# had some fatal flaw. And that of course makes me curious. Was it a slightly awkward phrasing, or does C# Godot have some serious footgun I'm unaware of?

I don't see how this article could possibly support the argument that C# is slower than GDScript

It compares several C# implementations of raycasts, never directly compares with GDScript, blames the C# performance on GDScript compatibility and has an strike-out'ed section advocating dropping of GDScript to improve C# performance!

Meanwhile, Godot's official documentation[1] actually does explicitly compare C# and GDScript, unlike the the article which just blames GDScript for C#'s numbers, claiming that C# wins in raw compute while having higher overhead calling into the engine

[1] https://docs.godotengine.org/en/stable/about/faq.html#doc-fa...

Are there technical reasons to prefer GDScript over C#?

GDScript is undoubtedly better integrated in the engine, but I would have expected C# compare more favorably in larger projects than the game jam sized projects I have made.

I'm unsure if you're making a joke that flies over my head, but no Greenland is Danish, not Dutch.

A lot of people have made careers out of telling you that it's a failure, but while not everything about the F-35 is an unquestionable success, it has produced a "cheap" fighter jet that is more capable than all but a handful of other planes.

Definitely not a failure.

And the fact that superman can fly is evidence that people are lighter than air. Otherwise it wouldn't happen.

The costs (in money and energy) of the infrastructure to mine another solar system would pay for a lot of R&D to synthesize whatever it is here in our solar system.

Unlike the other poster, I don't think interstellar mining needs finding, I'm perfectly happy to lean back and enjoy the show. But whatever they mine would have to be very magical indeed to not be cheaper from any other process.

I have seen it claimed that's a way of monetizing free phone apps. Just bundle a proxy and get paid for that.

They're not dealing with a pressure differential. Or at least I don't think so.

I don't think the Journalist who wrote the article understood the technical details, but from digging a little at their website I think what's going on is they're moving heavy brine up and down, all of it equalized with local pressure.

Despite them describing it as pumped hydro, I think its better framed as a cousin of the "chunk of concrete suspended over a mine shaft" style gravity battery. Replace the mineshaft with water and the concrete with salt.

That link isn't really a source for residential 3-phase power.

Almost every electrical network is 3 phase distribution, the matter under debate is if you bring every phase to each house, or if a phase reaches every third house.

Anecdotally I have never seen an electrical panel without three phases, but when I went looking it was like trying to find a source for the fact the sky is blue.

So, a Systolic Array[1] spiced up with a pinch of control flow and a side of compiler cleverness? At least that's the impression I get from the servethehome article linked upthead. I wasn't able to find non-marketing better-than-sliced-bread technical details from 3 minutes of poking at your website.

[1] https://en.wikipedia.org/wiki/Systolic_array

So, either me or the author has misunderstood something. Memory allocators are not among my specialties, so it might very well be me, but:

Being able to pre-allocate objects of fixed sizes and then offer up available objects to callers is much less work than allocating individual objects on demand.

At least, from reading his included code snippets I got the impression that what's actually happening is that it has multiple allocators to avoid fragmentation and that everything actually related to actually allocating does actually happen on demand.