Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of dawid.weiss@gmail.com
 designates 209.85.219.221 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=mU8OLdzRELHOfbxjAy8XlVChIsOpqGt/X3o4fhyUlkl0YMyhUxi/qclAUblLfYyVkQ
         uQqC47C8IVVOqU0+l5Zomf+OMnTqbzoiKm68ijKWVopsq9d1wxd881khi8xL5f2MhrjK
         KjQO7pY6pIQDJYkvs4DRFUFFrJM5AAeZz7bgI=
MIME-Version: 1.0
In-Reply-To: <l2q59b3eb371004191249if87efbaem7c3a640c133b9c0f@mail.gmail.com>
References: <p2p5e76f3841004190746v5472890akca97b4a2d7543647@mail.gmail.com>
	<n2ic7d45fc71004190944x45bd0831k9d1ae46e13187596@mail.gmail.com>
	<l2q59b3eb371004191249if87efbaem7c3a640c133b9c0f@mail.gmail.com>
From: Dawid Weiss <dawid.weiss@gmail.com>
Date: Mon, 19 Apr 2010 22:11:21 +0200
Message-ID: <m2nbaa8c5731004191311w2e54b4eena4bf8c66d7d0a539@mail.gmail.com>
Subject: Re: HPPC: High Performance Primitive Collections for Java
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8

> Hmmm.. can anybody compare these to fastutil?

I believe I can answer some of your questions.

1) HPPC is not directly Java Collections-compatible. It does have
interface hierarchy, but it's not a descendant of the familiar Set,
Map or List. Fastutil is collections-compatible.

2) HPPC has open internals, so you can do anything you like once your
collections are created, including manipulation of internal storage
arrays, for instance. This was a design decision and goal. As with any
sharp objects, improper use may cause harm.

3) HPPC uses assert instead of fixed condition checks. There are no
attempts to detect misuse (fail-fast iterators, etc.).

4) fastutil is more mature, has support for more data structures
(sorted trees, etc.) and was written by an excellent programmer
(Sebastiano Vigna). HPPC was created internally for use at Carrot
Search and was primarily motivated by speed; we believed that in
certain applications direct access to collections' internals should be
allowed and should be beneficial. Our micro-benchmarks show that this
is largerly true if you manipulate LOTS of data. For smaller data sets
even built-in Java collections with boxed types do surprisingly well
(due to HotSpot optimizations too).

5) There are subtle differences in how HPPC is written -- I use pretty
much normal generic classes with some pseudo-intrinsics and
regexp-substituted comments. Sebastiano uses C++ preprocessor to
generate Java classes from templates (yes, wicked).

I look at Lucene and SOLR source code and learn a LOT from folks
contributing to this project, so HPPC will be hardly any faster or
better compared to what Lucene already has, but if anybody find
anything from HPPC useful, please take handfuls. I would love for this
project to be finally merged with Mahout, but I intentially left it in
Carrot Search labs for a little while so that the API can stabilize
(through our in-house experiments mostly).

Thanks for showing your interest!
Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org