Здравствуйте, Erop, Вы писали:
E>Здравствуйте, ArtDenis, Вы писали:
RI>>>По-моему я довольно точно сказал. Ну если надо, пожалуйста AD>>...
AD>>Т.к. это pod-тип, то можешь смело использовать memcpy. Скорость, как минимум, будет не меньше, чем при поэлементном копировании элементов.
E>Точно ли так? Там же в каждой структуре есть дырка в слово по крайней мере, и копиконструктор её пересылать не будет. Так что может memcpy и проиграет Кто его знает-то?
, например, в VC 2003 копирование в цикле pod-типов разворачивается в rep movsd с любой оптимизацией, а memcpy только иногда (при компиляции с оптимизацией по объёмы заменяется на вызов call _memcpy)... Ясен пень, что без оптимизации всё остаётся на своих местах и поэтому не рассматривается...
Так что при компиляции в релизе никакого копирующего конструктора реально для них не генерируется и не вызывается (по крайней мере в этом случае)...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Не понял. Если ты напишешь цикл, то компилятор его уже никак на memcpy не заменит. И слава Богу. Не надо нам таких умных компиляторов. Или под оптимизатором ты человека имел в виду?
Vutik wrote:
> ME>У меня есть сильное подозрение, что Intel C++ compiler for Linux > разворачивает memcpy в mmx/sse, т.к. скорости рукописного цикла и > memcpy gcc на моих тестах были в 3 раза меньше. Сглупил кода > тестировал — не посмотрел asm output. > Скорее она использует DMA если размер блока большой...
DMA перестал быть самым быстрым способом копирования еще со времен 486.
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, Alex Alexandrov, Вы писали:
AA>>Не понял. Если ты напишешь цикл, то компилятор его уже никак на memcpy не заменит. И слава Богу. Не надо нам таких умных компиляторов. Или под оптимизатором ты человека имел в виду?
MN>Вы ошибаетесь. Заменит и ещё как. См. здесь
Здравствуйте, Cyberax, Вы писали:
C>Vutik wrote:
>> ME>У меня есть сильное подозрение, что Intel C++ compiler for Linux >> разворачивает memcpy в mmx/sse, т.к. скорости рукописного цикла и >> memcpy gcc на моих тестах были в 3 раза меньше. Сглупил кода >> тестировал — не посмотрел asm output. >> Скорее она использует DMA если размер блока большой...
C>D
MA перестал быть самым быстрым способом копирования еще со времен 486.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, arcman, Вы писали:
A>>Вот Вам книжка — всем читать!
A>>("Крис Касперский — Техника ортимизации программ.djvu", 5.2 MB, распаковывается RAR'ом или TAR'ом)
MN>А скажите пожалуйста, причём здесь техника оптимизации программ и приведённые мной результаты компиляции memcpy и копирования в цикле? Я что-то не понял...
Извиняюсь за то что мой пост ввёл Вас в заблуждение
Я использую "плоский" вид отображения форума и не слежу за тем в какую подветку мой пост попадает — просто тыкаю "ответить" у самого последнего поста =)
Мой пост адресован ВСЕМ и относится к основной теме ветки.
"От: RI
Дата: 16.08.05 01:45
У меня копируется один массив в другой (его размер под 2 метра).
Сейчас я планировал сделать это в цикле, а потом наткнулся на функцию memcpy.... с ней наверное будет быстрее? или нет?"
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Здравствуйте, arcman, Вы писали:
A>>Вот Вам книжка — всем читать!
A>>("Крис Касперский — Техника ортимизации программ.djvu", 5.2 MB, распаковывается RAR'ом или TAR'ом)
A>>PS: Разумеется электронная версия выложена в ознакомительных целях и подразумевает дальнейшую покупку своего легального бумажного собрата A>>Преимущества бумажной версии думаю перечислять не стоит
AA>Есть у меня дома полочка, на которую я ставлю книги, которые я бы вернул в магазин, если бы это возможно было. Если кончится место на полках и надо будет что-то делать — я их выкину без сожаления. Почти без сожаления — с поправкой на потраченные деньги. Сейчас на этой полке:
AA>1. Роберт Дж. Оберг, COM+ технология — Основы и программирование. AA>2. Сулейман Лалани, Рамеш Чандэк, Active X. AA>3. Эш Рофэйд, Яссер Шохауд, COM и COM+. AA>4. Эрик Аллен, Типичные ошибки проектирования. AA>5. Крис Касперски, Техника оптимизации программ. AA>6. Еще пара книг, про которые даже говорить стыдно...
Непонятно чем Вам не понравилась эта книга. Автор провёл серьёзное практическое исследование по вопросам связанным с оптимизацией вцелом, оптимизацией доступа в память, и т.д. Более полного/полезного издания я не встречал. Конечно материал представлен достаточно сумбурно, но тот кто ищет без проблем найдёт в этой книги ответы на свои вопросы. Лично я с нетерпением жду продолжения серии.
ЗЫ: Книга даёт однозначные ответы на весть тот флейм посвящённый вопросам оптимизации что поразвели в данном форуме.
Здравствуйте, Аноним, Вы писали:
А>Да он и не был никогда самым быстрым. А>Самый быстрый способ состоит в следующем:
А>Для мультизадачной ОС (Виндовс)
А>1. Запрещаем переключать процессы А>2. Запрещаем любые прерывания
А>3. Копируем.
А>4. Разрешаем прерывания А>5. Разрешаем переключать процессы.
А>Удачи.
Забавно: кто ж тебе даст то в User Mode запретить прерывания?
Здравствуйте, arcman, Вы писали:
A>Непонятно чем Вам не понравилась эта книга. Автор провёл серьёзное практическое исследование по вопросам связанным с оптимизацией вцелом, оптимизацией доступа в память, и т.д. Более полного/полезного издания я не встречал. Конечно материал представлен достаточно сумбурно, но тот кто ищет без проблем найдёт в этой книги ответы на свои вопросы. Лично я с нетерпением жду продолжения серии.
я рассказывал о конкретных недостатках книги.
A>ЗЫ: Книга даёт однозначные ответы на весть тот флейм посвящённый вопросам оптимизации что поразвели в данном форуме.
Документация по процессорам Intel (Optimization Reference Manual, в частности) дает на весь тот флейм еще более однозначные ответы.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, Mr. None, Вы писали:
MN>Вы читали внимательно ссылку, которую я дал? Я написал цикл и memcpy, а компилятор их обоих заменил на rep movsd и никакого шайтанства тут нет...
Я ее вообще не читал. Ну да, заменил на rep movsd или еще на что-то — все нормально, обычная intrinsic функция. Не пойму только, причем здесь вот это твое заявление:
AA>Не понял. Если ты напишешь цикл, то компилятор его уже никак на memcpy не заменит. И слава Богу. Не надо нам таких умных компиляторов. Или под оптимизатором ты человека имел в виду?
Вы ошибаетесь. Заменит и ещё как.
Заметь, в исходном тезисе речь идет о замене на memcpy (вызов CRT-функции), а не на какой-то rep movsd.
P.S. В целом тема себя изжила, так что я от нее отписываюсь.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, remark, Вы писали:
R>Здравствуйте, RI, Вы писали:
RI>>У меня копируется один массив в другой (его размер под 2 метра). RI>>Сейчас я планировал сделать это в цикле, а потом наткнулся на функцию memcpy.... с ней наверное будет быстрее? или нет?
R>Если массив POD-типов, то быстрее не будет, а если не POD-типов, то будет веселее
R>А если серьёзно, то я думаю, что скорость копирования большого блока памяти всё равно упрётся в скорость работы с памятью. memcpy просто нечего предложить принципиально нового по сравнению с циклом копирования. Т.е. если грамотно написать цикл копирования (без лишних операций), то скорость его выполнения будет не на много отличаться.
Про память всё верно, но "лишние" операции могут здорово помочь. Пример "лишних операций"
R>Хотя всё таки разумнее использовать memcpy как минимум по двум причинам. Первая — её реализацию скорее всего соптимизировали на уровне ассемблера. Вторая — код будет более читабельным, т.к. сразу будет понятно что что-то копируется, а не просто цикл, а так же понятно что, куда и сколько.
Если используется Intel C++ compiler, то результат memcopy будет довольно хороший. Иначе, вероятно, не очень .
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, MaximE, Вы писали:
ME>Здравствуйте, Аноним, Вы писали:
А>>Да он и не был никогда самым быстрым. А>>Самый быстрый способ состоит в следующем:
А>>Для мультизадачной ОС (Виндовс)
А>>1. Запрещаем переключать процессы А>>2. Запрещаем любые прерывания
А>>3. Копируем.
А>>4. Разрешаем прерывания А>>5. Разрешаем переключать процессы.
А>>Удачи.
ME>Забавно: кто ж тебе даст то в User Mode запретить прерывания?
