I was build SSE performance work on mac intel. But I found the SSE4.1 version of performance in xcode 12.4 is not as good as xcode 10.1, so I checked the assembly of my code. The one _mm_mul_epi() was translated into three pmuludq, which is the SSE2 instruction.This was normal when compiling on xcode 10.1 and _mm_mul_epi() was translated into pmuldq. Does anyone know how to fix this issue?

If you are going to sell your customers on eGPU's by blackmagic in store, why would you not plan on the integration of said eGPU processors via your update to BigSur? I spent over a $1000 on what is now a useless brick of a processing unit. The only solution that BlackMagic and Apple have to offer is to revert my system to Catalina, and Studio 16. Big Sur has been out how long now, and still no support for items you are shlepping in store Apple? Shame on you. Get the fix quick. Your business practices are showing, and I find them offensively grotesque. Keep nickel and diming your customers into oblivion as your quality degrades. I haven't considered going back to windows in decades, but now I am busting out the user manuals. Abandon ship. Apple, what a let down you have become. You used to be the pride and joy of design. Now you are the bane and boon.

Recently, the Voice Memos app from Apple got a new feature: a magic wand that performs noise reduction. This noise reduction seems to process live while the recorded audio is playing, since it doesn't pause the played audio. In the Apple documentation, there's a single reference - https://developer.apple.com/documentation/accelerate/signal_extraction_from_noise to a noise reduction, by performing a discrete cossine transform - https://en.wikipedia.org/wiki/Discrete_cosine_transform, removing the unwanted frequencies below a threshold, and then performing the inverse transform. My question is: is it a viable approach for performing live processing? If yes, how can I perform it? By calling installTap or maybe creating a custom AudioUnit?

The following C program (dgesv_ex.c) #include stdlib.h #include stdio.h /* DGESV prototype */ extern void dgesv( int* n, int* nrhs, double* a, int* lda, int* ipiv, double* b, int* ldb, int* info ); /* Main program */ int main() { /* Locals */ int n = 10000, info; /* Local arrays */ /* Initialization */ double *a = malloc(n*n*sizeof(double)); double *b = malloc(n*n*sizeof(double)); int *ipiv = malloc(n*sizeof(int)); for (int i = 0; i n*n; i++ ) { a[i] = ((double) rand()) / ((double) RAND_MAX) - 0.5; } for(int i=0;in*n;i++) { b[i] = ((double) rand()) / ((double) RAND_MAX) - 0.5; } /* Solve the equations A*X = B */ dgesv( &n, &n, a, &n, ipiv, b, &n, &info ); free(a); free(b); free(ipiv); exit( 0 ); } /* End of DGESV Example */ compiled on a Mac mini M1 with the command clang -o dgesv_ex dgesv_ex.c -framework accelerate uses only one core of the processor (as also shown by the activity monitor) me@macmini-M1 ~ % time ./dgesv_ex ./dgesv_ex 35,54s user 0,27s system 100% cpu 35,758 total I checked that the binary is of the right type: me@macmini-M1 ~ % lipo -info dgesv Non-fat file: dgesv is architecture: arm64 As a comparaison, on my Intel MacBook Pro I get the following output : me@macbook-intel ˜ % time ./dgesv_ex ./dgesv_ex 142.69s user 0,51s system 718% cpu 19.925 total Is it a known problem ? Maybe a compilation flag or else ?