News for hackers. Stuff that matters.
Re:CUDA grep by scott_s on Saturday June 01, 2013 @07:27PM (#5806526)
Interesting work! But I'm unclear on the end-to-end performance comparison, which includes the cost of copying data to and from the device.

I know you guys are eyeballs deep in your data, so what's obvious to you may not be obvious to a reader. From what I can tell, your performance numbers are reported as an average per regex. But you're calculating that without including the string copying cost; you're only timing the cost of performing the computation on the GPU.

You show the overhead in absolute numbers. It seems small compared to the cost of processing the whole file, but I need to know the cost for grep to process that whole file as well. Basically, you show me a number, but you don't explain the significance of this number.

In my experience, the best way to deal with such issues is to always report entire-application performance. (This can be in addition to other numbers, of course.) That way I can say "Ah, calling grep took x seconds on average, calling their program took y seconds on average, and y < x, so they've improved performance." If you report entire-application performance, your reader doesn't need to understand the particulars to at least determine if your technique is a performance win.

Re:CUDA grep by bkase on Sunday June 02, 2013 @01:04AM (#5807394)
Thanks for the advice. As soon as we get this project to run successfully on CUDA 5, we'll update the finalreport document with the entire-application performance numbers (hopefully before the end of tomorrow).
Re:CUDA grep by rezn on Sunday June 02, 2013 @01:05PM (#5809228)
Dont mean to hijack this thread or anything, but as someone who has spent many years researching pattern matching, I was intrigued by this posting and comment. I decided to put my own library (dClass) to the end-to-end performance comparison:

https://github.com/TheWeatherChannel/dClass/wiki/dClass-vs-g...