Dan Goodman thesamovar.net> writes:
...
> I got around 5x slower. Using numexpr 'dumbly' (i.e. just putting the
> expression in directly) was slower than the function above, but doing a
> hybrid between the two approaches worked well:
>
> def timefunc_numexpr_smart():
> _sin_term = sin(2.0*fr
Julian Taylor googlemail.com> writes:
>
> On 01.12.2013 22:59, Dan Goodman wrote:
> > Julian Taylor googlemail.com> writes:
> >> your sin and exp calls are loop invariants, they do not depend on the
> >> loop iterable.
> >> This allows to move the expensive functions out of the loop and only
>
On 01.12.2013 22:59, Dan Goodman wrote:
> Julian Taylor googlemail.com> writes:
>> your sin and exp calls are loop invariants, they do not depend on the
>> loop iterable.
>> This allows to move the expensive functions out of the loop and only
>> leave some simple arithmetic in the body.
>
> A
Julian Taylor googlemail.com> writes:
> your sin and exp calls are loop invariants, they do not depend on the
> loop iterable.
> This allows to move the expensive functions out of the loop and only
> leave some simple arithmetic in the body.
A! I feel extremely stupid for not realising this!
On 01.12.2013 21:53, Dan Goodman wrote:
> Julian Taylor googlemail.com> writes:
>> can you show the code that is slow in numpy?
>> which version of gcc and libc are you using?
>> with gcc 4.8 it uses the glibc 2.17 sin/cos with fast-math, so there
>> should be no difference.
>
> In trying to writ
Julian Taylor googlemail.com> writes:
> can you show the code that is slow in numpy?
> which version of gcc and libc are you using?
> with gcc 4.8 it uses the glibc 2.17 sin/cos with fast-math, so there
> should be no difference.
In trying to write some simple code to demonstrate it, I realised i
