Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SeekStorm – open-source sub-millisecond search in Rust

github.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#21

Post by wolfgarbe »

neonsunset wrote: post #18
wolfgarbe wrote: post #16

Earlier quoted context omitted.

The 2-4 speed ratio was not meant to denounce C#, which is a great language I loved to program in for over two decades, coming from Delphi. Unfortunately, C# has not a complete SIMD support. See our request to support the SSE4.2 _mm_cmpistrm instruction https://github.com/dotnet/runtime/discussions/63332 , which we required for a vectorized intersection between two sorted 16-bit arrays. We did the switch from C# to R…

Thank you. It is indeed true that .NET has some gaps in its SIMD API, which might require either writing a specific routine in C and pinvoking it or implementing the algorithm differently. Were there any other factors that contributed to the decision? FWIW I forwarded the issue the discussion links to dotnetevolution discord server.

Yes. We waited long for AOT compilation to become mature, to remove the need for the user to install the .Net framework. But two years ago when we decided to switch, we still couldn't just get the AOT compilation of our codebase to work without changes (perhaps it was somehow possible, but the available documentation was not very verbose about this). Also, there is still a performance gap. Of course, this doesn't matter for most of the applications, where the completeness and consistency of the framework, and the number of programmers fluent in that language might matter more. But for a search server, we needed to carve out every inch of performance we could get. And other benchmarks seemed to echo our experience: https://programming-language-benchmarks.vercel.app/rust-vs-c...

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#22

Post by neonsunset »

wolfgarbe wrote: post #21
neonsunset wrote: post #18

Earlier quoted context omitted.

Thank you. It is indeed true that .NET has some gaps in its SIMD API, which might require either writing a specific routine in C and pinvoking it or implementing the algorithm differently. Were there any other factors that contributed to the decision? FWIW I forwarded the issue the discussion links to dotnetevolution discord server.

Yes. We waited long for AOT compilation to become mature, to remove the need for the user to install the .Net framework. But two years ago when we decided to switch, we still couldn't just get the AOT compilation of our codebase to work without changes (perhaps it was somehow possible, but the available documentation was not very verbose about this). Also, there is still a performance gap. Of course, this doesn't mat…

That specific suite is...not the best. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is more focused on optimized implementations and showcases where the performance of .NET places given submissions someone cared to spend some time optimizing.

It is true that 2 years ago NAOT was in its infancy, it has improved substantially since then. Self-contained trimmed binaries already worked back then however.

I guess it is more about unfortunate timing than anything - even the compiler itself moves fast and in some areas the difference in codegen quality is very significant between 7, 8 and 9.

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#23

Post by wolfgarbe »

distracted_boy wrote: post #20

How does this compare to PostgreSQL?

PostgreSQL is an SQL database that also offers full-text search (FTS), with extensions like pg_search it also supports BM25 scoring which is essential for lexical search. SeekStorm is centered around full-text search only, it doesn't offer SQL.

Performance-wise it would be indeed interesting to run a benchmark. The third-party open-source benchmark we are currently using (search_benchmark_game) does not yet support PostgreSQL. So yes, that comparison is still pending.

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#24

Post by treefarmer »

Is there distributed server support? I see it on the list of new features with (currently PoC) next to it, but is the code for the PoC available anywhere?

Also, would there be any potential issues if the index was mounted on shared storage between multiple instances?

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#25

Post by Thaxll »

It feels like everyone re-implement the same application, searching text in language x.y.z has been done a million times, search speed in not a problem so what differenciate this solution with the dozen+ mature ones.

The speed looks great but isn't everything else already fast enough?

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#26

Post by wolfgarbe »

Thaxll wrote: post #25

It feels like everyone re-implement the same application, searching text in language x.y.z has been done a million times, search speed in not a problem so what differenciate this solution with the dozen+ mature ones. The speed looks great but isn't everything else already fast enough?

Its not just about speed. Speed reflects efficiency. Efficiency is needed to serve more queries in parallel, to search within exponentially growing data, with less expensive hardware, and fewer servers, consuming less energy. Therefore the pursuit for efficiency never gets outdated and has no limit.

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#28

Post by CharlieDigital »

jazzyjackson wrote: post #14
tlofreso wrote: post #5

Demo = impressed. How's SeekStorm's prowess in mid-cap enterprise? How hairy is the ingest pipeline for sources like: decade old sharepoint sites, PDFs with partial text layers, excel, email.msg files, etc...

On that topic, can anybody chime in on state of the art PDF OCR? Even if that's a multimodal LLM, I've used ChatGPT to extract tabular data from images but need something I can self host for proprietary data.

Azure Document Intelligence (especially with the layout model[0]) is really good. It has both JSON and MD output modes and does a pretty solid job identifying headers, sections, tables, etc.

What's interesting is that they have a self-deployable container model[1] that only phones home for billing so you can self-host the runtime and model.

[0] https://learn.microsoft.com/en-us/azure/ai-services/document...

[1] https://learn.microsoft.com/en-us/azure/ai-services/document...

Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust

#30

Post by sdesol »

wolfgarbe wrote: post #26
Thaxll wrote: post #25

It feels like everyone re-implement the same application, searching text in language x.y.z has been done a million times, search speed in not a problem so what differenciate this solution with the dozen+ mature ones. The speed looks great but isn't everything else already fast enough?

Its not just about speed. Speed reflects efficiency. Efficiency is needed to serve more queries in parallel, to search within exponentially growing data, with less expensive hardware, and fewer servers, consuming less energy. Therefore the pursuit for efficiency never gets outdated and has no limit.

In addition to what you said, faster searches can also provide different search options. For example, if you can execute five similar searches in the same time that it would take to execute one. You now have the option to ask "Can I leverage five similar searches to produce better results" and if the answer is yes, you can now provide better answers and still keep the same user experience.

Where I really think faster searches will come into play is with AI. There is nothing energy efficient about how LLM work and I really think Enterprise will focus on using LLM to generate as many Q and A pairs during off peak energy hours and using a hybrid search that can bridge semantic (vector) and text. I think for Enterprise the risk of hallucinations (even with RAG) will be too great and fall back to traditional search, but with a better user experience.

Based on the README, it looks like vector search is not supported or planned, but it would be interesting to see if SeekStorm can do this more efficiently than Lucene/OpenSearch and others. I only dabbled in the search space, so I don't know how complex this would be, but I think SeekStorm can become a killer search solution if it can support both.

Edit: My bad, it looks like vector search is PoC.

Post reply on HN