|
From: Nicholas N. <nj...@cs...> - 2006-01-23 09:40:51
|
On Sun, 22 Jan 2006, David Kimdon wrote: > I am working on implementing compressed vbits as described on the > project suggestions page. So far I have it, I think, working without > any of the load/store optimizations (VG_DEBUG_MEMORY = 2). It doesn't > look too terribly slow compared to the uncomrepessed, unoptimized > case. I am cautiously optimistic that the slowdown won't be too large > once the load/store optimixations. I placed the work in progress up > at > http://people.debian.org/~dwhedon/compressed-vbits/ for the curious. Ah. The good news is you've made a good start! The bad news is that I have a 90%-complete implementation already. It's in the COMPVBITS branch (use svn co svn://svn.valgrind.org/valgrind/branches/COMPVBITS to check it out). It's actually quite a bit faster (typically 15%-ish?) than the current head, because the fast cases are more streamlined. The plan is to merge it into the trunk fairly soon. Sorry about this, I should have removed that project from the website. I've done that now. Looking at your code, I see you have one secondary V bits table per SecMap, which is an interesting idea; I have a single table for everything. Your approach makes for faster lookups, but the garbage collection of stale nodes becomes more complicated... hmm, interesting. Nick |