DISQUS

Hello! Phil Dawes' Stuff is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

phildawes.net/blog/ Jump to website »

Subscribe
- New Comments
Community
Top Commenters
- phildawes
  5 comments · 1 points
- danja
  4 comments · 1 points
- David W.
  2 comments · 1 points
- ryantm
  1 comment · 1 points
Popular Threads
Recent Comments
- Hi, Do you feel that your agility in Factor has improved since this post? Roger
  1 month ago by Roger Levy
  
  in The Factor Attraction
- Thanks for the pointer - I've cleaned up the spam and regrettably added some moderation
  1 month ago by phildawes
  
  in Disqus comments
- I'm loving the comments thread for this post. Can't decide whether to get my upholstery cleaned or do something about my fast food obesity.
  1 month ago by Dominic Sayers
  
  in Disqus comments
- Cool - thanks Eric
  2 months ago by phildawes
  
  in Factor makes you write better code
- I pasted some code that does the moving sum in factor. http://paste.factorcode.org/paste?id=569#282
  2 months ago by Eric Mertens
  
  in Factor makes you write better code

Phil Dawes' Stuff

Jump to original thread »

Searching arrays in X86 assembler with a bloom filter

Started by phildawes · 9 months ago

I’m currently writing what amounts to an olap database in factor in my spare time, which is a pretty interesting project. Actually spare time is limited now that I have a child but factor is affording me a pretty good productivity compared to python and scheme so it’s proba ... Continue reading »

4 comments

David W.
10 months ago

How much memory have you got to play with? It's a primitive approach, but holding your set of ints in a 512mb bitset would allow very fast lookup. =)

reply

Rs
10 months ago

Not sure if you have ruled out C libraries completely but have you looked at Judy? The JudyL functions or some of the related counting ones might get you very close to an optimal solution.

http://judy.sourceforge.net/

reply

Michael S
10 months ago

David W: the large bitset approach sounds good, but with bitset that size you are going to encounter cache misses on almost every lookup, which is going to end up being far slower than a naive approach. You can execute a *lot* of instructions in the time it takes to load an L2 cache line.

reply