Why is it slower than native sort on my system?

[DanielMazurkiewicz]

Tests on Ryzen 2700U

Firefox 73, Linux x86_64, AMD RAVEN (DRM 3.36.0, 5.5.7-arch1-1, LLVM 9.0.1) ‎‎‎ 32,768 gpu.sort 29ms gpu.sortAsync 36ms Float64Array.sort 12ms

       131,072

gpu.sort 91ms gpu.sortAsync 98ms Float64Array.sort 49ms

       524,288

gpu.sort 263ms gpu.sortAsync 368ms Float64Array.sort 189ms

      2,097,152

gpu.sort 1,049ms gpu.sortAsync 2,366ms Float64Array.sort 726ms

      8,388,608

gpu.sort 4,811ms gpu.sortAsync 10,116ms Float64Array.sort 3,748ms

[demskie]

Thanks for sharing your results!

Unfortunately your results make sense given what I've learned.

1) The native sort method for TypedArrays is extremely fast. Especially on Firefox.

2) If I had to guess, I'd say less than 5% of the overall execution time was spent actually sorting. The primary bottleneck for this kind of work is the time it takes to transfer data between the CPU and GPU contexts. This is especially true with regards to WebGL.

I planned on sorting generic Javascript arrays where the browser's native sort performs much worse. But unfortunately it wasn't viable due to the performance penalty incurred whilst casting numbers and strings to an ArrayBuffer.

Maybe WASM can do that casting much faster?

[DanielMazurkiewicz]

Maybe WASM can do that casting much faster?

To pass data to WASM you have to cast them as well :-D I'm pretty sure that casting itself isn't a bottleneck. What could be an potential issue here is a way of handling serialization.

[demskie]

To pass data to WASM you have to cast them as well

Yeah looks like your right. It appears the only way to interact with WASM is through TypedArrays. I don't know why I was thinking it'd be like webworkers where you can shove pretty much anything through.