nice night for a walk.....people don't wanna program these days On Thu, Sep 26, 2013 at 7:15 PM, David Barbour <dmbarb...@gmail.com> wrote:
> > > > On Thu, Sep 26, 2013 at 3:05 PM, Sam Putman <atmanis...@gmail.com> wrote: > >> >> >> >> On Thu, Sep 26, 2013 at 2:31 PM, David Barbour <dmbarb...@gmail.com> >> wrote: >> >>> >>> On Thu, Sep 26, 2013 at 11:58 AM, Sam Putman <atmanis...@gmail.com> >>> wrote: >>> >>>> >>>> >>>>> How often do we compare very large integers for equality? >>>>> >>>>> >>>> Rather often, and still less than we should. Git does this routinely, >>>> and Datomic revolves around it. The lower-level the capability is built in, >>>> the more often, in general, we can benefit from it. >>>> >>> >>> In incremental systems, there is a tradeoff between recomputing vs. >>> caching. At too fine a granularity, caching can be orders of magnitude >>> worse than recomputing, due to the extra memory and branching overheads. At >>> too coarse a granularity, recomputing can be orders of magnitude worse. >>> More of a good thing can be a bad thing. This is made more complicated when >>> different substructures update at different frequencies, or in different >>> bursts, or with various feedback properties. In general, there are no easy >>> answers (other than "profile!") when it comes to optimizing performance. >>> >> >> It's less about performance, per se, as it is about making certain >> actions easy. In Datomic, for example, one may request a hash that >> represents the complete state of a database at any given point in time, and >> then query that database using that hash. This is a pretty good trick. It's >> also difficult to imagine a globally distributed cache that didn't in some >> fashion follow this principle. >> > > Use of a hash to identify states in a large persistent data structure is > indeed a nice trick. I can see the appeal of centralizing information about > update over time. I do not find it difficult to think of alternatives, > though, such as keeping timestamps all-the-way down. The latter approach > weakens global serializability and offers greater expressiveness. These > properties can be leveraged for speculative evaluation or open systems > integration. > > Anyhow, at this time I feel hashes should be used explicitly, and have > relatively specialized use-cases. > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
