Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Основная";
Текущий архив: 2005.06.14;
Скачать: [xml.tar.bz2];

Вниз

Pointer->Integer->Pointer   Найти похожие ветки 

 
Marser ©   (2005-05-27 23:50) [40]


> Defunct ©   (27.05.05 21:10) [35] [Новое
>сообщение][Ответить]
>begin...end ©   (27.05.05 20:58) [31]
>
> > Ваш код я видоизменил: вместо ламерского способа
> измерения времени выполнения кода функцией использовал
>GetTickCount,
>
> Вам не стыдно такое писать?

Действительно ламерство. Если б ты предложил QueryPerformanceTimer, то это дело. Но TDateTime с сопутствующими - истинная черепаха.
Твоя проблема, ИМХО, в том, что глубочайшие знания у тебя соседствуют с пробелами чуть ли не в табличке умножения.


 
ZlDoc ©   (2005-05-28 00:09) [41]

Народ чет вы все похоже на высоком уровне засиделись (хоть я сам на асьме не профи). Но скажу, что смотреть длинну команды или прогонять Mov в цикле For (да еще и с вызовом процедуры), это както не по научному. имхо.
Время выполнения команды надо тактами процессора измерять (они в старых учебниках по процессорам написаны). Процессор такая вещ что состояние может тока раз в такт менять. Следовательно, чтоб выполнить mov eax, [I + ESP + ECX], ему надо несколько тактов чтоб I + ESP + ECX посчитать, а потом mov выполнить.
Так что и без тестов сказать можно что быстрее выполниться (тем более смотрю никак в результатах не сойдетесь)

PS. Быстрее ассемблера ничего не придумали...


 
Defunct ©   (2005-05-28 00:10) [42]

Marser ©   (27.05.05 23:50) [40]

Это мне?


 
Marser ©   (2005-05-28 00:12) [43]


> Defunct ©   (28.05.05 0:10) [42] [Новое
>сообщение][Ответить]
>Marser ©   (27.05.05 23:50) [40]
>
> Это мне?

У бегиныча я пробелов не наблюдал. Были какие-то мелочные проколы, но программное время с помощью TDateTime он не измерял...


 
Marser ©   (2005-05-28 00:13) [44]


> PS. Быстрее ассемблера ничего не придумали...

Фронт прямоугольного импульса (С)
:о)


 
Defunct ©   (2005-05-28 00:20) [45]

Marser ©   (28.05.05 00:12) [43]

А какая разница с помощью чего измерять время если мне хватает точности. Ведь на фоне 2*~110 Млрд инструкция, два обращения к системному таймеру, роли не играет. Тем более, Now изменяется с каждым тиком таймера, вот и скажате, какой смысл использовать GetTickCount который выдает какие-то значения в "попугаях", когда я вам вывел время более привычных секундах с такой же точностью как begin...end (вы сказали без проколов) с помощью GetTickCount.

Или "глубочайшие знания у тебя соседствуют с пробелами чуть ли не в табличке умножения" (C) Marser?.


 
Defunct ©   (2005-05-28 00:22) [46]

Marser ©   (27.05.05 23:50) [40]

Теперь уже вас спрашиваю, вам не стыдно такое писать?
1. функции QueryPerformanceTimer нет.
2. GetTickCount и Now изменяются с одинаковой точностью.
3. Вы просто так оскорбили меня на ровном месте.


 
Defunct ©   (2005-05-28 00:29) [47]

ZlDoc ©   (28.05.05 00:09) [41]

> несколько тактов чтоб I + ESP + ECX посчитать
Не нужно, потому что для вычисления адреса не используется обычное АЛУ, а используется дополнительный сумматор/вычислитель адреса, учитывая конвеерную организацию процессора, вычисление адреса и действие АЛУ выполняются параллельно.


 
Marser ©   (2005-05-28 00:32) [48]


> 1. функции QueryPerformanceTimer нет.

QueryPerformanceCounter, уж простите великодушно.

> 2. GetTickCount и Now изменяются с одинаковой
> точностью.

А скорость? GetTickCount это один элементарный системный вызов. А у Вас кроме того ещё и FormatDateTime используется.

> 3. Вы просто так оскорбили меня на ровном месте.

1. Не на ровном.
2. Не оскорбил.
3. Всё равно прошу прощения.


 
Defunct ©   (2005-05-28 00:41) [49]

Marser ©   (28.05.05 00:32) [48]

Я не хочу никого выставить ламером,
ошибаются все. Тем более под общую шумиху, впринципе ваше поведение было ожидаемо.

Но, обратите внимание сюда:

T1 := now;
цикл
T2 := now;


Ничего лишнего, кроме засечения времени старта и останова.
Наличие запущеных сервисов под winxp дадут куда большую погрешность чем погрешность, получаемая за счет времени затрачиваемого на конвертирование показаний сист. таймера в TDateTime. Тем более погрешность эта систематическая, и для первого и для второго тестов одинакова, соответственно на точность результата никак не влияет.

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


 
Marser ©   (2005-05-28 00:47) [50]

Вот неполное изложение того, во что выливается Now:
function Now: TDateTime;
{$IFDEF MSWINDOWS}
var
 SystemTime: TSystemTime;
begin
 GetLocalTime(SystemTime);
 with SystemTime do
   Result := EncodeDate(wYear, wMonth, wDay) +
     EncodeTime(wHour, wMinute, wSecond, wMilliseconds);
end;
function EncodeDate(Year, Month, Day: Word): TDateTime;
begin
 if not TryEncodeDate(Year, Month, Day, Result) then
   ConvertError(@SDateEncodeError);
end;
function TryEncodeDate(Year, Month, Day: Word; out Date: TDateTime): Boolean;
var
 I: Integer;
 DayTable: PDayTable;
begin
 Result := False;
 DayTable := @MonthDays[IsLeapYear(Year)];
 if (Year >= 1) and (Year <= 9999) and (Month >= 1) and (Month <= 12) and
   (Day >= 1) and (Day <= DayTable^[Month]) then
 begin
   for I := 1 to Month - 1 do Inc(Day, DayTable^[I]);
   I := Year - 1;
   Date := I * 365 + I div 4 - I div 100 + I div 400 + Day - DateDelta;
   Result := True;
 end;
end;
function EncodeTime(Hour, Min, Sec, MSec: Word): TDateTime;
begin
 if not TryEncodeTime(Hour, Min, Sec, MSec, Result) then
   ConvertError(@STimeEncodeError);
end;
function TryEncodeTime(Hour, Min, Sec, MSec: Word; out Time: TDateTime): Boolean;
begin
 Result := False;
 if (Hour < 24) and (Min < 60) and (Sec < 60) and (MSec < 1000) then
 begin
   Time := (Hour * 3600000 + Min * 60000 + Sec * 1000 + MSec) / MSecsPerDay;
   Result := True;
 end;
end;

Вот вам и ничего лишнего...
При кратковременных засечках это даёт очень большую погрешность. Крооме того, для кратковренных засечек измерений в милисекундах(gettickcount) вполне достаточно.

> Тем более под общую шумиху, впринципе ваше поведение
> было ожидаемо.

Моё - нет :-)


 
ZlDoc ©   (2005-05-28 00:49) [51]

Defunct ©
Ok. Возможно я не прав. (Но точно помню где-то читал что сначала вычисляется адрес)
Но всеравно мерить не выход. Ведь Win среда многозадачная, и праллельно с измерениями выполняются еще 2 десятка процессов + некоторые с RalTime приоритетом. Много опытов придется ставить чтоб чего то достоверное получить.


 
Defunct ©   (2005-05-28 00:55) [52]

Marser ©   (28.05.05 00:47) [50]

Спасибо что вы привели код функции Now, но опять-таки пусть 1000 команд, пусть 10000 (хотя на самом деле их там меньше), против 2.2*10^11 (кол-во команд в цикле), это вы сами понимаете фактически 0.

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


 
Marser ©   (2005-05-28 01:01) [53]


> Defunct ©   (28.05.05 0:55) [52]

Допустим, что так. Я кокретный пример не рассматривал. В общем случае GetTickCount эффективнее, а также проще.


 
Defunct ©   (2005-05-28 01:02) [54]

ZlDoc ©   (28.05.05 00:49) [51]

Ну так при измерении были приостановлены почти все процессы, и заметьте результат получился дважды одинаковым. (при первом тесте случайно дернул мышку).

Marser ©   (28.05.05 00:47) [50]
> Крооме того, для кратковренных засечек измерений в милисекундах(gettickcount) вполне достаточно.

Загляните в [30], ~45 секунд это кратковременная засечка? С точностью до сотых секунды NOW вполне достаточно.


 
Defunct ©   (2005-05-28 01:04) [55]

Marser ©   (28.05.05 01:01) [53]
> Я кокретный пример не рассматривал.

Вот, поэтому может быть не стоит делать поспешных выводов о ламерстве?


 
Marser ©   (2005-05-28 01:09) [56]


> Вот, поэтому может быть не стоит делать поспешных
> выводов о ламерстве?

А я о ламерстве конкретно вашем ничего и не говорил.  На злодієві шапка горить? ;-)


 
Defunct ©   (2005-05-28 01:17) [57]

Marser ©   (28.05.05 01:09) [56]

Да ладно там :) Куда уж отпираться-то.

Marser ©   (27.05.05 23:50) [40]
> Действительно ламерство.

Defunct ©   (28.05.05 00:10) [42]
> Это мне?

Marser ©   (28.05.05 00:12) [43]
> У бегиныча я пробелов не наблюдал. Были какие-то мелочные проколы, но программное время с помощью TDateTime он не измерял...


 
Marser ©   (2005-05-28 01:20) [58]

Добре. Можете мене записати в свої одвічні вороги, якщо вам так кортить.


 
Marser ©   (2005-05-28 01:22) [59]

Але я вам щиро не раджу цього робити... Зайвий ворог, та ще й на рівному місці...


 
Defunct ©   (2005-05-28 01:27) [60]

Marser ©   (28.05.05 01:22) [59]

Помоему и так все цивилизовано решилось.

"Мир! Дружба! Жвачка!" :) поговорка со времен когда жвачка стоила гораздо больше булки хлеба.


 
begin...end ©   (2005-05-28 10:55) [61]

> Defunct ©   (27.05.05 23:45) [39]

> Промолчу, если вы заметили, я уже стараюсь с вами не спорить.

Теперь смотрим, что же было в посте [36], на который Вы "промолчали":

1. Результаты, опровергающие Ваши утверждения (даже с отключённой оптимизацией вариант с умножением проиграл).
2. Уличение Вас во лжи насчёт отсутствия хинтов (их просто не могло не быть, или они были отключены).

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

> Для получение объективного результата проверьте в равных
> условиях команды
>
> mov eax, [I + ESP + ECX*8]
> и
> mov eax, [I + ESP + ECX]
>
> т.е. сугубо наличие умножения индекса.

Если нужно проверить команды, отличающиеся только наличием умножения индекса, то зачем тогда константа I? Команды, отличающиеся только наличием умножения, уже проверялись в Вашем коде [28], результаты выполнения которого были приведены мной в [31] и [36] (с включённой и отключённой оптимизацией, соответственно).

Сорри, но прогонять Ваши тесты уже надоело. Судя по тому, как Вы были уверены в результате, в [36] вариант с умножением должен был выиграть. Однако этого не произошло.

Что касается способа измерения времени, то не удивлюсь, если в следующий раз Вы будете использовать часы с кукушкой.

Судя по [33], автору вопроса мой совет помог, а для меня это в этой ветке -- главное.


 
Sergey Masloff   (2005-05-28 11:28) [62]

begin...end ©   (27.05.05 20:58) [31]
>способа измерения времени выполнения кода функцией использовал >GetTickCount, хотя это тоже не лучший способ.
Ну да. Это ж время работы системы а не вашего кода. Так что GetThreadTimes() было бы уместнее (если конечно это в NT системе происходит). А иначе меряется средняя по больнице температура.


 
TUser ©   (2005-05-28 13:11) [63]

Вообще, не думаю, что тут надо браться за асм или изменять логику работы с дин.массивами. Сущействует несколько алгоритмов умножения матриц, который различаются скоростью работы. Посмотрите в интернете по словам "алгоритм Штрассена" - это один из самых быстрых.


 
Defunct ©   (2005-05-28 18:03) [64]

begin...end ©   (28.05.05 10:55) [61]
LMD

> Судя по тому, как Вы были уверены в результате,
Я до сих пор в нем уверен.


Sergey Masloff   (28.05.05 11:28) [62]
прочитайте ветку дальше.

TUser ©   (28.05.05 13:11) [63]
Если на асме есть возможность расчитать индекс быстрее, почему бы не воспользоваться этим?


 
Defunct ©   (2005-05-28 18:59) [65]

Прочитать о масштабировании индексных региcтров можно в "Instruction Set Reference Vol 2.A" в разделе 2.6 "Addressing-Mode Enconiding of ModR/M and SIB"

В "Vol 2.B, Appendix B" можно найти что инструкции
[ecx]
[ecx*8]
выполняются за одинаковое количество тактов.

Всего хорошего.

PS: (как меня уже дастали выбрыки begin...end, я тебе не школьник, чтобы от тебя выслушивать все это дерьмо).


 
begin...end ©   (2005-05-28 20:31) [66]

> Defunct ©   (28.05.05 18:59) [65]

> LMD

Из этой реплики следует, что Вам надоело жить.

>> Судя по тому, как Вы были уверены в результате,
> Я до сих пор в нем уверен.

А я до сих пор уверен в результатах [31] и [36].

> Defunct ©   (28.05.05 18:59) [65]

Если это так, то [31] и [36] можно объяснить только корявостью написанного Вами теста.

> я тебе не школьник

Верно, Вы больше похожи на дошкольника.

> выслушивать все это дерьмо

Придётся.

Продолжать разговаривать с деревом смысла не вижу.


 
Defunct ©   (2005-05-28 21:01) [67]

begin...end ©   (28.05.05 20:31) [66]

> Если это так, то [31] и [36] можно объяснить только корявостью написанного Вами теста.

Странно, почему же у меня "коряво написанный тест" это подтверждает.

А может быть ваше "неламерское" видоизменение, так повлияло. Не вы ли написали:
> Ваш код я видоизменил: вместо ламерского способа измерения времени

> Верно, Вы больше похожи на дошкольника.
>> выслушивать все это дерьмо
> Придётся.

LMD


 
TUser ©   (2005-05-29 05:01) [68]

> Если на асме есть возможность расчитать индекс быстрее,
почему бы не воспользоваться этим?

Да я не против. Просто быстрее в таком случае означает - процентов на 10 максимум, я понимаю. Обычно, если уж программа медленно работает, то очень сильно помогает изменение логики работы алгоритма, а не переход на си, ассемблер или покупка супер-компьютера. А судя по [10] тут как раз такой случай, что алгоритм можно улучшить.

Хотя против асма тоже ничего не имею.


 
Defunct ©   (2005-05-29 07:54) [69]

TUser ©   (29.05.05 05:01) [68]

навеяно вашими размышлениями..
Алгоритм [33] на асме с MMX и SSE и масштабированием индексов о котором здесь был спор с begin...end.

Работает почти в 3 раза быстрее чем [33]. 0.38 сек. (моя функция) против 1.0сек. (оригинал [33])

procedure TForm2.Button4Click(Sender: TObject);
var
a:^real;  //311x700
b:^real;  //700x311
c:^real;  //311x311
begin
getmem(a,311*700*sizeof(real));
getmem(b,311*700*sizeof(real));
getmem(c,311*311*sizeof(real));

memo1.lines.add(writems);

{}
asm
{ подготовка MMX и SSE }
  push  ebx
  push  esi

  mov   eax, c
  movd  mm6, eax
  mov   eax, b
  movd  mm0, eax
  mov   eax, a
  movd  mm1, eax      // A - low dword

  mov   eax, 311
  movd  mm2, eax
  punpckldq mm2, mm2  // Двойной множитель на 311

// for i := 0 to 310 do
  mov   ecx, 310
@L1:
// for j := 0 to 310 do
  mov   edx, 310
@L2:
  pxor  xmm1, xmm1    // Переменная Temp в фантазии SSE
                      // Расчет i/j адреса вынесен из цикла k
  movd  mm4, ecx
  punpckldq mm4, mm4
  movd  mm4, edx
  movq  mm3, mm4
  pmullw mm3, mm2
  pmulhw mm4, mm2
  pslld  mm4, 16      // j * 311
  paddd  mm4, mm3
  punpckldq mm3, mm4  // i * 311

// for k := 0 to 699 do
  mov   ebx, 699
@L3:

  movd   eax, mm0   ; // pointer to B
  add    eax, ebx   ;
  movd   esi, mm4
  movq   xmm0, [eax + esi*8]
  movd   eax, mm1   ; // pointer to A
  add    eax, ebx
  movd   esi, mm3
  mulsd  xmm0, [eax + esi*8]
  addpd  xmm1, xmm0          ; // temp:=temp+pa^*pb^;

  dec    ebx
  jns    @L3

  movd   eax, mm6   ; // pointer to C
  movd   esi, mm4   ; // j * 311
  add    esi, ecx   ; // + i
  movq   [eax + esi*8], xmm1 // сохраняем temp

  dec    edx
  jns    @L2

  dec    ecx
  jns    @L1

  emms
  pop  esi
  pop  ebx
end;

memo1.lines.add(writems);

end;


 
Defunct ©   (2005-05-29 08:31) [70]

Кстати именно этот множитель индекса и не учтен в [33] его вообще там нет, соответственно функция [33] не рабочая .. и моя не рабочая (т.к. делал по образу [33]), а чтобы сделать ее рабочей надо поменять в цикле k этот код

 movd   eax, mm0   ; // pointer to B
 add    eax, ebx   ;
 movd   esi, mm4
 movq   xmm0, [eax + esi*8]
 movd   eax, mm1   ; // pointer to A
 add    eax, ebx
 movd   esi, mm3


на такой:

 movd   eax, mm0   ; // pointer to B
 movd   esi, mm4
 add    esi, ebx   ;
 movq   xmm0, [eax + esi*8]
 movd   eax, mm1   ; // pointer to A
 movd   esi, mm3
 add    esi, ebx


 
Marser ©   (2005-05-29 11:03) [71]


> begin...end ©
> Defunct ©  

Break!
Вы уже давно грызётесь. А толку-то? Никому из вас это на пользу не идёт, авторитету не добавляет. Только однеому создаёт неповторимый оттенок, а другому ещё более его усугубляет.
Зачем?


 
alertus ©   (2005-05-30 17:00) [72]

Подскажите, пожелуйста, где можно прочитать про инструкции SSE??


 
Digitman ©   (2005-05-30 17:03) [73]


> Подскажите, пожелуйста, где можно прочитать про инструкции
> SSE??


в мануалах от Интела ... это же его детище ..


 
alertus ©   (2005-05-30 17:06) [74]

Как я понял, там почти тоже самое, как программирование на асме, только добавляются регистры новые для быстрых операций с вещественными числами??
А ссылку не подскажете??


 
Digitman ©   (2005-05-30 17:11) [75]

на сайте у Анатолия Подгорецкого, кажется, был ..

в оригинале файл называется 24547112.pdf

IA-32 Intel ® Architecture
Software Developer’s
Manual
Volume 2 :
Instruction Set Reference


 
Defunct ©   (2005-05-30 17:28) [76]

alertus ©   (30.05.05 17:06) [74]

Боюсь у Athlon"a нет SSE. (во всяком случае насколько я помню у Athlon TB не было, а вы говорили что у вас Athlon 800, это скорее всего и есть TB). У AMD процессоров есть 3DNow! для работы с числами с плавающей точкой, так что ищите мануал на сайте AMD а не Intel"а. Вам всего навсего нужна замена команд ADDPD/ADDSD и MULPD/MULSD.


 
DiamondShark ©   (2005-05-30 17:53) [77]


> зависит ли скорость от расстояния между этими физическими
> адресами??

В системах с многоуровневой памятью -- зависит.
Иногда очень сильно.


 
begin...end ©   (2005-05-30 20:05) [78]

> alertus ©   (27.05.05 21:02) [33]

Этот код не выполняет умножения матриц. Вот рабочий код:

const
 M = 311; // Число строк в A и столбцов в B
 N = 700; // Число строк в B и столбцов в A
type
 TElement = Real;
 PElement = ^TElement;
var
 Temp: TElement;
 i, j, k: Integer;
 A, B, C: PElement;
 pA, pB, pC: PElement;
begin
 GetMem(A, M * N * sizeof(TElement));
 GetMem(B, N * M * sizeof(TElement));
 GetMem(C, M * M * sizeof(TElement));
 try
   pC := C;
   for i := 1 to M do
   begin
     pA := PElement(Integer(A) + (i - 1) * N * sizeof(TElement));
     for j := 1 to M do
     begin
       pB := PElement(Integer(B) + (j - 1) * sizeof(TElement));
       Temp := 0;
       for k := 1 to N do
       begin
         Temp := Temp + pA^ * pB^;
         Inc(pA);
         Inc(pB, M)
       end;
       pC^ := Temp;
       Inc(pC);
       Dec(pA, N)
     end
   end
 finally
   FreeMem(A);
   FreeMem(B);
   FreeMem(C)
 end
end.


> Defunct ©   (29.05.05 07:54) [69]
> Defunct ©   (29.05.05 08:31) [70]

Нерабочий код. Вылетает с External Exception.


 
Defunct ©   (2005-05-30 20:07) [79]

begin...end ©   (30.05.05 20:05) [78]

Код под P4, mulsd на P3 нет.


 
Defunct ©   (2005-05-30 20:08) [80]

> begin...end
Прошу прощения что поставил неверный коментарий:

{ подготовка MMX и SSE2 }



Страницы: 1 2 3 вся ветка

Форум: "Основная";
Текущий архив: 2005.06.14;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.64 MB
Время: 0.041 c
4-1113854624
Wistful
2005-04-19 00:03
2005.06.14
узнать события Light Alloy


1-1117506251
Gern
2005-05-31 06:24
2005.06.14
Проверка поля EdIt


4-1114001856
Medved
2005-04-20 16:57
2005.06.14
Отслеживание запуска программ.


14-1116491813
Skier
2005-05-19 12:36
2005.06.14
Опять новая концепция развития нашего автопрома...


4-1113930130
Studentik
2005-04-19 21:02
2005.06.14
Создание одноэкземплярного приложения с осложнением...





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский