Стандартными функциями пользоваться в принципе можно

Это какими?

Можно сделать на ассемблерной вставке. Наверняка быстрее будет. Хотя, чем черт не шутит: gcc -O3 иногда очень даже хорошо оптимизирует.

1 в 2 по байтно.

А данные не выровнены?

Да там полно. memcpy(), bcopy() например.

Вспомни шутку про идиотов, использовавших memcpy, не читая внимательно мануала. Помнится, какая-то адобовская ненужная поделка из-за этого отличненько сегфолтилась.

А для копирования памяти блоками наверняка ведь есть ассемблерные функции, которые будут явно шустрее побайтного копирования.

memmove для перекрывающихся участков

Я - идиот беспамятный!

http://glagolew2010.narod.ru/14/memmove.htm например.

Ну или самому побайтно попробовать. Что быстрее - черт его знает.

Да циклом-то не хуже можно скопировать.
Но опять же для разных процев можно по разному.
Например 16-байтовыми кусками с помощью xmm.

У меня такое подозрение (в кодах glibc ковыряться нет желания), что memmove и реализован через ассемблерные архитектурнозависимые инструкции.

http://glagolew2010.narod.ru/14/memmove.htm

Че за ссылка? kernel.org же наше всё!

memmove

Первая попавшаяся в гугле.

Да, видел. Наверно через нее и лучше. У нас еще NULL'ы могут быть. Их тоже переносить нужно, не останавливаясь. Перенесет?

Перенесет с точностью до байта. Куда ей деваться ;)

Было столько срачей на тему memcpy/memmove, где был ты?

/**
* memmove - Copy one area of memory to another
* @dest: Where to copy to
* @src: Where to copy from
* @count: The size of the area.
*
* Unlike memcpy(), memmove() copes with overlapping areas.
*/
void *memmove(void *dest, const void *src, size_t count)

> Действие происходит в ядре Linux. Куски памяти могут быть до 15 Мб.

Весьма вероятно, что вы что-то делаете не так. Какой сценарий?

Кстати, интересно, как будет вести себя memmove, если области перекрываются сильно (т.е. начальная область неперекрытия меньше размера блока).

Кстати, интересно, как будет вести себя memmove, если области перекрываются сильно (т.е. начальная область неперекрытия меньше размера блока).

Нормально будет себя вести. Все кривые случаи в ней предусмотрены. Это стандартная функция.

очень сильно плюую этого гражданина.

извините, я ем кофеты.

Ты еще и ман не читаешь :) Стандартная ф-ция memmove весьма медленная, т.к. используется третий участок памяти, и копирование for'ом будет быстрее :).

Вот. Значит, надо писать свою.

Может проще написать прототип 2х вариантов, скомпилить и посмотреть скорость на деле?

Ну если он это делает в ядре, то это не так уж и просто :)

Ты еще и ман не читаешь :) Стандартная ф-ция memmove весьма медленная, т.к. используется третий участок памяти, и копирование for'ом будет быстрее :).

4.2 и бан тебе, переводчик хренов.

void *memmove(void *dest, const void *src, size_t count)
{
    char *tmp;
    const char *s;

    if (dest <= src) {
        tmp = dest;
        s = src;
        while (count--)
            *tmp++ = *s++;
    } else {
        tmp = dest;
        tmp += count;
        s = src;
        s += count;
        while (count--)
            *--tmp = *--s;
    }
    return dest;
}

Код из ядра linux.

поясняю: в мане написано «as though»
Сырцы не смотрел, но уверен что там нет третьего участка. Ядро люди не глупей меня делают небось.

открыть сырцы libc и сделать так как тебе нужно.

Ты еще и ман не читаешь :) Стандартная ф-ция memmove весьма медленная, т.к. используется третий участок памяти, и копирование for'ом будет быстрее :).

Какой нах третий участок? Ты чем ударился?

Стандартная ф-ция memmove весьма медленная, т.к. используется третий участок памяти, и копирование for'ом будет быстрее

Слов нет. Кто ж нарожал-то вас таких, горе-оптимизаторов? Ты действительно уверен, что код ключевых библиотек написан хуже, чем ты, криворучка for-овая, за 5 минут на коленке нафигачишь?

Покажи, блин, где тут «третий участок памяти»:

http://www.mirrorservice.org/sites/ftp.gnu.org/gnu/glibc/glibc-2.14.1.tar.gz/...

А копировать куски памяти от конца к началу реально?

http://ompldr.org/vYnVwYg

http://ompldr.org/vYnVwYg

http://ompldr.org/vYnVwYg

http://ompldr.org/vYnVwYg

http://ompldr.org/vYnVwZQ

В выделенном тобой предложении ты не обратил внимания на словосочетание «as though», которое переводится, как «если бы, (как) будто бы, словно, как бы».

Если уж читать man-ы, то внимательно.

Я знаю что это за слово. Вот только смысл в том что копирование происходит в два этапа.

А для копирования памяти блоками наверняка ведь есть ассемблерные функции, которые будут явно шустрее побайтного копирования.

есть такие инструкции, rep movsb/rep movsd для копирования блоков, со времен, кажетсяб 486. Но т.к компиляторы ЯВУ таких инструкций не генерируют, а на ассемблере мало кто пишет, инженеры Intel дооптимизировались до того, что обычный mov в цикле, выдаваемый компиляторами, работает быстрее )

"...копирование происходит так, как будто бы (как если бы) байты в src сначала копируются в (некоторый) временный массив, который не пересекается ни с src, ни с dst, а затем те же байты копируются из этого временного массива в dst."

«as though» относится ко всей второй части предложения.

Упоминание «двух этапов» тоже воображаемое, как и «временный массив».

Посмотри уже на код, который тебе выше покакзали.

Эпичный фейл. Иди уже подучи английский и не позорься.

Я видел :)
Кстати в ядре это реализуется ассемблером а не вызовом из string.c

А ты ещё что за столб с высокогорья ?

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

Аватарок не вижу.
А ты чтоль обезьяна? Ну тогда мне не интересно с тобой, на этом, думаю, диалог окончен.

memmove во все поля, иначе натрахаетесь.

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

в моем так же. Но на самом деле так не происходит в умолчательном memmove :). Но есть еще архитектуро спецефические меммувы, которые писаны на асме, а я с асмом не дружу :)

Я вот думаю, а какой смысл вообще копировать через третий буфер? Есть ли этот смысл, если можно просто определить направление копирования, что гораздо быстрее и не требует выделения дополнительной памяти?