[Haskell-cafe] Problem with benchmarking FFI calls with Criterion

[Janek S.]

Well, it seems that this only happens on my machine. I will try to test this code on different 
computer and see if I can reproduce it.

I don't think using existing vector is a good idea - it would make the code impure.

Janek

Dnia sobota, 24 listopada 2012, Branimir Maksimovic napisał:
> I don't see such behavior neither.ubuntu 12.10, ghc 7.4.2.
> Perhaps this has to do with how malloc allocates /cachebehavior. If you try
> not to allocate array rather use existing one perhaps there would be no
> inconsistency?It looks to me that's about CPU cache performance. Branimir
>
> > I'm using GHC 7.4.2 on x86_64 openSUSE Linux, kernel 2.6.37.6.
> >
> > Janek
> >
> > Dnia piątek, 23 listopada 2012, Edward Z. Yang napisał:
> > > Running the sample code on GHC 7.4.2, I don't see the "one
> > > fast, rest slow" behavior.  What version of GHC are you running?
> > >
> > > Edward
> > >
> > > Excerpts from Janek S.'s message of Fri Nov 23 13:42:03 -0500 2012:
> > > > > What happens if you do the benchmark without unsafePerformIO
> > > > > involved?
> > > >
> > > > I removed unsafePerformIO, changed copy to have type Vector Double ->
> > > > IO (Vector Double) and modified benchmarks like this:
> > > >
> > > > bench "C binding" $ whnfIO (copy signal)
> > > >
> > > > I see no difference - one benchmark runs fast, remaining ones run
> > > > slow.
> > > >
> > > > Janek
> > > >
> > > > > Excerpts from Janek S.'s message of Fri Nov 23 10:44:15 -0500 2012:
> > > > > > I am using Criterion library to benchmark C code called via FFI
> > > > > > bindings and I've ran into a problem that looks like a bug.
> > > > > >
> > > > > > The first benchmark that uses FFI runs correctly, but subsequent
> > > > > > benchmarks run much longer. I created demo code (about 50 lines,
> > > > > > available at github: https://gist.github.com/4135698 ) in which C
> > > > > > function copies a vector of doubles. I benchmark that function a
> > > > > > couple of times. First run results in avarage time of about 17us,
> > > > > > subsequent runs take about 45us. In my real code additional time
> > > > > > was about 15us and it seemed to be a constant factor, not
> > > > > > relative to "correct" run time. The surprising thing is that if
> > > > > > my C function only allocates memory and does no copying:
> > > > > >
> > > > > > double* c_copy( double* inArr, int arrLen ) {
> > > > > >   double* outArr = malloc( arrLen * sizeof( double ) );
> > > > > >
> > > > > >   return outArr;
> > > > > > }
> > > > > >
> > > > > > then all is well - all runs take similar amount of time. I also
> > > > > > noticed that sometimes in my demo code all runs take about 45us,
> > > > > > but this does not seem to happen in my real code - first run is
> > > > > > always shorter.
> > > > > >
> > > > > > Does anyone have an idea what is going on?
> > > > > >
> > > > > > Janek
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe