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

11–20 of 39 posts

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

#11

Post by glangdale »

inetknght wrote: post #9
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. ]

I see your simdjson code appears to be C but has a dependency for jsoncpp. There's also a graph which compares several different json libraries except jsoncpp. I've used jsoncpp for some other projects and I'd be curious about your opinion and any comparisons you might have.

That could be clearer, sorry. We compare against RapidJSON and sajson for the bulk of the paper and for the 'splash' graphics as these are the fastest two libraries that validate to a similar extent (gason is a little faster than RapidJSON but accepts some crazy stuff).

In the paper, we do also include measurements against 7 other libraries including jsoncpp. It is an order of magnitude slower than we are on the measurements we took. I am not familiar enough with it to know whether that's meaningful; it may have a lot of other attributes that make it more useful for what you're doing than what we have. We're pretty barebones, especially at this stage.

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

#12

Post by glangdale »

glangdale wrote: post #11
inetknght wrote: post #9

Earlier quoted context omitted.

I see your simdjson code appears to be C but has a dependency for jsoncpp. There's also a graph which compares several different json libraries except jsoncpp. I've used jsoncpp for some other projects and I'd be curious about your opinion and any comparisons you might have.

That could be clearer, sorry. We compare against RapidJSON and sajson for the bulk of the paper and for the 'splash' graphics as these are the fastest two libraries that validate to a similar extent (gason is a little faster than RapidJSON but accepts some crazy stuff). In the paper, we do also include measurements against 7 other libraries including jsoncpp. It is an order of magnitude slower than we are on the meas…

(the broader comparison is in Table 9 at https://arxiv.org/pdf/1902.08318.pdf)

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

#14

Post by gok »

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. ]

You're using C intrinsics instead of assembly, right? Are you sure the compiler isn't doing the scheduling well enough on its own?

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

#16

Post by glangdale »

gok wrote: post #14
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. ]

You're using C intrinsics instead of assembly, right? Are you sure the compiler isn't doing the scheduling well enough on its own?

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/cycle, 1/cycle or 0.5/cycle (just fr'instance) - you might design the algorithm quite differently. It's not just a case of picking the one design choice and then having the compiler schedule that - if you're not thinking about this during design, you're not going to be remotely near peak performance.

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

#17

Post by inetknght »

glangdale wrote: post #12
glangdale wrote: post #11

Earlier quoted context omitted.

That could be clearer, sorry. We compare against RapidJSON and sajson for the bulk of the paper and for the 'splash' graphics as these are the fastest two libraries that validate to a similar extent (gason is a little faster than RapidJSON but accepts some crazy stuff). In the paper, we do also include measurements against 7 other libraries including jsoncpp. It is an order of magnitude slower than we are on the meas…

(the broader comparison is in Table 9 at https://arxiv.org/pdf/1902.08318.pdf )

That's pretty interesting, thanks!

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

#18

Post by snvzz »

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. ]

I'm curious about what you think about RISC-V's draft V extension.

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

#19

Post by mastax »

glangdale wrote: post #5
devit wrote: post #3

Looks like the author is going to enjoy RISC-V SIMD (once it is finalized).

I'm not sure... I like the look of the bit manipulation stuff, but I'm not really a fan of the variable-length vector approach. I think these systems are built to make the world safe for matrix multiply - and simple math workloads - but the short-vector approach (e.g. the typical x86 SIMD style of doing things) is sometimes exactly what you want. I keep meaning to write more about this. I have found 3 categories of S…

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 tries to run it on a cheap embedded CPU, they'll be disappointed that your code won't run on their 64-bit vectors, but this is no different from trying to run AVX code on an Intel Atom.

I suppose it's hard to know until we can actually write code for it, but I haven't imagined a scenario where the RV model is significantly worse than packed SIMD, other than a tiny bit of vector configuration bookkeeping. I think that's a worthwhile tradeoff for getting simple, portable, fast code for elementwise operations and implementation flexibility.

I'd love to be convinced otherwise, though.

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

#20

Post by Rebelgecko »

gok wrote: post #14
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. ]

You're using C intrinsics instead of assembly, right? Are you sure the compiler isn't doing the scheduling well enough on its own?

I'm not an expert assembly programmer and I'm definitely not an expert at using SIMD instructions, but the last time I created a NEON implementation of an algorithm I was able to beat GCC's output (from compiling C intrinsics) after an afternoon of tweaking things by hand. From looking at GCC's output it didn't seem like it was doing a great job interleaving ARM and NEON ops to take advantage of that pipeline, although maybe it's gotten better since GCC 5.
Post reply on HN