On Sat, 19 Jun 2010 22:27:05 +0100
Nicolas Oury <nicolas.o...@gmail.com> wrote:
> On Sat, Jun 19, 2010 at 10:15 PM, Mike Meyer <m...@mired.org> wrote:
> > Pretty much any time I really need integer speed, I also deal with
> > numbers that can get much larger than 10^19th, because I tend to be
> > doing combinatorics or cryptography.
> But you would agree that for this kind of domain, it wouldn't be too bad to
> be explicit about
> wanting bigint. If you write a program that work with XML, you don't ask
> clojure data to be
> encoded in XML.
Yes, I would agree. The real issue is that when I say "gimme bigints",
it happens pretty much everywhere, so I don't have to worry about
overlooking some quantity that might overflow. I suppose this cuts
both ways - when you want primitives, you want them everywhere, so you
don't have to worry about overlooking some heavily used quantity
somewhere.
The difference is, I'm worried about getting the correct answer, but
you're worried about performance. You can profile your code to
identify where the time is going (in fact, you should have already
done that before adding the first annotation) to make sure you don't
overlook anything. The only automated tool I've got for finding
overflows is - well, to run into them. Having to fix them and repeat
the run pretty thoroughly negates any win I might have gotten out of
using primitive arithmetic where I could.
> > True, this represents a small fraction of all programs. The question
> > I'd really like answered is how much difference does this make for
> > non-numeric clojure code, where only a few percent of the calls to
> > core functions are calls to integer ops.
> I tried on some code with 1/2 ops per functions and already quite a dew
> annotations. 10% speed-up in a program that spend 80% in Object.hashCode
> (which does not get accelerated at all).
Not quite what I wanted, for at least one reason (preexisting
annotations) and possibly because you should be comparing the two
variants of the appropriate branch, instead of comparing that branch
with either 1.1 or the current master.
In any case, I don't think 10% is enough gain to justify narrowing the
range for which naive programs are correct. An order of magnitude
would be. A factor of two is a maybe.
> I think that's due to the 1/2 ops + the ops hidden in clojure library code.
> I'd like to see more results like that and bugs in real programs.
> It was a matter of minutes to try.
> - pull the branch with git
> - compile with ant
> - replace your clojure.jar
> - recompile.
Except you have to do it twice, and get correct timings. It would
really help if someone could provide precompiled jars with an
appropriate README.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
