Nicolas Neuss <[EMAIL PROTECTED]> writes:
> 5. Unfortunately, for very high performance needs on this kind of
> application, Python still needs to be improved. For example, if I
> would do several sweeps over small data ranges, the memory access
> would get less important, and the difference between CMUCL and C
> will become much larger due to the more complex code for performing
> the addition:
>
> CMUCL: something like
> 9F0: FADDD FR1
> 9F2: MOV EDI, ESI
> 9F4: ADD EDI, 4
> 9F7: FSTPD FR1
> 9F9: FLDD [EDX+EDI*2+1]
> 9FD: FXCH FR1
>
> C:
> 0x804844c <main+92>: faddl 0xffffe0b8(%edx)
Nevertheless, the following should be the performance of flexible
C-code (allows different stencils at runtime):
~/Programming/C$ time a.out
1.000000
real 0m4.190s
user 0m4.110s
sys 0m0.070s
where the C-code used is
#include <stdio.h>
const int n = 1000;
int main ()
{
int i, k, pos1, pos2;
double mat[n*n];
double stencil_values[9];
int stencil_shift[9]={-1001,-1,999, -1000,0,1000, -999,1,1001};
for (i=0; i<9; i++) stencil_values[i]=1.0/9.0;
for (i=0; i<n*n; i++)
mat[i] = 1.0;
for (i=0; i<10; i++)
for (pos1=1; pos1<n-1; pos1++)
for (pos2=pos1+n; pos2<pos1+(n-1)*n; pos2+=n)
{
register double s = 0.0;
for (k=0; k<9; k++)
s +=
stencil_values[k]*mat[pos2+stencil_shift[k]];
mat[pos2] = s;
}
printf("%f", mat[n+1]);
return 0;
}
This code is almost 3 times slower than the Lisp code. Therefore, I
guess that my point is proved: for important numerical applications
Lisp (CMUCL) is faster than C.
Any objections?
Nicolas.