Not to say it isn't a great game, it has managed to steal a great deal of my time. With the caveat that its very unpolished and clearly straining under a load bearing amount of duct tape
265 karma · joined December 6, 2023
Not to say it isn't a great game, it has managed to steal a great deal of my time. With the caveat that its very unpolished and clearly straining under a load bearing amount of duct tape
But otherwise chains of microwave links does get much closer to c in applications where you want absolute lowest latency (or much more commonly, when digging a fiber line is too expensive)
Of course, it depends on the altitude of the satellite but speed of light in a fiber optic is only ~2/3rds of speed of light in a vacuum so you can afford some detour
Surely it isn't cheap, but given the price of the hardware, does it add substantially to the total cost of a datacenter?
My grandmother keeps a little notebook with detailed instruction on how to do things such as sending a message on facebook or pay a bill using netbank.
For a lot of things, the choice isn't going to be doing it herself or giving orders to the computer. Its going to be not doing it or giving orders to the computer.
Even if it will look very inefficient to people such as you or me
And if my experience from embedded development is in any way transferable, they're probably fairly spread out and probably takes a fairly big chunk of address space too.
It's not about lights, it's about electricity always being available. And well, always having power available (for domestic, but also for expensive production facilities that looses money while idle) using renewables is a lot more expensive than generating most of your power with renewables
This allows it to split complex instructions into multiple operations instead of having dedicated hardware for it.
High performance cores can also do the opposite trick of "fusing" two instructions into a single uOp: The usual example is compare-and-branch
For the vast majority of non-number-crunching code any theoretical difference between instruction sets vanishes in the noise of core design.
Not to say there isn't war, but they're small wars with a million deaths being a big one.
More people died in Second World War[1] than in all wars since then combined. If not for the Russian Civil War and WW2, the same would probably true for the Great War.
War is terrible, but the fraction of people who died in wars the last 75 years is substantially smaller than the 75 years before that and I do think that is worth celebrating. I am not confident this will hold for the next 75 years
[1]: https://en.wikipedia.org/wiki/List_of_wars_by_death_toll
With the exception of (sigh) newlines, I surely hope your text editor accurately records the characters you paste into it. This job isn't different just because the characters are strange, multi colored ligatures.
Edit: As long as you work in UTF-8 that is, but you have to go out of your way to use any other encoding as an interchange format these days, even if alternative internal encodings aren't uncommon-
x86 assembly isn't something I'm familiar with (and I should really get back to $dayjob), but I will mention the existence of emoji-test.txt [1] in case somebody wants to try and mine more executable sequences. It might be worth paying attention to the minimally-qualified, unqualified and component lines, which can be added and removed semi freely. No idea if they actually correspond to useful byte sequences.
[1]: https://www.unicode.org/Public/emoji/latest/emoji-test.txt
The big tradeoff you're making is that you have significantly less time to run your optimizer, since not everybody has a beefy machine or the patience to wait a day for their browser to start first time.
You could try doing optimization ahead of time, but I think (I could be wrong here) you would inevitably end up adding in some CPU assumptions if you went much further. This also somewhat conflicts with an advantage of VM based execution, that new optimizations apply to old binaries.
I'll also note that hand rolled assembly/SIMD code still beats compilers at the extreme end and you would either have to throw that away, or get all the disadvantages mentioned above without all the advantages
And however much you can say about the current US Administration, I don't think they're prioritizing bombing civilians over military targets.
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.
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
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.
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.
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_...