Великая битва 4х языков программирования на простейшей задачке

[johnk]

import std.c.windows.windows : GetTickCount;
import std.stdio : writefln, readln;

void main()
{
    int counter = 0;
    auto current = GetTickCount();

    scope map = new int[512 * 128 * 512];

    int allocationTime = GetTickCount() - current;

    writefln("Allocation took: %dms", allocationTime);

    current = GetTickCount();
    for(int i = 0; i < 20; ++i)
    {
        for(int x = 0; x < 512; ++x)
        {
            for(int y = 0; y < 128; ++y)
            {
                for(int z = 0; z < 512;++z)
                {
                    ++counter;
                    map[512 * 128 * x + 128 * y + z] = counter;
                }
            }
        }
    }

    int fillingTime = GetTickCount() - current;

    writefln("Total filling time: %dms", fillingTime);
    writefln("Average fill time per step: %dms", fillingTime/20);

    readln();
}

Версия для D 2.056.
Результаты чуток получше, но, увы...

Allocation took: 125ms
Total filling time: 1609ms
Average fill time per step: 80ms

Ди, к сожалению, далеко не конкурент С++

[moka]

Сделал 3 теста на C#, первый вариант, затем тот что PAX'а, и потом jagged от HolyDel'а.
В общем результаты такие:
Multidimensional:
Allocate: 1.6ms
Fill: 712.95ms
Get(65536 times): 1.03ms

Flattened:
Allocate: 1.6ms
Fill: 223.68ms
Get(65536 times): 0.62ms

Jagged:
Allocate: 448.18ms
Fill: 296.11ms
Get(65536 times): 0.46ms

Intel Pentium 4 CPU 3.00Ghz (2 CPUs)

Получается, работа в общем с Flatenned на C# в основном самый быстрый способ. Но с Jagged, если использовать статический массив, то доступ к данным будет быстрее.
Учитывая постоянный доступ, если он будет необходим, лучше всё таки использовать именно Jagged массив. А если нужен динамичный, то Flatten. Обычный мультиразмерный - естественно идёт мимо.

[HolyDel]

и намного ты быстрее напишешь, чем cl.exe нагенерит?

; 23   : ++counter;
	inc	esi
; 24   : map[512 * 128 * x + 128 * y + z] = counter;
	mov	DWORD PTR [eax], esi
	add	eax, 4
	dec	ecx
	jne	SHORT $LL3@main

[Платон Александрович]

Сообщение от HolyDel

и намного ты быстрее напишешь, чем cl.exe нагенерит?

; 23   : ++counter;
	inc	esi
; 24   : map[512 * 128 * x + 128 * y + z] = counter;
	mov	DWORD PTR [eax], esi
	add	eax, 4
	dec	ecx
	jne	SHORT $LL3@main

какое-то двусмысленное выражение
если написать в смысле напечатать, то быстрее не смогу , а если написать код который был бы быстрее, то вот
раза в два быстрее *trollface*

mov eax, 1
@@:
    movnti dword [ebp], eax
    add ebp, 4
    inc eax
test eax, 512 * 128 * 512 - 1
jnz @b

диалект fasm
ЗЫ
полный сырок

format PE console
entry start

include 'macro/import32.inc'
include 'macro/proc32.inc'

section '.data' data readable writeable

    text_alloc db 'allocation time %d ms', 13, 10, 0
    text_fill db 'fill time %d ms', 13, 10, 0

section 'code' code readable executable

start:

    stdcall [timeBeginPeriod], 1

    stdcall [timeGetTime]
    mov [esp+4], eax

    stdcall [GetProcessHeap]

    stdcall [HeapAlloc], eax, 0, 512 * 128 * 512 * 4
    mov ebp, eax

    stdcall [timeGetTime]
    mov [esp+8], eax

    mov eax, 1
    @@:
	movnti dword [ebp], eax
	add ebp, 4
	inc eax
    test eax, 512 * 128 * 512 - 1
    jnz @b

    stdcall [timeGetTime]
    mov [esp+12], eax

    stdcall [timeEndPeriod], 1

    mov eax, [esp+8]
    sub eax, [esp+4]
    ccall [printf], text_alloc, eax

    mov eax, [esp+12]
    sub eax, [esp+8]
    ccall [printf], text_fill, eax

    stdcall [ExitProcess], 0

section 'idata' import data readable

	library\
	   kernel32, 'kernel32.dll',\
	   winmm, 'winmm.dll',\
	   msvcrt, 'msvcrt.dll'

	import kernel32,\
		    GetProcessHeap, 'GetProcessHeap',\
		    HeapAlloc, 'HeapAlloc',\
		    ExitProcess, 'ExitProcess',\
		    GetTickCount, 'GetTickCount'

	import winmm,\
		 timeBeginPeriod, 'timeBeginPeriod',\
		 timeGetTime, 'timeGetTime',\
		 timeEndPeriod, 'timeEndPeriod'

	import msvcrt,\
		  printf, 'printf'

[HolyDel]

Платон, при всем уважении, твой ексешник у меня работает 36-43 мс. а сгенирированный студией 16 (если одна итерация, как у тебя, и 12, если итераций 20 как в исходном примере) такчто студия в два раза *trollface* fasm-а.

i7 - 2600K 3.4, 16GB, Win7 64 bit

[ffinder]

Сообщение от Платон Александрович

какое-то двусмысленное выражение
если написать в смысле напечатать, то быстрее не смогу , а если написать код который был бы быстрее, то вот
раза в два быстрее *trollface*

странно, но твой код дает дикий разброс времени выполнения от 60 до 340 мс.
но, учитывая, что джава может за 43 мс, то 60 на асме - это абсолютный фейл.
Да, "зоопарк" архитектур убил асм, как средство оптимизации.
ЗЫ: Core i3 Sandy Bridge

[HolyDel]

такчто плюсы грубой силой дали просраться даже asm-у


johnk, второй вариант на D 31, 19. уже очень близко к крестам.

[AVL]

var
  c:integer;
  n,t:integer;

procedure fill;
var
  a:array[1..512,1..128,1..512] of integer;
  i,j,k:integer;
begin
  writeln('allocation:',(milliseconds-n));
  n:=milliseconds;
  c:=1;
  for i:=1 to 512 do
    for j:=1 to 128 do
      for k:=1 to 512 do begin
        a[i,j,k]:=c;
        c:=c+1;
      end;
  t:=milliseconds-n;
  writeln('filling:',t);
end;
begin
  n:=milliseconds;
  fill;
end.

PascalABC.NET:
allocation:546
filling:891

MidletPascal: (эмулятор KEmulator Lite)
allocation: 515
filling: 234 //

Железо - P4 3.2 GHz

[HolyDel]

AVL, ну ексешник же... дай.

[Платон Александрович]

Сообщение от HolyDel

Платон, при всем уважении, твой ексешник у меня работает 36-43 мс. а сгенирированный студией 16 (если одна итерация, как у тебя, и 12, если итераций 20 как в исходном примере) такчто студия в два раза *trollface* fasm-а.

i7 - 2600K 3.4, 16GB, Win7 64 bit

Ну значит не судьба Надежда была на единственную (остальной-то код ничем не отличается от студийного) инструкцию movnti которая кеш не дергает за счет чего быстрее выполняется, но видимо в новых пеньках это не так. У меня 4ый.
Можно еще попробывать SSE, но врятли будет профит на таком простом заполнении памяти.

Сообщение от ffinder

странно, но твой код дает дикий разброс времени выполнения от 60 до 340 мс.
но, учитывая, что джава может за 43 мс, то 60 на асме - это абсолютный фейл.
Да, "зоопарк" архитектур убил асм, как средство оптимизации.
ЗЫ: Core i3 Sandy Bridge

Да-да, все из-за специфичной movnti Но можно оптимизировать под основные ходовые процессоры и на старте выбирать по используемому процессору, тогда будет хорошо

ЗЫ
Как здесь удалять мессаги-то? Не вижу такой кнопки

[ffinder]

Сообщение от Платон Александрович

Да-да, все из-за специфичной movnti Но можно оптимизировать под основные ходовые процессоры и на старте выбирать по используемому процессору, тогда будет хорошо

а еще надо помнить про эффективность работы программиста, майнкрафт он не из одного заполнения массива состоит. если так полировать код под все процессоры руками...

[pax]

Ну чо, выбор ложиться на C# или на яву?

[johnk]

бери Nemerle

[.Squid]

C++ FTW!

[HolyDel]

Получается, работа в общем с Flatenned на C# в основном самый быстрый способ. Но с Jagged, если использовать статический массив, то доступ к данным будет быстрее.

это очень странно. не должно так быть. с flatten надо просто выполнить несколько арифмитических операций, чтобы вычислить индекс, а с jagged нужны как минимум два обращения к памяти. покажи код.