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.
Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor
41–50 of 51 posts
Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor
#42Earlier 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 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
#43SVE 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…
Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor
#44Thanks 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?
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
#45Earlier 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?
Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor
#46Earlier 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?
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.
Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor
#47SVE 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…
Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor
#48The complexity almost looks like an April Fools joke.
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
#49SVE 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…
Re: Trimming spaces from strings faster with SVE on an Amazon Graviton 3 processor
#50In 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.