fictive

this is an intrinsic. the intrinsic is in smmintrin.h which is included by nmmintrin.h nmmintrin.h should be included because thats what the code says happens when the -DSIMDE_X86_SSE4_2_H. hello???

diff --git a/include/simd-compat/pmmintrin.h b/include/simd-compat/pmmintrin.h
index 8ba6b36d..5b5d9c22 100644
--- a/include/simd-compat/pmmintrin.h
+++ b/include/simd-compat/pmmintrin.h
@@ -32,6 +32,7 @@
 
 // assume SSE3 only on macOS
 # ifndef ARCH_MAC
+#  include <smmintrin.h>
 #  include "simde/x86/sse3.h"
 # endif

it is apparently wrapping whatevermmintrin.h with its own "smart" versions. but then relying on the compiler's provided immintrin.h to include smmintrin before pmmintrin. and my versions of gcc/clang do not do this. what.

also what do you MEEEAN "assume SSE3 only on macOS" ????????? lmao

this is an intrinsic. the intrinsic is in smmintrin.h which is included by nmmintrin.h nmmintrin.h should be included because thats what the code says happens when the -DSIMDE_X86_SSE4_2_H. hello???

but i ain't buyin a mac tho

An excerpt from a document we were writing earlier today:

How Many?

Any ideal solution should account for some users having hundreds or thousands of identities. Most users will only have a handful, somewhere in the 2-30 range, but I know multiple systems that are hovering around 100 or so.

PluralKit has a default limit of 1000 identities for an account. I went and asked some communities I'm in and learned that some systems do hit that limit, and ask for that limit to be increased for their account.

There's a variety of reasons for that, but the end consequence is the same: UX and protocol decisions should accommodate a large number of identities linked to an account. Friction for creating and modifying identities should be low. A large quantity of identities should not cause performance problems. Any hard-cap on the number of identities an account can have should be generous. Most people will not approach those numbers, but some will.

Obviously there are computational limits we need to work within, but we should avoid getting ourselves stuck with inefficient decisions here.