информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаSpanning Tree Protocol: недокументированное применениеЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Утекший код XP и Windows Server... 
 Дела виртуальные 
 Простое пробивание рабочего/провайдерского... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Однако и трудоёмкость обоих фрагментов одинакова - к... 10.03.05 22:57  Число просмотров: 2132
Автор: 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, если стандарт и будет меняться, то обязательно с оглядкой на прошлые версии.
<programming> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach