Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
эффективный код 02.09.03 21:41 [amirul, Ktirf]
Автор: vaborg <Israel Vaborg> Статус: Elderman
|
Граждане посоветуйте пжлста книжки статьи и пр.
про эффективный код, стиль программирования, структурирование программ и пр.
Приходится писать программы где критична их работа,
требуется скорость выполнения максимально, работа с памятью оптимально. и тд...
|
|
Вряд ли тут скажут чего нить нового - предлагаю закрыть 03.09.03 21:17
Автор: amirul <Serge> Статус: The Elderman
|
|
|
| |
Нет смысла обсуждать прописные истины, по крайней мере с этим пора завязывать. 04.09.03 10:25
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
|
|
| | |
спасибо 04.09.03 11:38
Автор: vaborg <Israel Vaborg> Статус: Elderman
|
|
Несколько коряво выразился и сколько эмоций :))
|
|
А еще в плане технических аспектов очень интересно посмотреть 03.09.03 16:42
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 03.09.03 16:43 Количество правок: 1
|
|
на исходный код операционных систем навроде Linux и FreeBSD. Огромное количество интересного узнаешь. В свое время по исходному коду ядра Linux (тогда еще 2.2) даже была издана книга "Ядро Linux в комментариях", автора не помню, увы.
|
|
еще книги, которая могут пригодиться 03.09.03 16:36
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
Но это, правда, уже хардкор %-)
Джефф Элджер "Язык программирования C++" - про управление памятью. Большей частью фантазерство, но некоторые полезные идеи почерпнуть можно.
Герб Саттер "Решение сложных задач на C++" - обо всем понемножку. Но это ОЧЕНЬ сложная книга (в плане кода). Кстати говоря, в ней товарищ об оптимизации говорит следующее:
1) не оптимизируйте.
2) см. пункт 1.
Он там расшифровывает, почему. Все не так тупо, конечно. И я с ним согласен: оптимизацией программы надо заниматься только вместе с профайлером (VTune рулит).
|
|
эффективный код 02.09.03 21:55
Автор: Tlo Статус: Незарегистрированный пользователь
|
> Приходится писать программы где критична их работа...
Да-а... И часто приходиться писать именно ТАКИЕ программы? ;))))
Мне очень понравилась [http://oz.by/books/more104648.html] и [http://oz.by/books/more105039.html] - Роберт Седжвик "Фундаментальные алгоритмы на C++" - она одна из редких книг подобного рода, где язык используется только как средство, а не как цель.
В e-бучных коллекциях такого в принципе можно найти... хотя там обычно валяется дежурный Кнут - считается очень хорошим источником для сабжа, но я лично его стиль повествования терпеть не могу :) и знаю, что не только я один.
Только вот выскажу одно мнение. Скорость прямо пропорциональна эффективности алгоритма, не зависит от стиля программирования и обратно пропорциональна структурированности программы :)
|
| |
Золотые слова! 03.09.03 11:12
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Только вот выскажу одно мнение. Скорость прямо
> пропорциональна эффективности алгоритма, не зависит от
> стиля программирования и обратно пропорциональна
> структурированности программы :)
>Граждане посоветуйте пжлста книжки статьи и пр.
>про эффективный код,
Эффективность кода в первую очередь зависит от алгоритма, а во вторую от компилятора, который генерит уже конечный код. Так что книжки про эффективные алгоритмы искать надо.
>стиль программирования,
А эта штука у каждого своя, как почерк. Но существуют общие положения, которые обязывают, чтобы программа (если она написана стильно) хорошо читалась. Эти положения найти не сложно теми же поисковиками.
Вот некоторые из них:
1) Не пишите все слитно - отделяйте лексические элементы пробелами.
2) Коментируйте, но не злоупотребляйте "глубокомысленными" коментариями.
3) Не создавайте сложные конструкции - очень длиные операторы/строки, очень длиные функции.
4) Давайте переменным и функциям понятные имена.
5) Старайтесь обходиться без условных и безусловных переходов.
>структурирование программ и пр.
6) См. п. 3. Разбивайте сложные процедуры на более простые, руководствуясь их логическим предназначениям.
Научиться красиво писать программы также тяжело, как и писать красивые стихи, прозу, музыку...
>Приходится писать программы где критична их работа,
>требуется скорость выполнения максимально, работа с памятью >оптимально. и тд...
А вот это меня обычно сильно поражает. Так же поражает, как и желание купить супер современный компьютер, чтобы операционная система работала быстрее. ОС не должна потреблять ресурсов вообще! Она отвечает за запуск/завершение программ, распределение памяти и процессорного времени, обработку прерываний, ввод/вывод - работу с файловой системой, устройствами ввода/вывода и т. п.
Многие сейчас покупают супер пупер компьютеры, потому что программы медленно работают. Это меня убивает не меньше. Господа! Десяток - другой лет назад, у нас, в совке, химические и ядерные реакции обсчитывались на компьютерах с производительностью милион операций в секунду. Можность современных машин на три-четыре десятичных порядка больше (в тысячу и десяток тысяч раз). А что сейчас обсчитываем бухгалтерию - сотня хозяйственных операций в день (раньше на счетах считали) или текстовый редактор тормозит (текстовый процессор - сейчас так эти программы называют) - нажал на кнопочку и ждешь несколько секунд, пока он символ на экран выведет!
С памятью та же фигня, примеры приводить не буду. Тем, кому за 30, сами все помнят.
Что-то не так в это мире. Оверклокеры выжимают десятки процентов вычислительной мощности - для чего, это что, сама цель, или так критично чтобы программа (если у них такая есть) вместо 12 часов 10 часов считала, или вместо 12 милисекунд - 10 милисекунд, а 12 не устраивает. Через пару месяцев за те же деньги можно будет купить процессор именно на этот десяток - другой процентов быстрее.
Важно не полениться и пяток минут подумать над алгоритмом - это может сделать программу более быстоработающей - раз так в десять.
Помнится, обратился ко мне кто-то, написать програмку (курсовик) просчета распределения простых чисел. Ну накатал я первый вариант. Простые числа тупым перебором генерил (проверял остаток при делении на все предидущие). Интервала (тысяча) не хватило - заинтересовало как график дальше себя поведет. Десяток тысяч программа почти час считала. За пять минут подкрутил алгоритм (стал проверять на простые) - время счета в десять раз сократилось. Еще пять минут посидел (стал проверять не до N, а до квадратного корня из N) - еще в десять раз быстрее (меньше минуты). Зашел колега, посмотрел програмку, поправил (решето Эратосфена закатал) - еще раз в сто быстрее считать стала (засечь тяжело - меньше секунды). Итого в десяток тысяч раз за счет хорошего алгоритма.
Еще одна задачка была - просчитать кольчество вариантов расстановки восьми ферзей на шахматной доске, чтобы они не "били" друг друга. Реализовывать полный перебор - лучше не браться 64 в восьмой степени или 281474976710656 комбинаций и их все еще проверить надо (еще умножить на 64). Сначала (полчасика подумав) реализация работала полчаса. После улучшений добились пять минут. Потом достали неизвестно кем написанную программу, которая считала и выводила на экран все 92 комбинации за доли секунды под интерпритатором. Как она это делает - понять не удалось. Помню использовались там два массивчика по 15 элементов.
А посчитать количество "счастливых" билетиков в катушке (от 000000 до 999999). Да мало ли таких задач.
Светлая эра наступит, когда программисты наиболее оптимальные алгоритмы применять начнут! Это был крик души.
|
| | |
А-а! :,,,,-O 03.09.03 15:26
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> > Только вот выскажу одно мнение. Скорость прямо
> > пропорциональна эффективности алгоритма, не зависит от
> > стиля программирования и обратно пропорциональна
> > структурированности программы :)
Ну тут я так однозначно не могу сказать про структурированность... Совсем недавно мне был продемонстрирован примерчик, на котором шаблоны C++ оказываются быстрее указателей на функции C... В общем, нет уверенности.
> Эффективность кода в первую очередь зависит от алгоритма, а
> во вторую от компилятора, который генерит уже конечный код.
> Так что книжки про эффективные алгоритмы искать надо.
Я тоже рекомендую Седжвика, кстати. И Кнута. И тоже его не люблю :)
> 5) Старайтесь обходиться без условных и безусловных
> переходов.
Кстати, безусловные переходы иногда помогают оптимизировать программу. ИНОГДА, говорю :) Потому что как ни крути, а структурированность программы все же иногда (иногда!) мешает.
> Научиться красиво писать программы также тяжело, как и
> писать красивые стихи, прозу, музыку...
Но красивая программа (не алгоритм) нередко оказывается менее производительной.
> Многие сейчас покупают супер пупер компьютеры, потому что
> программы медленно работают. Это меня убивает не меньше.
> С памятью та же фигня, примеры приводить не буду. Тем, кому
> за 30, сами все помнят.
Тут достаточно быть за 20, кажется, чтобы такое помнить... %-)
> Что-то не так в этом мире. Оверклокеры выжимают десятки
> процентов вычислительной мощности - для чего, это что, сама
> цель, или так критично чтобы программа (если у них такая
> есть) вместо 12 часов 10 часов считала, или вместо 12
> милисекунд - 10 милисекунд, а 12 не устраивает. Через пару
> месяцев за те же деньги можно будет купить процессор именно
> на этот десяток - другой процентов быстрее.
Но всем-то охота сейчас...
Гонка вооружений.
> Светлая эра наступит, когда программисты наиболее
> оптимальные алгоритмы применять начнут! Это был крик души.
Я вторым голосом подвою %-)
|
| | | |
А-а! :,,,,-O 03.09.03 16:05
Автор: amirul <Serge> Статус: The Elderman
|
> Ну тут я так однозначно не могу сказать про
> структурированность... Совсем недавно мне был
> продемонстрирован примерчик, на котором шаблоны C++
> оказываются быстрее указателей на функции C... В общем, нет
> уверенности.
Ага, темплейтную функцию можно сделать inline-овой, кроме отстутствия оверхеда на вызов, компилер еще может и соптимизировать данный конкретный вызов, в том контексте куда вставлена функция. Раньше меня пугало то, что будет инстанцироваться сильно много шаблонов и это невероятно раздует код. Теперь я этого не боюсь :-)
> > 5) Старайтесь обходиться без условных и безусловных
> > переходов.
> Кстати, безусловные переходы иногда помогают оптимизировать
> программу. ИНОГДА, говорю :) Потому что как ни крути, а
> структурированность программы все же иногда (иногда!)
> мешает.
У самого Кнута, который ратовал за структурное программирование есть статья что то типа "Места, где использование goto приемлимо". Это вопрос вкуса, но можно пользоваться следующим правилом:
1) Переходить ТОЛЬКО вперед
2) Никогда не ВХОДИТЬ внутрь блока (выходить можно :-) )
Эти правила в частности разрешают использовать goto для выхода из вложенных циклов (использование флага и проверка на каждой итерации не кажется мне слишком изящной). В perl-е для этого вообще введена отдельная конструкция (метки циклов и break по метке). Кроме того лично я использую goto для обработки ошибок (вложенные if-ы тоже не кажутся мне слишком читаемыми), а метка fail: только добавляет читаемости и выносит обработку ошибок отдельно от основного потока исполнения. В том же C++ для этих целей есть exception-ы.
> > Научиться красиво писать программы также тяжело, как и
> > писать красивые стихи, прозу, музыку...
> Но красивая программа (не алгоритм) нередко оказывается
> менее производительной.
А мне кажется красота во всех проявлениях это отражение целесообразности. Именно поэтому можно рассуждать как о красоте человека (целесообразность оценивается подсознательно) так и о красоте программы, технического решения, математической конструкции и т.д.
А целесообразное решение как раз и означает эффективное.
> > С памятью та же фигня, примеры приводить не буду. Тем,
> кому
> > за 30, сами все помнят.
> Тут достаточно быть за 20, кажется, чтобы такое помнить...
> %-)
Гы. Эт точно :-) Мне нет 30-ти, но я это помню
> > месяцев за те же деньги можно будет купить процессор
> именно
> > на этот десяток - другой процентов быстрее.
> Но всем-то охота сейчас...
>
> Гонка вооружений.
> > Светлая эра наступит, когда программисты наиболее
> > оптимальные алгоритмы применять начнут! Это был крик
> души.
> Я вторым голосом подвою %-)
Уже не вторым, тут несколько подвываний уже замечено :-)
А интенсивное развитие начнется, когда уже ничего нельзя будет выжать экстенсивно. А сейчас это просто невыгодно. Зачем оптимизировать сейчас, если через год это все равно устареет и придется писать заново, а чересчур оптимизированные части по моим наблюдениями не очень часто болеют возможностью повторного использования в изменившихся условиях.
|
| | | | |
Задело за живое?... 03.09.03 17:13
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 03.09.03 17:25 Количество правок: 4
|
> Ага, темплейтную функцию можно сделать inline-овой, кроме
> отстутствия оверхеда на вызов, компилер еще может и
> соптимизировать данный конкретный вызов, в том контексте
> куда вставлена функция. Раньше меня пугало то, что будет
> инстанцироваться сильно много шаблонов и это невероятно
> раздует код. Теперь я этого не боюсь :-)
Инлайновая функция может как раздуть код (как правило, когда тело большое), так его и сократить (когда тело меньше вызова функции). Но уж ускорение произойдет однозначно из-за отсутствия вызова (и передачи аргументов). Текст программы это не портит. Но ускорение может быть мало, по сравнению с оптимизацией алгоритма. Есть еще одна беда - встречаются компиляторы, которые просто игнорируют слово "inline" или не переваривают локальные переменные, циклы, ассемблерные вставки и т.д.
> Эти правила в частности разрешают использовать goto для
> выхода из вложенных циклов (использование флага и проверка
> на каждой итерации не кажется мне слишком изящной). В
> perl-е для этого вообще введена отдельная конструкция
> (метки циклов и break по метке). Кроме того лично я
> использую goto для обработки ошибок (вложенные if-ы тоже не
> кажутся мне слишком читаемыми), а метка fail: только
> добавляет читаемости и выносит обработку ошибок отдельно от
> основного потока исполнения. В том же C++ для этих целей
> есть exception-ы.
Пишу очень мало (хобби такое, а не работа), но давно. Не припомню, чтобы "goto" где-то воспользовался. Сначала тяжело было (после бэйсика с фортраном №4), потом привык, сейчас забыл и оператор такой ("пошел на...").
> А мне кажется красота во всех проявлениях это отражение
> целесообразности. Именно поэтому можно рассуждать как о
> красоте человека (целесообразность оценивается
> подсознательно) так и о красоте программы, технического
> решения, математической конструкции и т.д.
Не факт, что красота сильно помешает эффективности. Важно, чтобы кто-нибудь или сам в этой программе потом разобраться смог и поправить что-нибудь. Или ошибки исправить не наляпав новых. Если, спустя год, Вас просят изменить вами написанную программу, а Вы уже через час говорите, что проще заново написать, значит старая написана плохо. А не часто ли Вам приходится плеваться, работая с некрасиво написанной программой, ругаться, сразу возникает желание руки оторвать тем программистам, когда Вы натыкаясь на ляпы, сразу понимаете, что программист-криворучка там наваял второпях? Ну, конечно не следует забывть и о пользователе, интерфейс и все такое...
> Гы. Эт точно :-) Мне нет 30-ти, но я это помню
Ну да, и двадцати достаточно - конец эры БК, ДВК, Поиск, Спектрум, Атари.... начало эры 1ВМ/РС-ХТ.
> Уже не вторым, тут несколько подвываний уже замечено :-)
> А интенсивное развитие начнется, когда уже ничего нельзя
> будет выжать экстенсивно. А сейчас это просто невыгодно.
> Зачем оптимизировать сейчас, если через год это все равно
> устареет и придется писать заново, а чересчур
> оптимизированные части по моим наблюдениями не очень часто
> болеют возможностью повторного использования в изменившихся
> условиях.
"Жаль, только жить в эту пору прекрасную, уж не придется ни мне, ни тебе". (Некрасов)
Пока закон Мура выполняется, и в ближайшие десятки лет будет выполнятся тоже (ученые-разработчики обещают).
Конечно не следует неделю оптимизировать алгоритм, и добиться счета программы один час, как и не следует писать час, если программа потом неделю считать будет. Важно время (а время - деньги, З.П. программиста + оборотная прибыль). Оптимально будет день писать, день считать. Т. е. совокупное время счета до устаревания программы должно быть адекватно человекочасам, потраченным на написание программы. Если программа будет эксплуатироваться год по пять минут чистого счета в день - потратьте часок другой, если есть возможность добиться одной секунды счета в день вместо пяти минут. Да еще предлагать обновить год назад купленный компьютер, поскольку он морально устарел и слаб для таких задач, хотя грамотно написанная (в которой применен оптимальный алгоритм) та же программа будет и на 286 летать. Разве не так?
|
| | | | | |
Ага 03.09.03 18:59
Автор: amirul <Serge> Статус: The Elderman
|
> Инлайновая функция может как раздуть код (как правило,
> когда тело большое), так его и сократить (когда тело меньше
> вызова функции). Но уж ускорение произойдет однозначно
> из-за отсутствия вызова (и передачи аргументов). Текст
> программы это не портит. Но ускорение может быть мало, по
Его надо использовать с умом (как в общем и любой инструмент, никто не спорит, что дрелью можно и убиться - засверлиться :-), но это проблемы не с дрелью, а с руками). У страуструпа есть пример хорошего использования инлайн-функции: получение символа из потока. Так как в обобщенном потоке любой буфер тянется посимвольно, то использование для той же цели виртуальной функции или даже не инлайнового темплейта заметно скажется на производительности самого потока.
> сравнению с оптимизацией алгоритма. Есть еще одна беда -
Это да. Но когда алгоритм уже вылизан, начинаются другие методы.
> Пишу очень мало (хобби такое, а не работа), но давно. Не
> припомню, чтобы "goto" где-то воспользовался. Сначала
> тяжело было (после бэйсика с фортраном №4), потом привык,
> сейчас забыл и оператор такой ("пошел на...").
Я сначала тоже умных книжек начитался и усилием воли заставил себя от него отказаться, но потом пришло понимание, что дело не в самом goto, а в способах его использования. Например, ходить на красный свет через дорогу нельзя. Если следовать этому правилу очень маловероятно (но вероятно), что тебя собьет машина. Но я видел мужиков, которые ждали зеленого на СОВЕРШЕННО пустой, прямой и просматривающейся на несколько километров в обе стороны дороге.
> > А мне кажется красота во всех проявлениях это
> отражение
> > целесообразности. Именно поэтому можно рассуждать как
> о
> > красоте человека (целесообразность оценивается
> > подсознательно) так и о красоте программы,
> технического
> > решения, математической конструкции и т.д.
>
> Не факт, что красота сильно помешает эффективности. Важно,
А я сказал как раз обратное. Что красивое решение как раз и является эффективным.
> чтобы кто-нибудь или сам в этой программе потом разобраться
> смог и поправить что-нибудь. Или ошибки исправить не
> наляпав новых. Если, спустя год, Вас просят изменить вами
> написанную программу, а Вы уже через час говорите, что
> проще заново написать, значит старая написана плохо. А не
> часто ли Вам приходится плеваться, работая с некрасиво
> написанной программой, ругаться, сразу возникает желание
> руки оторвать тем программистам, когда Вы натыкаясь на
Ага. Бывает :-)
> ляпы, сразу понимаете, что программист-криворучка там
> наваял второпях? Ну, конечно не следует забывть и о
> пользователе, интерфейс и все такое...
> "Жаль, только жить в эту пору прекрасную, уж не придется ни
> мне, ни тебе". (Некрасов)
Почему же. Я например уже жил. Платформа "Синклер" практически не развивалась и начались извращения, типа стек в видеопамяти потому как стековые операции - самый быстрый способ доступа к памяти (на пару тактов на каждые 2 байта).
> Пока закон Мура выполняется, и в ближайшие десятки лет
> будет выполнятся тоже (ученые-разработчики обещают).
> Конечно не следует неделю оптимизировать алгоритм, и
> добиться счета программы один час, как и не следует писать
> час, если программа потом неделю считать будет. Важно время
> (а время - деньги, З.П. программиста + оборотная прибыль).
> Оптимально будет день писать, день считать. Т. е.
> совокупное время счета до устаревания программы должно быть
> адекватно человекочасам, потраченным на написание
> программы. Если программа будет эксплуатироваться год по
> пять минут чистого счета в день - потратьте часок другой,
> если есть возможность добиться одной секунды счета в день
> вместо пяти минут. Да еще предлагать обновить год назад
> купленный компьютер, поскольку он морально устарел и слаб
> для таких задач, хотя грамотно написанная (в которой
> применен оптимальный алгоритм) та же программа будет и на
> 286 летать. Разве не так?
Ага
|
| | | | | | |
Ага 04.09.03 10:05
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 04.09.03 10:08 Количество правок: 1
|
> Я сначала тоже умных книжек начитался и усилием воли
> заставил себя от него отказаться, но потом пришло
> понимание, что дело не в самом goto, а в способах его
> использования. Например, ходить на красный свет через
> дорогу нельзя. Если следовать этому правилу очень
> маловероятно (но вероятно), что тебя собьет машина. Но я
> видел мужиков, которые ждали зеленого на СОВЕРШЕННО пустой,
> прямой и просматривающейся на несколько километров в обе
> стороны дороге.
После того, как я стал водить машину, я стал осторожней переходить дорогу.
Есть и объективные понятия удобства, но есть и привычка. Нужно объективно оценить преимущества новых методов, и, если они будут удобнее, то смириться с неудобствами на время переучивания.
> Почему же. Я например уже жил. Платформа "Синклер"
> практически не развивалась и начались извращения, типа стек
> в видеопамяти потому как стековые операции - самый быстрый
> способ доступа к памяти (на пару тактов на каждые 2 байта).
Если научно-технический прогресс, вдруг, тормознул, то жди скачка/прорыва в технологиях.
Я когда-то думал, что стэк после вызова функций лучше читстить посредством вытаскивания значения в неиспользуемый регистр. Быстрее должно работать, нежели добавлять константу, поскольку АЛУ не задействуется и длина команды меньше - нет операндов, вида адресации, компактно, меньше кода (в байтах) в конвеер тянется. Ошибался. Оказывается дергание памяти медленнее, чем сложение, да и операнд в конвеере никому не мешает. Это я не про синклер.
|
| | | | |
А-а! :,,,,-O 03.09.03 16:30
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> ...лично я использую goto для обработки ошибок (вложенные if-ы тоже не
> кажутся мне слишком читаемыми), а метка fail: только
> добавляет читаемости и выносит обработку ошибок отдельно от
> основного потока исполнения. В том же C++ для этих целей
> есть exception-ы.
Есть, но они существенно медленнее. Из-за попытки решать слишком общую задачу, кстати :) - try проверяет "все на свете" и переходит неизвестно куда, а условный goto - конкретное условие и переходит в точное место. Хотя по хорошему, компиляторы C++ когда-нибудь должны дойти до того, чтобы реализовывать exceptions как один максимально адресный условный переход.
Кстати, вот для чего я бы купил суперкомпьютер - это для того, чтобы компилировать программы с вложенными шаблонами... :(
> А интенсивное развитие начнется, когда уже ничего нельзя
> будет выжать экстенсивно. А сейчас это просто невыгодно.
> Зачем оптимизировать сейчас, если через год это все равно
> устареет и придется писать заново, а чересчур
> оптимизированные части по моим наблюдениями не очень часто
> болеют возможностью повторного использования в изменившихся
> условиях.
Ой, что-то мало я видел даже неоптимизированный код, больной возможностью повторного использования... Как только речь отходит от всяких all-purpose библиотек вроде MFC - сразу такой кошмар начинается, что с реюзом, что с оптимизированностью...
|
| | | | | |
А-а! :,,,,-O 03.09.03 18:43
Автор: amirul <Serge> Статус: The Elderman
|
> > есть exception-ы.
> Есть, но они существенно медленнее. Из-за попытки решать
В частности потому их и рекомендуют использовать только какисключительныеситуации. Вот у меня при нормальном ходе исполнения ни один из этих goto не выполняется. Точно так же условный throw ни приведет ни к каким оверхедам, пока не возникнет что то непредвиденное.
> слишком общую задачу, кстати :) - try проверяет "все на
> свете" и переходит неизвестно куда, а условный goto -
> конкретное условие и переходит в точное место. Хотя по
> хорошему, компиляторы C++ когда-нибудь должны дойти до
> того, чтобы реализовывать exceptions как один максимально
> адресный условный переход.
Хорошо бы. Типа SEH а-ля микрософт, но в стандарте C++.
> Кстати, вот для чего я бы купил суперкомпьютер - это для
> того, чтобы компилировать программы с вложенными
> шаблонами... :(
:-)
> > болеют возможностью повторного использования в
> изменившихся
> > условиях.
> Ой, что-то мало я видел даже неоптимизированный код,
> больной возможностью повторного использования... Как только
> речь отходит от всяких all-purpose библиотек вроде MFC -
Собственно имеется в виду не столько all-purpose и даже не portability (что действительно является кошмаром :-) ), а именно реюз. В частности болезнь многих программистов (и моя в том числе :-) ) решать любую задачу в наиболее общем виде, а потом просто настраивать получившуюся систему. То бишь ядро по-любому предполагается использовать более одного раза. А такого кода даже у меня навалом, не то что в мире. :-)
Хороший пример: микроядерность. На основе одного микроядра можно написать практически любую архитектуру ОС. А например на основе подсистем NT можно написать поддержку API практически любой платформы. Вот это я и называю реюзабилити. А конфликт с оптимизацией появляется потому, что универсальный инструмент не может быть оптимальным ни для одного из выполняемых действий. Точно так же инструмент заточенный под конкретное применение с очень большим трудом можно применить где-либо кроме того применения под которое собственно он и заточен.
> сразу такой кошмар начинается, что с реюзом, что с
> оптимизированностью...
|
| | | | | | |
Ok, превратим эту тему в маленький сателлит fido7.su.c-cpp :) 03.09.03 19:08
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> > > есть exception-ы.
> > Есть, но они существенно медленнее. Из-за попытки
> решать
> В частности потому их и рекомендуют использовать только как
>исключительныеситуации. Вот у меня при нормальном ходе
> исполнения ни один из этих goto не выполняется. Точно так
> же условный throw ни приведет ни к каким оверхедам, пока не
> возникнет что то непредвиденное.
К сожалению, оверхед и по размеру, и по скорости возникает даже просто при -fexceptions (как это на Visual C++, не знаю). И любой try тоже добавляет от себя :(
> > Кстати, вот для чего я бы купил суперкомпьютер - это
> для
> > того, чтобы компилировать программы с вложенными
> > шаблонами... :(
> :-)
Не вижу ничего веселого.
> В частности болезнь многих программистов (и
> моя в том числе :-) ) решать любую задачу в наиболее общем
> виде, а потом просто настраивать получившуюся систему.
Меня жизнь интенсивно отучает решать слишком общие задачи :) Просто становится ясно, что в сроки не уложусь %-)
> Хороший пример: микроядерность. На основе одного микроядра
> можно написать практически любую архитектуру ОС. А например
> на основе подсистем NT можно написать поддержку API
> практически любой платформы.
Боюсь, что попытка реализовать полный POSIX-layer на базе подсистем NT приведет к не слишком производительному API...
> А конфликт с оптимизацией появляется потому,
> что универсальный инструмент не может быть оптимальным ни
> для одного из выполняемых действий.
Возражаю! Пример - STL.
>Точно так же инструмент
> заточенный под конкретное применение с очень большим трудом
> можно применить где-либо кроме того применения под которое
> собственно он и заточен.
А вот это справедливо.
|
| | |
Согласен 03.09.03 11:41
Автор: amirul <Serge> Статус: The Elderman
|
Сабж. В смысле со всем, что тут было сказано до меня.
> Научиться красиво писать программы также тяжело, как и
> писать красивые стихи, прозу, музыку...
А вот этот пример я всегда привожу, когда надо объяснить человеку, чем я занимаюсь. Русский язык у нас знают все. Выучить любой язык из, например, индоевропейской семьи романской группы при условии знания парочки - дело нескольких недель. Но. Писать хорошую прозу даже на родном русском может не каждый.
> Светлая эра наступит, когда программисты наиболее
> оптимальные алгоритмы применять начнут! Это был крик души.
У меня свой пример. В бытность программирования на спектруме, я именно так и программировал. Так вот один алгоритм, который и так уже был довольно оптимальным, я за счет извращений ускорил в 10 раз.
А насчет того же PC. Есть два пути развития (вернее не развития, а роста): интенсивный и экстенсивный. Сейчас используется экстенсивный путь развития, т.к. невыгодно чересчур оптимизировать программу под какую либо платформу, если уже через пару лет она станет морально устаревшей. Когда моральное старение замедлится и обновление парка машин будет производится раз хотя бы лет в 10, придется перейти на интенсивный путь. И это неизбежно произойдет, когда технологии производиства вплотную подойдут к своему физическому пределу.
|
| | | |
Родная душа: Ты тоже на Спектруме прогал? 8-) 03.09.03 12:14
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| | | | |
Ага. И был весьма крут :-) 03.09.03 13:16
Автор: amirul <Serge> Статус: The Elderman
|
Хотя ни одного паблик релиза у меня не было.
Я уже почти написал движок для журнала, причем с импользованием пропорционального шрифта (моноширинные, особенно 4x8 меня к тому времени уже достали :-) ), который выводил полную страницу за 3 прерывания (или типа того), в общем быстрее, чем в некоторых моноширинных журналах. Причем выравнивал текст не за счет добавления пробелов, а за счет их вытягивания (то есть пробелы и отступы имели произвольную ширину в пикселах) и т.д. Также к этому журналу был написан граф интерфейс с иконками, стрелками и прочая. Но к тому времени спектрум уже бился в агонии и я перешел на амигу :-)
|
| | | | | |
Я русификатор делал (правда, не доделал - меня Робик обогнал) 03.09.03 15:07
Автор: Zef <Alloo Zef> Статус: Elderman
|
Собственную схему разработал, сверхдешовую: ИР12, ИР1, ИР13, РТ4, РТ5.
А последний мой программно-аппаратный изыск в 93-м репрограммируемый картридж к Спектруму, типа Денди. С собственной адаптацией программ, РОМ и схем для всех наличных модификаций.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
