Tuple Spaces (or, Good Ideas Don’t Always Win) • Hacker News Board

Re: Tuple Spaces (or, Good Ideas Don’t Always Win)

#21

Post by regularfry » Thu, Mar 03, 2011, 7:51 AM UTC

jerf wrote: post #9

Has anyone successfully used this for anything significant? As I post this there's only a couple of people posting about how either they tried but it didn't work out well enough, or they just played with it in school without any code. It strikes me as having the same problems as RDF storage; precisely because the model is so general, there's nothing for optimizations to grab on to and optimize on. Your database has t…

Yeah, I've used Rinda for load balancing across small numbers of machines before. It's a couple of screens of ruby in total to get that working, which I was astonished by.

Re: Tuple Spaces (or, Good Ideas Don’t Always Win)

#22

Post by irv » Thu, Mar 03, 2011, 12:08 PM UTC

cool. but this seems fundamentally similar to the Chan/Var style of parallelism in haskell?

Re: Tuple Spaces (or, Good Ideas Don’t Always Win)

#23

Post by DrJosiah » Fri, Mar 04, 2011, 1:34 AM UTC

murrayh wrote: post #5

cachemoney wrote: post #4

I tried it in Ruby in ~2006, and found that many operations in Rinda were O(n) in the size of the tuple space :(

Interesting. Could a better-than-O(n) parallelisable tuple space be implemented with something like skip lists?

Tuplespace is all about lookups/publish/subscribe on filters on the tuples. For the vast majority of the time, filters are of the form of (, , ...) or (, , ...) . You don't need to use skip lists (or binary trees generally) for that, you can use nested hash tables on the prefix/suffix of the tuples. Then you get O(len(filters)) instead of O(log(size of tuple space)). Trust me when I say that using hashes of filters is a lot faster.

Also, see my higher-ranked post about why I stopped using tuple spaces.