I wonder how burnt sushi feels about this
Show HN: SeekStorm – open-source sub-millisecond search in Rust
11–20 of 64 posts
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#12[flagged]
I find the note unfortunate. They state 2-4x performance improvement. I'm sure looking at the implementation with a profiler and tactically optimizing critical paths would have yielded them 2-3x as is. They could have also reached out to .NET JIT team via issues or discussions on GitHub for guidance. Especially since .NET has rich set of SIMD APIs very well suited for implementing SOTA text search algorithms (and also comes with many out of box, seriously, look at e.g. https://devblogs.microsoft.com/dotnet/performance-improvemen...)
The note also states "No framework dependencies (CLR or JVM virtual machines)" which isn't true either - 'dotnet publish /p:PublishSingleFile=true /p:PublishTrimmed=true' gives the same "dependency-less" experience. "Ahead-of-time instead of just-in-time compilation" is similarly wrong - replace previous args with '/p:PublishAot=true' and you get a native binary.
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#13What is the story for multi-language corpus? Do I have to do my own stop word pruning, tokenizing, lemming, etc? This is usually the case with full-text search solutions and it is a pain.
Re: stemming and lemming, I just want to plug the most impressive NLP stack I ever used, "chat script", really it's for building dialog trees where it walks down a branch of conversation using effectively switch statements but with really rich conceptual pattern matching and capturing - so somewhere in the middle of the stack it has excellent abstracting from word input to general concept (in WordNet), performing all the spell correction (according to your dictionary), stem, lem, and disambiguation.
I've had it in mind for a while to build a fuzzy search tool based on parsing each phrase into concepts, parsing the search query into concepts, and finding nearest match based on that. It's a C library and very fast.
https://github.com/ChatScript/ChatScript
Looks like it hasn't been committed to in some time, I'll have to check out their blog and see what's up. I guess with the advent of LLMs, dialog trees are passé.
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#14Demo = 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.
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#15Sub-millisecond latency sounds impressive, but isn't network latency going to overshadow these gains in most real-world scenarios?
A typical server is serving more than one request at a time, hopefully.
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#16[flagged]
I find the note unfortunate. They state 2-4x performance improvement. I'm sure looking at the implementation with a profiler and tactically optimizing critical paths would have yielded them 2-3x as is. They could have also reached out to .NET JIT team via issues or discussions on GitHub for guidance. Especially since .NET has rich set of SIMD APIs very well suited for implementing SOTA text search algorithms (and als…
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 Rust not light-minded, as the cost of porting a fairly large codebase is time-consuming.
We just wanted to share our experience for our specific task, not as a general statement.
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#17Impressive, bookmarked, upvoted.
Appreciate the demo: https://deephn.org/?q=apple+silicon
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#18Earlier quoted context omitted.
I find the note unfortunate. They state 2-4x performance improvement. I'm sure looking at the implementation with a profiler and tactically optimizing critical paths would have yielded them 2-3x as is. They could have also reached out to .NET JIT team via issues or discussions on GitHub for guidance. Especially since .NET has rich set of SIMD APIs very well suited for implementing SOTA text search algorithms (and als…
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.
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#19I really like your approach. Impressed by your care for performance and your fast pace of adding what appears to be pretty complex stuff, while making sure it stays performant.
Keep it up!
Bookmarked.
Re: Show HN: SeekStorm – open-source sub-millisecond search in Rust
#20How does this compare to PostgreSQL?