{"id":24616307,"url":"https://github.com/wunkolo/qreverse","last_synced_at":"2025-06-13T07:33:38.350Z","repository":{"id":39620664,"uuid":"97494361","full_name":"Wunkolo/qreverse","owner":"Wunkolo","description":"A small study in hardware accelerated AoS reversal","archived":false,"fork":false,"pushed_at":"2018-12-19T20:51:48.000Z","size":5856,"stargazers_count":174,"open_issues_count":2,"forks_count":11,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-05-07T02:27:20.092Z","etag":null,"topics":["optimization","simd"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Wunkolo.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-07-17T15:55:08.000Z","updated_at":"2025-04-22T07:46:10.000Z","dependencies_parsed_at":"2022-08-09T15:07:23.811Z","dependency_job_id":null,"html_url":"https://github.com/Wunkolo/qreverse","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/Wunkolo/qreverse","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Wunkolo%2Fqreverse","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Wunkolo%2Fqreverse/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Wunkolo%2Fqreverse/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Wunkolo%2Fqreverse/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Wunkolo","download_url":"https://codeload.github.com/Wunkolo/qreverse/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Wunkolo%2Fqreverse/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":259602503,"owners_count":22882998,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["optimization","simd"],"created_at":"2025-01-24T22:16:47.712Z","updated_at":"2025-06-13T07:33:38.328Z","avatar_url":"https://github.com/Wunkolo.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"# qReverse [![GitHub license](https://img.shields.io/badge/license-MIT-blue.svg)](https://raw.githubusercontent.com/Wunkolo/qreverse/master/LICENSE)\n\nqReverse is an architecture-accelerated array reversal algorithm intended as a personal study to design a fast AoS reversal algorithm utilizing SIMD.\n\n|||||||\n|:-:|:-:|:-:|:-:|:-:|:-:|\n||Serial|bswap/rev|SSSE3/Neon|AVX2|AVX512\n|Pattern|![Serial](images/Serial.gif)|![bswap/rev](images/Swap64.gif)|![SSSE3](images/SSSE3.gif)|![AVX2](images/AVX2.gif)|![AVX512](images/AVX512.gif)|\n|Processor|Speedup|||||\n|[i9-7900x](https://en.wikichip.org/wiki/intel/core_i9/i9-7900x)|x1|x15.386|x10.417|x22.032|x22.357|\n|[i3-6100](https://en.wikichip.org/wiki/intel/core_i3/i3-6100)|x1|x15.8|x10.5|x16.053|-|\n|[i5-8600K](https://en.wikichip.org/wiki/intel/core_i5/i5-8600k)|x1|x15.905|x10.21|x16.076|-|\n|[E5-2697 v4](https://en.wikichip.org/wiki/intel/core_i5/i5-8600k)|x1|x16.701|x15.716|x19.141|-|\n|[BCM2837](https://en.wikipedia.org/wiki/Broadcom_Corporation#Raspberry_Pi)|x1|x7.391|x7.718|-|-|\n\n\n---\n\nArray reversal implementations typically involve swapping both ends of the array and working down to the middle-most elements. C++ being type-aware treats array elements as objects and will call overloaded class operators such as `operator=` or a `copy by reference` constructor where available. Many implementations of a \"swap\" function would use an intermediate temporary variable to make the exchange which would require a minimum of two calls to an object's `operator=` and at least one call to an object's `copy by reference` constructor. Some other novel algorithms use the xor-swap technique after making some assumptions about the data being swapped(integer-data, register-bound, no overrides, etc). `std::swap` also allows an overload of `swap` for a type to be used if it is within the same namespace as your type should you want to expose your overloaded method to C++'s standard algorithm library during the reversal\n\n```cpp\n// Taken from http://en.cppreference.com/w/cpp/algorithm/reverse\n// Example of using std::reverse\n#include \u003cvector\u003e\n#include \u003ciostream\u003e\n#include \u003citerator\u003e\n#include \u003calgorithm\u003e\n \nint main()\n{\n\tstd::vector\u003cint\u003e v({1,2,3});\n\tstd::reverse(std::begin(v), std::end(v));\n\tstd::cout \u003c\u003c v[0] \u003c\u003c v[1] \u003c\u003c v[2] \u003c\u003c '\\n';\n\n\tint a[] = {4, 5, 6, 7};\n\tstd::reverse(std::begin(a), std::end(a));\n\tstd::cout \u003c\u003c a[0] \u003c\u003c a[1] \u003c\u003c a[2] \u003c\u003c a[3] \u003c\u003c '\\n';\n}\n```\n\nNote that for an odd-numbered amount of elements the middle-most element is already exactly where it needs to be and doesn't need to be moved.\n\n![](/images/Serial.gif)\n\nShould `std::reverse` be called upon a \"**P**lain **O**l **D**ata\"(POD) type such as `std::uint8_t`(aka `unsigned char`) or a plain `struct` type then compilers can safely assume that your data doesn't have any special assignment/copy overrides to worry about and can treated as raw bytes. This assumption can allow for the compiler to optimize the reversal routine into something simple and much more `memcpy`-like.\n\nThe emitted x86 of a `std::reverse` on an array of `std::uint8_t` generally looks something like this.\n\n```x86asm\n         ; std::reverse for std::uint8_t\n         0x000014a0 cmp rsi, rdi\n     /=\u003c 0x000014a3 je 0x14c5\n     |   0x000014a5 sub rsi, 1\n     |   0x000014a9 cmp rdi, rsi\n    /==\u003c 0x000014ac jae 0x14c5\n   .---\u003e 0x000014ae movzx eax, byte [rdi] ; Load two bytes, one from\n   |||   0x000014b1 movzx edx, byte [rsi] ; each end.\n   |||   0x000014b4 mov byte [rdi], dl    ; Write them at opposite\n   |||   0x000014b6 mov byte [rsi], al    ; ends.\n   |||   0x000014b8 add rdi, 1            ; Shift index at\n   |||   0x000014bc sub rsi, 1            ; both ends \"inward\" toward the middle\n   |||   0x000014c0 cmp rdi, rsi\n   \\===\u003c 0x000014c3 jb 0x14ae\n    \\\\-\u003e 0x000014c5 ret\n```\n\nWhen making qReverse, the primary interface implements a templated algorithm that follows the same logic.\nThe element-size at compile-time will be templated and emit a pseudo-structure that fits this exact size in an attempt to keep this illustrative implementation as generic as possible for an element of _any_ size in bytes. By having the element-size be templated it will be a lot easier to implement specializations for certain element-sizes while all other non-specialized element sizes fall-back to the serial algorithm.\nDoing this with a template allows only the proper specializations to be instanced at compile-time as opposed to comparing an element-size variable against a list of available implementations at run-time.\n\n```cpp\ntemplate\u003c std::size_t ElementSize \u003e\ninline void qReverse(void* Array, std::size_t Count)\n{\n\t// An abstraction to treat the array elements as raw bytes\n\tstruct ByteElement\n\t{\n\t\tstd::uint8_t u8[ElementSize];\n\t};\n\tByteElement* ArrayN = reinterpret_cast\u003cByteElement*\u003e(Array);\n\t\n\t// If compiler adds any padding/alignment bytes(and some do) then assert out\n\tstatic_assert(\n\t\tsizeof(ByteElement) == ElementSize,\n\t\t\"ByteElement is pad-aligned and does not match specified element size\"\n\t);\n\t\n\t// Only iterate through half of the size of the Array\n\tfor( std::size_t i = 0; i \u003c Count / 2; ++i )\n\t{\n\t\t// Exchange the upper and lower element as we work our\n\t\t// way down to the middle from either end\n\t\tByteElement Temp(ArrayN[i]);\n\t\tArrayN[i] = ArrayN[Count - i - 1];\n\t\tArrayN[Count - i - 1] = Temp;\n\t}\n}\n```\n\nEmitted assemblies from gcc with certain template specializations:\n\n\u003e ```cpp\n\u003e auto Reverse8 = qReverse\u003c1\u003e;\n\u003e ```\n\u003e ```x86asm\n\u003e void qReverse\u003c1ul\u003e(void*, unsigned long):\n\u003e   mov rcx, rsi\n\u003e   shr rcx\n\u003e   je .L1\n\u003e   lea rdx, [rsi-1]\n\u003e   lea rax, [rdi+rdx]\n\u003e   sub rdx, rcx\n\u003e   lea rdx, [rdi+rdx]\n\u003e .L3:\n\u003e   movzx ecx, BYTE PTR [rdi] ; Load bytes at each end\n\u003e   movzx esi, BYTE PTR [rax]\n\u003e   sub rax, 1                ; Move indexs \"inwards\"\n\u003e   add rdi, 1\n\u003e   mov BYTE PTR [rdi-1], sil ; Place them at the other end\n\u003e   mov BYTE PTR [rax+1], cl\n\u003e   cmp rax, rdx              ; Loop\n\u003e   jne .L3\n\u003e .L1:\n\u003e   rep ret\n\u003e ```\n\n\u003e ```cpp\n\u003e auto Reverse16 = qReverse\u003c2\u003e;\n\u003e ```\n\u003e ```x86asm\n\u003e void qReverse\u003c2ul\u003e(void*, unsigned long):\n\u003e   mov rdx, rsi\n\u003e   shr rdx\n\u003e   je .L17\n\u003e   lea rax, [rdi-2+rsi*2]\n\u003e   add rdx, rdx\n\u003e   mov rsi, rax\n\u003e   sub rsi, rdx\n\u003e .L12:\n\u003e   movzx edx, WORD PTR [rdi] ; Same as above\n\u003e   movzx ecx, WORD PTR [rax]\n\u003e   sub rax, 2\n\u003e   add rdi, 2\n\u003e   mov WORD PTR [rdi-2], cx\n\u003e   mov WORD PTR [rax+2], dx\n\u003e   cmp rax, rsi\n\u003e   jne .L12\n\u003e .L17:\n\u003e   rep ret\n\u003e ```\n\n\u003e ```cpp\n\u003e auto Reverse32 = qReverse\u003c4\u003e;\n\u003e ```\n\u003e ```x86asm\n\u003e void qReverse\u003c4ul\u003e(void*, unsigned long):\n\u003e   mov rdx, rsi\n\u003e   shr rdx\n\u003e   je .L25\n\u003e   lea rax, [rdi-4+rsi*4]\n\u003e   sal rdx, 2\n\u003e   mov rsi, rax\n\u003e   sub rsi, rdx\n\u003e .L20:\n\u003e   mov edx, DWORD PTR [rdi] ; Same as above\n\u003e   mov ecx, DWORD PTR [rax]\n\u003e   sub rax, 4\n\u003e   add rdi, 4\n\u003e   mov DWORD PTR [rdi-4], ecx\n\u003e   mov DWORD PTR [rax+4], edx\n\u003e   cmp rax, rsi\n\u003e   jne .L20\n\u003e .L25:\n\u003e   rep ret\n\u003e ```\n\n\u003e ```cpp\n\u003e auto Reverse24 = qReverse\u003c3\u003e;\n\u003e ```\n\u003e ```x86asm\n\u003e void qReverse\u003c3ul\u003e(void*, unsigned long):\n\u003e   mov rdx, rsi\n\u003e   shr rdx\n\u003e   je .L25\n\u003e   lea rax, [rsi-3+rsi*2]\n\u003e   lea rdx, [rdx+rdx*2]\n\u003e   add rax, rdi\n\u003e   mov r8, rax\n\u003e   sub r8, rdx\n\u003e .L20:\n\u003e   movzx esi, WORD PTR [rax] ; Due to the element being 3 bytes\n\u003e   movzx ecx, WORD PTR [rdi] ; The arithmetic gets especially weird\n\u003e   sub rax, 3                ; But it is still the same\n\u003e   movzx edx, BYTE PTR [rdi+2]\n\u003e   add rdi, 3\n\u003e   mov WORD PTR [rdi-3], si\n\u003e   movzx esi, BYTE PTR [rax+5]\n\u003e   mov WORD PTR [rsp-3], cx\n\u003e   mov BYTE PTR [rsp-1], dl\n\u003e   mov BYTE PTR [rdi-1], sil\n\u003e   mov WORD PTR [rax+3], cx\n\u003e   mov BYTE PTR [rax+5], dl\n\u003e   cmp rax, r8\n\u003e   jne .L20\n\u003e .L25:\n\u003e   rep ret\n\u003e ```\n\n**From here it gets better!**\n\nThis \"plain ol data\" assumption can be made for lots of different types of data. Most usages of `struct` are intended to be treated as \"bags of data\" and do not have the limitation of additional memory-movement logic for copying or swapping since they are intended only to communicate a structure of interpretation of bytes. The more obvious case-study can also be having an array of `chars` found in an ASCII `string` or maybe a row of `uint32_t` pixel data. If the array elements are aligned to register-sizes(which tend to be powers of 2) then these in-register byte swaps and shuffling can be especially useful. **From this point on assume that the array of data is to be interpreted as these \"bags of data\" instances** that do not involve any kind of `operator=` or `Foo (const Foo\u0026)` type of overhead logic so the data may be safely interpreted strictly as bytes, think `memcpy`-like.\n\nMost of the market are running 64-bit or 32-bit machines or have register sizes that are easily much bigger than just 1 byte(the animation above had register sizes that are 4 bytes, which is the size of a single 32-bit register). An observation is that this can speed this up is by loading in a full register-sized chunk of bytes, flipping this chunk of bytes within the register, and then placing it on the other end! Swapping all the bytes in the registers is a popular operation in networking called an `endian swap` and x86 happens to have just the instruction to do this!\n\n# bswap\n\nThe `bswap` instruction reverses the individual bytes of a register and is typically used to swap the `endian` of an integer to exchange between `host` and `network` byte-order(see `htons`,`htonl`,`ntohs`,`ntohl`). Most x86 compilers implement assembly intrinsics that you can put right into your C or C++ code to get the compiler to emit the `bswap` instruction directly:\n\n**MSVC:**\n- `_byteswap_uint64`\n- `_byteswap_ulong`\n- `_byteswap_ushort`\n\n**GCC/Clang:**\n\n- `_builtin_bswap64`\n- `_builtin_bswap32`\n- `_builtin_bswap16`\n\nThe x86 header `immintrin.h` also includes `_bswap` and `_bswap64`. Otherwise a more generic and portable implementation can be used as well to be more architecture-generic.\n\n```cpp\ninline std::uint64_t Swap64(std::uint64_t x)\n{\n\treturn (\n\t\t((x \u0026 0x00000000000000FF) \u003c\u003c 56) |\n\t\t((x \u0026 0x000000000000FF00) \u003c\u003c 40) |\n\t\t((x \u0026 0x0000000000FF0000) \u003c\u003c 24) |\n\t\t((x \u0026 0x00000000FF000000) \u003c\u003c  8) |\n\t\t((x \u0026 0x000000FF00000000) \u003e\u003e  8) |\n\t\t((x \u0026 0x0000FF0000000000) \u003e\u003e 24) |\n\t\t((x \u0026 0x00FF000000000000) \u003e\u003e 40) |\n\t\t((x \u0026 0xFF00000000000000) \u003e\u003e 56)\n\t);\n}\n\ninline std::uint32_t Swap32(std::uint32_t x)\n{\n\treturn(\n\t\t((x \u0026 0x000000FF) \u003c\u003c 24) |\n\t\t((x \u0026 0x0000FF00) \u003c\u003c  8) |\n\t\t((x \u0026 0x00FF0000) \u003e\u003e  8) |\n\t\t((x \u0026 0xFF000000) \u003e\u003e 24)\n\t);\n}\n\ninline std::uint16_t Swap16(std::uint16_t x)\n{\n\t// This tends to emit a 16-bit `rol` or `ror` instruction\n\treturn (\n\t\t((x \u0026 0x00FF) \u003c\u003c  8) |\n\t\t((x \u0026 0xFF00) \u003e\u003e  8)\n\t);\n}\n```\n\nMost compilers are able to detect when an in-register endian-swap is being done like above and will emit `bswap` automatically or a similar intrinsic for your target architecture(The ARM architecture has the `rev` instruction for **armv6** or newer). Note also that `bswap16` is basically just a 16-bit rotate of 1 byte which is the `rol` or `ror` instruction.\n\nx86_64 (gcc):\n```x86asm\nSwap64(unsigned long):\n  mov rax, rdi\n  bswap rax\n  ret\nSwap32(unsigned int):\n  mov eax, edi\n  bswap eax\n  ret\nSwap16(unsigned short):\n  mov eax, edi\n  rol ax, 8\n  ret\n```\n\nx86_64 (clang):\n```x86asm\nSwap64(unsigned long): # @Swap64(unsigned long)\n  bswap rdi\n  mov rax, rdi\n  ret\n\nSwap32(unsigned int): # @Swap32(unsigned int)\n  bswap edi\n  mov eax, edi\n  ret\n\nSwap16(unsigned short): # @Swap16(unsigned short)\n  rol di, 8\n  mov eax, edi\n  ret\n```\n\nARM64 (gcc):\n```armasm\nSwap64(unsigned long):\n  rev x0, x0\n  ret\nSwap32(unsigned int):\n  rev w0, w0\n  ret\nSwap16(unsigned short):\n  rev16 w0, w0\n  ret\n```\n\n\nUsing 32-bit `bswap`s, the algorithm can take a 4-byte _chunk_ of bytes from either end into registers, `bswap` the register, and then place the reversed _chunks_ at the opposite ends. As the algorithm gets closer to the center it can use smaller 16-bit swaps(aka a 16-bit rotate) should it encounter 2-byte chunks and eventually do serial swaps to anything left over.\n\n![](/images/Swap32.gif)\n\nand this of course can be expanded into a 64-bit `bswap` on a 64-bit architecture allowing for even larger chunks to be reversed at once. Once again, first exhaust as many 8-byte swaps, as possible, then do the 4-byte swaps, then the two-2byte swaps, and finally fallback onto the serial 1-byte swaps if need be:\n\n![](/images/Swap64.gif)\n\nGiven an array of `11` bytes to be reversed(odd number, so the middle byte stays the same), divide the array size by two to get the number of _single-element_ swaps to do(using whole-integer arithmetic):\n\n\u003e `11 / 2 = 5`\n\nSo `5` single-element serial swaps are needed to reverse this array. Now that there is a way to do `4` element chunks at once too, integer-divide this result `5` again by `4` to know how many _four-element_ swaps needed. The remainder of this division is the number of serial swaps still needed once all the four-element swaps have been exhausted:\n\n\u003e `5 / 4 = 1`\n\u003e \n\u003e `5 % 4 = 1`\n\nSo only one 4-byte `bswap`-swap and one `naive`-swap is needed to fully reverse an 11-element array. Now the 1-byte qReverse template specialization can be added.\n\n```cpp\n// Reverse an array of 1-byte elements(such as std::uint8_t)\n\n// A specialization of the above implementation for 1-byte elements\n// Does not call assignment or copy overloads\n// Accelerated using - 64,32 and 16 bit bswap instructions\ntemplate\u003c\u003e\ninline void qReverse\u003c1\u003e(void* Array, std::size_t Count)\n{\n\tstd::uint8_t* Array8 = reinterpret_cast\u003cstd::uint8_t*\u003e(Array);\n\tstd::size_t i = 0;\n\n\t// Using a new iteration variable \"j\" to illustrate that we know\n\t// the exact amount of times we have to use our chunk-swaps\n\t// BSWAP 64\n\tfor( std::size_t j = i / 8; j \u003c ((Count / 2) / 8); ++j )\n\t{\n\t\t// Get bswapped versions of our Upper and Lower 8-byte chunks\n\t\tstd::uint64_t Lower = Swap64(\n\t\t\t*reinterpret_cast\u003cstd::uint64_t*\u003e(\u0026Array8[i])\n\t\t);\n\t\tstd::uint64_t Upper = Swap64(\n\t\t\t*reinterpret_cast\u003cstd::uint64_t*\u003e(\u0026Array8[Count - i - 8])\n\t\t);\n\n\t\t// Place them at their swapped position\n\t\t*reinterpret_cast\u003cstd::uint64_t*\u003e(\u0026Array8[i]) = Upper;\n\t\t*reinterpret_cast\u003cstd::uint64_t*\u003e(\u0026Array8[Count - i - 8]) = Lower;\n\n\t\t// Eight elements at a time\n\t\ti += 8;\n\t}\n\t// BSWAP 32\n\tfor( std::size_t j = i / 4; j \u003c ((Count / 2) / 4); ++j )\n\t{\n\t\t// Get bswapped versions of our Upper and Lower 4-byte chunks\n\t\tstd::uint32_t Lower = Swap32(\n\t\t\t*reinterpret_cast\u003cstd::uint32_t*\u003e(\u0026Array8[i])\n\t\t);\n\t\tstd::uint32_t Upper = Swap32(\n\t\t\t*reinterpret_cast\u003cstd::uint32_t*\u003e(\u0026Array8[Count - i - 4])\n\t\t);\n\n\t\t// Place them at their swapped position\n\t\t*reinterpret_cast\u003cstd::uint32_t*\u003e(\u0026Array8[i]) = Upper;\n\t\t*reinterpret_cast\u003cstd::uint32_t*\u003e(\u0026Array8[Count - i - 4]) = Lower;\n\n\t\t// Four elements at a time\n\t\ti += 4;\n\t}\n\t// BSWAP 16\n\tfor( std::size_t j = i / 2; j \u003c ((Count / 2) / 2); ++j )\n\t{\n\t\t// Get bswapped versions of our Upper and Lower 4-byte chunks\n\t\tstd::uint16_t Lower = Swap16(\n\t\t\t*reinterpret_cast\u003cstd::uint16_t*\u003e(\u0026Array8[i])\n\t\t);\n\t\tstd::uint16_t Upper = Swap16(\n\t\t\t*reinterpret_cast\u003cstd::uint16_t*\u003e(\u0026Array8[Count - i - 2])\n\t\t);\n\n\t\t// Place them at their swapped position\n\t\t*reinterpret_cast\u003cstd::uint16_t*\u003e(\u0026Array8[i]) = Upper;\n\t\t*reinterpret_cast\u003cstd::uint16_t*\u003e(\u0026Array8[Count - i - 2]) = Lower;\n\n\t\t// Two elements at a time\n\t\ti += 2;\n\t}\n\t// Everything else that we can not do a bswap on, we swap normally\n\t// Naive swaps\n\tfor( ; i \u003c Count / 2; ++i )\n\t{\n\t\t// Exchange the upper and lower element as we work our\n\t\t// way down to the middle from either end\n\t\tstd::uint8_t Temp(Array8[i]);\n\t\tArray8[i] = Array8[Count - i - 1];\n\t\tArray8[Count - i - 1] = Temp;\n\t}\n}\n```\n\nOn some architectures and compilers, the [movebe](https://www.felixcloutier.com/x86/MOVBE.html) instruction may be emitted which is a CPU instruction that can either read OR write from a memory location AND swap the endian of it, all in one instruction. This instruction is supported since the `haswell` architecture of intel processors and `excavator` architecture of AMD processors and will be used automatically if you use `-march=native` with a processor that supports it.\n\nAnd now some benchmarks: on a _i3-6100_ with _8gb of DDR4 ram_. I automated the benchmark process across several different array-sizes giving each array-size `10,000` array-reversal trials before getting an average execution time for the given array-size. Using g++ compile flags: `-m64 -Ofast -march=native` these are the results of comparing the execution time of the current bswap `qreverse` algorithm against `std::reverse`:\n\nElement Count|std::reverse|qReverse|Speedup Factor\n---|---|---|---\n8|19 ns|19 ns|*1.000*\n16|20 ns|19 ns|**1.053**\n32|24 ns|23 ns|**1.043**\n64|36 ns|23 ns|**1.565**\n128|54 ns|21 ns|**2.571**\n256|90 ns|22 ns|**4.091**\n512|159 ns|26 ns|**6.115**\n1024|298 ns|35 ns|**8.514**\n100|43 ns|21 ns|**2.048**\n1000|290 ns|36 ns|**8.056**\n10000|2740 ns|191 ns|**14.346**\n100000|27511 ns|1739 ns|**15.820**\n1000000|279525 ns|24710 ns|**11.312**\n59|32 ns|22 ns|**1.455**\n79|43 ns|27 ns|**1.593**\n173|63 ns|29 ns|**2.172**\n6133|1680 ns|127 ns|**13.228**\n10177|2784 ns|190 ns|**14.653**\n25253|6864 ns|455 ns|**15.086**\n31391|8548 ns|564 ns|**15.156**\n50432|13897 ns|875 ns|**15.882**\n\n\nAnd so across the board there are speedups up to _**x15.8!**_ before dipping down a bit for the more larger array sizes potentially due to the accumulation of cache misses with such large amounts of data. The algorithm reaches out to either end of a potentially massive array which lends itself to an accumulation of cache misses at some point. Still a _very_ large and significant speedup over `std::reverse` consistantly without trying to do some `_mm_prefetch` arithmetic to get the cache to behave.\n\n# SIMD\n\nThe `bswap` instruction can reverse the byte-order of `2`, `4`, or `8` bytes, but several x86 extensions later and now it is possible to swap the byte order of `16`, `32`, even `64` bytes all at once through the use of `SIMD`. `SIMD` stands for *Single Instruction Multiple Data* and allows operation upon multiple lanes of data in parallel using only a single instruction. Much like `bswap` which atomically reverses all four bytes in a register, `SIMD` provides an entire instruction set of arithmetic that allows manipulation of multiple instances of data at once in parallel using a single instruction. These chunks of data that are operated upon tend to be called `vectors` of data. Multiple bytes of data can then be elevated into a `vector` register to reverse its order and place it on the opposite end similarly to the `bswap` implementation but with even larger chunks.\n\nThese additions to the algorithm will span higher-width chunks of bytes and will be append above the chain of `bswap` accelerated swap-loops to esure that the largest swaps are exhausted first before the smaller ones. Over the years the x86 architecture has seen many generations of `SIMD` implementations, improvements, and instruciton sets:\n\n- `MMX` (1996)\n- `SSE` (1999)\n- `SSE2` (2001)\n- `SSE3` (2004)\n- `SSSE3` (2006)\n- `SSE4 a/1/2` (2006)\n- `AVX` (2008)\n- `AVX2` (2013)\n- `AVX512` (2015)\n\nSome are kept around for compatibilities sake(`MMX`) and some are so recent, elusive, or so _vendor-specific_ to Intel or AMD that you're probably not likely to have a processor that features it(`SSE4a`). Some are very specific to enterprise hardware (such as `AVX512`) and are not likely to be on consumer hardware either. Other architectures may also have their own implementation of SIMD such as ARM's simd co-processor `NEON`.\n\nAt the moment (July 21, 2017) the steam hardware survey states that **94.42%** of all CPUs on Steam feature `SSSE3`([store.steampowered.com/hwsurvey/](http://store.steampowered.com/hwsurvey/)). `SSSE3` is what will be used as first step into higher `SIMD` territory. `SSSE3` in particular due to its `_mm_shuffle_epi8` instruction which lets allows the processor to _shuffle_ bytes within our 128-bit register with relative ease for illustrating this implementation.\n\n# SSSE3\n\n`SSE` stands for \"Streaming SIMD Extensions\" while `SSSE3` stands for \"Supplemental Streaming SIMD Extensions 3\" which is the _fourth_ iteration of `SSE` technology. SSE introduces registers that allow for some `128` bit vector arithmetic. In C or C++ code the intent to use these registers is represented using types such as `__m128i` or `__m128d` which tell the compiler that any notion of _storage_ for these types should find their place within the 128-bit `SSE` registers when ever possible. Intrinsics such as `_mm_add_epi8` which will add two `__m128i`s together, and treat them as a _vector_ of 8-bit elements are now available within C and C++ code. The `i` and `d` found in `__m128i` and `__m128d` are to notify intent of the 128-register's interpretation as `i`nteger and `d`ouble respectively. `__m128` is assumed to be a vector of four `floats` by default. Since integer-data is what is being operated upon, the `__m128i` data type will be used as our data representation which gives access to the `_mm_shuffle_epi8` instruction. Note that `SSSE3` requires the gcc compile flag `-mssse3`.\n\nNow to draft a `SSSE3` byte swapping implementation and create a simulated 16-byte `bswap` using `SSSE3`. First, add `#include \u003ctmmintrin.h\u003e` in C or C++ code to expose every intrinsic from `MMX` up until `SSSE3` to your current source file. Then, use the instrinsic `_mm_loadu_si128` to `load` an `u`naligned `s`igned `i`nteger vector of `128` bits into a `__m128i` variable. At a hardware level, _unaligned_ data and _aligned_ data interfaces with the memory hardware slightly differently and can provide for some further slight speedups should data-alignment be guarenteed. No assumption can be made about the alignment of the pointers being passed to qReverse so unaligned memory access will be used. When done with the vector-arithmetic, call an equivalent `_mm_storeu_si128` which stores the vector data into an unaligned memory address. This `SSSE3` implementation will go right above the previous `Swap64` implementation, ensuring that our algorithm exhausts as much of the larger chunks as possible before resorting to the smaller ones:\n\n```cpp\n#include \u003ctmmintrin.h\u003e\n\n...\nfor( std::size_t j = i / 16; j \u003c ((Count / 2) / 16); ++j )\n{\n\tconst __m128i ShuffleRev = _mm_set_epi8(\n\t\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n\t);\n\t// Load 16 elements at once into one 16-byte register\n\t__m128i Lower = _mm_loadu_si128(\n\t\treinterpret_cast\u003c__m128i*\u003e(\u0026Array8[i])\n\t);\n\t__m128i Upper = _mm_loadu_si128(\n\t\treinterpret_cast\u003c__m128i*\u003e(\u0026Array8[Count - i - 16])\n\t);\n\n\t// Reverse the byte order of our 16-byte vectors\n\tLower = _mm_shuffle_epi8(Lower, ShuffleRev);\n\tUpper = _mm_shuffle_epi8(Upper, ShuffleRev);\n\n\t// Place them at their swapped position\n\t_mm_storeu_si128(\n\t\treinterpret_cast\u003c__m128i*\u003e(\u0026Array8[i]),\n\t\tUpper\n\t);\n\t_mm_storeu_si128(\n\t\treinterpret_cast\u003c__m128i*\u003e(\u0026Array8[Count - i - 16]),\n\t\tLower\n\t);\n\n\t// 16 elements at a time\n\ti += 16;\n}\n// Right above the Swap64 implementation...\nfor( std::size_t j = i / 8; j \u003c ( (Count/2) / 8 ) ; ++j)\n...\n```\n\nThis basically implements a beefed-up 16-byte `bswap` using `SSSE3`. The heart of it all is the `_mm_shuffle_epi8` instruction which _shuffles_ the vector in the first argument according to the vector of byte-indices found in the second argument and returns this new _shuffled_ vector. A constant vector `ShuffleRev` is declared using `_mm_set_epi8` with each byte set to the index of where it should get its byte from(starting from least significant byte). You might read it as going from 0 to 15 in ascending order but this is actually indexing the bytes in reverse order which gives a fully reversed 16-bit sub-array of bytes.\n\n![](images/SSSE3.gif)\n\nNow for some speed tests.\n\nElement Count|std::reverse|qReverse|Speedup Factor\n---|---|---|---\n8|19 ns|19 ns|*1.000*\n16|22 ns|20 ns|**1.100**\n32|27 ns|20 ns|**1.350**\n64|37 ns|21 ns|**1.762**\n128|55 ns|23 ns|**2.391**\n256|91 ns|24 ns|**3.792**\n512|158 ns|31 ns|**5.097**\n1024|297 ns|42 ns|**7.071**\n100|43 ns|21 ns|**2.048**\n1000|291 ns|42 ns|**6.929**\n10000|2743 ns|261 ns|**10.510**\n100000|27523 ns|2966 ns|**9.280**\n1000000|279812 ns|33832 ns|**8.271**\n59|32 ns|21 ns|**1.524**\n79|43 ns|24 ns|**1.792**\n173|62 ns|29 ns|**2.138**\n6133|1683 ns|185 ns|**9.097**\n10177|2787 ns|291 ns|**9.577**\n25253|6862 ns|712 ns|**9.638**\n31391|8546 ns|916 ns|**9.330**\n50432|13893 ns|1497 ns|**9.281**\n\n\nSpeedups of up to _**x10.5**_!... but this is lower than the `bswap` version which reached up to _**x15.8**_? Maybe some loop unrolling or some prefetching might help this algorithm play nice with the cache. In this implementation only two out of the available 8 registers are being used as well so there is some great room for improvement(Todo)\n\n# AVX2\n\nThe implementation can go even further to work with the even larger 256-bit registers that the `AVX/AVX2` extension provides and reverse *32 byte chunks* at a time. The implementation is very similar to the `SSSE3` one: load in *unaligned* data into a 256-bit register using the `__m256i` type. The issue with `AVX/AVX2` is that the `256-bit` register is actually two individual `128-bit` _lanes_ being operated in parallel as one larger `256-bit` register and overlaps in functionality with the `SSE` register almost as an additional layer of abstraction added upon `SSE`. Now here's where things get tricky, there is no `_mm256_shuffle_epi8` instruction that works like you'd think it would. Since it's just operating on two 128-bit lanes in parallel, `AVX/AVX2` instructions introduces a limitation in which some cross-lane arithmetic requires special cross-lane attention. Some instructions will accept 256-bit `AVX` registers but only actually operates upon 128-bit lanes. The trick here is that rather than trying to reverse a 256-bit register atomically in one go, instead reverse the bytes within the two 128-bit lanes, as if shuffling two 128-bit registers like in the `SSSE3` implementation, and then reverse the two 128-bit lanes themselves with whatever cross-lane arithmetic that _is_ available in `AVX/AVX2`. Note that `AVX2` requires the gcc compile flag `-mavx2`.\n\n[_mm256_shuffle_epi8](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=AVX,AVX2\u0026text=shuffle\u0026expand=4726) is an `AVX2` instruction that shuffles the two 128-bit lanes of the 256-bit register much like the `SSSE3` intrinsic so this can be taken care of first.\n\n```cpp\nconst __m256i ShuffleRev = _mm256_set_epi8(\n\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15, // first 128-bit lane\n\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15  // second 128-bit lane\n);\n// Load 32 elements at once into one 32-byte register\n__m256i Lower = _mm256_loadu_si256(\n\treinterpret_cast\u003c__m256i*\u003e(\u0026Array8[i])\n);\n__m256i Upper = _mm256_loadu_si256(\n\treinterpret_cast\u003c__m256i*\u003e(\u0026Array8[Count - i - 32])\n);\n\n// Reverse each the bytes in each 128-bit lane\nLower = _mm256_shuffle_epi8(Lower,ShuffleRev);\nUpper = _mm256_shuffle_epi8(Upper,ShuffleRev);\n```\n\nSo in the large 256-bit register, the two 128-bit lanes are now reversed, but now the 128-bit lanes themselves must be reversed. [_mm256_permute2x128_si256](https://software.intel.com/en-us/node/524015) is another `AVX2` instruction that permutes the 128-bit lanes of two 256-bit registers:\n\n![](/images/_mm256_permute2x128_si256.jpg)\n\nGiven two big 256-bit vectors and an 8-byte immediate value it can select how the new 256-bit vector it builds is going to be assembled. Pass in the same variable for both of the arguments and \"picking\" from them as if they were just 2-element arrays of 16-byte elements can simulate a big 128-bit cross-lane swap(think of it like `__m128i SomeAVXRegister[2]` and going `SomeAVXRegister[0]` or `SomeAVXRegister[1]` ). In a way, this is also a big 128-bit \"rotate\" if you can visualize it.\n\n```cpp\n...\nfor( std::size_t j = i / 32; j \u003c ((Count / 2) / 32); ++j )\n{\n\tconst __m256i ShuffleRev = _mm256_set_epi8(\n\t\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15,\n\t\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9,10,11,12,13,14,15\n\t);\n\t// Load 32 elements at once into one 32-byte register\n\t__m256i Lower = _mm256_loadu_si256(\n\t\treinterpret_cast\u003c__m256i*\u003e(\u0026Array8[i])\n\t);\n\t__m256i Upper = _mm256_loadu_si256(\n\t\treinterpret_cast\u003c__m256i*\u003e(\u0026Array8[Count - i - 32])\n\t);\n\n\t// Reverse the bytes inside each of the two 16-byte lanes\n\tLower = _mm256_shuffle_epi8(Lower,ShuffleRev);\n\tUpper = _mm256_shuffle_epi8(Upper,ShuffleRev);\n\n\t// Reverse the order of the 16-byte lanes\n\tLower = _mm256_permute2x128_si256(Lower,Lower,1);\n\tUpper = _mm256_permute2x128_si256(Upper,Upper,1);\n\n\t// Place them at their swapped position\n\t_mm256_storeu_si256(\n\t\treinterpret_cast\u003c__m256i*\u003e(\u0026Array8[i]),\n\t\tUpper\n\t);\n\t_mm256_storeu_si256(\n\t\treinterpret_cast\u003c__m256i*\u003e(\u0026Array8[Count - i - 32]),\n\t\tLower\n\t);\n\n\t// 32 elements at a time\n\ti += 32;\n}\n// Right above the SSSE3 implementation\n...\n```\n\n![](images/AVX2.gif)\n\nBenchmarks:\n\nElement Count|std::reverse|qReverse|Speedup Factor\n---|---|---|---\n8|19 ns|19 ns|*1.000*\n16|21 ns|21 ns|*1.000*\n32|26 ns|20 ns|**1.300**\n64|37 ns|22 ns|**1.682**\n128|54 ns|20 ns|**2.700**\n256|91 ns|24 ns|**3.792**\n512|159 ns|27 ns|**5.889**\n1024|298 ns|36 ns|**8.278**\n100|45 ns|20 ns|**2.250**\n1000|292 ns|36 ns|**8.111**\n10000|2739 ns|189 ns|**14.492**\n100000|27515 ns|1714 ns|**16.053**\n1000000|279701 ns|25417 ns|**11.004**\n59|32 ns|21 ns|**1.524**\n79|44 ns|25 ns|**1.760**\n173|63 ns|29 ns|**2.172**\n6133|1681 ns|127 ns|**13.236**\n10177|2782 ns|192 ns|**14.490**\n25253|6863 ns|449 ns|**15.285**\n31391|8545 ns|556 ns|**15.369**\n50432|13888 ns|875 ns|**15.872**\n\n\nA speedup of up to _**x16.053**_!\n\n# AVX512\n\n`AVX512` is particularly rare out in the commercial world. Even so, the algorithm can take that much more of a step forward and operate upon massive 512-bit bit registers. This will allow a swap of `64` bytes of data at once. At the moment, C and C++ compiler implementations of the `AVX512` instruction set are spotty at best. There is the benefit of the [_mm512_shuffle_epi8](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=4729,4753\u0026text=_mm512_shuffle_epi8) instruction that will allow the shuffling of the four 128-lane registers within the 512-bit register with 8-bit indexes though there is not a confident implementation of [_mm512_set_epi8](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#=undefined\u0026avx512techs=AVX512F\u0026expand=4726,4038,4594,4594,4618,4618\u0026text=_mm512_set_epi8) to be found in MSVC or GCC. There is [_mm512_set_epi32](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#=undefined\u0026expand=4726,4038,4594,4594,4618,4618,4618,4611\u0026text=_mm512_set_epi32\u0026avx512techs=AVX512F) which will require generation of the `ShuffleRev` constant to use 32-bit integers rather than 8-bit integers. After the initial `_mm512_shuffle_epi8` the four lanes still must be reversed due to the need for cross-lane arithmetic so an additional [_mm512_permutexvar_epi64](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=4726,4594,4729,3972,4029,4029,3930,4729,3930,4029,4589,4029,4029,4047,4047\u0026avx512techs=AVX512F\u0026text=_mm512_permutexvar_epi64) is needed to truely complete the reversal. This is similar to what had to be done for the `AVX2` implementation above.\n\n`AVX512` is not a single set of instructions. `AVX512` has different subsets which may or may not be implemented for a particular processor. For example there is `AVX512CD` for conflict detection and `AVX512ER` for exponential and reciprocal instructions though ALL implementations of `AVX512` _require_ that `AVX512F`(AVX-512 Foundation) be implemented. `_mm512_shuffle_epi8` is an instruction implemented by the `AVX512BW` subset which adds **B**yte and **W**ord operations while `_mm512_setepi32` and `_mm512_permutexvar_epi64` are `AVX512F` so `_mm512_shuffle_epi8` is the only \"stretch\" requirement involved here. `AVX512BW` is currently supported by the current Skylake-X processors and is planned to be implemented more commonly in future processors. For reference, a current map of `AVX512` subset implementations(as of September 3, 2017).\n\n![](images/avx512-cpus.png)\n\nIn GCC, specific subsets of `AVX512` must be enabled using compile flags:\n\nSubset|Flag\n-|-\n**Foundation**|`-mavx512f`\nPrefetch|`-mavx512pf`\nExponential/Reciprocal|`-mavx512er`\nConflict Detection|`-mavx512cd`\nVector Length|`-mavx512vl`\n**Byte And Word**|`-mavx512bw`\nDoubleword and Quadword|`-mavx512dq`\n*Integer Fused Multiply Add*|`-mavx512ifma`\n*Vector Byte Manipulation*|`-mavx512vbmi`\n\n\n`_mm512_shuffle_epi8` and requires the `-mavx512bw` flag to compile in gcc while the rest only requires `-mavx512f`.\n\n```cpp\n// Could have done:\nconst __m512i ShuffleRev = _mm512_set_epi8(\n\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\n\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\n\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\n\t0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n);\n// but instead have to do the more awkward:\nconst __m512i ShuffleRev = _mm512_set_epi32(\n\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f,\n\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f,\n\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f,\n\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f\n);\n```\n\nThe full `AVX512` implementation:\n\n```cpp\n...\n\tfor( std::size_t j = i / 64; j \u003c ((Count / 2) / 64); ++j )\n\t{\n\t\t// Reverses the 16 bytes of the four  128-bit lanes in a 512-bit register\n\t\tconst __m512i ShuffleRev8 = _mm512_set_epi32(\n\t\t\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f,\n\t\t\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f,\n\t\t\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f,\n\t\t\t0x00010203, 0x4050607, 0x8090a0b, 0xc0d0e0f\n\t\t);\n\n\t\t// Reverses the four 128-bit lanes of a 512-bit register\n\t\tconst __m512i ShuffleRev64 = _mm512_set_epi64(\n\t\t\t1,0,3,2,5,4,7,6\n\t\t);\n\n\t\t// Load 64 elements at once into one 64-byte register\n\t\t__m512i Lower = _mm512_loadu_si512(\n\t\t\treinterpret_cast\u003c__m512i*\u003e(\u0026Array8[i])\n\t\t);\n\t\t__m512i Upper = _mm512_loadu_si512(\n\t\t\treinterpret_cast\u003c__m512i*\u003e(\u0026Array8[Count - i - 64])\n\t\t);\n\n\t\t// Reverse the byte order of each 128-bit lane\n\t\tLower = _mm512_shuffle_epi8(Lower,ShuffleRev8);\n\t\tUpper = _mm512_shuffle_epi8(Upper,ShuffleRev8);\n\n\t\t// Reverse the four 128-bit lanes in the 512-bit register\n\t\tLower = _mm512_permutexvar_epi64(ShuffleRev64,Lower);\n\t\tUpper = _mm512_permutexvar_epi64(ShuffleRev64,Upper);\n\n\t\t// Place them at their swapped position\n\t\t_mm512_storeu_si512(\n\t\t\treinterpret_cast\u003c__m512i*\u003e(\u0026Array8[i]),\n\t\t\tUpper\n\t\t);\n\t\t_mm512_storeu_si512(\n\t\t\treinterpret_cast\u003c__m512i*\u003e(\u0026Array8[Count - i - 64]),\n\t\t\tLower\n\t\t);\n\n\t\t// 64 elements at a time\n\t\ti += 64;\n\t}\n\t// Above the AVX2 implementation\n...\n```\n\n![](images/AVX512.gif)\n\nSince `AVX512` is pretty rare on consumer hardware at the moment: [Intel provides an emulator](https://software.intel.com/en-us/articles/intel-software-development-emulator) that can provide for some verification that the algorithm properly reverses the array. The emulator is no grounds for a proper hardware benchmark though. After creating a simple test program to verify that the array has been reversed it can be ran through the emulator and verified:\n\n`sde64 -mix -no_shared_libs  -- ./Verify1 128`\n\n```\nOriginal:\n0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127\nReversed:\n127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0\n[PASS] Array Reversed\n```\n\nThe `-mix` will cause the software development emulator to audit the execution of the program and the instructions it encounters into a `sde-mix-out.txt` file. This file is massive by default so `-no_shared_libs` removes the auditing of shared libraries(such as the standard libraries) from the report. With this the execution summery of `qreverse\u003c1\u003e` can be examined:\n\n```\n# $dynamic-counts-for-function: void qReverse\u003c1ul\u003e(void*, unsigned long)  IMG: /qreverse/build/Verify1 at [0x4e1ffd40a0, 0x4e1ffd4e3e)   1.442%\n#\n# TID 0\n#       opcode                 count\n#\n...\n*isa-set-AVX512BW_512                                                  4\n*isa-set-AVX512F_512                                                   6\n...\n*category-AVX512                                                       4\n...\n*avx512                                                               10\n...\n...\nVMOVDQA64                                                              2  \u003c Note these are called only twice which\nVMOVDQU64                                                              2    makes sense given a 128-byte array\nVMOVDQU8                                                               2    and only needing one AVX-512 swap\nVPERMQ                                                                 2\nVPSHUFB                                                                2\n*total                                                                75\n\n```\n\nNot only are the `AVX512BW` instructions verified to have ran and worked but the entire reversal of `128` elements took only `75` instructions in total!\n\nI recently acquired an Intel i9-7900x `BX80673I97900X` which features a large portion of the `AVX512` subsets and is capable of providing some actual hardware benchmarks for this implementation.\nHere the benchmark is compiled using Visual Studio 2017 for x64-Release mode. \n\nElement Count|std::reverse|qReverse|Speedup Factor\n---|---|---|---\n8|63 ns|59 ns|**1.068**\n16|62 ns|61 ns|**1.016**\n32|74 ns|59 ns|**1.254**\n64|104 ns|61 ns|**1.705**\n128|80 ns|18 ns|**4.444**\n256|90 ns|20 ns|**4.500**\n512|157 ns|22 ns|**7.136**\n1024|276 ns|28 ns|**9.857**\n100|44 ns|20 ns|**2.200**\n1000|269 ns|30 ns|**8.967**\n10000|2504 ns|112 ns|**22.357**\n100000|24222 ns|1368 ns|**17.706**\n1000000|236354 ns|21192 ns|**11.153**\n59|33 ns|21 ns|**1.571**\n79|40 ns|23 ns|**1.739**\n173|58 ns|29 ns|**2.000**\n6133|1438 ns|93 ns|**15.462**\n10177|2481 ns|147 ns|**16.878**\n25253|5794 ns|332 ns|**17.452**\n31391|7397 ns|420 ns|**17.612**\n50432|11915 ns|858 ns|**13.887**\n\nA plateau of speedups up to _**x22.357**_!\n\n# Misc\n\nOnce we work our way down the middle and end up with something like `4` \"middle\" elements left then we are just one `Swap32` left from having the entire array reversed. What if we worked our way down to the middle and ended up with `5` elements though? This would not be possible actually so long as we have `Swap16`. `5` middle elements would mean we have `one middle element` with `two elements on either side`. Our `for( std::size_t j = i/2; j \u003c ( (Count/2) / 2)` would catch that and `Swap16` the two elements on either side, getting us just `1` element left right in the middle which can stay right where it is within a reversed array(since the middle-most element in an odd-numbered array is our *pivot* and doesn't have to move anywhere).\n\nLater we can find a way to accelerate our algorithm to have it consider these pivot-cases efficiently so that rather than calling two `Swap16`s on either half of a 4-byte case it could just call one last `Swap32` or even a bigger before it even parks itself in that situation of having to use the naive swap. Something like this could remove the use of the naive swap pretty much entirely.\n\n[Here's a little writeup of how to \"count\" greedy algorithms such as this one!](https://gist.github.com/Wunkolo/56ed3c2d1de5dcd890464af1b44c03cd)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwunkolo%2Fqreverse","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwunkolo%2Fqreverse","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwunkolo%2Fqreverse/lists"}