информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаПортрет посетителяГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft прикрывает Visual Studio... 
 Умер Кевин Митник 
 Массовое внедрение вредоносного... 
главная обзор 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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Золотые слова! 03.09.03 11:12  Число просмотров: 1241
Автор: 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). Да мало ли таких задач.
Светлая эра наступит, когда программисты наиболее оптимальные алгоритмы применять начнут! Это был крик души.
<programming> Поиск 






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


  Copyright © 2001-2023 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach