CSV Game tests various programming languages on how fast they can parse a CSV file. All the usual suspects are represented — C, C++, Java, Rust, and so on — but Nim was missing until I added it over the weekend. It'll come as no surprise to people here but Nim is very speedy and, well, let's just say it does very well against the competition.
You can see the results in the README (look for the Timings section) and you can see the Nim code in csvreader.nim.
Very pleased with the result, as I am particularly planning to read large CSV files with Nim in the near future.
Good work
I wonder if changing the code to the following will help much?
import os, parsecsv, streams
proc main() =
var
fields = 0'i32
csv: CsvParser
let
stream = newFileStream(paramStr(1), fmRead)
csv.open(stream, paramStr(1))
while csv.readRow():
inc(fields, csv.row.len())
csv.close()
echo(fields)
main()
Making sure that fields is a 32 bit integer and wrapping the main body in a function can help speed things up a little usually.
I question the results when something beats C for speed. Either it is poor C code, or there is something weird going on.
Sure, get close or the same, but beat C for speed? You must be doing some ASM stuff that is faster than C-generated ASM (good for them, if that is the case).
@euant: I timed your code but I didn't see a consistent speed-up. Sometimes it was a few milliseconds faster, sometimes slower, so I would guess it and the original compile down to the same C. But I like the idea that there are still tweaks to be made to such a short program.
@jlp765: I watched a talk last year where the speaker — I forget who it was — explained why they stopped writing Python extensions in plain C and started using Cython. Although he was competent at C, the C produced by Cython was exemplary, and far better than anything he could produce. It could be the same with Nim: the C produced by Nim's compiler is better than the C found in libc.
Having said that, the C program was only six milliseconds slower than the Nim program, averaged over ten runs of a short benchmark (count 50,000 fields in a CSV). That's basically within the margin of error.
I question the results when something beats C for speed. Either it is poor C code, or there is something weird going on.
Or, the compiler is able to take advantage of information in language X source not available from the C source to generate better code than available C compilers? That's not hard to grasp, pre-restrict C was widely known to be slower than Fortran. Also, as @flother points out, the C generated by a good X to C compiler may be better than code anyone is likely to write by hand. The whole program optimizing Scheme to C compiler compiler Stalin was known to generate C code much faster than hand written equivalents. Unfortunately, it was also known to be very slow; but it's purpose was to generate a fast executable.
When Nim's llvm backend is stable it would be fun to have a running benchmark against C, C++, Rust, Swift, and the ldc D compiler. I think the results would be revealing.