>>> простая
>> "I'd personally suggest that glibc just alias memcpy() to memmove()."
>> В glibc она не такая простая, насколько помню, там есть выбор от
>> размера копируемых данных. А если добавить проверку перекрытия в простой код:
>> на больших объёмах не играет роли; на малых memcpy() не эффективна.
> Не могу с Вами, как и с Линусом, согласиться. На малых и
> известных на этапе компиляции объёмах, при соответствующем уровне оптимизации, gcc может
> заменить memcpy() на свой код, который копирует как memcpy() (разворачивается в
> последовательность команд mov). По крайней мере я такое точно наблюдал в
> своих проектах.Тоже наблюдал такое и очень давно. Именно это и имел ввиду, когда писал что сама функция не эффективна (это и обуславливает инлайн mov). В таком случае замена не должна играть роли, поскольку аналогичная оптимизация происходит и с memmove(), и с ручным (в смысле, в цикле) копированием.
> На больших объёмах - да, лишние потери будут меньше,
> но всё-равно будут. А если это какой-нибудь там Intel Atom с
> тактовой частотой 400MHz? Не везде можно, и оправдано, ставить самый распоследний
> 32-х ядерный, или какой там сейчас самый топовый, Intel Xeon с
> сотнями гигабайт памяти ОЗУ.
Пенальти на неверно предсказанный переход, навскидку, тактов 10-20, а вот скорость копирования упирается в ширину пропускания шины памяти, которая поуже чем у кеша, то есть процессор часть времени в любом случае как бы простаивает. Ну и если проверок несколько, значит и пенальти при неверном предсказании потенциально и так есть.
С моей точки зрения такое объединение нежелательно по другой причине: поощряет пофигизм при написании кода и нарушает переносимость на другие ОС и libc.