Live data from Hacker News

Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

lemire.me

41–50 of 51 posts

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#41
post #39
post #36

Earlier quoted context omitted.

What are the use cases for that, though?

There's a ton if you think of it as a byte array, rather than just a string. For example, network proxies that may remove various protocol TLV options from a packet.

Is that an example of “remove all occurrences of a specific byte value from an array”? Wouldn’t packet processing require some sort of structural parsing?

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#42

Earlier quoted context omitted.

I/O is fast, and efficiency matters for every workload. The sooner your CPU is done running code, the sooner it can go into an energy saving state. Energy saving means a longer battery life on portable computers, and less cost in the server case. Remember that people are running algorithms like this "in the cloud" against millions of concurrent requests. The 40Gbps network card can keep the CPU busy, and users are wa…

What was the rule of thumb?

This was based on yearly RAM cost. I worked on a log analysis system. In the beginning, it ran on one computer. That one program would read logs, generate fleet-wide analytics, and serve those out of RAM. Eventually we wanted to run on more than one computer, for both scaling and reliability reasons. The design of the system allowed us to basically do the same serving with many replicas, so for a long time we just ran a fleet of replicas that still had all the capabilities of the monolith. The change we made was to move the aggregation stage to a new dedicated program, that we only ran 3 copies of worldwide. (A man with 2 replicas never knows which one is broken, they say.) This meant that the mappers became significantly lighter RAM-wise, they just existed to use as much CPU time as they could, and then we had 3 beefy reducer replicas to aggregate and serve data.

This was a very easy change; we just made a new main.go and an RPC to send the data to aggregate. The system was designed internally to be logically isolated across that boundary, so we just stuck in the RPC and then the other side of the boundary could be another data center.

In the end, I think we saved a few terabytes of RAM-years. Not a big deal, but it was something.

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#43

SVE and SVE2 are similar to Intel's AVX512-etc for vector, I would use intrinsics instead of hand crafting ASM code, unless it's a performance bottleneck. And yes if you want to play with SVE, Amazon's own ARM chip is the best one available now, maybe the only one in fact, for the general public.

Just to be clear, SVE is similar to AVX512 but the “Scalable” part is that the length is not hard-coded to any set number of bits or elements. It is more like the vector computers of old, such as the Cray-1. This means there is no need for continually updating the instruction set with longer and longer versions of the same instructions. Hopefully this leads to a more stable base and wider adoption, we’ll see how that…

I seem to remember reading that the 'scalable' part of SVM was lost as soon as you did loop unrolling.. I hope I'm wrong though!

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#44
post #10

Thanks for sharing. Is understanding how best to utilize computer hardware part of a classic CS program or is most learned on the job? I studied Econ in college and been a python guy for last 8 years but have no knowledge of how the machine actually interacts with my code. Is there a formal name for understanding that?

A course in high performance computing should include some material on computer architecture and SIMD, though the focus is more on parallel programming and GPU.

To get into the right mindset for SIMD optimization, play Zachtronic games. You have a big pile of odd-shaped tools that take some input and output a result a few cycles later, you have limits on how many instructions can run at once, but maybe you can do something like a load each cycle for free. Run your benchmark, count the cycles, make a small tweak and test again.

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#45
post #41
post #39

Earlier quoted context omitted.

There's a ton if you think of it as a byte array, rather than just a string. For example, network proxies that may remove various protocol TLV options from a packet.

Is that an example of “remove all occurrences of a specific byte value from an array”? Wouldn’t packet processing require some sort of structural parsing?

Packets are usually parsed by casting a uint8_t * to a struct. Frequently, the part that needs to be removed is always at the same offset in the non-error case.

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#46
post #36
post #35

Earlier quoted context omitted.

I was confused too but the author uses “trim” to mean “remove anywhere in the string”, rather than just from the beginning and end.

What are the use cases for that, though?

This particular routine doesn't seem that useful, but sometimes these weird vector algorithms that don't seem useful on their own are composed together in interesting ways to solve a larger, more interesting problem. For example, there was a cppcon talk a few years ago where the presenter came up with a novel way of using AVX instructions to efficiently find the median of seven (yes, exactly seven) integers, by coming up with a novel representation of the problem that AVX instructions were well-suited for.^[1]

That said, I don't know if this particular routine is something the author came up with while working on some other problem, or if it's just a neat idea that he came up with and wrote a short blog post about.

[1] https://www.youtube.com/watch?v=qejTqnxQRcw

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#47

SVE and SVE2 are similar to Intel's AVX512-etc for vector, I would use intrinsics instead of hand crafting ASM code, unless it's a performance bottleneck. And yes if you want to play with SVE, Amazon's own ARM chip is the best one available now, maybe the only one in fact, for the general public.

Just to be clear, SVE is similar to AVX512 but the “Scalable” part is that the length is not hard-coded to any set number of bits or elements. It is more like the vector computers of old, such as the Cray-1. This means there is no need for continually updating the instruction set with longer and longer versions of the same instructions. Hopefully this leads to a more stable base and wider adoption, we’ll see how that…

yes,SVE is vector which is scalable and AVX is SIMD which has a few fixed width.

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#48
post #5

The complexity almost looks like an April Fools joke.

Not really IMO. Seems pretty by the books SIMD optimization at the high level (main body vs manually peeled iteration for the tail), just using a nice instruction set. Straightforward vectorization of the original code. I suspect modern AVX is probably not much worse.

You're more-or-less programming in assembly here using these intrinsics, using C for goodies like for loops, and at the moment that's about as good as you can do while scalable autovectorization is still WIP/NIH in most compilers, so it's not really surprising or noteworthy. For experienced SIMD programmers, this is the standard approach to getting data parallelism out of many "boring" algorithms.

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#49

SVE and SVE2 are similar to Intel's AVX512-etc for vector, I would use intrinsics instead of hand crafting ASM code, unless it's a performance bottleneck. And yes if you want to play with SVE, Amazon's own ARM chip is the best one available now, maybe the only one in fact, for the general public.

Just to be clear, SVE is similar to AVX512 but the “Scalable” part is that the length is not hard-coded to any set number of bits or elements. It is more like the vector computers of old, such as the Cray-1. This means there is no need for continually updating the instruction set with longer and longer versions of the same instructions. Hopefully this leads to a more stable base and wider adoption, we’ll see how that…

I don't think scalable vectors is particularly useful feature, especially compared to what compilers have to go though to support it. It's much more useful to be able to do "more powerful" things with existing vector widths at hardware speeds (or perhaps just make the existing stuff faster than it is) than to be able to go wider. Scalable vectors also doesn't solve the ISA problem: don't break existing processors.

Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor

#50
post #35

In order for this to matter, you'd need to expect the possibility of strings with huge numbers of leading spaces. Why then would you use this naive algorithm for comparison? An obvious and more straight forward improvement would be to compare 4 bytes at a time with 0x20202020. (or maybe 8) There would be a maximum of 3 spaces to identify individually.

I was confused too but the author uses “trim” to mean “remove anywhere in the string”, rather than just from the beginning and end.

better word is compact?
Post reply on HN