Bogosort speedup
bob099 wrote 08/23/2022 at 22:11 • -1 pointInsane idea here, is there a way to speed up the bogosort? This goes against the entire reason for it. Kind of like a friendly nuclear bomb.
askInsane idea here, is there a way to speed up the bogosort? This goes against the entire reason for it. Kind of like a friendly nuclear bomb.
ask
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
There are two versions of bogosort: deterministic and random.
For the random one, if you hijack the random function then you feed in the exact order of the elements to choose thereby resulting in the ideal complexity of O(n).
For the deterministic version, the algorithm itself cannot be sped up. However, it's implementation can be optimized. If the number of elements is known at compilation time then you could fully unroll the loop, thereby excluding any jump instructions though it could be argued that it is technically a different algorithm. Beyond that, it's going to be architecture/instruction set dependent.
* Pipelining generally allows you to rapidly execute the same instruction IF AND ONLY IF it doesn't need a register that a presently executing instruction has marked as "busy". While instructions mark registers as "busy" by the instruction using it, this is usually only for fractions of the total number of cycles that the instruction needs in order to complete. Instructions are generally a handful of cycles so you would want to use a few sets of registers to compare and move them as fast as possible. It would be a marginal improvement but a compiler could make this optimization (in theory) which is a good argument that it's not a modification to the algorithm.
* Cache levels also determine how fast an algorithm executes. For example, if you copy portions of memory into lower levels of cache (presuming the data sorted exceeds the cache) while it's being searched/sorted then there will be a marginal improvement. This could be considered a different algorithm if they are a being stickler as it requires additional code (unless you invent a programming language designed around this optimization concept).
* Processors with SIMD and MIMD instructions could possibly minimize the number of cycles required to process the same data. It would be like performing the same sort but doing it with eight elements at a time. However, this seems like it would require resolving which ones were sorted and which could easily qualify as a modification to the algorithm. However, in theory (and only theory) a compiler could optimize in this fashion though it's a very weak argument.
Are you sure? yes | no
Well, just sneak in a round of qsort with a probability of 1/n...
Are you sure? yes | no