"He" isn't even covering it, he eventually automated himself out of the channel: He AI-cloned his voice and had it read AI-generated scripts. I assume he still does.
Wii U and Switch aren't x86 at all. All of GameCube, Wii and Wii U used a PowerPC CPU and an ArtX/ATI/AMD GPU. And Switch has moved to Nvidia ARM chips; they had been using ARM for portables since GBA.
We recently got an article claiming the front and back of the brain grow from two different progenitor cells, which some scientific media reported as it being two organs, whereas others claim that's an exaggeration.
Probably more mlock (keep memory area in RAM), mincore just tells you what is or is not in RAM, and madvise is about access patterns.
You could MADV_WILLNEED the GC metadata when you start the GC process hoping they’ll have been paged in by the time you STW, but assuming that area is not massive it’s probably a better idea to just prevent it being paged out.
I was assuming they meant for the heap. Not even executable memory is locked though, so if you mlock too much memory the kernel will page out your executable instead. Something has to give, so it's better to schedule it.
On a lower level, the OCaml and cpython GCs use a prefetch buffer during marking to schedule around the cache.
C has many more ways to trigger undefined behaviour than memory access. If C had unsafe blocks they'd restrict most forms of signed integer arithmetic and shifting, for a start.
How could SHA-512 be faster? It does more rounds of the exact same operations as SHA-256 with a bigger state. Although if it really were faster, SHA-512/256 gives you a truncated version.
It hashes a double amount of data per cycle with much less than a double amount of operations.
SHA-512 is always faster in software than SHA-256, when run on 64-bit CPUs, and it is also faster in the CPUs that support both SHA-256 and SHA-512 in hardware.
Arm-based CPUs have supported SHA-512 already for many years and the latest Intel CPUs also support it, i.e. Lunar Lake, Arrow Lake S (S is for desktops, Arrow Lake H for laptops does not support it), Panther Lake and Clearwater Forest.
I expect that AMD Zen 6 should also support it, because they are the last important vendor without SHA-512 support.
All modern CPUs support SHA-256 in hardware, so it is faster when SHA-512 is not supported in hardware, otherwise SHA-512/256 is preferable, by being both faster and more secure.
Thanks, that makes sense. I was vaguely aware that SHA-256 halved the internal state from SHA-512 but not that it halved the block size, I haven't looked much into it. Although it makes sense in retrospect that they would simply use 32-bit variables to keep the same structure.
Good question, why did Russia rename the Shahed-131 to Geran-1? Those are allegedly Iranian made, and Geran-2 is allegedly a slightly modified Shahed-136. Of course, as they keep modifying them they slowly become their own thing, but there's a clear tech ancestry.
It is not weird to call something by the name of something that is much more widely known, that it is closely related to. It is maybe a little bit weird to get really angry online about that, unless you are upset about the association being reinforced.
long can't be smaller than int, so a 64-bit int leaves short as the only type between char and long long, and you need to pick whether it's 16 bits or 32.
Then again, we'd still have stdint around. And ultimately this doesn't matter because most code isn't portable anyway.
I don't think of the stdint types as being less native than the keyword integer types. C# for example makes keyword types aliases to System.* types, not the other way around.
I think you would need to have a compiler intrinsic type which is 16 bits. That is what the stdint.h file would define (u)int_16 to.
It would be odd for there to be a compiler intrinsic type to be unavailable until a header was included.
The compiler intrinsic type could be a mess like __int16_exactly_t but without it stdint.h would have some magic line which makes a compiler intrinsic available which wasn't before, or generates a new 16-bit type ex nihilo.
So you could have a "#pragma expose_extra_types" in stdint.h but that would not be the conventional approach.
I mostly wanted to make the point that a mere "at least 16 bits" type is not sufficient for some use cases, which is not in response to you but the comment you responded to.
This is a bizarre sentence seeing as Google is a portal for most people. So replacing Google with ChatGPT is replacing all those destination sites as well.
The use cases described above aren't really multiple applications though. They're just using a search method to get the right fact or factoid. I consider that the scope of a single "app".
Most of those websites have been complements for Google Search rather than standalone services whether they like it or not, and if chat bots replace Google Search, they'll replace the entire ecosystem.
Oh, and she also uses image generation to test redecoration ideas by asking "gipitiak" to add/remove/recolor things on room photos. That's something you can't do with Google search in any way, shape or form.
Not that this matters, because Google search alone disproves the claim that people only use phones for videos and social media.
I didn't intend to argue either way, but I feel that adding "and search" to the argument made above doesn't really weaken it. The full claim is that regular users weren't really interested in using power-user apps, so they won't be interested with a chat-bot UI either.
I do personally think that we'll see regular users interested in new, different workflows than the automation ones we associate with power users, and the image generation use case you mention is a good example. Chat-bots do seem to be owning those rather than entirely new apps.
reply