It's also due to technical and economic reasons. Tiny reactors require highly enriched fuel and have worse neutron economy and thermal efficiency. You can't use the same low-enriched fuel in a tiny reactor that you can in a typical (hundreds of megawatts or larger) commercial power reactor.
In a big commercial power reactor, fuel costs are tiny relative to the total system costs. If you used a tiny reactor like the Kilopower [1] to power a single home, the cost of the highly enriched fuel alone (upward of $50,000 per kilogram, 28 kg in a unit) would be orders of magnitude more expensive than grid-supplied electricity.
I've never heard that before. I don't think politics would stop a fleet of small 50-100MW replacing a 1GW reactor, and that's certainly not the opposition to SMRs now.
It's actually both economic and technical: the technical side makes smaller reactors less economic in terms of efficiency. Thermal generation benefits massively from being really really big.
This is exactly the situation for desktop games right now, something Epic is profiting immensely from. It's an extremely annoying situation for users, having a dozen launcher/store apps around contributing to bloat.
That's exactly the competition that keeps PC from having the hiked prices the likes of Switch/XBox/PS5 stores and having to pay $15/mo to play games with your friends online.
I'll happily have to deal with a few extra launchers on PC in comparison to what the alternative is.
The future where this "extremely annoying" situation is fully solved is Xbox XXX being un removable and the only Game Store allowed on any PC sold, with legal threats to anyone jailbreaking.
As long as user have a choice and control on their device, and competition is alive, we'll hopefuly have different stores with different rules and you'll be extremely annoyed I think.
Is it? I regularly use Steam, Epic and XBox and occasionally Ubi, Larian and whatever the GoG one is called... and it's fine. It's just another program.
Yeah, it is. I don't use anything except Steam. If it's not on Steam I'm not buying or playing it. Making your game exclusive to one distribution channel is stupid.
If it does't have to be offline for long durations, software raid + adding a new drive every once in a while, and discarding failing drives is pretty foolproof.
AFAIK large data centers automate something like this.
The issue with (software) raid is you have no idea if what you're copying isn't actually corrupted. If the filesystem isn't checksumed there's no guarantee.
As they said though, the hash function on a string type requires looking at every element in the string. Also, modulo is historically very slow. So, they still have to deal with O(n) operations, where n is the length of the input string. If they can improve the memory hopping problem associated with lists / graph structures (which they claim to have done in their library), then a trie could would be much fast enough, which is what they observed. Combined with the fact that they claim that 90% of the time there is a miss when querying the trie, then you exit early a lot, whereas you always need to compute the whole hash on the input string when doing the hash map strategy.
The hash does not need to be computed on the whole string. I pointed this out in my other comment but just as a example: a hash function could be as simple as xoring the first 16 and last 16 bits of the string then indexing a 2^16 array. That means hashing is two pointer offsets and an xor (no modulo required). If there are 100 strings that need to be removed, then ~99% of rejections will be a very fast O(1).
And in the case of a match, a fast hash + memcmp will be way faster than a trie traversal. In fact, according to the trie-hard github readme, std::HashMap is already much faster than their trie implementation when searching for a match.
> As they said though, the hash function on a string type requires looking at every element in the string.
Maybe for the default hash function. As another commenter pointed out, your data may make the following hash very effective: s[0] + s[len(s)//2] + s[-1] which would be very fast. The point being is spending a day seeing if such a hash exists is worth it.
CRC32 is the same speed as an integer multiply, going all the way back to Nehalem (2008). 3 cycles latency, and you can start a new one each cycle (or more than one, on Zen 5).
Yes.
> Obviously that is impossible
I assume you're willing to short Intel at this point?