When I saw this weblog entry, I decided to port the reverse complement benchmark to Factor. The benchmark took a whopping 51 minutes to run on my G5, compared to 3 seconds for the Java version. There are definitely some low-hanging fruit in the I/O code. I'll start working on I/O performance in Factor 0.84, and hopefully improve on the benchmark result by several orders of magnitude.
Update: I ported the benchmark wrong. The initial buffer size was wrong; 3mb versus 30mb, so there was a lot of copying going on. Fixing this, the run time decreased to 170 seconds. Still poor, but not nearly as bad. 120 seconds are spent simply reading the file, line by line. This will be the first thing I will optimize in 0.84.
Here is the benchmark code. It seems to be clearer and simpler than most of the implementations on that page.
Subscribe to:
Post Comments (Atom)
2 comments:
I suspect, if this benchmark were the other way around, you'd be calling the Hotspot/JRE developers at Sun completely incompetent. A factor of 50x-1000x slower seems pretty inc....
Its not a factor of 50x-1000x, but 40x. And I'll freely admit that Factor's I/O code is unoptimized and pretty crap.
If the JRE was this slow, Java bloggers would be making postings about how performance is not relevant in the "real world", how optimization goes against the sayings of the great design patterns gods, how slow performance helps the computer industry, etc. At least I admit when my stuff sucks.
Post a Comment