[pythran] Re: new master

  • From: Eliott Coyac <eliott.coyac@xxxxxxxxx>
  • To: pythran@xxxxxxxxxxxxx
  • Date: Tue, 22 Apr 2014 23:37:40 +0200

I tested those three functions (the last one is just the regular modulo) with -O2:


inline int positive_mod(int a, int b)
{
    return ((a % b) + b) % b;
}

inline int positive_mod_2(int i,int n)
{
    int res = i % n;
    if (res < 0) return res+n;
    else return res;
}

inline int positive_mod_3(int i,int n)
{
    return i % n;
}

The first one is always twice slower than the other two, and the second one is only a little slower than the third.

Here are the results I obtained:

2.79993e-07 (first function)
1.36992e-07 (second function)
1.22993e-07 (regular modulo)

6.11006e-07
1.12996e-07
1.43002e-07

3.64002e-07
1.53988e-07
1.16997e-07

3.14001e-07
1.54003e-07
1.16997e-07

We can see that the second function performs a lot better than the first one everytime. So maybe we should specialize modulo to use the second function for every natural type, and use the first one for the rest (lazy exprs)?

Or maybe we should include conditionals in lazy expressions so we can always use the second function?

By the way, here is the full code of my test: http://pastebin.com/7HETXaT0

On 22/04/2014 22:54, Pierrick Brunet wrote:
Just for information,

I run codespeed on the current master and we have poor performance compare to c04330eb17e0f57d605dd1048e5c959bea1b02e7

On average, we are 5% (x1.05) slower mainly because of pi_buffon, sexy_prime and sum_prime which are 100% slower now. It looks to be the result of the modulo operator modification.

I also run the omp version.

We can have speed up some time but others may be really horrible.

Best :
arc_distance : 79% speed up (x4.8)

Worse :
wave_simulation : 4.3 time slower
wdist : 3.7 time slower
slowpart : 2.8 time slower

average : 1.15 time slower

Good night,
Pierrick



Other related posts: