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

Вниз

выравнивание данных   Найти похожие ветки 

 
вразлет ©   (2004-09-13 11:15) [0]

В С++ для увеличения скорости доступа к данным структур используется выравнивание полей по размеру машинного слова, что приносит некоторые неудобства при работе с ними (приходится трахаться с порядком определения полей или явно указывать величину выравнивания посредством директивы компилятору).
Вопрос: А как обстоит дело с выравниванием данных в Делфях?


 
Сусилк   (2004-09-13 11:17) [1]


> Вопрос: А как обстоит дело с выравниванием данных в Делфях?

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


 
Суслик ©   (2004-09-13 11:18) [2]

Ах, да - такое же слово (packed) можно ставить и перед array, но по моим наблюдениям оно в массивах ни на что не влияет. ПО крайней мере я не знаю ни одного примера массива, где это бы оказывало влияние на разположение элементов (заметте, не внутри элементов) в памяти.


 
DiamondShark ©   (2004-09-13 11:19) [3]

Есть packed, есть $A


 
Игорь Шевченко ©   (2004-09-13 11:23) [4]


> В С++ для увеличения скорости доступа к данным структур
> используется выравнивание полей по размеру машинного слова,


Далеко не всегда. Например, все структуры в WinAPI невыровненные.


 
KSergey ©   (2004-09-13 11:27) [5]

> вразлет ©   (13.09.04 11:15)
> В С++ для увеличения скорости доступа к данным структур
> используется выравнивание полей по размеру машинного слова

Не по размеру, а на границу слова.

> что приносит некоторые неудобства при работе с ними (приходится
> трахаться с порядком определения полей или явно указывать
> величину выравнивания посредством директивы компилятору

Я только не понял зачем трахаться? Надо упаковано - указал #pragma pack, не надо - не указал ;) Ну либо в настройках компилера на весь исходник.


 
KSergey ©   (2004-09-13 11:29) [6]

> [4] Игорь Шевченко ©   (13.09.04 11:23)
> > В С++ для увеличения скорости доступа к данным структур
> > используется выравнивание полей по размеру машинного слова,
> Далеко не всегда. Например, все структуры в WinAPI невыровненные.

Что не говорит о том, что они оптимизированы по скорости ;) Другое дело, что не выровненность не всегда лишь для экономии места - об этом речь?


 
вразлет ©   (2004-09-13 11:39) [7]

KSergey ©

Не спорю.


 
Игорь Шевченко ©   (2004-09-13 11:47) [8]

KSergey ©   (13.09.04 11:29) [6]


> Что не говорит о том, что они оптимизированы по скорости
> ;)


Да, конечно. Зато они совместимы с имеющимися компиляторами, а это перевешивает некоторые потери быстродействия. Кроме того, внутренние структуры Windows оптимизированы по быстродействию, а так как основная работа ведется внутри, то быстродействие в целом не страдает.


 
Юрий Зотов ©   (2004-09-13 11:48) [9]

> вразлет ©   (13.09.04 11:15)

См. [3], а в новых версиях Delphi границу выравнивания полей еще можно и указывать непосредственно (1, 2, 4, 8), в том числе и глобально для всего проекта.

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

Конечно, нет ничего плохого в том, что один человек хорошо знает, например, Си, но гораздо слабее знает, например, Паскаль (а другой человек - наоборот). И, конечно, можно только приветствовать, когда каждый из них стремится узнать больше (например, задавая вот такие совершенно нормальные и корректные вопросы, как нынешний).

Но, вероятно, было бы странно (да и просто смешно), если бы человек, очень слабо знающий некую сущность, вдруг позволил себе судить о ее достоинствах или недостатках, не так ли? Заметьте - не срашивать и уточнять, а именно судить.

Так вот - не стоит ли воздержаться от оценок Delphi/Паскаля до той поры, пока он не будет изучен и понят (!) в достаточной для этого степени?


 
KSergey ©   (2004-09-13 11:51) [10]

Да ладно...
Это как в анекдоте про профессарора и границу незнания ;)


 
вразлет ©   (2004-09-13 12:24) [11]

[9] Юрий Зотов ©   (13.09.04 11:48)

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


 
суслик ©   (2004-09-13 12:25) [12]

оно у ввех разное


 
Fay ©   (2004-09-13 12:27) [13]

2  [9] Юрий Зотов ©   (13.09.04 11:48)
Вы не могли бы привести пример структуры/массива, которую(ый) можно выровнять по границе QWORD? Просто очень любопытно - мне ни разу не удалось.


 
Юрий Зотов ©   (2004-09-13 12:45) [14]

> вразлет ©   (13.09.04 12:24) [11]

И это, безусловно, есть влияние внутренних недостатков самого Си.

> Fay ©   (13.09.04 12:27) [13]

Если верить справке, то для этого достаточно использовать директиву {$A8}. А если она не помогает, то это вопрос не ко мне, а к разработчикам.

Правда, еще нужно принять во внимание и то, что написано в справке по теме "Record types" (автоматическое определение способа выравнивания для полей разных типов, если не указано packed). Похоже, что для 32-битных процессоров A8 идентично A4 (возможно, как раз поэтому и не удается получить реальное выравнивание на QWORD).


 
Fay ©   (2004-09-13 12:49) [15]

2   [14] Юрий Зотов ©   (13.09.04 12:45)
М.б. я плохо старался (всякое бывает), но у КОГО-НИБУДЬ получится - опубликуйте тут, plz.


 
MBo ©   (2004-09-13 13:11) [16]

>Fay
Увы, для выравнивания массива 8-байтных данных, что требуется для работы с SSE, приходилось выделять чуть больший блок памяти, возвращая указатель на адрес, кратный 8


 
Fay ©   (2004-09-13 13:35) [17]

2  [16] MBo ©   (13.09.04 13:11)
Я, собственно, всегда так делаю (если правильно понял), т.е. выделяю блоки нужной кратности, и вссегда пишу packed 8)


 
DiamondShark ©   (2004-09-13 13:46) [18]

Когда-то я пугал народ таким объявлением:
type Z = packed class A: packed file of packed array[0..10] of packed record a: packed set of byte end end;


 
MBo ©   (2004-09-13 13:47) [19]

>Fay
Я имел в виду что-то вроде такого:


type
 PInt64Array = ^TInt64Array;
 TInt64Array = array[0..$FFFFFF] of Int64;

function Make64Array(Size: Integer): PInt64;
var
 p: Pointer;
begin
 GetMem(p, Size * 8 + 4);
 Result := Pointer(((Integer(p) + 7) shr 3) shl 3);
end;

procedure Delete64Array(p: Pointer);
begin
 if p <> nil then
   FreeMem(Pointer(Integer(p) - 4));
end;



 
Fay ©   (2004-09-13 14:04) [20]

2 [19] MBo ©   (13.09.04 13:47)
Если это не очень большой секрет, что иллюстрирует приведённый код?
Массив из Int64 будет выровнен в любом случае, разве нет?
А, понял 8) Это выравнивание начала массива. А как уговорить Delphi выравнивать по QWORD записи вида

type
 TAnyRec = record    
   dw : DWORD
   n : Integer;
   a : packed array[0..12] of byte;
 end;


???


 
Семен Сорокин ©   (2004-09-13 14:21) [21]


> DiamondShark ©   (13.09.04 13:46) [18]
> Когда-то я пугал народ таким объявлением:
> type Z = packed class A: packed file of packed array[0..10]
> of packed record a: packed set of byte end end;

Без пол-литры и не разберешь, только в коде расставив нужные отступы, забавно :))


 
DiamondShark ©   (2004-09-13 14:24) [22]


> А как уговорить Delphi выравнивать по QWORD записи вида

А зачем?


 
MBo ©   (2004-09-13 14:24) [23]

>Массив из Int64 будет выровнен в любом случае, разве нет?
Увы, на адрес 8n+4 (свойство менеджера памяти- перед выделенным функциями типа GetMem блоком хранится его размер - 4 байта, перед телом динамического массива - 12 байт служебной информации)

>А, понял 8) Это выравнивание начала массива.
Да, и каждого его 8-байтного элемента соответственно (иначе каждый элемент лежит по неподходящему для обработки SSE адресу)

>А как уговорить Delphi выравнивать по QWORD записи вида
видимо, только фиктивными полями :(


 
Fay ©   (2004-09-13 14:30) [24]

8( я пришёл к такому же выводу 8(



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

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

Наверх





Память: 0.51 MB
Время: 0.03 c
4-1093435027
FreeMan1
2004-08-25 15:57
2004.10.03
LowLevelKeyboardProc


1-1095156943
aleks-ran
2004-09-14 14:15
2004.10.03
FastReport 2.46 Не работает переменная COLUMN#


3-1094024391
Koala
2004-09-01 11:39
2004.10.03
Клиент-сервер (MIDAS) под Firebird 1.5


1-1095704751
klopan
2004-09-20 22:25
2004.10.03
RichEdit &amp; Enter


8-1088095062
Sunny Way
2004-06-24 20:37
2004.10.03
Чтение JPEG





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский