3 ms·

Ugh, I started to write a response, but then I realised I was more or less just going over the same ground that mikeash has more eloquently covered. https://mik

Ugh, I started to write a response, but then I realised I was more or less just going over the same ground that mikeash has more eloquently covered. https://mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html https://mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-yo... One thing that Mike missed though is that you can do large bandwidth operations faster. You can blend two pixels at a time with 64bit, so your graphical blend can be twice as fast (of course, if you're really worried about the speed of these types of operation, you go SIMD - but that's a pain in the butt and requires in line assembly language to get the biggest boosts. In particular, ARM Neon's C function wrappers on SIMD instructions generally gives you a much smaller boost than if you hand code the assembly language calls. With 64bit, you can get some of the advantage without the hassle).

exDM69 12y ago
> In particular, ARM Neon's C function wrappers on SIMD instructions generally gives you a much smaller boost than if you hand code the assembly language calls. My practical experience using intrinsics is quite the opposite. Using C + NEON or SSE intrinsics yielded a lot better performance than what my hand written assembly could. I've heard similar stories to yours from others but they were from years ago. Later versions of compilers seem to be a lot better at this. In particular, the C compilers (GCC, Clang) were able to further optimize code written using intrinsics, where using assembler code practically inhibits all compiler optimizations. While I am able to do pretty good instruction selection by hand (which the compiler wasn't very good at), what blew me away was the compiler's ability to do instruction scheduling and register allocation. I could not have matched that without spending a huge amount of time reading architecture specific optimization manuals. So I got pretty neat, readable and portable code (x86+SSE and ARM+NEON) using a single code base where I had only written some "primitive" functions using low level intrinsics. I could write nice high level code and the compiler would inline my primitive function calls and then further optimize and re-organize the instructions.
- antimagic 12y ago
  Um, I don't think my GCC was that old, it was for an Android tablet from about two years ago - GCC 4.3 or 4.4 if memory serves me correctly. But yes, it was definately a failure to optimise that was causing the problem. To be honest, I generated my "hand-written" assembly by taken the output of gcc compiling intrinsic-based code, and then removing all of the dumb, unnecessary shuffles to main memory by better use of the registers... That said, there were clearly bugs in the compiler - you could crash GCC by doing certain innocuous things in your assembly code...

exDM69 12y ago

> In particular, ARM Neon's C function wrappers on SIMD instructions generally gives you a much smaller boost than if you hand code the assembly language calls. My practical experience using intrinsics is quite the opposite. Using C + NEON or SSE intrinsics yielded a lot better performance than what my hand written assembly could. I've heard similar stories to yours from others but they were from years ago. Later versions of compilers seem to be a lot better at this. In particular, the C compilers (GCC, Clang) were able to further optimize code written using intrinsics, where using assembler code practically inhibits all compiler optimizations. While I am able to do pretty good instruction selection by hand (which the compiler wasn't very good at), what blew me away was the compiler's ability to do instruction scheduling and register allocation. I could not have matched that without spending a huge amount of time reading architecture specific optimization manuals. So I got pretty neat, readable and portable code (x86+SSE and ARM+NEON) using a single code base where I had only written some "primitive" functions using low level intrinsics. I could write nice high level code and the compiler would inline my primitive function calls and then further optimize and re-organize the instructions.

antimagic 12y ago
Um, I don't think my GCC was that old, it was for an Android tablet from about two years ago - GCC 4.3 or 4.4 if memory serves me correctly. But yes, it was definately a failure to optimise that was causing the problem. To be honest, I generated my "hand-written" assembly by taken the output of gcc compiling intrinsic-based code, and then removing all of the dumb, unnecessary shuffles to main memory by better use of the registers... That said, there were clearly bugs in the compiler - you could crash GCC by doing certain innocuous things in your assembly code...