[Monetdb-developers] [Monetdb-pf-checkins] pathfinder/modules/pftijah pftijah.mx, 1.85, 1.86

Jan Flokstra flokstra at cs.utwente.nl
Wed Jan 17 14:27:58 CET 2007


On Wednesday 17 January 2007 13:54, Stefan Manegold wrote:
> On Wed, Jan 17, 2007 at 12:34:18PM +0000, Jan Flokstra wrote:
> > Update of /cvsroot/monetdb/pathfinder/modules/pftijah
> > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv5537
> >
> > Modified Files:
> > 	pftijah.mx
> > Log Message:
> > - repair "jan was right" bug. On 64 bit machines BUNtloc() is different
> > from BUNtail() on void tail'ed BAT's.
>
> To avoid the spreading of incomplete/incorrect facts/knowledge:
>

To add even more knowledge to the community I will explain what happened. The 
BUNtloc() operation was on the result bat of a join([oid,oid],[oid,oid]). You 
would expect a fixed size atom [oid,oid] result where you can use BUNtloc() 
for optimized access to the tail.But the snake here was that the join() 
algorithm 'optimized' the result to an [oid,void] bat.
So the lesson learned here is that you always have to check on 'oid' BAT's 
which are the result of an operation if the 'oid' is still an 'oid' or if it 
has been optimized to a 'void'.

JanF.

> BUNhloc/BUNtloc are significantly different from BUNhead/BUNtail on ALL
> platforms, i.e., in ALL cases:
>
> BUNhloc/BUNtloc are for fixed-sized atoms (e.g., chr, bte, sht, int, wrd,
> lng, flt, dbl, oid, etc.) that are stored *loc*ally in the BUNheap, and
> hence alloc direct/*loc*al access.
>
> BUNhvar/BUNtvar are for *var*iable-sized atoms (e.g., str, void, etc.) that
> are stored in the extra head-/tail-heaps, or not stored ("materialized") at
> all (void).
>
> BUNhead/BUNtail are wrappers, that check whether head/tail is fixed- or
> var-sized and use either of the above respectively.
>
> Hence, BUNhead/BUNtail work in all cases, but at the expense of an extra if
> (branch) that can considereably contribute to overall costs in case it has
> to be evaluated millions of times in inner loops.
> Hence, to gain speed, BUNhvar/BUNtvar and in particular BUNhloc/BUNtloc
> allow to avoid this extra if (branch => costs) in cases where we know that
> either only var-sized or only fixed-sized atoms (i.e., columns) occur,
> e.g., by moving this loop-invariant if out of the loop.
>
> see also MonetDB/src/gdk/gdk.mx for the definition and description of these
> (and other) macros.
>
> Stefan
>
> > - repair no-result bug which haunted the testweb last night.
> >
> > Hopefully the pftijah testweb is OK again tonight.
> >
> >
> >
> > Index: pftijah.mx
> > ===================================================================
> > RCS file: /cvsroot/monetdb/pathfinder/modules/pftijah/pftijah.mx,v
> > retrieving revision 1.85
> > retrieving revision 1.86
> > diff -u -d -r1.85 -r1.86
> > --- pftijah.mx	16 Jan 2007 13:37:23 -0000	1.85
> > +++ pftijah.mx	17 Jan 2007 12:34:13 -0000	1.86
> > @@ -321,7 +321,7 @@
> >      bat("tj_" + collName + "_param").insert("preExpansion","4");
> >      bat("tj_" + collName + "_param").insert("status","building");
> >      bat("tj_" + collName + "_param").insert("_last_tijahPre","1");
> > -    bat("tj_" + collName + "_param").insert("_last_finalizedPre","1");
> > +    bat("tj_" + collName + "_param").insert("_last_finalizedPre","0");
> >      #
> >      commit();
> >  }
> > @@ -1365,7 +1365,7 @@
> >
> >       # evaluate doc/term (anc/desc) relationship
> >       var t2 := time();
> > -     var elem_tid := _containing_desc(left.mark(0 at 0), pre_tid,
> > pre_size); +     var elem_tid := _containing_desc3(left.mark(0 at 0),
> > pre_tid, pre_size); var t3 := time();
> >       pre_tid := nil;
> >       if (elem_tid.count() = 0) {return new(oid,dbl);}
> > @@ -3187,8 +3187,9 @@
> >
> >
> >  	BATloopFast(elem_tid, p, q, xx) {
> > -		oid *h = (oid*) BUNhloc(elem_tid, p);
> > -		oid *t = (oid*) BUNtloc(elem_tid, p);
> > +		oid *h = (oid*) BUNhead(elem_tid, p);
> > +		oid *t = (oid*) BUNtail(elem_tid, p);
> > +
> >  		for(i = 0; i < term_cnt; i++)
> >  			if (terms[i] == *t) {
> >  				if (0) BUNappend(bats[i], h, 0);
> > @@ -3208,8 +3209,9 @@
> >  				}
> >  				break;
> >  			}
> > -		if (i == term_cnt)
> > -			GDKerror("%s: jan was right.\n",name);
> > +		if (i == term_cnt) {
> > +			GDKerror("WARNING:%s: cannot find term " OIDFMT ".\n",name,*t);
> > +	        }
> >  	}
> >
> >          t = BUNfirst(tid_cnt);
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys - and earn
> > cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Monetdb-pf-checkins mailing list
> > Monetdb-pf-checkins at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins




More information about the developers-list mailing list