Mark:
There is no reason for me to withhold information. I just want to
understand and share my findings.
My bad for not being clear.
Mike's test is actually very well written, I just followed
instructions in the jira and got it running. I think the tests has good
coverage and shows the symptoms the algorithms would suggest.
-John
On Thu, Oct 22, 2009 at 7:42 PM, Mark Miller <markrmil...@gmail.com> wrote:
> Thanks - thats all I'm asking for. A simple explanation of why you'd ask
> for a retest with those two things changed. Just seems its hold your
> cards a little to close to say - please do this with 0 explanation.
>
> As to point 2, thats fine - I'm sure it helps - I was just saying I
> didn't buy it helps by 20-40%. Not arguing against doing it, but since
> the request had no info, the only thing I could assume was that that was
> supposed to change things.
>
> I was about to run some of these tests myself (if i can find what darn
> revision to patch), and its a bit frustrating to see you guys knew
> something but were not telling ...
>
> Jake Mannix wrote:
> > Mark,
> >
> > We're not seeing exactly the numbers that Mike is seeing in his tests,
> > running with jdk 1.5 on intel macs, so we're trying to eliminate
> > factors of difference.
> >
> > Point 2 does indeed make a difference, we've seen it, and it's only
> > fair: the
> > single pq comparator does this branch optimization but the current
> > patch multi-pq
> > does not, so let's level the playing field.
> >
> > John's on the road with limited net connectivity, but we'll have
> > some numbers to
> > compare more over the weekend for sure.
> >
> > -jake
> >
> > On Thu, Oct 22, 2009 at 7:29 PM, Mark Miller <markrmil...@gmail.com
> > <mailto:markrmil...@gmail.com>> wrote:
> >
> > Why? What might he find? Whats with the cryptic request?
> >
> > Why would Java 1.5 perform better than 1.6? It erases 20 and 40%
> > gains?
> >
> > I know point 2 certainly doesn't. Cards on the table?
> >
> > John Wang wrote:
> > > Hey Michael:
> > >
> > > Would you mind rerunning the test you have with jdk1.5?
> > >
> > > Also, if you would, change the comparator method to avoid
> > > brachning for int and string comparators, e.g.
> > >
> > >
> > > return index.order[i.doc] - index.order[j.doc];
> > >
> > >
> > > Thanks
> > >
> > >
> > > -John
> > >
> > >
> > > On Thu, Oct 22, 2009 at 2:38 AM, Michael McCandless
> > > <luc...@mikemccandless.com <mailto:luc...@mikemccandless.com>
> > <mailto:luc...@mikemccandless.com
> > <mailto:luc...@mikemccandless.com>>> wrote:
> > >
> > > On Thu, Oct 22, 2009 at 2:17 AM, John Wang
> > <john.w...@gmail.com <mailto:john.w...@gmail.com>
> > > <mailto:john.w...@gmail.com <mailto:john.w...@gmail.com>>>
> > wrote:
> > >
> > > > I have been playing with the patch, and I think I
> > have some
> > > information
> > > > that you might like.
> > > > Let me spend sometime and gather some more numbers and
> > > update in jira.
> > >
> > > Excellent!
> > >
> > > > say bottom has ords 23, 45, 76, each corresponding to a
> > > string. When
> > > > moving to the next segment, you need to make bottom to
> > have ords
> > > that can be
> > > > comparable to other docs in this new segment, so you would
> > need
> > > to find the
> > > > new ords for the values in 23,45 and 76, don't you? To
> > find it,
> > > assuming the
> > > > values are s1,s2,s3, you would do a bin. search on the new
> val
> > > array, and
> > > > find index for s1,s2,s3.
> > >
> > > It's that inversion (from ord->Comparable in first seg, and
> > > Comparable->ord in second seg) that I'm trying to avoid (w/
> > this new
> > > proposal).
> > >
> > > > Which is 3 bin searches per convert, I am not sure
> > > > how you can short circuit it. Are you suggesting we call
> > > Comparable on
> > > > compareBottom until some doc beats it?
> > >
> > > I'm saying on seg transition you indeed get the Comparable
> > for current
> > > bottom, but, don't attempt to invert it. Instead, as seg 2
> > finds a
> > > hit, you get that hit's Comparables and compare to bottom.
> > If it
> > > beats bottom, it goes into the queue. If it does not, you
> > use the ord
> > > (in seg 2's ord space) to "learn" a bottom in the ord space
> > of seg 2.
> > >
> > > > That would hurt performance I lot though, no?
> > >
> > > Yeah I think likely it would, since we're talking about a
> binary
> > > search on transition VS having to do possibly many
> > > upgrade-to-Comparable and compare-Comparabls to slowly learn
> the
> > > equivalent ord in the new segment. I was proposing it for
> > cases where
> > > inversion is very difficult. But realistically, since you
> > must keep
> > > around the ful ord -> Comparable for every segment anyway
> > (in order to
> > > merge in the end), inversion shouldn't ever actually be
> > "difficult" --
> > > it'd just be a binary search on presumably in-RAM storage.
> > >
> > > Mike
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > java-dev-unsubscr...@lucene.apache.org
> > <mailto:java-dev-unsubscr...@lucene.apache.org>
> > > <mailto:java-dev-unsubscr...@lucene.apache.org
> > <mailto:java-dev-unsubscr...@lucene.apache.org>>
> > > For additional commands, e-mail:
> > java-dev-h...@lucene.apache.org
> > <mailto:java-dev-h...@lucene.apache.org>
> > > <mailto:java-dev-h...@lucene.apache.org
> > <mailto:java-dev-h...@lucene.apache.org>>
> > >
> > >
> >
> >
> > --
> > - Mark
> >
> > http://www.lucidimagination.com
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> > <mailto:java-dev-unsubscr...@lucene.apache.org>
> > For additional commands, e-mail: java-dev-h...@lucene.apache.org
> > <mailto:java-dev-h...@lucene.apache.org>
> >
> >
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>
