On Thursday, November 19, 2015 at 6:25:19 PM UTC-5, Matthias Felleisen wrote: > Brian, > > -- when you say "raw speed", do you need "Fortran" level speed for numerical > algorithms or just "somewhat faster than Racket, almost close to C"? If it's > the latter, Rust may work out for you.
I would say more the latter - less than 2x of C speed. > -- when you say you need many cores for your computations. That sounds like > very-raw speed, not just raw speed. This may call for C after all. The example that provided the initial motivation is extremely simple - process 45M+ text records with some minor transformations (including computing a couple soundex values on first/last names). Racket came in at 2.4x faster than Ruby, but still CPU bound, and it really should be I/O bound, so I figure I'll process N records in parallel. But I'm really thinking more generally - I know I'll occasionally encounter these types of issues. > -- then again, if it is just about trying to exploit the parallelism of your > computer when possible, why not use places (or futures) in Racket? Yes, > Rust's type system makes this a bit safer. It basically rules out race > conditions via its type system. But this one depends on your take of how much > you fear race conditions and how familiar you are with a mostly-functional > approach of our CML library, which in my experience reduces this danger, too. Yes, re-implementing the Racket version with places is on my list, and I'll compare with the Rust or C multi-threaded version. I was getting ~ 10 MB/s I/O on my SSD in Racket, but I should be able to get ~ 70 MB/s, so even using 4 cores may not be quite enough. > -- if you opt for Rust, consider the callback problem. My (passive) > experience with lots of code that has to set up call backs from C to Rust, is > that this area is a bit problematic. I scanned John's blog post and didn't > see how he addressed that, though I didn't read his git repo. Perhaps there > are some examples there. And yes, in the end it's doable; it just seems to > require a lot of fiddling. In this specific case, I would probably just create a standalone program in the lower level language since it won't need much domain/business logic, so no FFI would be involved. In other cases, I'll definitely want to use FFI though, so if turns out that C is much better for FFI w/ Racket, that would influence me. > -- finally, beware of the need to drop from Rust to unsafe Rust -- where the > type system just gives up the key innovations that Rust introduces. This is > especially noticable for callbacks, but even other code (see John's) tends to > include one or the other unsafe block. > > -- Matthias Thanks - good things to consider. -- 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. For more options, visit https://groups.google.com/d/optout.
