Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/modules/pftijah pftijah.mx, 1.85, 1.86
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: 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@0), pre_tid, pre_size); + var elem_tid := _containing_desc3(left.mark(0@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |
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@0), pre_tid, pre_size); + var elem_tid := _containing_desc3(left.mark(0@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
participants (2)
-
Jan Flokstra -
Stefan Manegold