How I Speeded Up the MAYA MOD Pipeline 2× Using an Inline…
0 reactions
How I Speeded Up the MAYA MOD Pipeline 2× Using an Inline Rolling Filter
Hello everyone, I’m sharing a comparison from the pilot MIT research of the MAYA MOD filter versions 2.04 and 2.05. The filter and materials are mainly to show what kind of interesting structures and behaviors a person can encounter on the old path.
In version 2.04 I was testing the lookup approach vs the number of memory accesses and cache behavior. Because of that, the pipeline had an extreme runtime of 7963s during the 10B test. Take it more as solving the fundamental problems and understanding the base mechanics. That is also why a new version and challenge appeared — how to make the pipeline at least 2x faster.
In version 2.05 I used a different solution based on recommendations from the comments, replacing the lookup system with an inline rolling filter (17/19), which filtered most candidates already during the first computation pass. Thanks to better cache locality, lower memory access overhead, and reduced branching, the runtime dropped to roughly half — around 3988 seconds — while keeping the same reduction ratio and the exact same number of primes found (The current reduction ratio is around 77% before the deeper primality stages).
Thanks everyone for the comments and suggestions. Soon I will also share a new project focused on a completely different filtration philosophy using spatial mapping in multiple dimensions, working with axis\_offsets, singularities, and bifurcations, where algorithms will operate in near real-time conditions. It will focus more on computational geometry and multidimensional mapping. But that will already be another league.
Have a beautiful day and thanks again for all ideas and feedback.
David
https://preview.redd.it/yrepea5odpzg1.jpg?width=1536&format=pjpg&auto=webp&s=134c006175c0764111978b8381394d509922c83d
#technology
Hello everyone, I’m sharing a comparison from the pilot MIT research of the MAYA MOD filter versions 2.04 and 2.05. The filter and materials are mainly to show what kind of interesting structures and behaviors a person can encounter on the old path.
In version 2.04 I was testing the lookup approach vs the number of memory accesses and cache behavior. Because of that, the pipeline had an extreme runtime of 7963s during the 10B test. Take it more as solving the fundamental problems and understanding the base mechanics. That is also why a new version and challenge appeared — how to make the pipeline at least 2x faster.
In version 2.05 I used a different solution based on recommendations from the comments, replacing the lookup system with an inline rolling filter (17/19), which filtered most candidates already during the first computation pass. Thanks to better cache locality, lower memory access overhead, and reduced branching, the runtime dropped to roughly half — around 3988 seconds — while keeping the same reduction ratio and the exact same number of primes found (The current reduction ratio is around 77% before the deeper primality stages).
Thanks everyone for the comments and suggestions. Soon I will also share a new project focused on a completely different filtration philosophy using spatial mapping in multiple dimensions, working with axis\_offsets, singularities, and bifurcations, where algorithms will operate in near real-time conditions. It will focus more on computational geometry and multidimensional mapping. But that will already be another league.
Have a beautiful day and thanks again for all ideas and feedback.
David
https://preview.redd.it/yrepea5odpzg1.jpg?width=1536&format=pjpg&auto=webp&s=134c006175c0764111978b8381394d509922c83d
#technology
| 4,000 mlx | |
| 7 | |
| 0 |