The type seems to just be a small wrapper around a BigDecimal; the actual conversion arithmetic will presumably be relatively extremely slow regardless, a single extra allocation (in addition to BigDecimal's ≥3) won't change much.
Speedrunning is very much modded - ranked (the big content) is just flat out modded (not just the match setup, there are game tweaks too (guaranteed blaze drops after 20 or so iirc, guaranteed dragon perch in ≤3 mins)), and even RSG/SSG/AA/etc have a long list of allowed mods (much quicker seed rerolling, timer, perf improvement mods, etc). Many(/most/all? idk) Many (/most/all? idk) hermits use mods (esp. freecam, replaymod for creating timelapses / pretty camera perspectives). Never mind shaders sprinkled in a portion of everything.
These are minor tweaks. You could remove these and the speedrunning community/HC would lose little. A second account in spectator mode is a slightly less convenient version of freecam and the speedrunning community is kidding themselves in the first place allowing any tweaks to RNG whatsoever. They could ban that tomorrow and there'd be some grumbling but nothing would change viewership-wise
Minor tweaks are still a mod. Gameplay overhaul modpacks that turn the game into Factorio are definitely the a small minority of the playerbase, but anyone who knows better plays with at least some sort of client-side performance mod (Optifine, Lithium, etc), and that's been true since before 1.0.
Etho's dedication to keeping a purely vanilla singleplayer world is a unique feat. If you want to use Hermitcraft as an example of the median SMP, their modlist is actually quite large: https://github.com/henkelmax/hermitcraft-server
Minecraft simply has a lot of areas for improvement that haven't been touched by Mojang for one reason or another, and a big reason why people stick with Java is because the community has built an ecosystem to tweak the game to their liking.
The main actual speedrunning categories don't allow any RNG changes; but I doubt anyone doing RSG would have any interest whatsoever going back to the 20x-or-whatever slower seed rolling, that's just a completely utterly dumb waste of time doing literally nothing except clicking a button every 5 seconds (effectively changing the category from "who can play the game the best" to much more like "who has the most beast of a machine to run as many minecraft instances in parallel to more quickly roll a good seed"). Viewership would definitely go down from there being less actual gameplay.
Ranked is intended to be a fun competitive thing; waiting 10 minutes for a dragon perch doing nothing is Not Fun; waiting forever at a spawner is Not Fun; simple as that, people wouldn't play it if it wasn't fun. (oh, also, I believe Ranked also just generally includes making mob drops consistent for the same seed (and consistent portal locations, and probably other things), without which the whole entire concept of competitively playing the same seed would not work whatsoever, devolving to just who got the better RNG, distinctly Not Fun; also the ability to review a replay of your game afterwards for learning). Viewership and player counts would go down because you'd just be looking at very slow gambling instead of something actually meaningfully-skill-based.
A second account might work for freecam (though it adds more editing work, aka makes you not want to actually use it much), but making pretty timelapses is not feasible that way. Granted, you could still live without it, but the quality of content would undoubtedly go down. The little things go a long, long, long way.
To be clear I do kinda agree with the general idea that modding isn't that important to Minecraft Java; but it's still very important at least indirectly - were there not as large of a modding scene, I'd imagine many more content creators would've long ran out of content to make on it (or at least unique ways to do things), and the technical research/farms/whatever would be hampered by less available tooling.
(for what it's worth, last I played minecraft, like 1-2 years ago, I did so lightly-modded - Do A Barrel Roll for much more fun elytra; lithium; Distant Horizons; Hydrophobic Elytra to fix a stupid extremely-annoying elytra bug (might be fixed now?), BetterF3 (kinda superceded by the more recent F3 overhaul now I suppose?))
RVV still very much requires you to write a manual code/assembly loop doing the "compute how many elements can be handled, decrease count by that, repeat if necessary" thing. All it does is make it slightly less instructions to do so (and also allows handling a loops tail in the same loop while at it).
Yeah, except you don't need to rewrite that code every time a new AVX drops, and also don't need to bother to figure out what to do on older CPUs.
IIRC libc for x64 has several implementations of memcpy/memmov/strlen/etc. for different SSE/AVX extensions, which all get compiled in and shipped to your system; when libc is loaded for the first time, it figures out what is the latest extension the CPU it's running on actually supports and then patches its exports to point to the fastest working implementations.
You don't need to write a new loop every time a new vector size drops, but over time you'll still get more and more cases of wanting to write multiple copies of loops to take advantage of new instructions; there are already a good bunch of extensions of RVV (e.g. Zvbb has a good couple that are encounterable in general-purpose code), and many more to come (e.g. if we ever get vrgathers that don't scale quadratically with LMUL, some mask ops, and who knows what else will be understood as obviously-good-to-have in the future).
This kinda (though admittedly not entirely) balances out the x86 problem - sure, you have to write a new loop to take advantage of wider vector registers, but you often want to do that anyway - on SSE→AVX(2) you get to take advantage of non-destructive ops, all inline loads being unaligned, and a couple new nice instrs; on AVX2→AVX512 you get a ton of masking stuff, non-awful blends, among others.
RVV gets an advantage here largely due to just simply being a newer ISA, at a time where it is actually reasonably possible for even baseline hardware to support expensive compute instrs, complex shuffles, all unaligned mem ops (..though, actually, with RISC-V/RVV not mandating unaligned support (and allowing it to be extremely-slow even when supported) this is another thing you may want to write multiple loops for), and whatnot; whereas x86 SSE2 had to work on whatever could exist 20 years ago, and as such made respective compromises.
In some edge-cases the x86 approach can even be better - if you have some code that benefits from having different versions depending on hardware vector size (e.g. needs to use vrgather, or processes some fixed-size data that'd be really bad to write in a scalable way), on RVV you may end up needing to write a loop for each combination of VLEN and extension-set (i.e. a quadratic number of cases), whereas on x86 you only need to have a version of the loop for each desired extension-set.
It's beneficial for the average user to know that other clients exist at the very least; it's rather common in the matrix space I'm in that someone asks "how do I do X" without clarifying which client they use, and as such the question is unanswerable (or, worse, someone may answer with info about a different client; or they use some client that noone else does and as such noone can help them).
As some specific example, it's happened a couple times that someone's using a client that doesn't support rendering spoilers as spoilered, and as such they made unspoilered replies of something that should've been spoilered (and of course many clients (incl. the Elements) don't even have a sane way to type spoilers).
I've certainly encountered clang & gcc not finding or just not having header files a good couple times. Mostly around cross-compilation, but there was a period of time for which clang++ just completely failed to find any C++ headers on my system.
It only does if & while, not for. A goto in a single-pass thing would need separate handling for forwards vs backwards jumps, which involves keeping track of data per name (in a form where you can tell when it's not yet set; whereas if/while data is freely held in recursion stack). And you'd still need to handle at least `if ( expr ) goto foo;` to do any conditionals at all.
Clicked on the first thing I happen to be interested in - SIMD stuff - and ended up at https://github.com/anthropics/claudes-c-compiler/blob/6f1b99..., which is a fast path incompatible with the _mm_free implementation; pretty trivial bug, not even actually SIMD or anything specialized at all.
A whole lot of UB in the actual SIMD impls (who'd have expected), but that can actually be fine here if the compiler is made to not take advantage of the UB. And then there's the super-weird mix of manual loops vs inline assembly vs builtins.
That's an OxygenOS 16.0 bug; worked fine on 15.0, and broken on all (~five?) launchers I tested on 16.0. (currently on Octopi Launcher, and just live with that annoying delay until it Hopefully™ gets fixed)
> people shouldn't be posting their location or sensitive information publicly if they don't want it exposed like that
They shouldn't, but they still could: accidentally paste in the wrong browser tab; have been stupid when they were 12 years old; have gotten drunk; or a number of other things.
Old scrapes can't have data about new things though; have to continously re-scan to not be stuck with ancient info.
some scrapers might skip out on already-scraped sources, but easy to imagine that some/many just would not bother (you don't know if it's updated until you've checked, after all). And to some extend you do have to re-scrape, if just to find links to the new stuff.
