[Numpy-discussion] numpy vbench-marking, compiler comparison

[Daπid]

Have you tried on an Intel CPU? I have both a i5 quad core and an i7 octo
core where I could run it over the weekend. One may expect some compiler
magic taking advantage of the advanced features, specially the i7.

/David
On Nov 25, 2013 8:16 PM, "Julian Taylor" <jtaylor.debian at googlemail.com>
wrote:

> On 25.11.2013 02:32, Yaroslav Halchenko wrote:
> >
> > On Tue, 15 Oct 2013, Nathaniel Smith wrote:
> >> What do you have to lose?
> >
> >>> btw -- fresh results are here
> http://yarikoptic.github.io/numpy-vbench/ .
> >
> >>> I have tuned benchmarking so it now reflects the best performance
> across
> >>> multiple executions of the whole battery, thus eliminating spurious
> >>> variance if estimate is provided from a single point in time.
>  Eventually I
> >>> expect many of those curves to become even "cleaner".
> >
> >> On another note, what do you think of moving the vbench benchmarks
> >> into the main numpy tree? We already require everyone who submits a
> >> bug fix to add a test; there are a bunch of speed enhancements coming
> >> in these days and it would be nice if we had some way to ask people to
> >> submit a benchmark along with each one so that we know that the
> >> enhancement stays enhanced...
> >
> > On this positive note (it is boring to start a new thread, isn't it?) --
> > would you be interested in me transfering numpy-vbench over to
> > github.com/numpy ?
> >
> > as of today, plots on http://yarikoptic.github.io/numpy-vbench  should
> > be updating 24x7 (just a loop, thus no time guarantee after you submit
> > new changes).
> >
> > Besides benchmarking new benchmarks (your PRs  would still be very
> > welcome,  so far it was just me and Julian T) and revisions, that
> > process also goes through a random sample of existing previously
> > benchmarked revisions and re-runs the benchmarks thus improving upon the
> > ultimate 'min' timing performance.  So you can see already that many
> > plots became much 'cleaner', although now there might be a bit of bias
> > in estimates for recent revisions since they hadn't accumulated yet as
> > many of 'independent runs' as older revisions.
> >
>
> using the vbench I created a comparison of gcc and clang with different
> options.
> Cliffnotes:
> * gcc -O2 performs 5-10% better than -O3 in most benchmarks, except in a
> few select cases where the vectorizer does its magic
> * gcc and clang are very close in performance, but the cases where a
> compiler wins by a large margin its mostly gcc that wins
>
> I have collected some interesting plots on this notebook:
> http://nbviewer.ipython.org/7646615
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20131126/a0cdcda4/attachment.html>