Портирование FPU на SSE

не, его ещё долго не выкинут..

а на таком https://dalthron.com.pe/product/laptop-hp-245-g7-amd-ryzen-3-1tb-8gb-ram-freedos/ ещё и фридос запускается

 

UbIvItS,

sse/mmx блоки ведь не для расчёта тригонометрии. А если выкинуть fpu, то это изменение всей архитектуры - как обрабатывать ошибки, ловушки и прочие вещи(нп осевой планировщик не тупо крутит мат блоки, он их оптимизирует выключая мат блоки на новых квантах). Если отказаться от fpu, то это будет уже не IA. Что все утверждают что новые мат блоки быстрее это всё фигня, где реальные цифры, как всегда где замеры по профайлу ?

Кто там выше утверждал что реализовал Тейлор на sse, где примеры тесты профайл ?

 

Indy_,
aida64
prime95
https://www.codeproject.com/Articles/21024/Inner-Product-Experiment-CPU-FPU-vs-SSE
тестЬ сколько хОшЪЪЪ. другой Вопрос, что фпу и векторные регистры всё же несколько разные вещи == фпу -- это скалярные вычисления и аж 80бит число, а векторные регистры позволяют проводить пакетные операции, но точность страдает. т.е. лобовое сравнение тут не очень уместно.

 

UbIvItS,

Тут задача в реализации тригонометрии через блоки расширения(sse etc). Тоесть софт реализация вычислений, Тейлор/Маклорен/etc. Конечный результат не обязательно в регистрах хранить, всё равно они выгружаются в память при чтении. По ссылке никакой тригонометрии не обнаружил.

 

Indy_, Delphi 10.4 (последний): x86 использует FPU, x64 – SSE2.
Тестим:

Код (Text):

1. {$APPTYPE CONSOLE}
2. uses Winapi.Windows;
3. var
4.   C, i: Integer;
5.   D, delta: Double;
6.  
7. begin
8.   D := 0;
9.   delta := Pi / 18000000;
10.   C := GetTickCount;
11.   for i := 1 to 36000000 do
12.   begin
13.     D := D + delta;
14.     Sin(D);
15.   end;
16.   C := GetTickCount - C;
17.   WriteLn(C);
18. end.

x86 ≈ 1350
x64 ≈ 875

Заменяем Sin на Exp: 1150 / 750.
Ln у обоих 780.

 

Jin X,

Теорию относительности читал, константа не имеет смысла если её не с чем сравнить. Получилось значение для fpu-sin. Теперь нужен тот же цикл для реализации син через Тейлор-sse.

А в общем нужно глянуть на саму дельфовую sin() дизом, не известно что там, я дельфи никогда не юзал. Для математики лучший сборщик басик как не удивительно https://www.purebasic.com/

Дельфи тут глупо приводить в пример, это дичь.

 

тут имеем место быть несколько иная хистория...
https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/
http://notabs.org/fpuaccuracy/

 

Так, я ж говорю, что x86 – это fpu, а x64 – sse2 (Тейлор).
Там не нужен дизасм, там есть исходники этих функций. Я их смотрел (да и под дизасмом тоже), там именно то, что я написал.

Не вопрос:

Спойлер: FASM

Код (ASM):

1. format  PE64 Console 5.0
2. include 'win64axp.inc'
3.  
4. ;-- CODE SECTION -------------------------------------------------------------------------------------------------------
5.  
6. .code
7.  
8. entry:
9.  
10. frame
11.                 finit
12.                 fldz
13.  
14.                 invoke  GetTickCount
15.                 mov     ebx,eax
16.  
17.                 mov     ecx,36000000
18.         @@:
19.                 fadd    [delta]
20.                 fld     st
21.                 fsin
22.                 fstp    st
23.                 dec     ecx
24.                 jnz     @B
25.  
26.                 fstp    st
27.  
28.                 invoke  GetTickCount
29.                 sub     eax,ebx
30.  
31.                 cinvoke printf, <'%d',10>, eax
32.                 invoke  ExitProcess, 0
33. endf
34.  
35. ;-- DATA SECTION -------------------------------------------------------------------------------------------------------
36.  
37. .data
38.  
39. delta           dq      1.745329251994e-7
40.  
41. ;-- IMPORT SECTION -----------------------------------------------------------------------------------------------------
42.  
43. section '.idata' import data readable
44.  
45. library kernel32, 'kernel32.dll',\
46.         msvcrt, 'msvcrt.dll'
47.  
48.         import_kernel32
49.         all_api
50.  
51. import  msvcrt,\
52.         printf, 'printf'

У меня выдаёт ≈ 1150.
Если уж "дичь"-sse2/Тейлор работает на 30+% быстрее, чем чистый асм-fpu, то что уж говорить о "нормальной" реализации Тейлора?

--- Сообщение объединено, 30 июл 2020 ---

А вообще говоря, улучшить её можно как минимум бóльшим "распараллеливанием" вычислений, чем в Delphi.
Надо ещё на плюсах попробовать. По любому там будет sse2 под x64 (по крайней мере, под какие-то компиляторы).

 

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

 

Jin X,

> x86 – это fpu, а x64 – sse2

И что межу ними общего. Это не замер, а чушь. Сравнение профайла на разных архитектурах. А есчо покажи где тригон вычисляется через sse, дельфя такое врядле умеет.

> Я их смотрел

В студию сурки или диз. Что ты видел никого не волнует, может у тебя глюки кто знает

 

В Delphi (x64) синус выглядит так:

 

maalchemist,

Какой то полином, начало ряда:

r6 = ([487] * (r0^2)^2 + [47f]) * (r0^2)^2 + [477]
r4 = ((([487] * (r0^2)^2 + [483]) * ((r0^2)^2 + [47b]*2) * r0^2 + r6 + [46B]) * r0^2

Врядле может быть какая то точность. Но уже больше похоже на правду. Это нужно сравнить по таймингу с fsin.

 

Дельфийский SSE-синус возвращает абсолютно такой же результат, что и FPU:fsin, если аргумент <= 18003.
Для косинуса результаты совпадают, если аргумент <= 17908.
Только что проверил.

 

maalchemist,

Тогда получается что хард fsin использует тот же полином.

А что по таймингу ?

 

Однако для разных аргументов получаются существенно разные времена.
Если сравнивать встроенный SSE-синус вот с такой функцией,

Код (Text):

1. function FPU_fsin (a: Double): Double;
2. asm
3.   sub     rsp, 16
4.   movupd  dqword ptr [rsp], xmm0
5.   fld     qword ptr [rsp]
6.   fsin
7.   fstp    qword ptr [rsp]
8.   movupd  xmm0, dqword ptr [rsp]
9.   add     rsp, 16
10. end;
11.  

то для аргумента 0.01 SSE-версия работает в 4.4 раза быстрее.

Для других аргументов имеем такие результаты:
0.1 - 4.4
1.0 - 2.8
5.0 - 1.5
10.0 - 1.3
100.0 - 1.3
1000.0 - 1.5
10000.0 - 1.5
100000.0 - 1.04
1000000.0 - 1.3

 

maalchemist,

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

 

Для оценки я использовал вот такую простенькую функцию:

Код (Text):

1. function FPU_SSE_sin_TEST (a: Double): Double;
2. var
3.   I      : Integer;
4.   I1, I2 : Int64;
5.   J1, J2 : Int64;
6.   ID, JD : Double;
7.   Ratio  : Double;
8. begin
9.   QueryPerformanceCounter (I1);
10.   for I := 1 to 1000000 do begin
11.     FPU_fsin (a);
12.   end;
13.   QueryPerformanceCounter (I2);
14.   ID := I2 - I1;
15.  
16.   QueryPerformanceCounter (J1);
17.   for I := 1 to 1000000 do begin
18.     sin (a);
19.   end;
20.   QueryPerformanceCounter (J2);
21.   JD := J2 - J1;
22.  
23.   Ratio := ID / JD;
24.   Result := Ratio;
25. end;
26.  

 

maalchemist,

Если длительность менее кванта профайл будет невалид. Нужно либо очень большое значение dTSC, либо лучше использовать GetTickCount().

 

Я ж замерил x64 на асме (fpu) и на Delphi (sse), вторая оказалась быстрее, см. выше.
К тому же, я переделывал асм-код под x86, скорость была абсолютно той же, как и на x64, так что разница архитектур тут большой роли не играет.

Пишем под x86 Sin(1), заходим под отладчиком (IDE-шным), видим:

Код (Text):

1. asm
2.         FLD     tbyte ptr X
3.         FSIN
4.         FWAIT
5. end;

Пишем под x64 то же самое, видим:

Код (Text):

1.  
2. function Sin(const X: Double): Double;
3. var
4.   Q: integer;
5.   Y,Z: Double;
6. begin
7.   if Abs(x) < Pi/4 then
8.     Result := pSinDouble(X, 0)
9.   else
10.   begin
11.     Q := pRemDouble(X, Y, Z);
12.     case Q of
13.       0: Result :=  pSinDouble(Y, Z);
14.       1: Result :=  pCosDouble(Y, Z);
15.       2: Result := -pSinDouble(Y, Z);
16.       3: Result := -pCosDouble(Y, Z);
17.       else Result := 0; // avoid warning W1035 Return value of function '%s' might be undefined
18.     end;
19.   end;
20. end;

далее (pRemDouble неинтересен, идём в pCosDouble):

Код (Text):

1. {$IF    defined(ARITH_PUREPASCAL_EXT64) or defined(ARITH_X64_SSE)}
2. function pCosDouble(const x, y: Double) : Double;
3. const
4.   CCos : ARRAY[0..5] OF UINT64 =
5.   ( $BDA8FA6A8A7D84DF,
6.     $3E21EE9DC12C88AC,
7.     $BE927E4F7F1EE922,
8.     $3EFA01A019C8F945,
9.     $BF56C16C16C15018,
10.     $3FA555555555554B );
11. var
12.   r1, r2, s, t, u, v,
13.   L, L1, L2,
14.   D2, D4 : Double;
15. begin
16.   D2 := x * x;
17.   D4 := D2 * D2;
18.   L1 :=           PDouble(@CCos[0])^;
19.   L2 :=           PDouble(@CCos[1])^;
20.   L1 := L1 * D4 + PDouble(@CCos[2])^;
21.   L2 := L2 * D4 + PDouble(@CCos[3])^;
22.   L1 := L1 * D4 + PDouble(@CCos[4])^;
23.   L2 := L2 * D4 + PDouble(@CCos[5])^;
24.   L := L2 + L1 * D2;
25.   L := L * D4;
26.   s := 1.0;
27.   t := D2 * 0.5;
28.   u := s - t;
29.   v := u - s;
30.   r1 := t + v;
31.   r2 := x * y;
32.   r2 := L - r2;
33.   r2 := r2 - r1;
34.   Result := u + r2;
35. end;

Смотрим дизасм в этом месте:
https://www.screencast.com/t/pTo3pLs7Urz

Вот ещё вараинт:

Код (Text):

1. {$APPTYPE CONSOLE}
2. uses Winapi.Windows;
3. var
4.   C, i: Integer;
5.   D, delta: Double;
6. procedure FpuInit;
7. asm
8. FINIT
9. end;
10. function FpuSin: Double;
11. asm
12.         FLD     qword ptr D
13.         FSIN
14.         FWAIT
15.         FSTP    st
16. end;
17. begin
18.   D := 0;
19.   delta := Pi / 18000000;
20.   FpuInit;
21.   C := GetTickCount;
22.   for i := 1 to 36000000 do
23.   begin
24.     D := D + delta;
25.     FpuSin();
26.   end;
27.   C := GetTickCount - C;
28.   WriteLn(C);
29. end.

Компилим в x64 (чтоб всё по-честному было), получаем: 1125 мсек (против ≈ 850 обычного Sin на sse/Тейлор, тоже x64, исходники выше).

--- Сообщение объединено, 1 авг 2020 ---

Х/з, что там внутри и почему это медленнее.
В исходнике Delphi, по меньшей мере, идёт чередование использования регистров (переменные L1, L2), которые вычисляются параллельно (можно сделать 3 шт вообще, по идее, должно быть ещё быстрее). Может, в харде все вычисления последовательны?
Кстати, надо ещё на AMD замерить скорость, кстати...

--- Сообщение объединено, 1 авг 2020 ---

На AMD разница меньше: 1100 / 800 (вообще говоря, замер sse сильно скачет от 700 до 950 примерно).

--- Сообщение объединено, 1 авг 2020 ---

*разница НЕ меньше.

 

Jin X,

~1.3 раза быстрее, это ниочём. Странно конечно почему последовательность инструкций выполняется быстрее чем одна fsin при том же результате. Фишка fpu - там есть стек, на котором идут вычисления, что делает не нужным выгрузку результата в память. Те на последовательности мат функций fpu будет быстрее. Судя по профайлу нет никакого смысла юзать левое(полиномы на sse), тем более для системы это не имеет значения - она выгружает мат блок через xsave.

> pCosDouble

Так это чебышев походу, нужно искать по коэффициентам. В точности совпадает с fsin ??

--- Сообщение объединено, 1 авг 2020 ---

Jin X,

> FWAIT

Эта инструкция доставляет мат фаулт, если его нет работает как nop. Если зациклить L: fwait/jmp L, то ядро будет использовать мат блок и общий профайл потока просядет. Это сам факт использования математики, mmx отображены на fpu, sse в том же блоке и в общем любо обращение к этим блокам включает механизм выгрузки контекста математики, а это долго ибо он большой.

--- Сообщение объединено, 1 авг 2020 ---

Jin X,

На скрине L1 := CCos[0]

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