что нибудь лучше чем loop & mov

Для пересылки байта, слова, двойного слова в памяти благополучно юзается mov-подобные команды.
Но если мне к примеру нужно переслать 32кб, есть ли что нибудь более продуктивное чем зацыкливание mov'а?

 

rep movsd ?

 

loop - отстой, rep тоже не самое лучшее. Лучше всего - mov + condition jump.

 

Самое простое тебе уже подсказали rep movsd. Еще быстрее может быть зацикливание movaps при наличии, особенно с ymm0 )).

 

А cамый джедайский способ, это развернуть весь луп на 8192 MOVD'а прямо в коде

 

Советую глянуть опен-сорс библу FastMM,там отдельные процедуры на различные по длине куски памяти.

 

Booster

rep movsd на немалых размерах работает достаточно шустро, и обычный mov+jcc может с ней сравниться только при развороте цикла как минимум на 4 - см. аналогичный вопрос "300 лет тому назад"

 

Cx-ветвления не годны. Не юзайте их. Они требуют сложный морфинг графа.

 

А пары MOVAPS не дадут эффекта?

 

[offtop]

Ohhhmyyygahhh! Так, где тут эта картинка с фэйспалмом...
[/offtop]

 

rep movsd будет быстрее всего, по крайней мере, в новых процах

 

l_inc
Зачем вы свою подпись пофиксили, годный был холивар же

Cx-ветвления это зло. Любой годный код(это который кодером полностью контролируется, тоесть может легко изменяться в бинарном виде) не может использовать Loop, Jcxz etc. Так как до ребилда оптимизатор должен отморфить эти ветвления, они короткие. А для их морфа два пути - либо вы определяете дельту флагов, что требует анализ большого кода(тяжёлые процедуры EN/OUT-EFlags), либо сохранение флагов, последнее не годно ибо вносится в сигнатуры и аверская эвристика негодует на pushfd.

Если суть вопроса в производительности, то это смысла не имеет. Вы работаете в мультизадачной среде. Свапконтекст заберёт у задачи времени много больше, чем сотни лупов.

 

Malfoy

А какая была старая? Я её несколько лет назад менял. Не помню уже, что там за холивар был.

Для 32кб может и не имеет. А когда пересылаются десятки гигабайт (пусть даже чанками по 10 метров), то имеет. В любом случае пермутируемость кода тс точно не интересовала.
P.S. Кстати, даже вот такая простая замена всего лишь одной функции, вызываемой при конвертировании цветовой палитры из yuv в bgr, давала 20%-й выигрыш во времени декодирования метровых jpeg-ов, включая чтение файла с диска и сохранение 17-метрового результата на диск:

Код (Text):

1. static inline unsigned char clamp(int i)
2. {
3.     __asm volatile (".intel_syntax noprefix\n\t"
4.                     "mov eax,%[i]\n\t"
5.                     "cmp eax,0x80000000\n\t"
6.                     "sbb edx,edx\n\t"
7.                     "add eax,0xFFFFFF00\n\t"
8.                     "sbb ecx,ecx\n\t"
9.                     "or eax,ecx\n\t"
10.                     "and eax,edx\n\t"
11.                     ".att_syntax prefix\n\t" : : [i]"r"(i) : "%eax", "%ecx", "%edx");
12.  
13.     /*
14.     if (i<0)
15.         return 0;
16.     else if (i>255)
17.         return 255;
18.     else
19.         return i;
20.     */
21. }

А разница всего-то в непредсказанных переходах.