[
https://issues.apache.org/jira/browse/LUCENE-7745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722717#comment-16722717
]
Rinka Singh commented on LUCENE-7745:
-------------------------------------
Thank you.
As a first step let me come up with a GPU based index builder and we can look
at query handling on the GPU as a second step.
:-) I AM going to be slooow - my apologies but I'm interested enough to put
effort into this and will do my best.
Here's what I'll do as a first step:
Develop a stand alone executable (we can figure out modifications to directly
use in Lucene as step 1.1) that will:
a. Read multiple files (command line) and come up with an inverted index
b. write the inverted index to stdout (I can generate a lucene index as step
1.1)
c. will handle a stop-words file as a command line param
d. Will work on one GPU+1 thread of the CPU (I'll keep multi-GPU and multi
threading to use all CPUs in mind but implementing that will be a separate step
altogether).
Goal: Look at speed difference between an Index generated on the CPU vs GPU for
just this.
We can build from there...
Thoughts please...
> Explore GPU acceleration
> ------------------------
>
> Key: LUCENE-7745
> URL: https://issues.apache.org/jira/browse/LUCENE-7745
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Ishan Chattopadhyaya
> Assignee: Ishan Chattopadhyaya
> Priority: Major
> Labels: gsoc2017, mentor
> Attachments: TermDisjunctionQuery.java, gpu-benchmarks.png
>
>
> There are parts of Lucene that can potentially be speeded up if computations
> were to be offloaded from CPU to the GPU(s). With commodity GPUs having as
> high as 12GB of high bandwidth RAM, we might be able to leverage GPUs to
> speed parts of Lucene (indexing, search).
> First that comes to mind is spatial filtering, which is traditionally known
> to be a good candidate for GPU based speedup (esp. when complex polygons are
> involved). In the past, Mike McCandless has mentioned that "both initial
> indexing and merging are CPU/IO intensive, but they are very amenable to
> soaking up the hardware's concurrency."
> I'm opening this issue as an exploratory task, suitable for a GSoC project. I
> volunteer to mentor any GSoC student willing to work on this this summer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
