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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7409b25d-8638-36ff-4c2e-7253da5ab672%40trustica.cz.
