> While I think everyone can agree this is just yet another terrible design decision in JavaScript
I disagree. Double was the best choice they could have made for a dynamically typed language.
1,486 karma · joined September 13, 2015
I disagree. Double was the best choice they could have made for a dynamically typed language.
* Creates a sequence of unique integers
* Uses prime numbers that are congruent to P = 3 (mod 4).
* A single iteration has noticable patterns but applying it twice already results in randomness that is sufficiently good for many use cases.
* It is "embarrassingly parallel", a simple mapping of randomValue = randomize(i). You can calculate unique and deterministic random numbers from input i in parallel threads with no sync between threads.
* Since it is a unique mapping of i to r, you can use it to shuffle data sets virtually instantly. Take the index of a value in the original array, and use it to compute the target index in the shuffled array.
* I've used it to shuffle up to 800 million items per second on a GPU, including the time it took to transfer the data from RAM to GPU. So without the IO, you could probably shuffle billions of values per second, probably mostly bound by GPU bandwidth. E.g., 700GB/s and each item is 70 bytes -> could perhabs shuffle 10 billion items per second.
Can be used to shuffle a billion points per second on the GPU with sufficient randomness for some use cases.
* I'm splitting data sets into batches of around 50-300MB, but each individual batch must be processed sequentially. Each batch loops through the data (multiple times), and every single iteration of a loop depends on state from previous iterations.
* Altough each batch essentially does the same thing, it does not operate in lockstep. Lot's of ifs, different execution paths, differently sized sub-problems, etc.
I'd benefit from having 200 CPU cores and enough RAM to fit the batches, but I can't let individual GPU threads run through batches of 50MB, each.
For my computer graphics and processing work, multithreaded tasks scale amazingly well with the number of cores so single core performance doesn't matter all that much. A single thread isn't even be able to process all the data that's streamed from an SSD. I need three threads just to process/prepare the data in the background, in addition to the main thread that keeps rendering.
I suspect it's only a matter of time until multithreading is a must for games. The additional programming effort may not have paid off if players only have 2 or 4 core CPUs, but now that 8 cores with 16 threads are increasingly common, it's going to make a difference.