sharpneli

And same thing applies to LCDM. How does it explain bullet cluster, and several others, existing in the first place?

Disclaimer: I'm not a cosmologist even if I do have a background in physics. I do like following the field. It's just not quite so clear as you imply.

And if we go into things like superfluid dark matter then it doesn't really matter if its dark matter or some kind of modified gravity. One has bunch of equations and what matters is how they behave.

On the other hand if your ISA is the micro-ops directly then the instructions start to take ridiculous amounts of space. It's a balancing act between instruction size (to save instruction cache) and the complexity of decoding them.

And it's not just about being 1:1. It's also about how wide you can go. And variable length encodings simply are fundamentally more hard to parse in parallel fashion. That means a wider unit is harder to achieve, needing more space and power.

This is also the reason why the whole CISC and RISC debate in it's original form is outdated. The processors internally are all RISC. But the ISA can be more complex.

The x86 ISA makes the decoder harder to parallelize, so it takes more chip area compared to equivalent width for ARM64. And the wider you want to go the harder it becomes, whereas with ARM64 you just slap more decoders.

Another is the x86 memory model that restricts how stores can be issued into memory so that they're visible to other cores.

This is also a good thing for AMD. They could "just" make a Zen ARM CPU. Sure it would be a lot of work, but vast majority of the chip is shared.

It wasn't fast/efficient enough. If it had been faster or with better power consumption it would've been fine. There was a massive push to get Android studio to automatically compile X86 binaries for you etc.

But why would you put an Atom in your phone if it means it's slower and worse battery life? That's the reason it flopped. ISA change is a hindrance for switching, but it can be overcome. Even if Intel had sold Atom chips with ARM ISA and identical performance to the X86 variant it would have still flopped due to the poor performance and efficiency.

SF is expensive for sure, but that expensive? Where is the money going to?

Why should the streamer pay for the privilege of being basically an advertisement platform for a commercial product? And they don't, and thus there is less discovery. Hence what is meant by the music industry shooting itself in the foot.

I personally listen mostly to music I listened as a teenager and early 20's. Sometimes I learn of something new and nice from my friends, but otherwise I find discovering new music quite hard.

A new game comes out: Tons of reviews and letsplays and whatnot. Looks interesting, I'll buy. New music comes out: Its advertised maybe in Spotify but that's it. Making a review or analysis is not possible (without paying extra), so I can't encounter it. And thus I won't listen it.

C doesn't have a concept of provenance in this fashion, or alternatively the compiler must assume the pointers may alias. This is why we have the restrict keyword.

The only cases where the compiler can assume things do not alias are when pointers are to different types (except for char).

Naturally the compiler is allowed to prove that some pointers cannot alias and optimize based on that. But if it messes up it's a compiler bug pure and simply.

Reads and writes to char* always alias everything. Unless the compiler can prove that no writes happened it has to emit a read. So if it "forgets" due to the uintptr_t cast where the char* came from then it must assume that it can be pretty much arbitrary and must emit a read.

I haven’t verified the exact numbers myself. And it will depend on the exact thing you’re running. It’s just on the order of low tens of percents.

TSO cannot be enabled outside of rosetta as it’s not exactly a good arm extension. Perhaps you could do some trickery but Apple likely prevents that.

However you can test it by making something where you know rosetta generates comparable arm assembly from the X86 one and just run comparison that way. Some sort of parallel lockfree algorithm would be the best candidate.

One couldn’t do X86 version of M1, mostly because there is no way of making an instruction decoder that wide for it.

And the performance penalty of M1 when working in TSO mode strongly implies that yes the weaker memory model indeed plays a major role. Not the biggest, but definitely not insignificant. Tens of percents here and tens of percents there combined become a ridiculous perf boost.

Without that the store buffers can be kept unflushed to, as an example, see if one can get a full cacheline or whatnot and only flush then.

The comment is correct that an X86 with heavy reordering backend will beat arm without one. However arm with one does handily beat X86 with one. Case in point: M1

” Cell phone robberies and thefts from persons went down 50 percent in the first two years after the kill switch became mandatory on phones. In the past two years they fell again by another 8 percent, to a total of 1,754 last year.” 2018

Not only that. Perhaps most importantly it curbed the growth rate.

M1 actually also implements the X86 memory model too in HW. It’s only usable for the rosetta applications and comes with perhaps 20% perf penalty. But it’s still way better than emulating it with barriers.

In C++ terms it pretty much means X86 is always seq_cst. With ARM one can actually get benefit of the different memory model options. As an example one can do an atomic access without having to flush the whole store buffer out, which is impossible in X86.

Due to the instruction coding and memory model for multicore I don’t really see X86 dominating anymore in the upcoming decades.

And as the modern OoO cores are so similar internally it’s not even a big deal in the end. AMD shouldn’t have any issues with producing a Zen arm core. Switch the inst decoder and that’s pretty much it (ton of design work for sure). Keep the X86 mem model optional for emulation and binary translation can be almost thought as just making X86 instructions into fixed width ahead of time.

There is a massive practical upside of this. It makes thefts worthless, or almost worthless as the only value is spare parts.

It worked like a charm for phones. Thefts of smarphones were rising very rapidly but then diminished as they become worthless to steal.

However it would be nice to be able to disable this for allowing usage in offline environment.

Still, having Cannabis at Schedule IV is funny.

Based on perusal on the drug categories before this change one could get prescription of cocaine but not cannabis. This is absolutely hilarious.

I do not disagree that VLIW is a great for things like DSP where the power consumption is of the essence. One can get ridiculously high perf/watt by going explicit VLIW. I just don't see any way we'd see that approach in general purpose CPU's again.

GPU's do not need to reorder instructions to hide memory latency. It just happens on a different level. While a single threadgroup (as in that single instruction pointer that controls the SIMD unit) will not get reordered at all, one has multiple threadgroups in flight. So if one group stalls at a memory load the unit will just schedule a different threadgroup. Because one generally has tons of them in flight. It's all about throughput. One could think of this as an in order CPU (from viewpoint of a single thread) but with ridiculous amounts of hyperthreading (one thread stalls, we can pick an instruction from another thread but never one from the stalled thread).

I consider it to be roughly as important as being able to reorder instructions across non statically determined branches and function calls. And both of these expose the fundamental weakness in explicit VLIW, if it's essentially nondeterministic it cannot be taken advantage of.

Then we naturally have some other benefits, like hyperthreading. Which basically is just compiling two instruction streams together on the fly.

Static compile time VLIW means one cannot really make it wider anymore, or narrower. Dynamically doing it on runtime means a cheaper and smaller core can just be narrower. Remove an instruction slot for one integer ALU? Fine, no issues. Everything still works, albeit slower by that much. Make a beefier chip? Perfect, it got faster by the amount of instruction level parallelism that was available.

In addition a compiler cannot really see across function boundaries (except if it's statically determinable). A jitter can. Modern chips have reordering window of hundreds of instructions, M1 apparently goes up to over 600. That's quite a lot of stuff there that it can dynamically reorder across. A compiler might not have noticed that due to some weird dynamic call that was not visible during compilation time there is now an FPU instruction that could be inserted here, an OoO processor can.

Due to that explicit VLIW is basically dead outside of some highly specific applications, like DPS and whatnot.

In a similar fashion ridculously wide vector units were obsoleted by the approach pioneered by GPU's. Just add few things to allow masking based on branches and you get SIMT approach. Write as if it was scalar code and it'll run on HW that has vector lengths going from none at all up to whatever, NVidia has 32 wide vector units as an example.

So the word is used in different contexts. And De Beers is more than willing to use the term artificial diamond. They can claim that they're not lying, but they're also very happy that it's also easy for customers to think its artificial in the fake sense, not in the man-made sense.

And you can always disasm X86 code and see what -ffast-math did. Doesn't mean that everyone would be fine with just mandating it everywhere with no option to disable it.

Even then the DX functional spec gives some leeway. As an example if you write x*y+z it will compile it into mad instruction. And that's just specified as that the precision must not be worse as the worst possible ordering of separate instructions. So which it is? Depends on the vendor. This is completely fine for graphics, but not fine for all workloads.

> No need for manual shenanigans with command queues

Unless you do access same buffer from multiple places in a way that's still spec conformant, just in a way that the DX11 implementation cannot detect.

Nowadays MS has actually published the spec for DX that was closed previously. See https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_... for differences of strict IEEE behaviour. In Cuda and OpenCL one can get way closer. As an example for performance reasons one might want to flush denorms to zero. But DX mandates that. So no denormals for you. In CL and Cuda they’re usable by default.

As for the command queues. I’ve often used them in Cuda. Just to get overlap between kernel executions. In DX12 one can do that by omitting barriers. DX11 allows no such feat.

It has also improved greatly. Using workgroup shared memory is now a thing. And also one can use subgroup ops that have been in Cuda for years.

Some of the other things like commandqueues are in Vulkan and DirectX12. But oh boy those are pain to program in compared to OpenCL or Cuda. Usability matters too.

It's not exactly the same as Cuda and OpenCL. Especially the numerical precision requirements are way off on graphics apis. And by way off I mean they're not always even specified what they should be.

DX12 doesn’t have descriptorsets like Vulkan. It has descriptorheaps that are bit different. This extension basically makes them quite similar. First of all the descriptors can be stored into the same place (In Vulkan the descriptors are strongly typed.). With this an image or buffer etc can use same descriptor in a set, like DX12. In addition the CPU only heap is exposed in this, allowing the platform to directly implement DX12 heaps with desc sets.

Don’t really think this would help with DX11 at all. But it would make the mess that is DX12 binding model more tolerable to emulate.

Still not sure how would they emulate the root parameters to their full extent though.

It’s C++ that’s lacking this feature. Not C.