An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
1–10 of 39 posts
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#2Author 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. ]
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#3Looks like the author is going to enjoy RISC-V SIMD (once it is finalized).
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#4Author 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. ]
How do you feel working on code that is (will be) used by governments and organizations of all kinds to censor the Internet?
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#5Looks 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 SIMD use in my own work:
1) Doing one thing a gazillion times (e.g. conventional SIMD). This works well on vector machines, of course.
2) Using SIMD registers to do "more stuff". So in a couple string matchers and regex matchers I've designed, you are really use using a SIMD register because it's bigger than a GPR register (duh). But this might be because you want to simulate a 512-bit NFA rather than a 64-bit NFA.
3) Using SIMD operations to do weird, irregular stuff where what you're really getting is a substitute for branchy code. I blogged about an example of this called "SMH" https://branchfree.org/2018/05/30/smh-the-swiss-army-chainsa...
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#6Looks like the author is going to enjoy RISC-V SIMD (once it is finalized).
Are there any cores available that implement it?
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#7Author 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. ]
How do you feel working on code that is (will be) used by governments and organizations of all kinds to censor the Internet?
One of the uncomfortable aspects of open source is that you don't get to choose who uses it. The majority of customers we were aware of were security customers looking to stop attacks on machines behind next-gen firewalls. We weren't aware of any "democracy suppression" use cases, but it would be naive to assume it's impossible.
(edit - also worth noting that this question seems to refer to my old job; I don't currently work on Hyperscan, although I may go back to regex one day. I'm sympathetic with the line of questioning, though, so please stop downvoting the parent)
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#8Author 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. ]
The best you can do for an ARM latency table is ddging
"aXX optimization guide"
a57: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Co...
a72: http://infocenter.arm.com/help/topic/com.arm.doc.uan0016a/co...
Notably not public is the a53 version of this document. I did some work getting ORB_SLAM to run on the raspberry pi a couple years ago. My conclusion was that the instruction timings for NEON instructions are more or less the same as the a57, but just remember there are only two instructions issued per cycle and everything is in order.
Edit: replace google with ddg
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#9Author 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.
Re: An Intel Programmer Jumps over Wall: First Impressions of ARM SIMD Programming
#10Author 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. ]
The best you can do for an ARM latency table is ddging "aXX optimization guide" a57: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Co... a72: http://infocenter.arm.com/help/topic/com.arm.doc.uan0016a/co... Notably not public is the a53 version of this document. I did some work getting ORB_SLAM to run on the raspberry pi a couple years ago. My conclusion was that the instruction timings for NEON instructio…
I've seen those. We also can get A55, A75 but notably not A76 either. And what's there is... terse. But generally OK (not a fan of the blank spot in latency/throughput tables, regardless of who is doing it). Sadly, ARM is the exception - Ampere, Marvell/Cavium and Apple don't have a _whiff_ of information like this out there.