One question to PyPy developers: CPython 3.5 [1] introduced math.gcd which uses Lehmer's algorithm [2], are there any plans to include it in PyPy, too?
When you say "details very much might have changed between then and now", are there any news on bringing in the float128 type? I mean, do you happen to know whether there is any reasonable chance of having it in Rust at all?
- Why the chose stack-based VM, rather than register-based one?
- I see the docs mention Float128 type, is this a real possibility? What it their opinion on having Float128?
- there doesn't seem to be any support for ADC instruction ("add with carry") which would be very useful for implementing multi-precision numeric types. Are the plans to support ADC and the like or not? How to implement, say BigInt, with WebAssembly?
- maybe I misunderstood but when adding two integers result in an overflow, does it trigger the "trap"? I mean, lot of time (e.g. modular arithmetic) one does what fast "wrap around" (i.e. modulo 2^INT_SIZE) in integer types. Is this behaviour (of C) going to stay in WebAssembly?
Or try sorting points (struct of two float64s) by the x-coordinate, and compare the timing with similar JavaScript code running in V8. You might be surprised...
Do you perhaps happen to have a link to the results of these benchmarks? I'm desperately looking for some, and http://lh3lh3.users.sourceforge.net/reb.shtml seems to be quite date.
Other sorting techniques may be faster. For example, using radix sorting, you can sort n word-sized integers by scanning the data a few bits at a time. Each scan can be done in linear time, and the number of scans depends on the word length w. Hence, the time for radix sorting is proportional to nw. Here, it’s easy to make a mistake. On most computers, w is a small number (typically 32 or 64), and you might be tempted to state that radix sorting is a linear time sorting algorithm. Not so. The algorithm will only work if w ≥ log n. If not, you wouldn’t even be able to store the numbers. Since each memory address is a word consisting of w bits, the address space won’t accommodate n numbers if w < log n. Hence, in the unit-cost RAM model, radix sort also runs in time proportional to n log n.
What does the "zero will be produced once less often than every other output" for negative qualities of XorShift and XorShift* means? That they are not able to generate "0"?
Also, does anyone know if PCG is in use somewhere today?