> Тыщ   (09.04.08 02:03) [19]
>
> Германн ©   (09.04.08 1:56) [18]
>
> Странный ты. Заладил "плохо читал", "плохо читал". Твое
> утверждение голословно.
>

Я не "странный". Я - Германн.
Из справки Д6: "The $A directive controls alignment of fields in record types."

Германн ©   (09.04.08 2:11) [20]

Согласись, если бы record'ы могли выравниваться на 16 байт, это бы решило часть моей проблемы.

> Тыщ   (09.04.08 02:17) [21]
>
> Германн ©   (09.04.08 2:11) [20]
>
> Согласись, если бы record'ы могли выравниваться на 16 байт,
>  это бы решило часть моей проблемы.
>

Не соглашусь. Пока ты не объяснишь смысл фразы "если начало функции кратно параграфу".

> Согласись, если бы record'ы могли выравниваться на 16 байт,
>  это бы решило часть моей проблемы.

Сделай 8-байтное выравнивание, и засунь между элементами "заглушки" int64. Будет тебе 128 бит.

Германн ©   (09.04.08 2:29) [22]

Объясняю. "начало функции кратно параграфу" означает, что адрес, с которого начинается функция, кратен 16 байтам.
Но это относится к выравниванию кода, а [20] решило бы выравнивание данных.

DrPass ©   (09.04.08 2:33) [23]

Так все равно не будет гарантии, что record начнется на 16-байтной границе.
Вот я и говорю,
[0] > "или можно только подбирать каждый раз неиспользуемые код и данные для выравнивания?"

> DrPass ©   (09.04.08 02:33) [23]

Это уже подразумевалось в tesseract ©   (08.04.08 21:59) [1]

> Тыщ   (09.04.08 02:41) [24]
>
> Германн ©   (09.04.08 2:29) [22]
>
> Объясняю. "начало функции кратно параграфу" означает, что
> адрес, с которого начинается функция, кратен 16 байтам.
>

Ну и ?
А дальше то что?
Или ты надыбал функцию, а она не не работает?

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

>Тыщ   (08.04.08 22:03) [2]

Из документации Intel

Code Alignment
The P6 family and Pentium® processors have a cache line size of 32 bytes. Since the prefetch
buffers fetch on 16-byte boundaries, code alignment has a direct impact on prefetch buffer efficiency.
For optimal performance across the Intel Architecture family, it is recommended that:
• A loop entry label should be 16-byte aligned when it is less than 8 bytes away from that
boundary.
• A label that follows a conditional branch should not be aligned.
• A label that follows an unconditional branch or function call should be 16-byte aligned
when it is less than 8 bytes away from that boundary.

14.4.3. Data Alignment
...................
CODE OPTIMIZATION
• Align 80-bit data on a 128-bit boundary (that is, any boundary that is a multiple of 16
bytes).
• Align 128-bit SIMD floating-point data on a 128-bit boundary (that is, any boundary that is
a multiple of 16 bytes).

В итоге, тебе нужно выравнивание DATA на 128-bit boundary.
И выравнивание кода циклов и переходов согласно.

• A loop entry label should be 16-byte aligned when it is less than 8 bytes away from that
boundary.

• A label that follows an unconditional branch or function call should be 16-byte aligned
when it is less than 8 bytes away from that boundary.

P.S. Напиши перемещаемый ASM код. Далее VirtualAlloc и Copymemory + Reloc FIXING на метках.

> Тыщ   (09.04.08 02:41) [24]
> Германн ©   (09.04.08 2:29) [22]
>
> Объясняю. "начало функции кратно параграфу" означает, что
> адрес, с которого начинается функция, кратен 16 байтам.
> Но это относится к выравниванию кода, а [20] решило бы выравнивание
> данных.
>
> DrPass ©   (09.04.08 2:33) [23]
>
> Так все равно не будет гарантии, что record начнется на
> 16-байтной границе.
> Вот я и говорю,


Делай выравнивание на стеке сам

procedure TForm1.Button1Click(Sender: TObject);
var AlignedData:pointer;
begin
asm
mov ecx,esp;
and cl,$F0;
sub ecx,esp;
mov eax,DWORD PTR sizeof(Trect);
and al,$F0;
add eax,$10;
sub ecx,eax;
mov edx,esp;
lea esp,[esp+ecx];
mov AlignedData,esp;
mov esp,edx;
end;
end;

> Ты не знал, что SSE работает с 128-битными переменными и
> таким же выравниванием?


Я знаю, что в MMX и 170-битные значения может пользовать. Вот только какое это оношения имеет к {$ALING 16}  и тому что DELPHI не поддерживает SSE, это не имеет. SSE пишуться чаще всего на ASM-е, так что смотри, как тебе нужно всё обравнять.

> Ты не знал, что SSE работает с 128-битными переменными и
> таким же выравниванием?

Не с переменными, а со 128-битными регистрами и данными. Переменные для SSE филькина грамота.

> Dimaxx  (09.04.2008 13:16:31)  [31]

Это так, но речь идет о переменных, а Интел еще и о переходах. Связано это с шириной кеша. И более того на повестке дня уже выравнивание и на 32 байта, современные процессоры имеют кеш 256 бит и есть материнские платы с 4 каналами памяти, в которых возможно загрузка кеша за одну операцию чтения вместо двух, в них выравнивание на 32 байта может дать реальный выигрыш.

Выравнивание на 16 байт нужно не столько для SSE, сколько для Extended (80 бит), это то есть во многих программах и есть во всех на Дельфи работающих с плающеей запятой, она вся основана на Extended

> tesseract ©   (08.04.08 22:15) [5]
> 128 битное выравнивание это к врачу. 64-битное это приемлимо,
>  если понимаешь зачем процессору это нужно. Оно реально
> нужно только для 64 битных регистров.

Это тебе надо к врачу. М.б. он научит прежде чем постить, изучить предмет.

Не так давно, в пределах месяца, наверно, эта тема обсуждалась

Ага, вот она:
http://pda.delphimaster.net/?id=1206039059&n=18

По поводу SSE - телепатор мне подсказывает, что автору вопроса следует для начала заглянуть сюда:
http://www.fastcode.dk/fastcodeproject/fastcodeproject/index.htm

>  М.б. он научит прежде чем постить, изучить предмет.


Я имел в виду программирование в Delphi.  Тема про SSE/MMX/вариации float не поднималась. В виду новых данных пост считьть как основанный на неверных вводных данных.

oxffff, Sapersky, спасибо!