PixelOfDeath

I hat very good experience with using buffer variables to copy-"prefetch" unpredictable costly fetches. E.g. from cache lines that get touched by several cores for communication.

And I only actual use them after one iteration of whatever I do. So the core could fetch the memory content without actually having to stall because I do not use it until later.

I'm not sure how realistic that is inside a kernel thread scheduler, but it sure is useful in user space for task based libraries.

Should electro bicycles not make such issues easier to handle?

x86_64 malloc already uses 16 byte alignment and portions to support SSE commands. So why not go all the way and allocate full cache lines? This also prevents accidental false sharing between different malloc pointers.

ME TO!

Especially because of the x86 oligopoly I would think that Arm is so much more important as an ecosystem.

In Germany and surrounding countries it is very common to eat raw minced pork meat (Mett) on bread/buns.

> keeping the natural local time

Fuck that! I want a single unified global time!

Isn't AVX512 basically cacheline-instructions?

The K5 was actually a RISC CPU with an x86 decoder on top. So we can count that one, too?!

x86 guarants that memory writes to different locations are seen in order by other cores.

If you write memory first to address A and then to B. Another core never can see the B change without also seeing the A change at any moment in time.

But in this case there is only a single memory location. So there is no ordering that could be violated in the first place.

> 1. This would dramatically increase cache line size. I don't have data, but I assume this would generally be bad.

Why would it change cache line size? GPUs also use cache lines in the range of 32-128 byte?! I think that is independent of the bus system/width.

GPUs can hide memory latency very well, because they are basically SMT on steroids. (Imagine instead of 2 threads per "core" you have 32-64 threads)

But they are starved of memory bandwidth! And the lower latency memory CPUs prefer is not the same as the high bandwidth memory that GPUs like.

Also there is different kind of caching. Modern APUs often have two ways to access memory. Over there own cache, or over the CPUs cache. So shared memory for CPU<->GPU gets the full advantage of a cache, but still it is a trade off.

If you want some work done by the GPU part of an APU, by sharing a pointer, you can do that today. But from the point of view of the CPU there is no prediction beyond the "GPU do X" commands. And a very high latency until the job is done. So you need a minimum GPU job size for it to make sense.

AI scales better to how many jets you want to use. AI improvements can also instantaneously be rolled out to every jet. There is no need for continues live communication in "hot" combat. Less video leaks when they kill a bunch of civilians again.

Also think about the export market! Countries that now can buy the ruthless-pilot with the plane! And like with so many exports, you can give them a shittier version of the AI, so they do not become a danger to your forces!

I prefer Hitchens answer to the question: "We have free will, we have no choice."

You just set your chosen segment register(s) in protect mode, jump back to real mode, and then can use this segment register(s) in combination with the 32bit prefix to make a 32 bit memory access. All other segment registers are untouched and you can call into the bios just fine.

Even if it may still take some years, I have really high hopes for chiplet GPUs.

The small vector class contains a static array of a few bytes. And as long as your data fits in it, no extra heap allocation is needed. A vector always does heap allocation, even if you only use a few bytes.

Isn't the tendency to use more and more large pages (1MiB) on x86 anyway? And then just use user space allocators to split them up for malloc.

I wonder if there is anything between the complexity of HPX and this stack-less task libraries.