Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

branchfree.org

Post reply on HN
Print view View original

31–39 of 39 posts

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#31

Post by glangdale »

dragontamer wrote: post #22
glangdale wrote: post #2

Author here. Happy to answer questions, endure abuse, or, best yet, be put in my place by someone with a Really Nice Table of ARM Latencies and Throughputs that Could Have Been Found If I Wasn't Such an Idiot. [ Note the title of the article was "Jumps over The Wall", in keeping with the dish. ]

BTW: I would suggest you look into the closely related art of GPGPU programming. OpenCL, CUDA, or whatever. The architecture of GPUs is SIMD on steroids. You'll likely be very happy with the metrics associated with GPU-shared memory (NVidia) or Local-memory (AMD). NVidia publishes throughput metrics in their PTX page: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.... AMD's information is harder to find,…

I got my start on performance programming doing GPGPU regex (a terrible idea in our context - networked IPS - but that's for another time). This was in 2006, so this meant doing GPGPU using "Cg", including such delights as using textures as arrays and floats for everything. CUDA 0.9 and a engineering sample G80 card were a revelation.

I keep meaning to go back and do some GPGPU again. I am very fond of architectures that actually exist. GPU is a very different bet than SIMD but a lot of fun.

Incidentally PTX is a fiction - more of an IR than something with true throughput and latency numbers. I don't know if anyone programs GPUs directly but that would be interesting.

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#32

Post by glangdale »

gok wrote: post #25
glangdale wrote: post #16

Earlier quoted context omitted.

If you're think about algorithms in terms of how they might embed into a processor, you need to know the throughput and latency numbers even if the compiler is getting things right. For example, there are some nice possibilities with the TBL instruction (or PSHUFB, or VERMB, etc) for doing character class membership tests. Which version you use would have a lot to do with whether you think TBL is going to issue 2/cyc…

Sure but the compiler can compile your intrinsics to different-but-equivalent instructions, and modern compilers actually do that pretty aggressively. Are you sure the code output was actually using the instructions you expected?

Yes. I look at the asm all the time, having not fallen off the turnip truck yesterday.

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#34

Post by wmu »

Const-me wrote: post #15

About documentation, Intel’s is not great either. Otherwise I wouldn’t bother making this: https://github.com/Const-me/IntelIntrinsics

I did similar thing, but the output are unix man pages: https://github.com/WojciechMula/man-intrinsics

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#35

Post by dragontamer »

glangdale wrote: post #31
dragontamer wrote: post #22

Earlier quoted context omitted.

BTW: I would suggest you look into the closely related art of GPGPU programming. OpenCL, CUDA, or whatever. The architecture of GPUs is SIMD on steroids. You'll likely be very happy with the metrics associated with GPU-shared memory (NVidia) or Local-memory (AMD). NVidia publishes throughput metrics in their PTX page: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.... AMD's information is harder to find,…

I got my start on performance programming doing GPGPU regex (a terrible idea in our context - networked IPS - but that's for another time). This was in 2006, so this meant doing GPGPU using "Cg", including such delights as using textures as arrays and floats for everything. CUDA 0.9 and a engineering sample G80 card were a revelation. I keep meaning to go back and do some GPGPU again. I am very fond of architectures…

> Incidentally PTX is a fiction - more of an IR than something with true throughput and latency numbers. I don't know if anyone programs GPUs directly but that would be interesting.

PTX is a fiction, but its very close to the underlying "SASS" assembly language of NVidia GPUs. There was some research done into this field here: https://arxiv.org/abs/1804.06826

They reverse engineered the SASS assembly language, all the op-codes match up to PTX opcodes. The main difference is that SASS includes control information, such as stall cycles, write or read barrier information.

In effect, it seems like NVidia's compiler figures out stalls and dependencies at compile-time. Memory-dependencies are written to each SASS assembly instruction in Volta, in a format that has changed differently each generation.

The typical assembly programmer doesn't care about these details (CPUs typically handle that logic automatically), so it makes sense to ignore them through the higher-level PTX Assembly language.

It seems like PTX is sufficient for understanding the general execution of an NVidia GPU. There's probably no reason to write the underlying SASS code by hand, especially because PTX matches up to the SASS opcodes. Furthermore, it is clear that NVidia is tweaking the details of those memory-barrier and dependency information, and doesn't want programmers to write against that abstraction level.

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#36

Post by dman »

blu42 wrote: post #33

Props to the author for the objective article. Re CA53 throughput and latencies, no -- I don't have the tables, but I've done my fair share of tbl/tbx mesurements: https://www.cnx-software.com/2017/08/07/how-arm-nerfed-neon-...

Welcome to hn, we meet again!

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#37

Post by blu42 »

dman wrote: post #36
blu42 wrote: post #33

Props to the author for the objective article. Re CA53 throughput and latencies, no -- I don't have the tables, but I've done my fair share of tbl/tbx mesurements: https://www.cnx-software.com/2017/08/07/how-arm-nerfed-neon-...

Welcome to hn, we meet again!

Salut! I've finally decided to register for writing, after years of mute reading ; )

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#38

Post by glangdale »

Iwan-Zotow wrote: post #23
glangdale wrote: post #2

Author here. Happy to answer questions, endure abuse, or, best yet, be put in my place by someone with a Really Nice Table of ARM Latencies and Throughputs that Could Have Been Found If I Wasn't Such an Idiot. [ Note the title of the article was "Jumps over The Wall", in keeping with the dish. ]

Scalar Vector Extensions?! Used to be Scalable VE

Fixed, thanks. I type the word 'scalar' so much, apparently, I didn't notice.

Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming

#39

Post by devit »

brandmeyer wrote: post #27
mastax wrote: post #19

Earlier quoted context omitted.

I'll grant that a lot of code can't be readily adapted to large vectors, but this doesn't seem like much of a problem for (proposed) RISC-V. If you're creating an algorithm that only works on a specific width, you can just `setvl` and assert that you have enough space available. You're likely targeting a specific CPU or class of CPU where you know there will be support for 256-bit vectors or whatever. If someone trie…

I'm not sure I understand how callee-saved registers are going to work under RVV, given the way that dynamic reconfiguration works.

My guess is that either no registers will be callee-saved or one group of 8 registers will be callee-saved (in the current draft, you can group 1, 2, 4 or 8 sequential registers, but only starting on a multiple of the group size, so register groups are always going to be contained within one of the four 8-register maximum-size groups); this will require dynamic stack allocation since the vector length is not fixed.

The saving sequence would be something like this (after setting up a frame pointer if needed): "vsetvl t0, x0, e8, m8; sub sp, sp, t0; vse.v v16, (sp)".

Post reply on HN