Сообщение Re[9]: Как вышло, что наложение предполагается по умолчанию? от 21.09.2021 10:08
Изменено 21.09.2021 11:33 Videoman
Re[9]: Как вышло, что наложение предполагается по умолчанию?
Здравствуйте, netch80, Вы писали:
N>Почему из-за одного IP заголовка? Таких структур десяток только у IETF и несколько сотен включая остальные вполне распространённые протоколы.
Я не спорю, что есть частные случаи, когда можно читать или менять данные сохраняя раскладку, но таких < 1%. Во всех остальных протоколах нужно, как минимум, собрать несколько пакетов, что бы получить из них целиковое полезное содержимое и что то там менять.
N>И гонять байты в памяти только ради финальной упаковки или начальной распаковки.
По скорости будет одинаково, т.к. по сравнению с памятью сеть это тормоз. Во всяком случае, это не медленнее чем каждый раз при работе с полем вызывать htol() + ltoh().
N>И такие есть. Ну на такое двигают указатели.
Только в каких-то уж очень частных случаях. В общем виде никакими указателями не отделаешься. Возьмем какой-нибудь mpeg — там просто меняешь значение поля и его длина в битах тут же меняется, да и еще где-нибудь в конце CRC нужно будет пересчитать.
N>И сколько таких случаев вы реально видели?
N>Даже на x86 прочесть другой порядок бит или байт банально. На каком-нибудь ARM ещё проще.
Видимо мне так не везет, но почти все протоколы мультимедиа так устроены: сжатие (переменная длина), поля в битах, СRC, всякие маски сверху и т.д.
N>Ну такие и читают/пишут по блоку, там время даже полного копирования в памяти заведомо меньше времени I/O.
Полностью согласен, но тогда и формат данных стараются подобрать удобным для этого, выровнять структуры на границы секторов и т.д.
N>Почему из-за одного IP заголовка? Таких структур десяток только у IETF и несколько сотен включая остальные вполне распространённые протоколы.
Я не спорю, что есть частные случаи, когда можно читать или менять данные сохраняя раскладку, но таких < 1%. Во всех остальных протоколах нужно, как минимум, собрать несколько пакетов, что бы получить из них целиковое полезное содержимое и что то там менять.
N>И гонять байты в памяти только ради финальной упаковки или начальной распаковки.
По скорости будет одинаково, т.к. по сравнению с памятью сеть это тормоз. Во всяком случае, это не медленнее чем каждый раз при работе с полем вызывать htol() + ltoh().
N>И такие есть. Ну на такое двигают указатели.
Только в каких-то уж очень частных случаях. В общем виде никакими указателями не отделаешься. Возьмем какой-нибудь mpeg — там просто меняешь значение поля и его длина в битах тут же меняется, да и еще где-нибудь в конце CRC нужно будет пересчитать.
N>И сколько таких случаев вы реально видели?
N>Даже на x86 прочесть другой порядок бит или байт банально. На каком-нибудь ARM ещё проще.
Видимо мне так не везет, но почти все протоколы мультимедиа так устроены: сжатие (переменная длина), поля в битах, СRC, всякие маски сверху и т.д.
N>Ну такие и читают/пишут по блоку, там время даже полного копирования в памяти заведомо меньше времени I/O.
Полностью согласен, но тогда и формат данных стараются подобрать удобным для этого, выровнять структуры на границы секторов и т.д.
Re[9]: Как вышло, что наложение предполагается по умолчанию?
Здравствуйте, netch80, Вы писали:
N>Почему из-за одного IP заголовка? Таких структур десяток только у IETF и несколько сотен включая остальные вполне распространённые протоколы.
Я не спорю, что есть частные случаи, когда можно читать или менять данные сохраняя раскладку, но таких < 1%. Во всех остальных протоколах нужно, как минимум, собрать несколько пакетов, что бы получить из них целиковое полезное содержимое и что-то там менять.
N>И гонять байты в памяти только ради финальной упаковки или начальной распаковки.
По скорости будет одинаково, т.к. по сравнению с памятью сеть это тормоз. Во всяком случае, это не медленнее чем каждый раз при работе с полем вызывать htol() + ltoh().
N>И такие есть. Ну на такое двигают указатели.
Только в каких-то уж очень частных случаях. В общем виде никакими указателями не отделаешься. Возьмем какой-нибудь mpeg — там просто меняешь значение поля и его длина в битах тут же меняется, да и еще где-нибудь в конце CRC нужно будет пересчитать.
N>И сколько таких случаев вы реально видели?
N>Даже на x86 прочесть другой порядок бит или байт банально. На каком-нибудь ARM ещё проще.
Видимо мне так не везет, но почти все протоколы мультимедиа так устроены: сжатие (переменная длина), поля в битах, СRC, всякие маски сверху и т.д.
N>Ну такие и читают/пишут по блоку, там время даже полного копирования в памяти заведомо меньше времени I/O.
Полностью согласен, но тогда и формат данных стараются подобрать удобным для этого, выровнять структуры на границы секторов и т.д.
N>Почему из-за одного IP заголовка? Таких структур десяток только у IETF и несколько сотен включая остальные вполне распространённые протоколы.
Я не спорю, что есть частные случаи, когда можно читать или менять данные сохраняя раскладку, но таких < 1%. Во всех остальных протоколах нужно, как минимум, собрать несколько пакетов, что бы получить из них целиковое полезное содержимое и что-то там менять.
N>И гонять байты в памяти только ради финальной упаковки или начальной распаковки.
По скорости будет одинаково, т.к. по сравнению с памятью сеть это тормоз. Во всяком случае, это не медленнее чем каждый раз при работе с полем вызывать htol() + ltoh().
N>И такие есть. Ну на такое двигают указатели.
Только в каких-то уж очень частных случаях. В общем виде никакими указателями не отделаешься. Возьмем какой-нибудь mpeg — там просто меняешь значение поля и его длина в битах тут же меняется, да и еще где-нибудь в конце CRC нужно будет пересчитать.
N>И сколько таких случаев вы реально видели?
N>Даже на x86 прочесть другой порядок бит или байт банально. На каком-нибудь ARM ещё проще.
Видимо мне так не везет, но почти все протоколы мультимедиа так устроены: сжатие (переменная длина), поля в битах, СRC, всякие маски сверху и т.д.
N>Ну такие и читают/пишут по блоку, там время даже полного копирования в памяти заведомо меньше времени I/O.
Полностью согласен, но тогда и формат данных стараются подобрать удобным для этого, выровнять структуры на границы секторов и т.д.