CS>>и 7.1 хороший компайлер. правильно разбирает ситуацию на stosd и stosb. CS>>Интересно, а что будет с невыровненными данными?
Ш>Это надо эксперементировать. Но вообще, у современных Pentium-ов внутренняя шина данных (процессор -- кэш) 128-битная, по идее, это должно скомпенсировать блочные операции с невыровненными данными.
Однако невыравненности это никак не компенсирует. Отнюдь, увеличение конвейера требует большой осторожности при выравнивании, поскольку производительность подсистемы памяти тут крайне важна. В некоторых краевых случаях можно в разы поднять быстродейстиве только за счет выравнивания.
Здравствуйте, MShura, Вы писали:
MS>Есть подзадача: MS> написать эквивалент MS>
MS>memset( mem, 0, size );
MS>
MS>но без вызова функции memset.
MS>Ограничение в том, чтобы при использовании любого компилятора, с любыми ключами, не было вызова внешней функции "memset", потому как в некоторых случаях этой функции нет в подключаемых библиотеках. MS>Очень хочется, чтобы любой компилятор встраивал эту функцию всегда.
MS>Варианты типа: MS>- самому написать memset с помощью циклов — не интересны MS>- написать вставку на asm не подходят, т.к. на разных компиляторах разные синтаксисы.
MS>P.S. MS>memcpy(dst, src, size) легко заменяется примерно таким кодом:
MS>*(A*)dst = *(A*)src, где A — произвольная структура размера size.
MS>Для memset хочется примерно такой же вариант, поскольку если написать
MS>
L>вызов функции clear_guid в релизе транслируется в 4 ассемблерных инструкции mov
Для типов, размер которых >= sizeof(int), но требования к выравниванию менее строгие чем у int, это может привести к alignment fault.
Например:
char array[4];
zero_fill(array);
// будет эквивалентноchar array[4];
*reinterpret_cast<int*>(&array) = 0; // здесь возможен fault, т.к. array не обязательно будет выровнен на 4
Здравствуйте, folk, Вы писали:
L>>вызов функции clear_guid в релизе транслируется в 4 ассемблерных инструкции mov
F>Для типов, размер которых >= sizeof(int), но требования к выравниванию менее строгие чем у int, это может привести к alignment fault.
F>Например:
F>
F>char array[4];
F>zero_fill(array);
F>// будет эквивалентно
F>char array[4];
F>*reinterpret_cast<int*>(&array) = 0; // здесь возможен fault, т.к. array не обязательно будет выровнен на 4
F>
Это можно решить, заполняя начало блока байтами, а потом уже интами с выравниванием, но дело в том, что данная конструкция не эквивалентна memset и предназначена для более других вещей.
Здравствуйте, Шахтер, Вы писали:
АШ>>Ведь с умножением матриц Вы бы так не поступили?
Ш>Честно говоря, не понял про матрицы. Как, так?
Вот как раз с матрицами я бы
1) передавал по ссылке, и только по ссылке (слишком велик оригинал). Внутри функции заводил бы локальные переменные и как-то учитывал, что на вход может придти *this.
2) В матричной алгебре нет оператора *= произведение имеет другую размерность. Хотя если матрицы с динамическим размером, то пуркуа бы и не па...
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, Анатолий Широков, Вы писали:
АШ>>Это не сюрприз, это ошибка.
Ш>Ну да. По-моему, я так и написал -- bug.
АШ>>Ведь с умножением матриц Вы бы так не поступили?
Ш>Честно говоря, не понял про матрицы. Как, так?
Здравствуйте, folk, Вы писали:
F>Для типов, размер которых >= sizeof(int), но требования к выравниванию менее строгие чем у int, это может привести к alignment fault.
F>Например:
F>
F>char array[4];
F>zero_fill(array);
F>// будет эквивалентно
F>char array[4];
F>*reinterpret_cast<int*>(&array) = 0; // здесь возможен fault, т.к. array не обязательно будет выровнен на 4
F>
В общем случае — так оно и есть...
Интересно только, для x86 это замечание актуально? Если да, то насколько?
Здравствуйте, lextasy, Вы писали:
L>Здравствуйте, folk, Вы писали:
F>>Для типов, размер которых >= sizeof(int), но требования к выравниванию менее строгие чем у int, это может привести к alignment fault.
F>>Например:
F>>
F>>char array[4];
F>>zero_fill(array);
F>>// будет эквивалентно
F>>char array[4];
F>>*reinterpret_cast<int*>(&array) = 0; // здесь возможен fault, т.к. array не обязательно будет выровнен на 4
F>>
L>В общем случае — так оно и есть... L>Интересно только, для x86 это замечание актуально? Если да, то насколько?
Во сколько точно обойдется копирование на невыровненный адрес в x86 я не знаю, но здравый смысл подсказывает что падение производительности будет не менее чем в 2-3 раза.
Простейшее решение — вставить компайл-тайм проверку __alignof(X) >= __alignof(int), чтобы шаблон работал только с допустимыми типами.
Здравствуйте, folk, Вы писали:
F>Простейшее решение — вставить компайл-тайм проверку __alignof(X) >= __alignof(int), чтобы шаблон работал только с допустимыми типами.
Здравствуйте, lextasy, Вы писали:
L>Здравствуйте, zrs, Вы писали:
zrs>> дело в том, что данная конструкция не эквивалентна memset и предназначена для более других вещей.
L>Для более каких вещей?
Для вещей, размер которых известен в compile time и не слишком большой. Оговорюсь, сам ничего против такого подхода не имею и даже использую что то подобное.
Мнда.
В точности как задумывалось этот код работает только
будучи откомпилённым борландом 5.5
Вообще работает под cl 6,7.1, g++ 3.2.3 и CC: Sun C++ 5.5 2003/03/12.
Под icl 7.1 не работает. Темпорал убивается сразу же...
Здравствуйте, e-Xecutor, Вы писали:
EX>Здравствуйте, e-Xecutor, Вы писали:
EX>Мнда. EX>В точности как задумывалось этот код работает только EX>будучи откомпилённым борландом 5.5 EX>Вообще работает под cl 6,7.1, g++ 3.2.3 и CC: Sun C++ 5.5 2003/03/12. EX>Под icl 7.1 не работает. Темпорал убивается сразу же...
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, e-Xecutor, Вы писали:
EX>>Здравствуйте, e-Xecutor, Вы писали:
EX>>Мнда. EX>>В точности как задумывалось этот код работает только EX>>будучи откомпилённым борландом 5.5 EX>>Вообще работает под cl 6,7.1, g++ 3.2.3 и CC: Sun C++ 5.5 2003/03/12. EX>>Под icl 7.1 не работает. Темпорал убивается сразу же...
В данном конкретном случае всё понятно
Я ж про общий.
Жаль, такая фитча пропала...