Муж (м) — программер, (я) — филолог.
М: Сходи за меня на работу, а?..
Я: Окей, дорогой, буду править ошибки в комментариях твоего кода))
М: Я не комментирую код. То, что писалось тяжело, должно и читаться тяжело.
Я: Лев Толстой, наверное, по такому же принципу работал...
>Я как раз к тому, что самая распространенная архитектура для десктопов как раз может работать без выравнивания — а это не малый кусок, чтобы его игнорировать.
Эта архитектура рекомендует выравнивание и не гарантирует доступ с выравниванием и без выравнивания с одинаковой скоростью.
>Что такое stdlib? Кто сказал про C++? Вроде и статья не о C++, и блог не о C++, да и разговор не о C++ — так причем тут C++?
О C++ никто не и говорил — там строки с длинной и к ним не применяются эти функции. В C#/Java/Python/вставьте_сюда_Ваш_любимый_язык — скорее всего, тоже.
Я говорил о C, на котором работают почти все эти языки и куча юзерспейсных программ.
Пожалуйста, перестаньте себе противоречить — сначала Вы требуете показать конкретный случай, который я считаю частоиспользуемым, а потом не принимаете его, так как он привязан к языку.
>По второму пункту — тоже самое, «намного реже» нужно аргументировать, а не просто показать что в одном из случаев копирования ошибок нет.
Код для копирования/прочих манипуляций со строками есть в stdlib. Можете поставить профайлер и посмотреть на Вашей системе, сколько времени он выполняется. Ещё можете найти мне хотя бы 5 примеров в распространенных проектах, где используется доступ к строкам блоками по 1000 байт.
>Ну во первых то что есть некоторые платформы с невозможностью так сделать — ни о чем не говорит.
Когда таких платформ — 99%, это о чём-то говорит.
>и поэтому он не прав, потому что частно в вашем случае проблем не будет. Только вот автор говорит на самом деле о гораздо более общей проблеме.
Где я говорил, что автор не прав? Я пытался показать, что это замечание может привести к указанным последствиям намного реже, чем может показаться.
С этим согласен.
Однако, скорее всего, производительность в случае разных смещений от границы выравнивания при «поинтовом» копировании будет даже ниже, чем при побайтовом копировании.
>Ну во первых никакое выравнивание меня не ограничивает
На ряде платформ оно ограничит Вас SIGBUSом, на других — снизившейся в 4 раза производительностью. *((int*)0) = 0 Вы тоже можете написать и язык Вас в этом не ограничивает, но так делать не нужно.
>вот написать процедуру, которая берет блоки по 1000 байт мне ничто не мешает
Я же написал — «на деле этого никогда не произойдёт», а не «не существует никаких возможностей написать код, который столкнётся с этой проблемой». Потому что работа с кусками по 1000 байт в данном контектсе не имеет смысла, а имеет смысл копирование кусками по 4/8 байт, чем все активно и пользуются.
А почему Вы будете обращаться к следующей странице, если Вы знаете, что на текущей странице строка уже закончилась?
В выборе начала отсчёта и кусков Вас как раз ограничивает выравнивание.
Копирование строки не будет обращаться к строке как к числам с первых байтов, а начнет делать это по выравниванию. Это и гарантирует непересечение границы страницы. Грубо говоря, код вместо
void strcpy(char* _dest, const char* _src) {
int *dest = _dest, src = _src;
while (!contains_null_byte(*src)) {
*dest++ = *src++;
}
*dest = 0;
/* обработка граничных случаев */
}
для платформы с выравниванием по 4 байтам имеет вид примерно
void strcpy(char* _dest, const char* _src) {
if (_dest & 3 != _src & 3) {
while (*_src) *_dest++ = *_src++;
*_dest = 0;
return;
}
while (_dest & 3 && *_dest) {
*_dest++ = *_src++;
}
int *dest = _dest, src = _src;
while (!contains_null_byte(*src)) {
*dest++ = *src++;
}
_dest = dest; _src = src;
while (*src) *_dest++ = *_src++;
*_dest = 0;
}
То есть, доступ к памяти всегда будет проходить по границе страницы, и будет определено, что строка либо заканчивается на текущей странице, либо продолжается на следующей.
При использовании NUL-завершенной строки, попытка работы с ней частями, превышающими один байт, может привести к обращению к символам за символом NUL. Если NUL символ является последним байтом страницы виртуальной памяти и следующая страница не определена, это может привести к крушению процесса с ошибкой «страница не найдена» [«page not present»].>
На деле этого никогда не произойдёт. Библиотека осуществляет доступ к строке как к многобайтовым целым не начиная с начала строки, а начиная с первого её байта, кратному размеру удобного для процесса целого (часто совпадающему по размеру с указателем). Это называется выравнивание, а при доступе к памяти без выравнивания на одних процессорах происходят тормоза, а на других — ошибки выполнения.
Границы и размер страниц тоже выровнены по этому размеру, из-за чего выход за пределы страницы в поисках NULL-байта не произойдёт, так как часть многобайтного целого числа никогда не будет проходить по границе страницы.
Ну PoE же прекрасно работает с устройствами, не поддерживающими его. Думаю, будет аналог его протокола, который позволит устройству управлять напряжением и силой тока, которое оно хочет получить.
По рассказам менеджеров, в x-point достаточно заполнить специальную анкетку, отнести ноутбук в СЦ, где с него сдерут наклейку, очистят диск, после чего можно будет вернуть деньги.
Смысл CentOS — в том, что есть ряд пакетов определенных версий (ядро-2.6.32, гцц-4.4), которые железно протестированы на взаимную работу друг с другом и со всей остальной системой. Гарантируется их правильная работа, несменяемость ABI (то есть, модуль ядра с драйвером для 2.6.32 из RHEL/CentOS6.0 всегда подойдёт к ядру 2.6.32 через 10 лет в каком-нибудь RHEL/CentOS6.9).
Вы же просто наплевали на этот смысл и сделали из системы помойку.
©bash.org.ru
Эта архитектура рекомендует выравнивание и не гарантирует доступ с выравниванием и без выравнивания с одинаковой скоростью.
>Что такое stdlib? Кто сказал про C++? Вроде и статья не о C++, и блог не о C++, да и разговор не о C++ — так причем тут C++?
О C++ никто не и говорил — там строки с длинной и к ним не применяются эти функции. В C#/Java/Python/вставьте_сюда_Ваш_любимый_язык — скорее всего, тоже.
Я говорил о C, на котором работают почти все эти языки и куча юзерспейсных программ.
Пожалуйста, перестаньте себе противоречить — сначала Вы требуете показать конкретный случай, который я считаю частоиспользуемым, а потом не принимаете его, так как он привязан к языку.
en.wikipedia.org/wiki/Data_structure_alignment#Architectures
Распространенность архитектур сами нагуглите?
>По второму пункту — тоже самое, «намного реже» нужно аргументировать, а не просто показать что в одном из случаев копирования ошибок нет.
Код для копирования/прочих манипуляций со строками есть в stdlib. Можете поставить профайлер и посмотреть на Вашей системе, сколько времени он выполняется. Ещё можете найти мне хотя бы 5 примеров в распространенных проектах, где используется доступ к строкам блоками по 1000 байт.
Когда таких платформ — 99%, это о чём-то говорит.
>и поэтому он не прав, потому что частно в вашем случае проблем не будет. Только вот автор говорит на самом деле о гораздо более общей проблеме.
Где я говорил, что автор не прав? Я пытался показать, что это замечание может привести к указанным последствиям намного реже, чем может показаться.
Однако, скорее всего, производительность в случае разных смещений от границы выравнивания при «поинтовом» копировании будет даже ниже, чем при побайтовом копировании.
На ряде платформ оно ограничит Вас SIGBUSом, на других — снизившейся в 4 раза производительностью. *((int*)0) = 0 Вы тоже можете написать и язык Вас в этом не ограничивает, но так делать не нужно.
>вот написать процедуру, которая берет блоки по 1000 байт мне ничто не мешает
Я же написал — «на деле этого никогда не произойдёт», а не «не существует никаких возможностей написать код, который столкнётся с этой проблемой». Потому что работа с кусками по 1000 байт в данном контектсе не имеет смысла, а имеет смысл копирование кусками по 4/8 байт, чем все активно и пользуются.
В выборе начала отсчёта и кусков Вас как раз ограничивает выравнивание.
для платформы с выравниванием по 4 байтам имеет вид примерно
На деле этого никогда не произойдёт. Библиотека осуществляет доступ к строке как к многобайтовым целым не начиная с начала строки, а начиная с первого её байта, кратному размеру удобного для процесса целого (часто совпадающему по размеру с указателем). Это называется выравнивание, а при доступе к памяти без выравнивания на одних процессорах происходят тормоза, а на других — ошибки выполнения.
Границы и размер страниц тоже выровнены по этому размеру, из-за чего выход за пределы страницы в поисках NULL-байта не произойдёт, так как часть многобайтного целого числа никогда не будет проходить по границе страницы.
Вы же просто наплевали на этот смысл и сделали из системы помойку.
Поддерживается с сентября 2010.