4 ms·

Can verify does not work on an M1 MacBook Air with BMW AM radio, tried the _mm_stream_si128 version couldn't hear any of the tunes on any frequency between 1550

by soheil 6y ago

Can verify does not work on an M1 MacBook Air with BMW AM radio, tried the _mm_stream_si128 version couldn't hear any of the tunes on any frequency between 1550 and 1630 hz. I remember playing with Tempest probably 20 years ago. It worked on a CRT monitor, the bigger the monitor the better, I had a 21"! Even with that I had to get my computer's speakers literally right next to the monitor for it to barely work, but it was absolutely fabulous when it did!

exDM69 6y ago
Your result is hardly surprising as Apple M1 is a different CPU architecture using the ARM instruction set. It is unlikely that the CPU circuitry related to this particular function would be similar to Intel x86. This might not even work with an AMD x86 CPU. Out of curiosity, can you dump the relevant disassembly of the square_am_signal function (using `$ objdump -d mybinary`)? Note that this instruction (_mm_stream_si128) is a SSE instruction that will write 128 bits to memory, more or less bypassing the cache (as long as you write whole cache lines). This instruction is highly specific to the memory architecture in Intel x86 CPUs. When compiling for ARM, I expect that this will just be compiled to a regular store instruction.
- soheil 6y ago
  I actually compiled it with Rosetta turned on with x86_64 arch. Let me know if you still wanna see the objdump.
  - exDM69 6y ago
    If you compile it to x86_64, that _mm intrinsic will turn into a single instruction. No need to show the disassembly. Thanks for the info.
- fulldecent2 6y ago
  Thanks for your interest. If you have any advice on other instructions or M1 optimizations, I'd love to hear. My first thought is to synchronize effort of the 8 CPU and maybe even the 8 GPU. That's +12dB right there. We have a multithreaded implementation in the project already.
  - exDM69 6y ago
    No, sorry, I don't know anything about the M1. If you want to achieve something similar to _mm_stream_xxx, ie. bypassing the caches and causing bursts of DRAM traffic, try making some uncached/write combined memory mappings and writing to them. I don't know how this can be done in user space. You could try creating memory mapped buffers with OpenGL or Metal, with certain arguments you could get an uncached mapping. Another option is looking at ARM instructions for memory barriers and cache flushes. ARM's selection of instructions for dealing with caches is much richer than x86's.
fulldecent2 6y ago
Thanks for sharing. You are welcome to add to the TEST-DATA file. We just received the first field report of success with the M1 MacBook Pro here https://github.com/fulldecent/system-bus-radio/blob/master/TEST-DATA.tsv https://github.com/fulldecent/system-bus-radio/blob/master/T...

by soheil 6y ago

exDM69 6y ago

Your result is hardly surprising as Apple M1 is a different CPU architecture using the ARM instruction set. It is unlikely that the CPU circuitry related to this particular function would be similar to Intel x86. This might not even work with an AMD x86 CPU. Out of curiosity, can you dump the relevant disassembly of the square_am_signal function (using `$ objdump -d mybinary`)? Note that this instruction (_mm_stream_si128) is a SSE instruction that will write 128 bits to memory, more or less bypassing the cache (as long as you write whole cache lines). This instruction is highly specific to the memory architecture in Intel x86 CPUs. When compiling for ARM, I expect that this will just be compiled to a regular store instruction.

soheil 6y ago
I actually compiled it with Rosetta turned on with x86_64 arch. Let me know if you still wanna see the objdump.
- exDM69 6y ago
  If you compile it to x86_64, that _mm intrinsic will turn into a single instruction. No need to show the disassembly. Thanks for the info.
fulldecent2 6y ago
Thanks for your interest. If you have any advice on other instructions or M1 optimizations, I'd love to hear. My first thought is to synchronize effort of the 8 CPU and maybe even the 8 GPU. That's +12dB right there. We have a multithreaded implementation in the project already.
- exDM69 6y ago
  No, sorry, I don't know anything about the M1. If you want to achieve something similar to _mm_stream_xxx, ie. bypassing the caches and causing bursts of DRAM traffic, try making some uncached/write combined memory mappings and writing to them. I don't know how this can be done in user space. You could try creating memory mapped buffers with OpenGL or Metal, with certain arguments you could get an uncached mapping. Another option is looking at ARM instructions for memory barriers and cache flushes. ARM's selection of instructions for dealing with caches is much richer than x86's.

fulldecent2 6y ago

Thanks for sharing. You are welcome to add to the TEST-DATA file. We just received the first field report of success with the M1 MacBook Pro here https://github.com/fulldecent/system-bus-radio/blob/master/TEST-DATA.tsv https://github.com/fulldecent/system-bus-radio/blob/master/T...