[sword-devel] What-If: sword-api based app on computer with HT or 2+ cpu cores?

[Lynn Allan]

I speculate that applications based on the sword-api could potentially benefit from multi-threading, especially "Search". My impression is that the sword-api Search routines are single-threaded, but I could be wrong.

Concurrent apps are difficult, and not all algorithms lend themselves to it. I came across this interesting article (at least to me) from Herb Sutter. 
http://www.gotw.ca/publications/concurrency-ddj.htm

Apps like BibleCS may be in the category he describes of "wishful thinking that better hardware will help it out for those people who aren't satisfied with its performance."

"Search" seems like a good candidate for concurrency .... there are obvious threads by "Book" or "Testament". There would also seem to be less obvious threads by "pipeline" (decompress as applicable -> decrypt as applicable -> detag -> search itself -> presentation)

Here is a scenario for purposes of discussion:
Look for the phrase "God so love" across 100 modules that the end-user has installed. This could take a looooooong time, even with indexing (and the "love" rather than "loved" might cause problems for CLucene??)

I've got an older Dell server (circa 2000) with two Pentium III's installed, which would be a good "test-bed" for multi-threading. My impression is that HyperThreading and MultiCore cpu's would benefit from multithreading, but the conceptual model might be different in more or less subtle ways.

The original LcdBible used an "experimental plug-in subset" of the sword-api, and I am considering converting its much simpler search logic to use multi-threading. The upcoming LcdBible release uses the full sword-api, so would be harder to experiment with.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20051130/44292272/attachment-0001.html