Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Однако и трудоёмкость обоих фрагментов одинакова - к... 10.03.05 22:57 Число просмотров: 2810
Автор: Heller <Heller> Статус: Elderman
|
> Я специально уточнил, что кодогенератор не меняет СМЫСЛ
> сгенерированного кода, а может поменять сам код. И сказал я
> это к тому, что
>
> > cmp [ptr], 0
> jne is_not_null
>
> или
>
> cmp [ptr], 0
> je is_null
>
---
>
Однако и трудоёмкость обоих фрагментов одинакова - к оптимизации это мало отношения имеет. Если только не приходится jump'иться на большие расстояния, но эта проблема опять же легко решаема без оптимизатора, ручками. А компилятор в свою очередь, насколько я знаю, именно физическим размещением функций в памяти никак не управляет - строит всё в той последовательности, как это было написано на Си. Хотя здесь я не уверен на 100%.
> не имеет разницы и в данном обсуждении совершенно
> несущественно. Мне совершенно по фигу, в КАКОЙ КОД это
> скомпилируется. Гораздо важнее ИСХОДНЫЙ КОД на C++. И я это
> уже подчеркнул. Разрушить твою программу может не
> кодогенератор, а комитет по стандартизации
>
> > для построения кода (хотя при сравнении float'а с
> нулём
> > компилятор и строит хрень какую-то - cmp или test были
> бы и
> > проще и эффективнее - но это я уже склонен списывать
> на
> > баги Майкрософта).
>
> А ты уверен, что включил опцию оптимизации? :-)
> Я неоднократно убеждался, что оптимизатору можно доверять.
Уверен ;-)
> Надо внимательнее читать (в части про бутылочные горлышки).
> Человеку по силам оптимизировать 10-100 строк кода так,
> чтобы они были эффективнее того, что даст компилятор. Но
> проект в 1000-100000 строк кода совершенно невозможно не то
> что написать на ассемблере эффективно, а невозможно ВООБЩЕ.
>
> > 115940 - уже было подобное обсуждение. Да и то что я
> привёл
> > с float'ом при сравнении с нулём опять же не тянет на
> "не
> > по силам человекам". Я бы такое сравнение писал проще
> и
> > лучше. Мелочь, но однако.
>
> Интересно посмотреть. Хотя не зря бутылочные горлышки
> расширяются именно при помощи ручной оптимизации на
> ассемблере. И не зря они имеют мизерные размеры. Я Вам
> скажу почему: оптимальное распределение ограниченного
> набора регистров - NP-полная задача номер раз, оптимальная
> кодогенерация - NP-полная задача номер два. NP полные
> задачи решаются за экспоненциальное время от из размера.
> КАЖДАЯ дополнительная строка умножает сложность на
> определенную константу (пусть это будет 2). Оптимально
> написать 10 строк в 2 раза легче, чем 11. Написать 20 строк
> в 1024 раз сложнее, чем 10. Человек не способен справиться
> с этой сложностью.
Видимо, мы разные обсуждения имеем ввиду. Про бутылочные горлышки не помню. Что касается 1000-100000 строк кода, то, как уже заметил Den, "обычно оптимизируются соседние 3 - 7 мнемоник" - здесь вся сложность исключительно в больших объёмах кода на АСМе против компактности и наглядности Си.
>
> > Почему оно так называется понятно. Но что касается Си,
> то
> > он уж через чур "статический". Хоть убейте, но я не
> понимаю
> > зачем вообще разделять указатели. Какая разница,
> указывает
>
> Ну дык пиши на бейсике. Или наоборот на ассемблере. А еще
> рекомендую почитать про корректирующие коды и зачем нужна
> избыточность информации. Тебя не смущает что ЛЮБОЙ русский
> текст сжимается примерно на 60%. Это значит, что полезную
> нагрузку несет только 40% русской речи. Советую задуматься,
> а на фига остальные 60% (в английском эта цифра вообще
> около 75%).
>
> > он на int, char или вообще на другой указатель? Только
> что
> > бы программист сам при программировании не запутался?
> > Как-то это сомнительно.
>
> Ага, сомнительно. А ты подумай, подумай на хрена в русском
> языке 60% мусора.
Здесь-то как раз таки всё просто. Для записи любого символа на русском языке достаточно 6 бит, однако используется обычно 8. Это уже значит, что четверть можно выкинуть. Так же в русском тексте принято отделять тире пробелами и вообще ставить пробелы после всеми знаками препинания - их можно со спокойной совестью вырезать, но читать уже будет не удобно. Плюс ко всему этому - избыточность текста сама по себе ("а" встречается гораздо чаще "ы", а после "c" гораздо чаще идёт "е", чем "ъ"). Только если убрать всю избыточность - прочитать такой текст (который получится практически случайным) будет невозможно в силу строения человеческих органов речи.
А избыточность английского текста, кстати говоря, меньше, чем избыточность русского. Если он ужимается сильнее, то это происходит только по причине того, что сам алвавит меньше, в то же время для записи символов используются те же 8 бит. И вот за счёт уменьшения избыточности, правила чтения английского текста гораздо сложнее правил чтения русского. Уменьшите избыточность ещё немного и читать такой текст будет вообще невозможно.
Что же касается языков, то вообще-то избыточность АСМа значительно выше, чем избыточность Си, но это не делает АСМ более "прозрачным". Имхо, для нормального чтения, понимания и написания кода вполне достаточно различных скобок, комментариев и возможности вставлять неограниченное (в разумных пределах :-)) количество пробелов/переходов на новую строку. Статическая типизация указателей уже лишняя.
>
> > Думаю, теперь все вопросы прояснились. NULL - нулевой
> Все вопросы прояснились еще раньше. Когда Ktirf дал ссылку
> на 18-й параграф СТАНДАРТА (ага того, который ISO/IEC
> 14882)
>
> > указатель. Тип, на что именно NULL указывает, не
> важен.
> > Просто указатель на ноль. Если для вас и Страуструп не
> > стандарт, то я уж и не знаю :-)
> Ты будешь удивлен, но страуструп - НЕ СТАНДАРТ, а всего
> лишь мануал :-)
Однако бОльшая часть людей изучает и программирует в последствии не по Стандарту, а именно по Страуструпу. К тому же, как показывает практика, ведущие разработчики ПО далеко не всегда к стандартам прислушиваются. Ну и как уже заметил Den, если стандарт и будет меняться, то обязательно с оглядкой на прошлые версии.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
