Hi, On 08. 10. 19 6:58, Sam Tobin-Hochstadt wrote: > I've submitted a pull request fixing those errors and supporting > running in serial mode.
thank you for that, it's already fixed. I am actually pulling this from our internal git repository and I imported older info.rkt into the Github one. For the contracts - now it is void? instead of suggested any/c. The functions are modeled like vector-sort! - which returns #<void>. Btw, is it necessary to bump the version on pkgd.racket-lang.org in order to get it updated? When I `raco install' the package from its directory, it works fine now. When I use the github repository using plain `raco pkg install futures-sort' it still uses the old version. Just removing and re-installing does not change anything. > > One thing I notice is that it's substantially faster than > `vector-sort!` even when run in serial mode on traditional Racket (but > not on Racket CS), so perhaps this should be integrated (or there are > improvements that we can adopt). We mostly discussed that with Jens Axel on #racket - main advantage at the lowest level is the usage of fixnums for everything. This however means that the vector's size to be sorted must be `fixnum?'. Which I think is always the case on all supported architectures (addressable memory and such). > > Alex, just to clarify a couple things about futures: they block when > performing operations that are either sensitive to the current > continuation or need single-threaded access to the runtime. Vector > operations, as you see in Dominik's code, are not in this category. > Mutable hash table operations are blocking. Here's some numbers with > performance on sorting a vector with random fixnums using this package > on a 4 core machine with hyperthreading, "classic" is `vector-sort!`. > Note that the futures-sort library creates 2^k futures. > > k: 0 > cpu time: 3402 real time: 3399 gc time: 45 > k: 1 > cpu time: 3487 real time: 1834 gc time: 46 > k: 2 > cpu time: 3581 real time: 1097 gc time: 69 > k: 4 > cpu time: 5745 real time: 1014 gc time: 69 > k: 8 > cpu time: 5742 real time: 992 gc time: 45 > k: 16 > cpu time: 8111 real time: 2189 gc time: 279 > 'classic > cpu time: 4390 real time: 4388 gc time: 98 > > Here are similar numbers for Racket CS: > > k: 0 > cpu time: 2960 real time: 2960 gc time: 33 > k: 1 > cpu time: 3021 real time: 1594 gc time: 33 > k: 2 > cpu time: 3462 real time: 1154 gc time: 36 > k: 4 > cpu time: 4381 real time: 929 gc time: 36 > k: 8 > cpu time: 4406 real time: 889 gc time: 34 > k: 16 > cpu time: 7124 real time: 1655 gc time: 440 > 'classic > cpu time: 2749 real time: 2749 gc time: 51 Is there a package for these benchmarks? I created some benchmarks based on sorting vectors of varying size from 1 to 2^27 elements. It would be really nice to test this on a number of systems to get some empirical data here. The GC can sometimes surprise (me, at least). My benchmarks used (current-inexact-milliseconds) before and after each run which is not something very exact. I'll post some graphs on our company blog on Thursday probably. Thank you Sam and Alex! Cheers, Dominik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7409b25d-8638-36ff-4c2e-7253da5ab672%40trustica.cz.
