On Saturday, January 16, 2016 at 10:32:26 PM UTC-5, Brian Adkins wrote: > A while ago, I started a thread about whether Rust or C would be a better > complement to Racket. After much more Rust research/coding, I got very tired > of fighting the compiler, so I decided to blow the dust off my C skills (I > haven't done any serious coding in C since 1996), and code up the app in C. > > In about 2.5 hours, I had coded as much of the app in C as had taken many > more hours in Rust and it was about 2.5x faster and *much* easier to > understand. I knew exactly what I wanted to do for maximum performance, but I > found myself constantly fighting Rust. I've concluded that, for me, C is a > better complement. > > Anyway, the purpose for this post is to ask for some assistance in getting > the best performance out of my Racket code. After choosing a different > soundex algorithm, I was a little disappointed in the following runtime > numbers for identical functionality: > > Racket = 10.3s > Ruby = 7.61s > C = 0.472s > > Those are numbers for parsing 200K records in a fixed width format to create > a postgres bulk input file. The real data contains 45+M records, so speed is > a consideration (e.g. 1.8 min. for C vs. 38.6 min. for Racket) > > It's the fact that Racket is currently slower than Ruby which is bugging me. > Despite my rusty (no pun intended) C skills, I was able to hack a version > that does zero heap allocation and is pretty speedy, so I wouldn't expect > Racket to get close to it. On the other hand, I *would* definitely hope the > Racket version can beat the Ruby version. > > Here are the programs: > > C: https://gist.github.com/lojic/4369d9d57eb775296c92 > > Ruby: https://gist.github.com/lojic/2b91fde8e6bbb7bab1cd > > Racket: https://gist.github.com/lojic/f306104846d516761952 > > They have identical output (I measured through the first 4M input records), > and they are very similar (same functions, etc.) in style. > > Latest profile output from Racket (using open-output-nowhere as suggested by > Vincent): > > https://gist.githubusercontent.com/lojic/db6e02d0d9d88e1d5ced/raw/1002b6e6ee14f2c59b067abe6eac0488a3f2dc7a/profile.txt > > Earlier today, I had a hacked up Racket version with manual loops, etc., but > then I thought that I really shouldn't have to resort to that to beat Ruby, > so I returned the Racket code to a form that was most similar to Ruby. For > example: > > Ruby: > > def self.parse_string line, beg, len > line[beg,len].gsub("\\", '').strip > end > > Racket: > > (define (parse-string line beg end) > (string-trim (string-replace (substring line beg end) "\\" ""))) > > But I think the Ruby runtime is a little more optimized currently. In > particular, I suspect string-replace vs. gsub, string-trim vs. strip, etc. > > The real fun will come when I use a places version of the Racket code, but I > want to get decent linear speed before parallelizing. > > Ruby has no JIT, and both Ruby and Racket of C runtimes, so there doesn't > seem to be any fundamental reason why similar code shouldn't perform better > in Racket. > > By the way, I compared Racket 6.2.1 with 6.3 and the latter is 10.4% faster > for this app, so that was encouraging. > > Any help is greatly appreciated! > > Brian
Hmm... after briefly looking at the C and Racket runtimes, it appears that more of the Racket runtime is in Racket (which I think is a good thing) - for example, string-replace in Racket vs. String#gsub in C. Could that be the main difference here? I think the Ruby code is staying in the C runtime quite a bit (strip, gsub, tr!, String#[], etc.). I have mixed emotions - I like the idea of more of a language being written in itself, but I also like performance :) -- 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]. For more options, visit https://groups.google.com/d/optout.
