Apple CPU tricks: memory reordering, JavaScript support, ref counting
1–10 of 196 posts
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#2When I read this on Twitter yesterday, it seemed like it was just a summary of what has already been reported by others elsewhere. Not sure why it’s worth posting here, where all this info has already been covered in more detail in earlier threads.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#3Twitter makes no sense as platform for long reads. The format is atrocious and difficult to follow. (When all that you have is a hammer all problems seem a nail)
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#4"They did something in their CPU to double the speed of reference counting."
I wish we'd get that on x86_64 too. Especially since it seems like an obvious and easy win.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#5Twitter makes no sense as platform for long reads. The format is atrocious and difficult to follow. (When all that you have is a hammer all problems seem a nail)
This was a legitimate criticism back when there was no way to thread tweets and you had to read them in reverse.
Now that you just scroll down like any other website, it just sounds like tired complaining.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#6Finally I see somebody mentioning the memory ordering. I've been wondering for a while how they've managed to get multithreaded x86 emulation working fast. I had heard mentions of "kernel support", but hadn't really looked into it much. It turns out that what I had guessed was correct, and that they simply added intel's memory ordering as an optional mode to their processor; "When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering."
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#7Finally I see somebody mentioning the memory ordering. I've been wondering for a while how they've managed to get multithreaded x86 emulation working fast. I had heard mentions of "kernel support", but hadn't really looked into it much. It turns out that what I had guessed was correct, and that they simply added intel's memory ordering as an optional mode to their processor; "When running translated x86 code, they sw…
RISC-V also has a weak memory ordering by default, with TSO (like x86) as an optional feature. So this is not a novel approach in any way.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#8"They did something in their CPU to double the speed of reference counting." I wish we'd get that on x86_64 too. Especially since it seems like an obvious and easy win.
Refcounting in a single-threaded context is extremely quick and efficient. What's expensive is atomic reference counting, as seen e.g. in C++ shared_ptr and Swift ARC.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#9Twitter makes no sense as platform for long reads. The format is atrocious and difficult to follow. (When all that you have is a hammer all problems seem a nail)
This was a legitimate criticism back when there was no way to thread tweets and you had to read them in reverse. Now that you just scroll down like any other website, it just sounds like tired complaining.
It is still atrocious. Designers have developed thru the ages great fonts, layouts and a miriad of tools to create text that is easy to read.
Not having to read the text backwards is a extremely low bar, I expect more from a text.
Twitter is the wrong tool for the task, a very bad one.
Re: Apple CPU tricks: memory reordering, JavaScript support, ref counting
#10"They did something in their CPU to double the speed of reference counting." I wish we'd get that on x86_64 too. Especially since it seems like an obvious and easy win.
For an the references to this, I haven't yet seen a description of what the optimization is. Anyone know?