C++, Java и Python - кто быстрее?

> я возьмусь. Давай код на sl@whiteants.net

http://astronomy.swin.edu.au/~pbourke/analysis/inverse/ :)

java code public class Test { public static void main(String[] args) { final int n=1000; final int m=1000; final int p=1000; final long startDate = System.currentTimeMillis(); final double[] A = new double[n*m]; final double[] B = new double[m*p]; final double[] C = new double[n*p]; for (int i=0;i<n;i++) for (int j=0;j<m;j++) A[i*m+j]=Math.random(); for (int i=0;i<m;i++) for (int j=0;j<p;j++) B[i*p+j]=Math.random(); for (int i=0;i<n;i++) for (int j=0;j<p;j++) { for (int k=0;k<m;k++) C[i*p+j]+=A[i*m+k]*B[k*p+j]; } System.out.println("Calculation time: " + (System.currentTimeMillis() - startDate)); } }

> Date t0 = new Date();

long t0 = System.currentTimeMillis();

> System.out.println(" Time="+String.valueOf(t1.getTime-t0.getTime())+" ms")

Зачем String.valueOf()? Просто хватит круглых скобок.

Выделение памяти и инициализация (пробив нулями и вызовы random) занимала 673 миллисек. Основной тормоз работа с массивом.

> Упс :(((

Ты не представляешь, сколько таких упсов я уже видел в matlab7sp1. Регулярно падает. Особенно не любит нечёткий даблклик мышью в current directory window. Периодически виснет при обработке больших объёмов данных. В клинических случаях приходится ручками удалять toolbox cache, иначе сразу после старта выдаёт весь свой java-report прямо в основное окно, после чего валится окончательно. Пробовали разные дистрибутивы, разные машины. Всегда одно и то же. Рядом, как скала, стоит 5.3.1. Хоть бы раз упал. В нём java ещё далеко не везде, наверно :)

Ничего личного против java, но как-то неприятно. Непонятно, почему даже при использовании такого продвинутого языка девелоперы умудряются наделать столько косяков.

Зря вы так к календарю привязались.

Изначальный твой вариант: [set@solaris ~]$ /usr/java/j2sdk/bin/java Mul Calculation time: 23976 millis

Вариант с Date вместо Calendar: [set@solaris ~]$ /usr/java/j2sdk/bin/java Mul Calculation time: 23866 ms

Вариант с Date и println вместо printf: [set@solaris ~]$ /usr/java/j2sdk/bin/java Mul Calculation time: 23418 ms

Причем все это укладывается в погрешность.

Вариант на С: [set@solaris ~]$ ./a.out Calculation time: 14.000000

Разлеты и здесь секундные.

Там заведомо C/C++ должен быть быстрее, поскольку JVM скорее всего (??) будет многократно проверять индексы на соотвествие границам массивов. Поэтому нужно брать другую задачу, где не должны активно использоваться эти самые массивы. А, вообще, глупости это все! :)

2dea загляни в функцию Calendar.getInstance() и посмотри как он там гуляет по различным функциям. C[i*p+j]=0; в джаве всё в начале инициалицируется, так что этого не надо. А ещё полезно применять модификатор final, помогает =)

public class Test {
  public static void main(String[] args) {
    final int n=1000;
    final int m=1000;
    final int p=1000;

    final long startDate = System.currentTimeMillis();
    final double[] A = new double[n*m];
    final double[] B = new double[m*p];
    final double[] C = new double[n*p];
    for (int i=0;i<n;i++)
      for (int j=0;j<m;j++)
        A[i*m+j]=Math.random();
    for (int i=0;i<m;i++)
      for (int j=0;j<p;j++)
        B[i*p+j]=Math.random();
    for (int i=0;i<n;i++)
      for (int j=0;j<p;j++) {
        for (int k=0;k<m;k++)
          C[i*p+j]+=A[i*m+k]*B[k*p+j];
      }

    System.out.println("Calculation time: " + (System.currentTimeMillis() - startDate));
  }
}

Давайте всё же для C-программы перейдём на clock:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(int argc, char* argv[])
{
  double *A=NULL;
  double *B=NULL;
  double *C=NULL;
  int i,j,k,n,m,p;
  clock_t start,end;

  n=400;
  m=700;
  p=700;
  start=clock();
  A=(double *)malloc(n*m*sizeof(double));
  B=(double *)malloc(m*p*sizeof(double));
  C=(double *)malloc(n*p*sizeof(double));
  for (i=0;i<n;i++)
    for (j=0;j<m;j++)
      A[i*m+j]=rand();
  for (i=0;i<m;i++)
    for (j=0;j<p;j++)
      B[i*p+j]=rand();
  for (i=0;i<n;i++)
    for (j=0;j<p;j++) {
      C[i*p+j]=0;
      for (k=0;k<m;k++)
      C[i*p+j]+=A[i*m+k]*B[k*p+j];
    }

  end=clock();
  printf("Calculation time: %f\n",(end-start)/(double)CLOCKS_PER_SEC);
  free(C);
  free(B);
  free(A);
  return 0;
} 

> Зря вы так к календарю привязались.

Ясно дело, что его создание за циклом стоит, и на скорость повлиять не может. Просто как-то не хочется перед С-программистами позориться :)

кстати, у меня на Athlon было, видно для Intel gcc сумел-таки SSE инструкцию схватить.

У меня на Intel 25 sec на С против 36 сек на Java.

Что еще раз показывает что тест не годится, циклы хорошо векторизуются, мне больше мое LU нравится там на Intel расклад

20984 msec у С

против

19.1720 sec у Java

лучше сам не позорься

> Давайте всё же для C-программы перейдём на clock

Давайте лучше n,m,p побольше возьмём, а то бы ещё сравнивали скорость программ, котоые 2+2 вычисляют.

памяти не хватит

Кстати. А опции оптимизации?

Последние гайки на данный момент: [set@solaris ~]$ /usr/java/j2sdk/bin/java -server Mul Calculation time: 17745 ms

[set@solaris ~]$ ./a.out Calculation time: 13.470000

Мега оптимизация (см. код) привела к выигрышу 6 (51760)(!!!) секунд. Вумная Java такую оптимизация и сама могла бы сделать (java оптимизации фууу)
public class Test {
  public static void main(String[] args) {
    final int n=1000;
    final int m=1000;
    final int p=1000;

    final long startDate = System.currentTimeMillis();
    final double[] A = new double[n*m];
    final double[] B = new double[m*p];
    final double[] C = new double[n*p];
    for (int i=0;i<n;i++)
      for (int j=0;j<m;j++)
        A[i*m+j]=Math.random();
    for (int i=0;i<m;i++)
      for (int j=0;j<p;j++)
        B[i*p+j]=Math.random();
    for (int i=0;i<n;i++) {
      final int k1 = i*m;
      for (int j=0;j<p;j++) {
        final int k2 = i*p+j;
        for (int k=0;k<m;k++) {
          C[k2] += A[k1+k]*B[k*p+j];
        }
      }
    }

    System.out.println("Calculation time: " + (System.currentTimeMillis() - startDate));
  }
}

одно добавление. замена 
final int k2 = i*p+j;
for (int k=0;k<m;k++) {
          C[k2] += A[k1+k]*B[k*p+j];
        }

на 
final int k2 = i*p+j;
int _C = 0;
for (int k=0;k<m;k++) {
          _C += A[k1+k]*B[k*p+j];
        }
C[k2] = _C;
_увеливала_ время до 100 секунд. (ещё одно фууу - преведение стандартных типов на 2).
если там использовать double то время сокращается до 35165 и становится сравнимо с С. 
В обшем давовский оптимизатор заработал два.

re:Ничего личного против java, но как-то неприятно. Непонятно, почему даже при использовании такого продвинутого языка девелоперы умудряются наделать столько косяков.

По тому, что людям свойственно ошибаться ;-)
Чем сложнее и больше задача, тем больше вероятность сделать ошибку(причем зависимость наверное экспоненциальная).
Именно по этому делают высокоуровневые языки.
Тебе будет легче понять, если ты хоть раз поучаствуешь в большом проекте. (И это не важно на каком языке проект, чем больше проект - тем больше ошибок, KDE, GNOME (кстати в последнем думают использовать mono или java именно для того, что бы сократить количество ошибок, а вовсе не для того что бы сделать Gnome быстрее (sun уже встроил JAVA в свой "GNOME", Novel давит на GNOME разработчиков, что бы они использовали Novelовский mono).

Народ, почитайте классика и не деритесь :

http://cm.bell-labs.com/cm/cs/who/bwk/interps/pap.html

Brian W. Kernighan, Christopher J. Van Wyk

Timing Trials, or, the Trials of Timing:
Experiments with Scripting and User-Interface Languages

....
Needless to say, we advise all who want to know which version of a program will run faster to construct test programs and find out the truth for their language processor and machine.
....
Despite the preceding disclaimer, we essay the following summary of our observations:
Awk and Perl are similar in performance. Awk ran faster in about half the tests, contrary to the conventional wisdom that Perl is faster than Awk.
Tcl is significantly slower than Awk and Perl, typically by a factor of five or ten, but the latest bytecode version narrows that gap significantly. Scheme appears to be very roughly comparable with Tcl (aside from volume I/O, where interpreted Scheme's performance is hopeless); again, various compilation techniques speed improve this behavior.
Our experiments do not support the folklore that Java interpreters are 10 times slower than C, except when the excruciatingly slow I/O libraries are involved; otherwise the ratio is much smaller. Using buffered I/O functions improves runtimes, but by no more than a factor of two. Just-in-time compilation can have a significant effect, usually beneficial.

Если увеличить размеры матриц в 2 раза, то выходит уже совсем интересная картина:

[set@solaris ~]$ ./a.out Calculation time: 129.170000

[set@solaris ~]$ /usr/java/j2sdk/bin/java -Xmx512M -server Mul Calculation time: 144554 ms

Ну и прикола ради:

[set@solaris ~]$ gcj -o Mul -O2 --main=Mul Mul.java [set@solaris ~]$ ./Mul Calculation time: 152466 ms

З.Ы. а статью вряд-ли кто-то читал, она скорее для явапрогов, чтобы не плодили косяки создающие устойчивые мифы.

А так? :)

        for (int i = 0; i < n; i++) {
            for (int j = 0; j < p; j++) {
                final int ipj = i * p + j;
                final int im = i * m;
                C[ipj] = 0;
                int kpj = j;
                for (int k = 0; k < m; k++) {
                    C[ipj] += A[im + k] * B[kpj];
                    kpj += p;
                }
            }
        }

Сорри, умножение в 1-й цикл:

        for (int i = 0; i < n; i++) {
            final int im = i * m;
            final int ip = i * p;
            for (int j = 0; j < p; j++) {
                final int ipj = ip + j;
                C[ipj] = 0;
                int kpj = j;
                for (int k = 0; k < m; k++) {
                    C[ipj] += A[im + k] * B[kpj];
                    kpj += p;
                }
            }
        }

Обратите внимание, что в варианте с clock я забыл после своих экспериментов обратно вернуть значения n, p и m на 1000!!!!! Каюсь, в общем :)

GM, predvizhu more flama, no:

bash-3.00$ java -Xmx512M -server Mul

Calculation time: 102677 ms

bash-3.00$ uname -a

SunOS solaris 5.10 Generic_118844-01 i86pc i386 i86pc

PR sun'а начинает сильно доставать...

Resumiruyu:

Testovaya stanciya: P4 2.8HT, 1GB.

s n,m,p = 1000 programma na C pokazala na 30% luchshe rezultat'. Pri uvelichenii n,m,p do 2000, C prodolzhal ostavatsya liderom, no uzhe s 10% operezheniem. GCJ pokazal sebya s otvratitelnoy storoni, ustupiv C 18%, java 7%.

Na toy zhe mashine pod solaris 10 rezultati java oboshli C pod linuxom na 25%, resultati C pod solarisom hotya i oboshli linux na 8%, vse ravno otstayut ot javi na 17%.

bash-3.00$ /usr/sfw/bin/gcc -O2 m.c bash-3.00$ ./a.out Calculation time: 119.790000

re:Ничего личного против java, но как-то неприятно. Непонятно, почему даже при использовании такого продвинутого языка девелоперы умудряются наделать столько косяков.
а
потом
Обратите внимание, что в варианте с clock я забыл после своих экспериментов обратно вернуть значения n, p и m на 1000!!!!! Каюсь, в общем :)



Теперь понимаешь почему девелоперы "умудряются делать ошибки"?
;-)

> Теперь понимаешь почему девелоперы "умудряются делать ошибки"?

Ну, я же не продаю свой код за бешеные бабки, как это делает MathWorks :) Теперь ещё осталось: 1) отыскать и допросить счастливого обладателя icc; 2) попробовать на зуб Python, о коем тут также заикнулись :-D

P.S. От java я ожидал заметного торможения, но она меня порядком удивила.

>2) попробовать на зуб Python, о коем тут также заикнулись :-D

Кстати, да! C & JAVA пободались! С с некоторым перевесом победил. Помоему, ни кто другого и не ожидал. Но!!! Отсиделись в тени ценители Python и С приплюснутого!

С чего бы это?

Баяца!!! :)))

Не совсем понятно почему производительность тестируется на примитивных типах. Было бы удивительно, если бы после стольких лет после создания, ява на этих "машинно-приближенных" типах сильно отставала от С/С++. Давайте уж на каких-нибудь комплексных числах померяемся...

> Не совсем понятно почему производительность тестируется на примитивных
> типах. Было бы удивительно, если бы после стольких лет после создания,
> ява на этих "машинно-приближенных" типах сильно отставала от С/С++. 
> Давайте уж на каких-нибудь комплексных числах померяемся...

Так ты предложи примерчик-то :)

Ради смеха протестировал под виндой на Delphi 5 аналогичный код:

program mmult;

uses windows,sysutils;

const
  n=1000;
  m=1000;
  p=1000;

var
  A:array[0..n-1,0..m-1] of double;
  B:array[0..m-1,0..p-1] of double;
  C:array[0..n-1,0..p-1] of double;
  i,j,k:smallint;
  t0,tn:DWORD;

begin
  t0:=GetTickCount;
  for i:=0 to n-1 do
    for j:=0 to m-1 do
      A[i,j]:=random(1);
  for i:=0 to m-1 do
    for j:=0 to p-1 do
      B[i,j]:=random(1);
  for i:=0 to n-1 do
    for j:=0 to p-1 do begin
      C[i,j]:=0;
      for k:=0 to m-1 do
        C[i,j]:=C[i,j]+A[i,k]*B[k,j];
    end;
  tn:=GetTickCount;
  MessageBoxEx(0,PChar('Calculation time, ms: '+IntToStr(tn-t0)+#13#10),'mmult',MB_OK+MB_ICONINFORMATION,0);
end.

C под линуксом считает 21.73 секунды, delphi - 22.61.

Ну так создайте эквивалентные классы в С++ и Java, реализующие простейшее представление комплексного числа с операциями сложения и умножения. Будет любопытно сравнить вариант хранения массивов С++ в стеке и в динамической памяти с только одним (по моим сведениям) возможным вариантом в Java, которая размещает значения непримитивных типов только в куче.

Может быть я не прав, но сравнивать производительность арифметики на Java и C++ неприлично.

> Может быть я не прав, но сравнивать производительность арифметики на Java и C++ неприлично.

Во-первых, умножение матриц - это таки линейная алгебра. Во-вторых, а почему и нет? Ты отказываешь ей в праве решать такие задачи?

Это арифметика. Количество FPU от языка не зависит. Разница по времени из-за runtime компиляции.

Может это толькл в Visual работает но по-моему двумерные массивы удобней так выделять на С/С++:

double (*f)[10]=(double(*)[10])malloc(sizeof(double)*10*10);
double (*k)[10]= new double[10][10];

можно нормально ссылаться   f[5][5]=10;

> Ну так создайте эквивалентные классы в С++ и Java, реализующие
> простейшее представление комплексного числа с операциями сложения и умножения

Лень и неинтересно возиться с комплексными. Вот тебе объектный пример
с матрицами. Я там даже add не использовал, так что можешь развивать. 
Зато уже тормозит по-чёрному. Посмотрим, что скажет java :)

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>

class matrix {
	private:
		double **M;
		unsigned nrows,ncols;
	public:
		matrix(unsigned n,unsigned m);
		~matrix(void);
		int create(unsigned n,unsigned m);
		int collapse(void);
		double operator [](unsigned n);
		unsigned rows(void);
		unsigned cols(void);
		int size(unsigned &n,unsigned &m);
		double r(unsigned n,unsigned m);
		int w(unsigned n,unsigned m,double N);
		int add(matrix &L);
};

matrix::matrix(unsigned n,unsigned m)
{nrows=0; ncols=0; create(n,m);}

matrix::~matrix(void)
{collapse();}

int matrix::create(unsigned n,unsigned m)
{
	unsigned i;

	if ((nrows!=0) || (ncols!=0)) collapse();
	nrows=n; ncols=m;
	M=(double **)malloc(nrows*sizeof(double *));
	for (i=0;i<nrows;i++) M[i]=(double *)malloc(ncols*sizeof(double));
	return 0;
}

int matrix::collapse(void)
{
	unsigned i;

	if (M!=NULL) {
		for (i=0;i<nrows;i++) {free(M[i]); M[i]=NULL;}
		free(M); M=NULL;
	}
	nrows=0; ncols=0;
	return 0;
}

double matrix::operator [](unsigned n)
{	return M[n/ncols][n%ncols]; }

unsigned matrix::rows(void)
{return nrows;}

unsigned matrix::cols(void)
{return ncols;}

int matrix::size(unsigned &n,unsigned &m)
{n=nrows; m=ncols; return 0;}

double matrix::r(unsigned n,unsigned m)
{	return M[n][m]; }

int matrix::w(unsigned n,unsigned m,double N)
{
	unsigned i,j;

	if ((n+1)>nrows) {
		M=(double **)realloc(M,(n+1)*sizeof(double *));
		for (i=nrows;i<(n+1);i++) {
			M[i]=(double *)malloc(ncols*sizeof(double));
			for (j=0;j<ncols;j++) M[i][j]=0;
		}
		nrows=n+1;
	}
	if ((m+1)>ncols) {
		for (i=0;i<nrows;i++) {
			M[i]=(double *)realloc(M[i],(m+1)*sizeof(double));
			for (j=ncols;j<(m+1);j++) M[i][j]=0;
		}
		ncols=m+1;
	}
	M[n][m]=N;
	return 0;
}

int matrix::add(matrix &L)
{
	unsigned i,j;

	for (i=0;i<nrows;i++) for (j=0;j<ncols;j++) M[i][j]+=L[i*L.cols()+j];
	return 0;
}

int main(int argc,char* argv[])
{
	int i,j,k,n,m,p;
	clock_t start,end;

	n=1000;
	m=1000;
	p=1000;
	start=clock();
	matrix A(n,m);
	matrix B(m,p);
	matrix C(n,p);
	for (i=0;i<n;i++)
		for (j=0;j<m;j++)
			A.w(i,j,rand());
	for (i=0;i<m;i++)
		for (j=0;j<p;j++)
			B.w(i,j,rand());
	for (i=0;i<n;i++)
		for (j=0;j<p;j++) {
			C.w(i,j,0);
			for (k=0;k<m;k++)
				C.w(i,j,C.r(i,j)+A.r(i,k)*B.r(k,j));
		}
	end=clock();
	std::cout<<"Calculation time: "<<(end-start)/(double)CLOCKS_PER_SEC<<"\n";
	return 0;
}

Не совсем.

К примеру на моем ноуте ява под виндой выдает 20-21 секунда против 17-18 на линухе и десктопе на 1000 размерности и 166 против 140 на 2000 размерности. А ПМ1.5 и П4 2.8ХТ всё-таки разные камни.

C:\>j2sdk1.4.2_04\bin\java.exe -server Mul

Calculation time: 21181 ms

Дайте гадость напоследок скажу, а? :)

Matlab 7:
>> tic;n=1000;m=1000;p=1000;A=rand(n,m);B=rand(m,p);C=A*B;toc
Elapsed time is 1.900165 seconds.

В этом нет ничего необычного. Вы тут конечно неплохо померялись у кого жаба круче, но почему то забыли о том что умножение матриц стоит делать поблочно, так чтобы соблюдалась локальность по кешу. Ускорение в 5-10 раз гарантировано(а то и больше).

вах =). Всё отстой - матлаб рулит :)

> Может быть я не прав, но сравнивать производительность арифметики на Java и C++ неприлично.

Неприлично, конечно. Потому что Фортран забыли :)

Однако, уже на таких задачках Java показывает себя с хорошей стороны. Для того, чтобы найти пример, где Java будет шустрее C/C++ можно взять, например, обработку каких-нибудь сложных и взаимосвязных структур типа графов. Особенно хорошо, если на одни и те же объкты будет ссылаться множество других объектов (ассоциации 1..* x 1..*), а также будет обилие циклических ссылок (вроде такой: obj1 -> obj2 -> obj3 -> obj1).

Вот, тогда программирование таких вещей на низкоуровневых C/C++ может превратиться в настоящий геморрой (т.е., будут тормоза), тогда как явовский сборщик мусора заточен на решение таких задач. Другое дело, что придумать такую небольшую задачу для тестов не так просто.

Дык и ежу ясно, что тестируемый алгоритм был, мягко говоря, несовершенен.

Примечательно другое. Что в первые за мою память Ява на солярисе х86 порвала реализацию под вин и линух.

На P3-800 Python 2.4 при использовании Psyco, при n = m = p = 500 расчёт занял 122 секунды :) Ессно я не использова функции Numeric для работы с массивами.

import psyco
from Numeric import *
from random import *
from time import *

psyco.full()

def calc():
    n = 500
    m = 500
    p = 500
    
    a = array(zeros(n * m), Float)
    b = array(zeros(m * p), Float)
    c = array(zeros(n * p), Float)
    
    start_time = time()    
    
    for i in xrange(n):
        for j in xrange(m):
            a[i*m+j] = random()

    for i in xrange(m):
        for j in xrange(p):
            b[i*p+j] = random()

    for i in xrange(n):
        for j in xrange(p):
            for k in xrange(m):
                c[i*p+j]+=a[i*m+k] * b[k*p+j]
                
    print "Calculation time:%f" % (time() - start_time)
                
calc()

Господа! Вашему вниманию предлагается загадка! Берётся программа

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(int argc, char* argv[])
{
  double *A=NULL;
  double *B=NULL;
  double *C=NULL;
  double *times=NULL;
  int i,j,k,N,n,m,p,r,r0,rn,dr;
  clock_t start,end;

  r0=50;
  rn=900;
  dr=10;
  times=(double *)malloc(((rn-r0)/dr+1)*sizeof(double));
  for (r=r0;r<=rn;r+=dr) {
    N=r;
    n=N;
    m=N;
    p=N;
    A=(double *)malloc(n*m*sizeof(double));
    B=(double *)malloc(m*p*sizeof(double));
    C=(double *)malloc(n*p*sizeof(double));
    start=clock();
    for (i=0;i<n;i++)
      for (j=0;j<m;j++)
        A[i*m+j]=rand();
    for (i=0;i<m;i++)
      for (j=0;j<p;j++)
        B[i*p+j]=rand();
    for (i=0;i<n;i++)
      for (j=0;j<p;j++) {
        C[i*p+j]=0;
        for (k=0;k<m;k++)
        C[i*p+j]+=A[i*m+k]*B[k*p+j];
      }

    end=clock();
    times[(r-r0)/dr]=(end-start)/(double)CLOCKS_PER_SEC;
/*    printf("%d  %f\n",r,(end-start)/(double)CLOCKS_PER_SEC); */
    free(C);
    free(B);
    free(A);
  }
  for (r=r0;r<=rn;r+=dr) {
	  printf("%d  %f\n",r,times[(r-r0)/dr]);
	}
  free (times);
  return 0;
}

и запускается. Потом внимательно анализируются результаты. Мои:

50  0.000000
60  0.000000
70  0.010000
80  0.000000
90  0.020000
100  0.010000
110  0.030000
120  0.030000
130  0.040000
140  0.040000
150  0.060000
160  0.070000
170  0.080000
180  0.120000
190  0.120000
200  0.140000
210  0.180000
220  0.200000
230  0.240000
240  0.260000
250  0.320000
260  0.350000
270  0.410000
280  0.460000
290  0.560000
300  0.590000
310  0.690000
320  0.760000
330  0.830000
340  0.840000
350  1.010000
360  0.980000
370  1.180000
380  1.190000
390  1.550000
400  1.390000
410  1.580000
420  1.610000
430  1.820000
440  1.800000
450  2.100000
460  2.100000
470  2.390000
480  2.470000
490  2.680000
500  2.670000
510  3.010000
520  3.020000
530  3.380000
540  3.390000
550  3.780000
560  3.840000
570  4.230000
580  4.400000
590  4.790000
600  4.690000
610  5.300000
620  5.220000
630  7.590000
640  23.290000
650  6.490000
660  6.320000
670  7.050000
680  6.750000
690  7.720000
700  7.560000
710  8.620000
720  8.250000
730  10.180000
740  8.900000
750  10.140000
760  9.580000
770  10.810000
780  10.420000
790  11.550000
800  11.660000
810  12.570000
820  12.070000
830  13.590000
840  13.120000
850  14.550000
860  13.880000
870  15.440000
880  15.250000
890  16.630000
900  15.860000

Скачок при r=640 хорошо виден? У меня он 100% воспроизводится каждый раз :)

Кстати, он таки ровно при 640, вот тут подробнее:

630  7.500000
631  6.490000
632  5.450000
633  6.520000
634  6.000000
635  6.650000
636  5.630000
637  6.650000
638  6.160000
639  6.710000
640  23.380000
641  6.780000
642  6.230000
643  6.920000
644  5.860000
645  6.890000
646  6.370000
647  6.980000
648  5.860000
649  7.010000
650  6.460000 

А вы говорите - проценты... Тут такой разброс может быть, что мало не покажется :) Надо производить расчёт в цикле для ряда значений, а потом строить на графике и только тогда делать выводы :) Например, брать среднее значение разности за весь интервал.

вообщето на плюсах надо уметь писать :)))

________
int main(int argc, char* argv[])
{
clock_t start =clock();
Matrix<double, 400,700>* A = new Matrix<double, 400,700>;
Matrix<double, 700,700>* B = new Matrix<double, 700,700>;
Matrix<double, 400,700>* C = new Matrix<double, 400,700>;
A->fill(rand);
B->fill(rand);
mult(*C,*A,*B);
clock_t end =clock();
printf("Calculation time: %f\n",(end-start)/(double)CLOCKS_PER_SEC);
return 0;
}
__________
./c.elf
Calculation time: 2.210000
__________
./cpp.elf
Calculation time: 1.810000
__________
uname
Linux 2.6.10-1.770_FC3smp #1 SMP i686 i686 i386 GNU/Linux

> На P3-800 Python 2.4 при использовании Psyco, при n = m = p = 500 расчёт занял 122 секунды :) Ессно я не использова функции Numeric для работы с массивами.

А что на этой машине при этих же размерах массивов говорит C?

> вообщето на плюсах надо уметь писать :)))

mult(*C,*A,*B); - это из какой библиотеки? Я и к C могу подключить какую-нибудь либу, она того быстрее посчитает. А за матлабом вообще никто не угонится. И?