3 ms·
We've had MMX for a while now, I don't think we need to wait much longer. I don't really see why you would need specific hardware to express a type in a progra
by jeroenhd 3mo ago
We've had MMX for a while now, I don't think we need to wait much longer.
I don't really see why you would need specific hardware to express a type in a programming language, though.
- jerven 3mo agoNot for atomic writes, which is the important bit here. When dealing with concurrency the choice to make us will you allow tears when writing i.e. thread A writes aa and thread B writes bb. Will you allow the option of seeing ab or ba or only aa/bb. This is the thing that costs performance. Plus do you allow null which makes it harder too.
- muvlon 3mo agoThat being said, x86_64 has supported 128-bit atomic writes via cmpxchg16b for over a decade. Modern 64-bit ARM has several ways to do them as well. Probably still not widespread enough for OpenJDK to unconditionally assume it's supported, but I think we're getting there. (Is there "caniuse" for CPU features?)
- Coelacanthus 3mo agocmpxchg16b can only handle 64bits data correctly because of ABA problem.
- my-next-account 3mo agoIt's mostly a performance question in order to adhere to Java's memory model.
- DarkNova6 3mo agoYou can deliberately opt out of it though and for such a mainstream language such as Java, this just might be the sane choice.
- DarkNova6 3mo agoIt's about the semantic guarantees because you don't want to introduce a parallel programming bug just because you added a field to a type. Tearability is opt in and if you are serious about performance you will make the correct choice.