Re[8]: Ломать ли совместимость в недокументированной области
От: Sshur Россия http://shurygin-sergey.livejournal.com
Дата: 17.11.10 11:54
Оценка: +1
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, Sshur, Вы писали:


S>>Не понял. По вашему, надо каждый системный вызов обертывать и параноидально проверять на возможность некорректного использования?


M>Скорее речь идет об отладочной версии glibc, где предусмотреть создание лога предупреждений.


Я понял Донца, что пользователи сами должны делать себе такие версии glibc и прочего. А это ИМХО перебор
Шурыгин Сергей

"Не следует преумножать сущности сверх необходимости" (с) Оккам
Re: Ломать ли совместимость в недокументированной области?
От: minorlogic Украина  
Дата: 20.11.10 08:40
Оценка:
Я не понмаю проблемы .

Пофиксили поведение функции только в новых версиях системы , зачем же ее ставить прямо сразу. Пройдет определенное время и пофиксят совместимости . Вот и все. Я чего то не понимаю ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[10]: Ломать ли совместимость в недокументированной област
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.12.10 14:54
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Я замечу, что memcpy на ассемблере — это (без учета инициализации регистров) одна инструкция.

DOO>Так что накладные расходы на рантайм проверку совершенно неприемлемы.
К сожалению, уже лет 10 как попытка сделать "memcpy на ассемблере" в одну инструкцию породит больше накладных расходов, чем в несколько. Все приличные компиляторы выполняют развёртку цикла, и она работает быстрее, чем rep movsd.
Крайне не рекомендую учить матчасть в 2010 году по книге "ассемблер 386 для профессионалов".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Ломать ли совместимость в недокументированной области
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.12.10 14:55
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Нет, там будет одна инструкция ассемблера по копированию блока памяти.

Нет. Там будет довольно много инструкций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Ломать ли совместимость в недокументированной области
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.12.10 14:57
Оценка:
Здравствуйте, March_rabbit, Вы писали:
V>>Нет, там будет одна инструкция ассемблера по копированию блока памяти.
M_>ну да. примерно такой цикл она и будет выполнять, только со счетом от значения ECX до 0. Если со времен 386 процессора не появилось принципиально новых команд в основной линейке. Я со времен универа ассемблером не осень занимаюсь.
Дело не в новых командах, а в новой архитектуре. И во времена твоего универа rep movs* была ничуть не быстрее по тактам, чем ручное написание цикла. А сейчас развёртывание цикла позволяет существенно сэкономить. Современные компиляторы практически никогда не используют префикс rep.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Ломать ли совместимость в недокументированной области?
От: shasa  
Дата: 11.01.11 06:01
Оценка:
Здравствуйте, Michael7, Вы писали:

M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков...


Я считаю что в данном случае виноваты разработчики API, в частности реализовавшие memcpy, правильно работающей и с перекрывающимися блоками, т.к. это расходится с документацией, но вызов требует больших затрат времени ЦПУ чем простое копирование, т.к. требует дополнительных проверок. Следовательно, если это свойство широко используется, значит его нужно сохранить. А подобное поведение разработчиков glibc похоже вызвано тем что они чувствуют себя пупом земли. Думаю если это продолжится, или всплывут другие такиеже случаи, то glibc будет иметь альтернативные сборки.
Re[8]: Ломать ли совместимость в недокументированной области
От: Sharowarsheg  
Дата: 11.01.11 06:18
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

G>>>>А вот разработчики glibc положили йух на такую совместимость.

MC>>>Если у них есть такая возможность — за них можно только порадоваться.
G>>Да в том то и дело что у них нет, а они думают что есть.
MC>Она у них есть. Из всех программ сломался только флеш плеер. Ну и хуавей с ним.

И после этого кто-то агитирует за линукс на десктопе в реальной жизни. В следующий раз сломают гуй и скажут, "ну и гуй с ним".
Re[2]: Ломать ли совместимость в недокументированной области
От: Michael7 Россия  
Дата: 20.01.11 21:26
Оценка:
Здравствуйте, shasa, Вы писали:

S>Я считаю что в данном случае виноваты разработчики API, в частности реализовавшие memcpy, правильно работающей и с перекрывающимися блоками, т.к. это расходится с документацией, но вызов требует больших затрат времени ЦПУ чем простое копирование, т.к. требует дополнительных проверок.


Дополнительных проверок как раз не было, они просто тупо mov-или, продвигаясь сверху вниз по адресам. А потом им пришло в голову использовать векторные инструкции процессора для ускорения.

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

S> Следовательно, если это свойство широко используется, значит его нужно сохранить.


Вот это и есть камень преткновения: стоит или нет. Как видно, имеются доводы и за и против. С одной стороны, такое поведение де-факто похоже с самых первых версий линукса, с другой стороны — все-таки никто не обещал правильного поведения во всех случаях.

S> А подобное поведение разработчиков glibc похоже вызвано тем что они чувствуют себя пупом земли. Думаю если это продолжится, или всплывут другие такиеже случаи, то glibc будет иметь альтернативные сборки.


А и так уже были или есть.
Re[2]: Ломать ли совместимость в недокументированной области
От: WinterMute Россия http://yarrr.ru
Дата: 31.03.11 12:27
Оценка:
IT>Разработчики glibc не виноватые, они просто козлы. Всё что надо было сделать, чтобы избежать конфликта — это написать новую версию memcpy — memcpy2 или лучше fastmemcpy, и в своей либе перейти на неё, если им нужно.

Или realmemcpy(), и, по необходимости, добавить absolutely_real_memcpy_read_documentation_before_use().
В крайнем случае понадобится добавить absolutely_real_memcpy_read_documentation_TWICE_before_use() и почти наверняка не будет проблем.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.