Об эффективности программ в избранное  новое    подписка   модер.  /!\
От: Pavel Dvorkin 
Дата: 05.10.05 10:35
Оценка:590 (85) +13 -3 :)
Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно. Ну
что же — к счастью, я уже не в том возрасте, когда падение или рост рейтинга
могут серьезно повлиять на самочувствие.

Итак...

Когда компьютеры были большими, память у них была маленькой и
быстродействие тоже. И поэтому гуру от этих ЭВМ ничего, кроме ассемблера
(автокода, по-тогдашнему) и не признавали. А на нас, всяких там алгольщиков или
фортранщиков, смотрели свысока — писать , мол, эффективные программы не умеют,
только зря машинное время расходуют. Мы, конечно, с ними на словах не
соглашались и всякие аргументы приводили, но в глубине души их правоту, пожалуй,
признавали.
И действительно, как было не признать! Пока программа небольшая и в память
помещается — ладно, живите и радуйтесь! Ну а как побольше стала ? Тут-то и
придется признать свое бессилие. А гуру, им что, всегда что-нибудь придумают.
Кто-нибудь из нынешнего поколения слышал про "самоубийство программ" ? Нет, это
не стирание EXE-файла во время его работы. Это когда программа во время своей
работы использует память, занятую своими командами (которые уже отработали и
больше не потребуются) под свои данные. Вряд ли кому-нибудь придется этим сейчас
заниматься, и слава богу. А вот когда у Вас всего 18 Кбайт, то и таким не
пренебрегали.
Потом компьютеры стали больше. И в размерах (один мой знакомый, рост у
него 1.80, любит рассказывать, как он в процессор некоторой машины входил не
наклоняясь , но все же и память с быстродействием тоже росли. Вспоминаю
сейчас ЕС-1022. Памяти там было уже 512 Кбайт, правда, сотню из них занимала ОС.
Остальные 400 делились между 3-4 одновременно работавшими программами разных
пользователей. Так что на тех, кто заказывал больше 200 Кбайт, на ВЦ смотрели
довольно косо — за наш счет ведь! И правильно смотрели — нечего тут жировать!
Компилятор с Фортрана на 96 КБайтах работал, c PL/1 — даже на 64 Кбайтах (до сих
пор не знаю, почему — PL/1 сложнее Фортрана), линкеру тоже 96 Кбайт хватало, а
тебе так 200 надо ? Иди-ка, батенька, да перепиши свою программу как следует. До
сих пор помню, как потратил несколько часов, пытаясь написать вычисление
произведения трех матриц без промежуточной матрицы (было это на заре моей
карьеры, а я ведь химик .И студента своего, который без надобности
транспонировал матрицу, заведя еще одну, так отругал, что он долго это помнил :-
)
В общем, если говорить серьезнее, эффективность у нас была всегда на
первом плане. Не как-нибудь написать, а наиболее эффективным способом,
не любой алгоритм использовать, а лучший для этого случая. На этом мы
прочно стояли.
Поймите меня правильно. Это вовсе не значит, что мы оптимизировали
все и вся. Код, который работает 0.1 сек и занимает 100 байт, никто
не оптимизировал. И то, что оптимизировать нужно самые внутренние
циклы, мы прекрасно знали. Не об этом речь. А о том, что при написании
программ была определенная культура, требовавшая памятью не сорить
без надобности, первый попавшийся алгоритм не применять, а искать хороший,
ну и т.д.
Потом компьютеры стали меньше. И по размерам, и по быстродействию и
памяти тоже. Не потому, что большие исчезли, а потому, что малые
появились. Их так и называли — мини-ЭВМ. СМ-4, к примеру. Памяти у нее
было поменьше, быстродействие похуже, чем у той же ЕС-1022, зато у нее
было неоспоримое преимущество — она была моя! Никакого тебе ВЦ с десятком
конкурентов, никаких "Правил работы на ВЦ ... института", правила такие,
какие я хочу. Все это не могло не радовать, но все же уменьшение
памяти и быстродействия огорчало и тем более заставляло бороться
за эффективность. Первая моя серьезная работа на СМ-4 — адаптировать к
ней программу, которая на ЕС занимала 220 Кбайт, а здесь их всего 256.
Когда я понял, как ее в свободные 200 уложить — выяснилось, что понял
я неправильно, и для кода я могу рассчитывать только на 64 Кбайта, а
остальную память только под данные можно использовать. Вот тут-то я
и покрутился. Вы никогда не делали оверлейные структуры 9-го уровня ?
Даже не знаете, что это такое ? Ну и прекрасно, и не надо вам знать
Потом машины стали совсем маленькими, а быстродействие и память
уменьшились до неприличия. Проще говоря, пересел я на Ямаху-1. Память 64 Кбайта,
частота 2MHz, флоппи-диск — живи и радуйся! В общем, 8-битная машина. И вот на
этой машине я увидел чудо.
Чудо называлось Turbo Pascal 1.0. Сказать, что он меня поразил — не то
слово. И не меня только. Все, кто до этого Ямаху не видел (а их в Омск
очень немного попало тогда) и кому я о нем говорил, отвечали мне одинаково-
такого не может быть!
В 64 Кбайтах размещались
MSX-DOS, точнее , ее резидентная часть — несколько Кбайт
сам компилятор Turbo Pascal. Сидел резидентно в памяти.
редактор текста Turbo Pascal, вполне приличный по тому времени.
исходный текст программы, набранный в этом редакторе.
рабочая программа (машинные команды). Да-да, я не оговорился.В обычном
режиме компиляции программа размещалась в ОП и на диск не записывалась. И
не думайте, что это какой-то паршивый интерпретатор был, нет, самый
настоящий компилятор. Чуть позже (я уже в университете работал) был
у нас класс "Ямаха-2", память там была уже 128 Кбайт, а дисков на рабочих
станциях не было. Так вот. половину из этих 128 Кбайт мы отводили
под электронный диск, туда в начале занятия записывали Turbo Pascal,
а в конце с него переписывали на машину преподавателя .pas файлы студента.
Остановимся на минуту и вдумаемся. Итак, все это помещалось в 64 Кбайта.
Можно было, значит, написать это так, чтобы помещалось. Если, конечно,
эффективно написать. И работало это с вполне по тем временам приличной
скоростью. Не хуже, чем на СМ-4, кстати сказать. Даже лучше.
А потом компьютеры, хоть и не меньше и не больше по размерам стали, начали
резко увеличивать свою память и быстродействие. Сейчас любят вспоминать
пророчество Б.Гейтса — дескать, 256 Кбайт всем хватит. Ну, во-первых,
не думаю, что они имел в виду, что это навсегда. Во-вторых, никто,
в т.ч. Гейтс, в то время не понимал, что на свет явился не расширенный
калькулятор для научных лабораторий, а нечто такое, что перевернет
мир. А 256 Кбайт по тем временам — очень даже много. Настолько много,
что для большинства тогдашних задач это даже и не требовалось. Впрочем,
довольно скоро от этих 256 к 640 перебрались, на этом значении, правда,
надолго застряли.
Вот тут первые шаги в сторону пренебрежения оптимальностью уже и начались.
Действительно, на машине 600 Кбайт свободно, машина однопрограммная,
конкурентов нет, зачем мне пытаться программу в 100 Кбайт уложить ,если можно
все 500 спокойно использовать. Впрочем, память памятью, а есть еще и
быстродействие. Оно было еще очень маленьким, так что хотя бы в этом
плане писать все же приходилось эффективно, выжимать из машины все, что можно.
Так что писать старались все же эффективно, хотя десятком, а то и сотней
лишних Кбайт уже не мелочились.
Что было дальше — все знают. Память и быстродействие росли, эффективность
падала так же быстро, как те росли. Выяснилось, что и 1 Мбайта мало для
программы, предыдущая версия которой вполне 256 К было достаточно, да что там
1Мбайта, и 2 мало, и 16 мало, подайте 32, нет, 32 тоже мало, без 64 не
обойдемся.
Вот вам 2 классических примера.
Конечно, Object Pascal не Turbo Pascal, а Delphi 7 не Turbo Pascal 1.0.
Но, положа руку на сердце — неужели язык в 1000 раз усложнился ? Ну в 5-10
раз сложнее стал, не спорю (я имею в виду в плане написания собственно
компилятора, а не IDE, отладчика и т.д.). А раз так, то для компиляции
консольных приложений компилятор командной строки-то уж должен в 640 Кбайт
уложиться ? Дудки вам, а не 640 Кбайт. В 640 Кбайт сейчас умеют только "Hello,
World" укладывать! Пока несколько десятков Мбайт не будет, и не подходите.
Другой пример — сама Windows. Я прекрасно понимаю, что Windows NT 4 и
Windows XP — не совсем одно и то же. Но та на 8 Мбайтах работала, а эта от
128 нос воротит, подавай ей 256. А ядро, вообще говоря, претерпело не такие
уж большие изменения.
Почему же так произошло? На мой взгляд, просто потому, что требованию
эффективности просто перестали уделять нужное внимание. Если памяти много —
чего ее жалеть, зачем экономить? Какой смысл бороться за то, чтобы твоя
программа занимала 8 Мбайт, если можно взять 64 ? Даже, пожалуй, наоборот-
увидят, что твоя программа меньше памяти занимает, чем у конкурента — ну
и решат, что та более крутая
Разумеется, эффективности внимание перестали уделять не везде. Для тех
программ, которые и сейчас работают на пределе возможностей машины, за
эффективность по-прежнему борются, да еще как, иначе ведь работать вообще
не будет. Ну а там, где для предела далеко — чего это мы будем лишний
десяток Мбайт экономить ? Пусть пользователь память докупит, она нынче
дешевая!
Вспоминаю один случай из своей практики. Вел я тогда кружок в средней
школе,хорошие ребята попались, большинство из них потом наш матфак закончили. В
DOS на Turbo Pascal, лет 10 назад это было. И вот дал я одниу мальчику
упражнение, сделал он его, показал мне, посмотрел я , похвалил и добавил :"А
теперь, Илья, выкинь отсюда этот массив. Он здесь совсем не нужен, и без него
даже лучше получится". До сих пор помню тот взгляд, которым он меня одарил
Если кто-то думает, что моей целью было 200 байт сэкономить — ничего Вы
из моих рассуждений не поняли. Моей целью было научить его грамотно писать
программы, делать как следует, а не так, как получится. Не реализовать первую
пришедшую в голову идею, а подумать, нельзя ли здесь лучше сделать! Потому что
если я сейчас это пропущу — он и дальше будет так же делать, тройные циклы
писать там, где двойных хватит и лишние массивы без надобности заводить.
Меня тут некоторые уже обвиняли в "наездах" на C# и .Net. Вообще-то
я такое понятие "наезд" — не признаю. Если к любимой системе программирования,
компилятору и т.д. подходить с позиций "В России нет еще пока команды лучше
Спартака" — тогда, конечно, всякая критика левого крайнего Спартака есть явный
наезд . Если же подходить к этому вопросу объективно, скажем, с позиций
человека, который вообще ни за одну команду не болеет или болеет за Реал-Мадрид,
то сравнение левого крайнего Спартака и левого крайнего ЦСКА есть дело вполне
разумное, и если вывод будет не в пользу спартаковца — ничего страшного тут нет,
что же поделаешь... Другого левого крайнего искать надо, а может, стоит из
ЦСКА его переманить .
Так что в том. что примеры я буду приводить именно из области .Net — не
есть наезд на нее. Просто ИМХО она наиболее ярким образом характеризует то, о
чем я пишу.
Вот простой пример. Ставя свои эксперименты, обнаружил я , что в
библиотеке .Net не имеется способа получить список файлов каталога без того,
чтобы не прочитать его полностью.

http://www.rsdn.ru/Forum/Message.aspx?mid=1398903&only=1
Автор: Pavel Dvorkin
Дата: 23.09.05


Чтобы не было неясностей — класс DirectoryInfo как он есть, не позволяет.
То, что можно самому написать, с использованием InterOp — я это и до
постинга вполне понимал.
Мне это показалось странным, и я решил вопрос в форуме задать. В общем,
объяснили мне то, что я и так знал, и подтвердили , что без InterOp это
не делается, а с ним — великолепно.

Поясню, в чем проблема здесь. С помощью Win32 функций можно записи
о файлах по одной получать. Времени на чтение всего каталога это
никак не уменьшит, это вообще не от моей программы, а от драйвера
ФС зависит, а вот памяти мне в Win32 почти совсем не надо — одна
структура WIN32_FIND_DATA на все файлы, хоть 100 их будет, хоть
миллион. А класс DirectoryInfo предлагает считать весь каталог
в оперативную память (массив FileInfo), а потом уж из него брать.

Проверил я этот DirectoryInfo на имеющемся у меня каталоге в
100,000 файлов. Работало это все 1 минуту (неудивительно, и Win32 программа
не меньше бы потребовала, FAR, к примеру, именно столько и требует)
и заняло по Task Manager 57 Мбайт.

Ну ладно, я не вчера родился, и как это на Win32 делается — еще лет 10
назад знал Так что такое решение, приведись мне это в реальной программе
писать, меня вряд ли бы устроило, и что-нибудь бы придумал или вопрос бы задал.
А как же будут делать те, кто школу более или менее эффективного (в этом
плане, только в этом плане!) программирования в Win32 не прошел, а сразу за .Net
взялся ?
Вот ведь что мне Sinclair советует

http://www.rsdn.ru/Forum/Message.aspx?mid=1404835&only=1
Автор: Sinclair
Дата: 27.09.05


Цитирую

> То, что ты умеешь делать на плюсах, в рамках дотнета ты делать не сможешь.

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

Не обо мне сейчас речь. Но вот те, кто начнет именно с нуля, вполне
могут принять как принцип то, что если нужно что-то такого рода получить —
получайте всю коллекцию, и не мучайтесь, потом в ней разберетесь и нужное
найдете. Стиль мышления такой прививается, понимаете? Как вполне нормальный.
Да и не скрывают это адепты. Вот, например,

http://www.rsdn.ru/Forum/Message.aspx?mid=1403668&only=1
Автор: VladD2
Дата: 27.09.05


>А производительность и не должна быть на первом месте. Она должна быть

достаточной. А на первом месте должны быть удобство и простота.

Я не против удобства и простоты. Я за. А вот что такое "достаточной" —
извольте объяснить. Если машина однопрограммная — тогда, конечно, достаточно —
если помещается в память и достаточно быстро работает. А в многопрограммной
коммунальной квартире стоит еще и о других подумать. Потому как память хоть и
большая, но не резиновая. И процессор пока что только один, как правило.

Или вот другой пример — с умножением матриц

http://www.rsdn.ru/Forum/Message.aspx?mid=1410674&only=1
Автор: Pavel Dvorkin
Дата: 30.09.05


Я не касаюсь сейчас вопроса, можно ли это было оптимизировать. В дискуссии на
эту тему

http://www.rsdn.ru/Forum/Message.aspx?mid=1408480&only=1
Автор: Pavel Dvorkin
Дата: 29.09.05


был предложен не один способ это сделать, да я и сам предложил с самого начала
свой — как ни плохо .Net я знаю, а все же догадаться несложно было. Мой вопрос в
другом — кто именно этот вариант алгоритма так реализовал, что он вместо
чего-то похожего на n^3 показывает временную зависимость, напоминающую утренние
прыжки моего кота, когда он есть просит ? . Чтобы с увеличением размера
матрицы на 100 время уменьшалось, а при увеличении еще на 200 — увеличивалось в
10 раз —
такого в моей практике еще не было! Не знаю, кто тут виноват, не знаю, кто
эту исполняющую систему писал, но об эффективности здесь говорить не приходится.

Другой пример на эту же тему. Клонирование объектов (deep copy). Рихтер
для этого советует простой способ — сериализовать в memory stream, а потом
десериализовать. Просто ? Да. Изящно ? Да. Только при этом как-то забывают,
что вместо одной операции копирования мы здесь имеем две, и вместо двух
наборов байт (source и destination) имеем три — source, intermediate и
destination.
Правда, Рихтер тут же отмечает, что эта операция может оказаться слишком
дорогой,да и не всегда возможной. Рихтер, безусловно, понимает, когда ее можно
применять, а когда не стоит. Понимают ли это все разработчики под .Net ? Боюсь,
что нет. Так что будут они этот способ использовать, не слишком задумываясь,
скорее всего. Сериализуют двумерную матрицу размером в несколько Мбайт, и все
дела

Кстати, и о самой сериализации. Нет слов — реализовано в .Net красиво. Помечаешь
атрибутом, и все! Только вот не стоит забывать, что бесплатный сэр бывает только
в мышеловках. Конечно, приятно, что за тебя все сделают — reflection, чтение
значений, запись, проход по все ссылкам и опять reflection, чтение значений,
запись. А между тем грамотно написанный код в той же MFC, использующий
сериализацию, сделает в принципе то же самое без того, чтобы изучать
структуру класса(ов) и тратить на это время и память.


В в результате такого отношения — "что нам десяток Мбайт жалеть, что
нам с того, что это здесь на 100 мсек дольше выполняться будет", получается то,
о чем хорошо сказал Cyberax

http://www.rsdn.ru/Forum/Message.aspx?mid=1409923&only=1
Автор: Cyberax
Дата: 29.09.05


>Чего-то я начинаю в этой истине сомневаться. Слишком часто все "не

тормозит" (или не жрет памяти) в отдельности, но работает со скоростью
улитки (или жрет гигибайты) в целом.

>Причем наблюдается это, в основном, у современного софта — та же ICQ без

зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20
метров. Вот так и не остается памяти для чего-нибудь полезного....

Хороший, кстати, пример — ICQ. Написана она не на .Net ИМХО (давно
ее не держу, у меня Trillian, ему 7.5 Мбайт хватает . По существу — текстовый редактор плюс модуль связи с winsock. Все остальные возможности его используются
один раз в неделю, если не в месяц. Я ничего против них не имею, но
сидели бы они на диске в виде DLL и раз в неделю загружались! Так нет,
20 Мб вынь да положь! Интересно, под что?
Если бы ICQ был в DOS времена (кстати, был?), то быть бы ему
там TSR размером в 30-40 Кбайт максимум, и писать в нем свои SMS можно было
бы так же, или почти так же, как сейчас, разве что в текстовом
режиме. Да, ладно, бог с ней. с DOS. Сколько места занимали первые
версии ICQ (жаль, не сохранил я тот клиент, с которым начинал лет
8 назад), и сколько сейчас? Памяти много, чего ее жалеть!

Мне тут VladD2 упрек такой кинул — дескать, писать надо , не
слишком думая об эффективности, а потом узкие места можно оптимизировать.
Теоретически — совершенно безупречное рассуждение. А практически — это
верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
бы — что тут оптимизировать? Так и должно быть, все нормально сделали!

В результате получаем некую самодвижущуюся повозку размером с аэроплан,
ставим на нее ракетный двигатель, запускаем — едет! Едет ведь! Со скоростью
60 км/час. Ну вот это и есть настоящий аэроплан, в серию его и пусть
по дорогам ездит. А когда этим разработчикам объясняешь, что аэроплан
должен не ездить, а летать, и не 60, а 900 км/ч давать, а если Вы автомобиль
делали, то он и при двигателе внутреннего сгорания должен эти 60 (а то и 120)
давать, да и размерами должен быть раз в 20 меньше — удивляются, чего, мол,
привязался! Ездят же на нем, чего тебе надо!

А теперь перехожу к главному, что меня беспокоит.

Создается впечатление, что рост быстродействия процессоров несколько
замедлился. Может быть, я не прав, но мне кажется, что мы подошли к некоторому
пределу, и если не последует технологического прорыва, то скорость сильно расти
не будет. Еще раз — может быть, я не прав. Кстати, о памяти пока в этом плане
говорить не приходится.

Но так или иначе — этот предел есть. Очень уж четкие физические
законы здесь действуют, их не обойдешь. Раньше или позже, но бурный рост
мощности ПК заменится если не стагнацией, то более или менее плавным изменением,
на проценты, а не в разы.

И вот тогда этот неэффективный стиль программирования даст себя знать!
Сейчас можно просто рассуждать — чего я буду 20 Мбайт экономить, если
пользователь без проблем 256 может докупить ? А вот когда опять в жестких
лимитах работать придется — окажется, что некоторые программы, которые вполне
могли бы быть написаны, написаны не будут, или же будут написаны лет через 10
после того момента, когда они могли бы появиться! Потому что эффективно
работать большинство не умеет. Привычки у них такие — что нам стоит лишних
десяток Мбайт взять!

Не согласны ? OK, кто из вас взялся бы написать "Turbo Pascal 1.0"
образца 2005 года? Который будет работать в такой маленькой памяти — 512 Мбайт
и на таком медленном процессоре с частотой всего 3 GHz ? Боюсь, что Вы
потребуете для этого 16 Gb памяти и не менее 30 GHz . Вы же прекрасно знаете,
какие ресурсы для чего требуются, поэтому оцените их для этой задачи и получите
16 Gb и 30 GHz, А где их взять? Впрочем, нет, не потребуете. Вы даже задачу
такую не поставите — Вам она и в голову не придет: Боюсь, что мы даже и не
узнаем, что могло бы быть написанным, если бы это эффективно делалось...

Ну и к чему автор призывает, спросите Вы ? К поголовному возврату на
ассемблер
и к 64 Кбайтам ? К отказу от того пути, по которому сейчас пошло развитие ?

Я не настолько наивен, чтобы к этому призывать. Просто одно скажу :

Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
это возможно!
With best regards
Pavel Dvorkin
Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 05.10.05 11:54
Оценка:75 (10) +2 -1 :))) :))) :))) :))) :))) :))) :))) :))) :))) :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!

Архивредный совет дал нам уважаемый тов.Павел Дворкин!
Несвоевременный!
Какой же несвоевременный совет!

Наоборот, пусть неэффективность плодится и размножается, путь цветет и пахнет. Пусть сотни тысячи индусов копипастят миллионы строчек на managed языках. Пусть фреймворки становятся все толще и прожорливее. Путь рядовой пользователь меняет свой ПК не каждые два года, а каждые полгода. А корпоративные заказчики удваивают мощности своих серверов и класстеров после каждого выпущенного нами сервис-пака. Пусть XML процветает в телекоммуникационных протоколах -- долой всякие ASN1 и прочие двоичные упаковки, экономящие каждый бит. Давайте загадим все интернет каналы под завязку. Пусть это происходит все быстре и быстрее.

Пусть наши заказчики побыстрее увидят, что не выгодно покупать неэффективный (большой, неповоротливый) софт. Так же, как неэффективно ездить по городу на машине, сжигающей 30 литров на 100 киллометров. Так же, как неэффективно использовать 100W лампочку накаливания там, где достаточно использовать 20W галогеновую. Сделаем же так, чтобы рост вычислительной мощности ЭВМ не успевал за прожорливостью нового ПО. Пусть часть работы программиста окажется дешевле часа работы написанной им программы. Раза эдак в три, или в четыре.

Вот тогда наступит наше время.

А пока, не своевременный совет вы даете, уважаемый тов.Павел Дворкин. Эдак вы наши планы раньше времени раскрываете. Демаскируете вы нас, однако.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: McSeem2http://www.antigrain.com
Дата: 06.10.05 02:28
Оценка:295 (25) +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Минусов мне за эти тезисы поставят, это уж точно.


Что-то не видать.
Щас будет филосовское эссэ... Блииннн...

[...skipped...]

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!

Этот вопрос не такой очевидный как кажется. Начать с того, что такое "программа для компьютера"? Какой-нибудь хитрый алгоритм кластеризации в многомерном пространстве — это программа. ICQ — это тоже программа. Но между ними существует фундаментальное различие, которое довольно трудно сформулировать четко и однозначно. Но безусловно то, что это это совершенно разные категории программ. Для пояснения задействуем очень сильное колдунство — О-нотацию. ICQ занимает, скажем 30 мег. Но это все равно O(1) памяти! И до тех пор, пока эта программа работает на 99.99% ширпотребовских компьютеров, нам глубоко пофигу, сколько конкретно пямяти она занимает — это все равно O(1), просто в силу того, что нет такого параметра, от которого бы измерялось это "О". Количество записей в контакт-листе? — нет, это копейки, которые можно вообще не считать (впрочем, это тоже не так-то просто, но об этом — делее).
Другое дело — некий алгоритм кластеризации (это я говорю чисто абстрактно, алгоритм может называться как угодно, скажем, "структурной оптимизации параметрического синтеза"). Он может требовать O(N^2) памяти. Например, для 10 точек — 100 байт памяти, для тысячи точек — уже 10 мег, а для миллиона точек не хватит и всей памяти всех компьютеров на земле.
К чему эти все абстрактные рассуждения? А вот к чему.
Всем людям хочется легких и больших денег. А большие деньги можно сделать только на чем-то очень массовом. А массовое это что? — программа ICQ, например. Или MS Office, whatever. И все эти программы (ну не все, но 99%) относятся к классу сложности O(1) по памяти. Теоретически, это мое утверждение конечно же ложно, но практически — это так. Это раньше было не так, например, когда текстовый редактор требовал O(N) оперативной памяти, а ее всего было 32K, то это был плохой редактор. Файл размером в 100K в нем было принципиально невозможно отредактировать. Требовался редактор класса O(1) оперативной памяти, который динамически работал с дисковой памятью. Как сейчас помню — KED, он же K52, адаптированный под систему команд терминала VT52, который подключался по RS232 на скорости 9600. То есть, реальный канал был менее килобайта в секунду — и это между компьютером и монитором!
После преодоления порога в 640K произошла фундаментальная метаморфоза: тот же текстовый редактор из класса O(N) превратился в класс O(1)! Это опять же, спорное утверждение, но на практике это так. Допустим, у нас есть редактор класса O(N), требующий 1 байт памяти на символ. В 32K памяти можно отредактировать 32K символов. В 640K — 640K символов. А сколько можно отредактировать в одном гигабайте памяти? А самое главное — кому это надо? Лично я не видел ни одного человека, которому бы понадобилось редактировать гиговый текстовый файл. Есть чисто человеческое ограничение — больше мега текста в 99.99% случаев редактировать не требуется. А что такое один мег при объеме памяти в гиг? Именно по причине этого человеческого фактора и появилась принципиальная возможность не заморачиваться такими вещами, как "ручной" динамический своп. Дальше больше — когда сам текстовый редактор с пустым окном занимает 30 мег, а при загрузке 100K текста — 31 мег, мы можем смело считать его редактором класса O(1) — нам никогда не понадобится редактировать такой текстовый файл, который бы существенно увеличил объем занимаемой памяти. А редакторы, ранее бывшие в классе O(1) стали просто не нужны, поскольку работают медленнее. Конечно же я утрирую, но лишь для пояснения идеи — стало можно писать сколько угодно кода, который гарантированно влезает в память. И при условии эффективного хранения данных основная масса программ не требует какой-либо экономии.

Но не тут-то было — сон разума рождает чудовищ. Эта "свобода" породила монстра — неэффективные структуры данных. Взять, например, тот же IE или Firefox. При открытиии ветки на РСДН в 1000 сообщений они отъедают около 10 мег памяти. Десять килобайт на заголовок сообщения! Да сами сообщения в разы меньше! И программы снова превратились в класс O(N). Теоретически. На практике, в 99% случаев можно считать, что они остаются O(1), просто потому, что в большинстве случаев нам не требуется просматривать 1000 сообщений (а если и требуется, то это — исключение). И вот здесь-то и кроется главная причина неэффективности — для получения прибыли достаточно обеспечить работоспособность в 99% случаев, а те, которые требуют большего — они перебьются. Они погоды не делают.

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

И вот здесь мы подходим к главному вопросу — а в чем заключается это "удовольствие от жизни"? Вся индустрия mainstream-софта построена по принципу "американской мечты" — вот мы сейчас зафигачим, продадим, нарубим зеленой капусты, а потом будем всю жизнь "курить бамбук". Безусловно, кому-то это удается, точно так же, как есть шанс получить большие деньги в МЛМ-лохотроне. Другое отношение — это просто "поддерживать жизнедеятельность", то есть, работать на дядю за небольшую, но гарантированную зарплату (ничего не имею против этого — сам такой). Но лично мне и то и другое просто скучно. Мне гораздо интереснее думать — вот это для меня и есть по большому счету удовольствие. Конечно же, я тоже люблю деньги и тоже люблю кататься на доске по снегу с гор и тоже учавствую в этом лохотроне. И мой профессиональный рейтинг повышается, поскольку я стремлюсь к этому повышению. Но я все-таки опасаюсь, что это вся эта индустрия может рухнуть — такое уже было — помните дот-комы?

И именно поэтому я стремлюсь к написанию только эффективного кода. Во-первых, из чисто прагматических соображений. Я убежден (возможно ошибочно) в том, что мои инженерные навыки будут востребованы при любых катаклизмах в индустрии. Во-вторых, мне это просто по жизни нравится — заниматься нетривиальными задачами. Задачи класса O(1) мне неинтересны, хотя, надо признать именно они пока что и обеспечивают в основном мою жизнедеятельность (такова, брат, диалектика). Но я стремлюсь к некому кайфу в жизни — делать только эффективные вещи, интересные мне самому. И в-третьих, моя практика показывает, что это вполне возможно — оставаться в рамках того, что интересно мне и только мне (эффективный код и нетривиальные задачи) и при этом быть востребованным (я этого пока не достиг, но "есть тенденция").

Таким образом, вопрос о написании эффективного/неэффективного кода заключается в рисках и личном выборе этих рмсков. Мой риск — остаться вымершим динозавром. Риск индусов — остаться у разбитого корыта в случае падения рынка индустрии (не надо говорить, что это невозможно — это ОЧЕНЬ возможно). Все-таки, по совокупности факторов, я выбираю путь "динозавра". Индусы ничего не умеют кроме как дубасить мегатонны кривого кода. Я тоже это умею, хотя и не знаю все эти Java-дот-неты так как они знают. Но при этом я умею кое-чего еще, а именно — работать над задачами, сложнее класса O(1).

Не уверен, что моя позиция хороша. По крайней мере, я знаю, что эта ниша невелика и мне вряд ли удастся заработать большие деньги. Большие деньги в индустрии делаются на попсовом, кривом и глючном софте, пожирающем мегабайты. Period! Это никакой не сарказм, это просто факт — так устроен этот мир. Но если захотеть и не лениться, то это вполне реально — делать только эффективные и интересные вещи и при этом "выпивать-закусывать". Это не самый простой путь, но (цитируя Кастанеду), мне представляется, что это — путь с сердцем. А путь "чтоб просто работало" — это путь без сердца. Вот и вся разница. Большинство людей выбирает путь полегче — и они правы! — но это и есть причина того, что "the grass was greener, the taste was sweeter".
И нечего плакаться по поводу того, что "программы раздулись и тысячекратно замедлились". Лично для меня это является совершенно ортогональным фактором к моим интересам.
Надо так (цитата из Х.Забей, "Победил"):

Сражался как п...ц всему
Что было сил,
И выиграл войну.
И победил...

здесь (mp3, 1.7MB, много мата!)
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 25.10.05 02:15
Оценка:22 (5) :))) :))) :))) :))) :))) :)))
VladD2,

> GZ> Так что если говорить о промышленных языках, то я бы сказал что они есть компромисс — помочь первым, и не мешать вторым.

>
> Любое достойное дело и или вещь является компромисом. Бескомромисной может быть только вера и преданность.

Sorry, не могу удержаться

Думаю, когда-нибудь ты поймешь, что это очень верный, бескомпромиссный выбор архитекторов дотнета. Выбор архитектурно-чистого решения. Решения которое позволит писать код без компромисов.

(c)
Автор: VladD2
Дата: 07.02.05
VladD2
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 05.10.05 11:21
Оценка:28 (7) +5 -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!

Имхо, пока за скорость разработки платят больше, чем за скорость работы заказанной программы, этот призыв останется "гласом вопиющего в пустыне".
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 06.10.05 11:25
Оценка:90 (7) +4
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно.

Это вряд ли. Наоборот, правду-матку режешь.

Тут флейм уже заполыхал вовсю на тему проведения границы между тем, когда оптимизировать вредно, и тем, когда это необходимо.
Кратко выскажу несколько мыслей на заданную тему:
  • Не стоит бояться того, что программисты определенного склада "вымрут". Программистов порождает среда. Когда среда приветствовала нердов — программерами были нерды. Сейчас есть и нерды, которые живут на работе, иногда высовываются в сеть, а живых людей видят только на коференции. Есть и "индусы" — малоквалифицированные люди, которые покрывают потребность в "давай-давай", "нам некогда учиться — надо сдать систему вчера", "если у тебя есть рабочий кусок кода — скопируй его целиком" и так далее. Есть также промежуточное звено — люди, не испытывающие коммуникативных проблем, у которых есть некомпьютерные хобби, но при этом они любят свою работу и стараются делать ее хорошо.
    И все это — исключительно потому, что есть потребность в каждой из этих категорий. Напоремся на потолок производительности — те же индусы научатся писать эффективные программы. Ну, не все, а кроме 99% не сумевших и вымерших
  • Собственно, о самой эффективности. С одной стороны, я полностью согласен с теми, кто придает максимум значения экономии времени программиста. Ребята, время, когда можно было годами полировать текстовый редактор в одиночку, кануло в лету. Сейчас у нас нет времени на эту ерунду. Нам надо удовлетворять потребности бизнеса очень быстро. В первую очередь это означает переход к групповой разработке. Да, до сих пор очень редко в природе встречаются команды численностью более 10 человек. Я подозреваю — из-за технических и организационных проблем. Любой наш заказчик будет счастлив сократить время разработки вдвое. Кроме этого, большое значение имеет стоимость поддержки.
    Резюме: понятность программы сейчас значительно важнее ее эффективностибольшинстве случаев!). Соответственно, рулят платформы, которые позволяют писать более понятные программы. Рулят платформы, которые предоставляют исчерпывающую информацию об ошибках, а не Сore Dump. Рулят платформы, которые выполняют рутину за разработчика. Чтобы он мог сосредоточиться на написании действительно существенной части. Потому что ему надо будет писать (а его коллегам читать) меньше кода.

    Тем не менее, я тоже испытываю дискомфорт, глядя на неэффективности на ровном месте.

    В итоге, я свожу свою мысль к следующему замечанию:
    — нельзя ставить эффективность во главу угла. Она не является приоритетом
    — Это не значит, что стоит применять заведомо неэффективные решения.
    Этого простого правила, я считаю, должно быть достаточно. Остается только тонкость с этим "заведомо". (Это слово, кстати, встречается в тексте статьи 273 УК РФ). Тут каждый решает для себя. Главный критерий — насколько дорого обойдется применение альтернативного решения. Если чувствуешь, что объем работ вырастает больше, чем на 20%-50%, то лучше забей. Если стоимость примерно одинакова — применяй лучшее.

    Отдельный разговор надо завести об архитектуре. Premature optimization касается только микро-уровня. Если вдруг в саму архитектуру не было заложено возможности по повышению эффективности, то выполнение mature optimization может оказаться postmature, т.е. слишком поздним. И это сведет полученную экономию средств к нулю.

  • Ну, и последнее замечание: Очень важно правильно применять оптимизации. В предыдущем пункте я упоминал про неиспользование откровенно неэффективного кода. В большинстве случаев это будут мелкие глупости, вроде вызова new в цикле или ресайза динамического массива на 1. Так вот, на каждой платформе эти хитрости — свои. И ни в коем случае нельзя переносить привычные методы в другую среду. В дотнете new может означать всего лишь очистку памяти. Округление размера выделяемых объектов до "круглых" типа 32, 64 в дотнете контрэффективно — аллокатор сам разберется с выравниванием, а увеличение размера ускоряет забивание хипа и учащает сборку мусора.

    Поэтому для выполнения пункта 2 просто необходимо тщательно изучать среду, в которой работаешь. Чтобы, например, нутром чуять, что
    ...(string a, string b, string c)
    {
      return "Hello" + a + b + c;
    }

    — эффективно, а за
    ...(IEnumerable<string> strings)
    {
      string s = string.Empty;
            foreach(string a in strings) s=s+a;
        return s;
    }

    надо бить линейкой.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Об эффективности программ в избранное  новое    модер.  /!\
От: McSeem2http://www.antigrain.com
Дата: 06.10.05 13:33
Оценка:51 (7) +3 -1
Здравствуйте, Дарней, Вы писали:

Д>Ну и пусть делают. Я лучше буду иметь дело с неэффективной, но работающей реализацией. Чем с дьявольски эффективной, но ни хрена не работающей


Шас я процитирую (о ужас!) Баяна Ширянова:
     Но  ведь  какая  штука,  спроси  любого  ублюдка  на  улице, что бы  он
предпочел: жить долго, но  скучно, или  коротко, но радостно? И  он  выберет
последнее. Ну да, не все. Но большинство!
     Но, б..,  почему  этот  уличный опрашиваемый  не  согласится  на  такой
вариант: долго  и радостно?  А  потому,  что он думает,  что так не  бывает.
Столько  лет  все  рвались  к   счастливой   жизни,  что  абсолютно  в   ней
разуверились!


Это я к тому, по достижении "определенной стадии просветления" (это такой само-сарказм) оказывается, что писать эффективный код — это не только приятно и интересно, но он еще и оказывается гораздо надежнее! И стоимость некой абстрактной единицы функциональности оказывается ниже. И что характерно, индустрия, "в которой не место энтузиастам" проявляет тенденцию к спросу на таких "динозавров". Да потому что уже всех достал этот подход — "давайте сделаем это по-быстрому, а потом будем оптимизировать". И это "потом" никогда не наступает — получается как в занудном кошмарном сне — совсем чуть-чуть надо, чтобы вырваться из порочного круга, а не получается — что-то все время мешает.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 07.10.05 07:59
Оценка:23 (2) +3 :))) :)))
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>С такими ошибками в C++ шаблоны могут помочь бороться.

Заметка из жизни. Если у программиста проблемы с ДНК, то C# многое прощает, а вот шаблоны в С++ многое усугубляют.

С уважением, Gleb.
Re[7]: Об эффективности программ в избранное  новое    модер.  /!\
От: McSeem2http://www.antigrain.com
Дата: 09.10.05 22:05
Оценка:9 (7) +3 :)
Здравствуйте, gear nuke, Вы писали:

GN>Вот, кстати, хороший пример Вы привели. А если человек не понимает, что и почему лучше, он запросто может реализовать то, что первое придёт в голову (пузырёк) .


Да, но есть случаи, когда этот "пузырек" побьет std::sort в разы или даже десятки раз (на почти отсортированных массивах). В моей практике такой случай был, причем очень хитрый. В 99% случаев данные были отсортированы. В 0.9 процентов случаев — почти отсортированы. В 0.1% случаев — практически в беспорядке. Решение таково: пишем bubble sort (да, именно ее). Данная сортировка, являясь "наитупейшей" обладает важным свойством — мы можем контролировать, насколько нам удалось продвинуться и сколько мы сделали перестановок. В 99% случаев она срабатывала без единой перестановки. Но как только количество перестановок превышало некий предел (подобранный эмпирически), мы все бросали и отдавали на съедение quick sort. Это эмпирическое знание позволило ускорить некий процесс обработки данных более чем вдвое, по сравнению с просто вызовом std::sort().

К чему я все это? — да ни к чему, просто случай из практики. Ну и к тому, что "ученье — свет", "инженер — это звучит гордо" (в качестве само-сарказма). А так же к тому, что пути оптимизации неисповедимы.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: ZevS 
Дата: 05.10.05 12:03
Оценка:7 (2) +3 -1 :))) :))

Жаль только жить в это времы прекрасное уж не придется ни мне, ни тебе...

...поскольку крупные поставщики ПО в сговоре с железячниками — что б было как в анекдоте: кончилась водка, осталась закуска, сбегали за водкой, кончилась закуска, купили закуски...

Эффективное ПО также ненужно корпорациям как:
— вечная лампочка (почти вечная придумана давно)
— туфли на неснашиваемой подошве (казалось бы — чего проще пустить туда резину как в авто-покрышках)
— экономичные автомобили
— удобные и дешевые сотовые телефоны
Re: Нет уж, позвольте! в избранное  новое    модер.  /!\
От: mrozov 
Дата: 05.10.05 13:11
Оценка:84 (6) +3 -1
Необходимость в написании ну о-о-о-очень эффективных программ отпала. И слава богу. Туда и дорога.
Потому что единственными, кто был в этом заинтересован, были сами компьютерные энтузиасты (вроде вас, автор?), которые предпочитали ... э-э-э-э заниматься с компьютером любовью непременно стоя и непременно в гамаке.
А почти полная утеря общественностью навыков эффективного создания каменных топоров вас не волнует? А врдруг железо закончится, что делать будем?

Индустрия променяла эффективность кода на эффективность труда. И на его облегчение. Что тут плохого?

Описанная картина неизбежного апокалипсиса тоже сильно преувеличена.

Программы редко пишутся в расчете на то, что железо подрастет. Крупные игры, ОС и прочие перспективные разработки в основном. Мы же, простые прикладные смертные, имеем дело с тем, что есть. И выбор между экономией тактов и экономией человеко-часов стараемся делать однозначный.

Поэтому то, что есть.. java/.net, массивные framework-и и Windows XP никуда не денутся, даже если прогресс резко остановится.Эти вещи пришли, чтобы остаться. А если прогресс не замедлится, то мы постараемся занять и те ресурсы, что будут нам предоставлены. Зачем?

Понимаете, автор... гигабайт свободной оперативной памяти при запущенной IDE греет душу не всем. Мне, например, нет. А вот возврата к временам, когда редактор кода в IDE не умеет подсвечивать синтаксис и указывать на допущенные мной ошибки в background-е я не хочу.

И не надо мне говорить, что это не связанные вещи. Что компиляция в background-е была бы все равно, причем быстрее и надежнее. Ее бы не было именно потому, что ее пришлось бы писать на каком-нибудь asm-е с использованием столь эффектно описанного вами механизма самопожирания программы. Руки бы не дошли — надо было бы drag&drop прикручивать и баги в компиляторе исправлять. А может эту фичу вообще не стали бы делать — памяти ого-го сколько отжирает, целых 121 232 байта! В уме нужно компилировать, слабак!

За все нужно платить. Текущая плата лично мне представляется в высшей степени щадящей.

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

Раньше было не так? Да, но раньше это была элитарная профессия. А теперь потребность в кодерах возрасла многократно (несмотря на то, что эффективность труда тоже) и уровень, разумеется, упал. И отсутствие оптимизации — это меньшее из всех зол.
Re[7]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 07.10.05 12:00
Оценка:27 (3) +7
GlebZ,

> ПК>С такими ошибками в C++ шаблоны могут помочь бороться.


> Заметка из жизни. Если у программиста проблемы с ДНК, то C# многое прощает, а вот шаблоны в С++ многое усугубляют.


Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[11]: Об эффективности программ в избранное  новое    модер.  /!\
От: srggal 
Дата: 07.10.05 12:51
Оценка:27 (1) +4 -1 :)
Здравствуйте, mrozov, Вы писали:

S>>Такие вот интсрументы эти Ваши вилки


M>Простите, у вас есть дети?

M>Я имею в виду, знаете ли вы, какие меры предосторожности нужно предпринимать, если в доме есть ребенок, умеющий ходить, но еще не имеющий развитого инстинкта самосохранения?

Отлично, тема детей, это очень даже хорошо

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

Соответсвенно, взрослым, или как Вы изволили вырвзиться

умелецы по части поедания фруктов не теряя достоинства


Имеют свои вилки, а дети свои.

Таким образом кесарю — кесарево...

ВЫВОД:
Для

программиста проблемы с ДНК

нужны свои инструментальные средства

А для Взрослых — свои.

Прочитав топик про С# 3.0 С# 3.0
Автор: AndrewVK
Дата: 14.09.05

меня посетило подозрение, что C# взрослеет, и скоро там тоже понадобяться раздельные наборы столовых приборов


ЗЫ ОЛЛ прошу извинить фривольный стиль, просто, я отчего-то веселый такой Сыну сегодня пол-года
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 06.10.05 15:51
Оценка:15 (4) +3
Здравствуйте, eao197, Вы писали:

PD>>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>>это возможно!

E>Имхо, пока за скорость разработки платят больше, чем за скорость работы заказанной программы, этот призыв останется "гласом вопиющего в пустыне".


Платят не за скорость разработки, и не за скорость программы которая получается в результате разработки. Платят за решение своих проблем. Программа должна решать задачи заказчика. Делать это она должна с примлемой производительностью на имеющемся у него железе. И решать эти задачи программа должна не через 10 лет, а сейчас. Причем программа еще должна стоить приемлемые для заказчика деньги.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[6]: Об эффективности программ (уровень языка) в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 06.10.05 19:17
Оценка:1 (1) +4 -1 :)
GlebZ,

> Кроме того, тут стоит говорить не только о Framework, но вообще о языках высокого уровня. Не секрет, что язык высокого уровня генерит избыточный код и избыточно использует память. И чем выше язык, тем труднее поддается оптимизация кода компилятором.


Это не совсем так. Например, те же функциональные языки часто "уделывают" ряд других, менее высокоуровневых "конкурентов". В общем, корреляция не вполне установлена.

> В принципе, если взять тот-же STL, то говорить о том, что он по скорости 1 в 1 с кодом написанным вручную на С не приходится.


Да, часто быстрее.

> А string вообще кошмар, но зато жутко удобный.


Это к уровню языка отношения не имеет.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[11]: Об эффективности программ в избранное  новое    модер.  /!\
От: Igor Sukhov rsdn 
Дата: 26.10.05 10:06
Оценка: :))) :))) :)
Здравствуйте, Павел Кузнецов, Вы писали:

>> Любое достойное дело и или вещь является компромисом. Бескомромисной может быть только вера и преданность.


ПК>Sorry, не могу удержаться


ПК>

ПК>Думаю, когда-нибудь ты поймешь, что это очень верный, бескомпромиссный выбор архитекторов дотнета. Выбор архитектурно-чистого решения. Решения которое позволит писать код без компромисов.

ПК>(c)
Автор: VladD2
Дата: 07.02.05
VladD2


дык постилось чай под двуликим Янусом =)
* thriving in a production environment *
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 06.10.05 03:54
Оценка:67 (3) +2 -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD> И вот тогда этот неэффективный стиль программирования даст себя знать!

PD>Сейчас можно просто рассуждать — чего я буду 20 Мбайт экономить, если
PD>пользователь без проблем 256 может докупить ? А вот когда опять в жестких
PD>лимитах работать придется — окажется, что некоторые программы, которые вполне
PD>могли бы быть написаны, написаны не будут, или же будут написаны лет через 10
PD>после того момента, когда они могли бы появиться! Потому что эффективно
PD>работать большинство не умеет. Привычки у них такие — что нам стоит лишних
PD>десяток Мбайт взять!

Научить обычного, не озабоченного "оптимизацией-везде-где-можно" программиста оптимизировать программы куда проще, чем научить "байтовыжимателя" писать нормальный и понятный код. Потому что второй всегда будет искать, как в .NET обнулить поля структуры с помощью ZeroMemory (да-да, это намек ) — вместо того, чтобы проектировать архитектуру. Да еще и считать окружающих идиотами, потому что они не понимают, как же это важно — обязательно залезть на нижний уровень по самый локоть.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: kwas 
Дата: 05.10.05 13:41
Оценка:12 (3) +3
It is far, far easier to make a correct program fast than it is to make a fast program correct. (c) C++ Coding Standards: 101 Rules, Guidelines, and Best Practices

Ну и от себя (хотя тоже не мое):

Заказчик: Нам нужна программа, которая будет стоить не дорого, работать — быстро, и сделать ее надо срочно.
Программисты: Из трех перечисленных условий выберите любые два.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Cyberax 
Дата: 05.10.05 16:53
Оценка:7 (1) +1 -4
Centaur wrote:

> Однако, в наше время таки оптимизировать всё до последнего байта есть

> непозволительная роскошь. Моё время как разработчика несравненно
> дороже времени процессора и оперативной памяти.

Дайте я придумаю цитату: "Если разработчик экономит свое время, то он
тратит время своих пользователей".

> Пишите свои программы понятно, господа! Если использование показывает,

> что память — узкое место, найдите 10% кода, которые используют 90% памяти.

Миф. Современные программы тормозят одинаково по всему коду.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[2]: Об эффективности программ - мои замечания в избранное  новое    модер.  /!\
От: mik1java-performance.com
Дата: 17.10.05 12:57
Оценка:5 (3) +2 -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Есть такой класс программистов — программисты на Visual Basic. VB как-то в России не слишком популярен ИМХО и признаваться, что на нем пишешь, даже как-то стыдно считалось . А вот в мире он весьма популярен, где-то мне встретилось утверждение, что в мире около 1 млн. программистов на VB. За то. что мне память здесь не изменяет — не поручусь, так что критиковать это утверждение не надо. И потом, неизвестно кого они туда включили — может, школьников средних школ тоже


PD>Так вот, эти самые программисты на VB свою работу делали, а вот эффективности от них никто и не ждал. Потому что программы для массового использования они не делали, а делали для данного конкретного случая, порой для себя, или для заказчика, которому она нужна, а торговать он ей вовсе не собирается. Кстати, если во времена своих химических расчетов имел бы PC с VB — вполне возможно, на нем бы и начал свою карьеру. Просто, удобно, легко...


PD>Что касается эффективности — кто ее от Бейсика когда ждал ? К нему традиционное отношение как к чему-то неэффективному — интерпретатор же! И пусть VB никакой не интерпретатор — от однажды завоеванной репутации так легко не отделаешься


PD>Так вот, у меня впечатление такое, что этот стиль VB попросту начинает проникать в те области, куда программистов VB раньше и на пушечный выстрел не подпускали, да они и сами не стремились, так как знали, что им там делать нечего — не влезут они с VB в имеющиеся ресурсы, не добьются нужной производительности. А ресурсы увеличились — и они пошли!


Есть у меня на работе одна система. Клиентская часть написана на VC6. Около полумега cpp-шек. Многопоточная, большой объем взаимодействия с системой, работа с Oracle и прочие мелочи. Работать она должна на машинах с 32 мегами памяти (потому что есть у нас и такие). Ничего, работает. На тысяче машин где-то. Параллельно.

Есть для нее панель управления. Через которую ею администраторы управляют. Ее писал на VB6. Почему? Потому что надо быстро было писать, и чтобы работало. Больше сотни окошек в ней, а написана была за 4 месяца. Кстати, с собственным, заточенным под нее гридом (работает, чертяка, идеально). Памяти жрет под полсотни мег. Ну и что? У админов ее все равно 512. Не то, что у пользователей.

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

Кстати, об эффективности. На VB, бывает, тоже приходится данные локально обсчитывать. И где пооптимизировать — находится...
Re[10]: Об эффективности программ в избранное  новое    модер.  /!\
От: mrozov 
Дата: 07.10.05 12:36
Оценка:1 (1) +2 -1 :))
S>Такие вот интсрументы эти Ваши вилки

Простите, у вас есть дети?
Я имею в виду, знаете ли вы, какие меры предосторожности нужно предпринимать, если в доме есть ребенок, умеющий ходить, но еще не имеющий развитого инстинкта самосохранения?

Но главное не это. Главное то, что я, как и подавляющее большинство населения, фруктовыми вилками не пользуюсь. Зато пользуюсь чайными ложками. И человека, который заявляет, что "Чайные ложки не нужны, вот фруктовые вилки — это круто!", я всерьез воспринимать затрудняюсь. Так как он, вполне вероятно, большуй умелец по части поедания фруктов не теряя достоинства, но вот с кругозором и трезвой самооценкой у него явно некоторые проблемы
Re[6]: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 10.10.05 05:17
Оценка: +6
Здравствуйте, McSeem2, Вы писали:

E>>А поиск в Janus я привел как пример распространенного подхода: сделать работоспособный вариант без учета его эффективности. А потом, когда это станет проблемой, оптимизировать.


E>>Тут уже кто-то сказал, что это "потом" никогда не наступает.


MS>Это был я



MS>Но зададим себе вопрос — "а оно надо"? Может быть и не нужен поиск в Janus? Или нужен?


Мне нужен
Иногда возникает какой-нибудь вопрос, который уже затрагивался где-то или просто хочется привести ссылки на какие-то факты. Вот, как здесь: Re: Открыли зачем?
Автор: eao197
Дата: 08.10.05
, то найти нудные обсуждения без поиска для меня не реально.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Об эффективности программ (уровень языка) в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 07.10.05 18:05
Оценка:40 (5)
P.S.

> Какое отношение к string имеет уровень языка, и string к уровню языка? В лучшем случае тут можно говорить об уровне абстракции. Но и в этом случае вряд ли можно говорить об универсальной зависимости производительности от уровня абстракции. Иными словами, в данном случае производится попытка сделать общий вывод (зависимость производительности от уровня языка) из частных моментов (производительность char[] vs. std::string), не вполне относящихся к ходу рассуждений (уровень языка здесь, имхо, ни при чем).


Кстати, для C++ Степановым в свое время даже был написан набор их 13 тестов, меряющих так называемую abstraction penalty. Для современных компиляторов (Intel C++, Visual C++) abstraction penalty в соответствии с этим тестом, если и проявляется, то "плавает" в пределах единиц процентов.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[3]: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: Коваленко Дмитрийhttp://www.ibprovider.com
Дата: 29.10.05 15:53
Оценка:26 (2) +3
Здравствуйте, eao197, Вы писали:

E>Возьмем Janus. Когда я пишу это сообщение он у меня занимает в пямяти 53Mb. Сам инсталлятор у него маленький, но к нему же еще и .Net нужен. А к следующим версиям еще и .Net 2.0 потребуется. А уж поиск по базе сообщений по скорости с Opera вообще не сравнится. Да и объем сохраняемых сообщений на диске не маленький. Так что для меня Janus удобная программа, но вот эффективной я ее назвать не могу. А если для повышения ее эффективности для хранения сообщений вообще что-то посерьезнее Jet-та потребуется (какой-нибудь FireBird или MSSQL), то вообще...


Улыбнуло капитально.

Каждый программер на заре своей карьеры торжественно клянется — "Шоб я писал тормозные, глюкавые программы ... да шоб мне гореть в аду, если такое произойдет". Те, кто все таки становится профессионалом, говорят на эту тему уже гораздо осторожнее. Ибо познакомились с реалиями своей профессии.

-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: iehttp://ziez.blogspot.com/
Дата: 05.10.05 14:37
Оценка:19 (2) +3
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!

Не согласится не возможно.

Сперва, хочу все-таки попросить всех участников форума быть разумными "насколько это возможно!" (с) Pavel Dvorkin и не скатываться на обсуждение технологий и ЯП — жаль, что это сделал Павел.

Да, я, безусловно, ЗА эффективный код. Сам иногда удивляюсь вопиющему пофигизму к эффективности. Только ИМХО эффективность нынче меряется далеко не объемом используемой оперативки и быстродействием. Эффективность трансформирповалась нечто другое. Посмотрим на нее в немного другой плоскости. Буду говорить об эффективноти 2х типов: эфективность на уровне кода и на уровне технологий.

Эффективность на уровне кода.

Простейший пример неэффективности приведу из проекта, в который с недавнего времени пришел. Один коллега пишет:
        for (int i = 0; i < reporter.GetDistributorsCount()*reporter.GetReportTypesCount(); i++)
        {
            // работа с БД
        }

Я сказал, что это не очень красиво и попросил переписать сие безобразие на следующий код:
    for (int i = 0, count = reporter.GetDistributorsCount()*reporter.GetReportTypesCount(); i < count; i++)
    {
        // работа с БД
    }

На что мне открыто заявили: "reporter.GetDistributorsCount()*reporter.GetReportTypesCount() — это ничто по сравнению тем, что находится в теле цикла! работа с БД уничтожит эту оптимизацию". Уж не знаю и правда ли он так думает или для него слишком уж обидно, когда вчерашний студент учит код писать профессионала со стажем. Ну не прав он. На все 100 не прав. Когда в метод GetDistributorsCount(), однажды добавят работу с БД, а то и с веб-сервисами (на самом деле в этот метод вряд ли, а в другой?), тогда начнет плоды пожимать. А что, тяжело сразу написать эффективно?

Еще один пример неэффективности, я описывал недавно в другом форуме:
Злоупотребление try-catch или как не надо ловить эксэпшены.
Автор: ie
Дата: 27.09.05

Дело тут не в расбрасывании ценными килобайтами памяти, а в неэффективности с точки зрения поддержи кода и системы в целом.

Буду ли я оптимизировать работу с матрицами? — It depends... По большей части от поставленной задачи. Стараться сделать все как можно оптимальнее, определенно буду. Но скорее всего у начальства не вызовет восторга, на то, чтоб даже 5-6 часов, я сделал код экономящий пару МБ.

Действительно, мы сейчас живем в век дешевой техники и дорогой рабочей силы. Но экономя на поддержке и разработке многие, прежде всего заказчики и начальники, действительно портят программистов. Что однако не умоляет множество глупых и бездарных программ.

По поводу ICQ-клиента — Miranda рулит

Эффективность на уровне технологий.

Вот с архитектором в проекте очень даже повезло. Сейчас используется 5 ЯП с соответсвующими им технологиями. Я бы еще пол года назад сказал бы — да зачем мне какой-то там Питон, .NET форева. (Надеюсь больше меня эти мысли посещать не будут.) Все от начала до конца можно было сделать на .NET. Однако, прилили и C++, и Питон, и Ява Скритп, и Перл. Чего добились — думали: путаницы и неразберихи — оказалось: простоты и эффективноти!
Что я хочу этим сказать — ну сколько можно доказывать друг другу, что вот так вот в # не сделаешь, а вот так в ++ (хотя сам люблю друзьям ++никам, за кружечкой пива обяснить, что ++ — это так — игрушки ). Пора уже давно выяснить сильные стороны каждой из технологий и использовать их. А будь мне действительно так важны те 2 МБ при работе с матрицами — сяду за плюсы и глазом не моргну. Чего и вам, Павел, желаю.
... << RSDN@Home 1.1.4 stable rev. 510>>
Превратим окружающую нас среду в воскресенье.
Re: Закон Мура умер в избранное  новое    модер.  /!\
От: gear nuke 
Дата: 06.10.05 05:59
Оценка:9 (2) +3
Здравствуйте, alexeiz, Вы писали:

A>Абсолютно верно. Мы уже подошли к пределу. У меня 3GHz процессор уже два года. И никакого двухкратного скачка частоты за 18 месяцев не предвидется.


Да, закон Мура уже не работает несколько лет!

И ещё "нюанс", про который забывают говорить — архитектура современных компьютеров далека от фон-неймановской. Вы видите 3GHz + 2Gb памяти, а на самом деле... 3GHz + 512Kb (Вам ещё повезло, у Celeron кеш меньше в 2\4 раза). Остальная память работает со скоростью на порядок меньше.

Отсюда и отсутствие различия в скорости работы кода откомпилированного MSVC с опцией /clr и без неё. Сравнивается 2 неоптимальных варианта.

A>http://www.gotw.ca/publications/concurrency-ddj.htm


A>Тем не менее плотность транзисторов можно наращивать и дальше.


Я бы сказал — до сих пор удавалось находить решения технологических проблем.

A>Поэтому процессорная индустрия переходит из области гонки за частоту в область много ядерных процессоров (multicore). Уже существуют dual-core Intel Pentium D & AMD Athlon64 X2. В скором будущем у нас будут гораздо больше core, порядка десяти.


2 ядра — та ещё "конфетка". Ни о каком увиличении скорости в 2 раза речи быть не может. Общая шина памяти, необходимость в когеррентности данных в кеше — это только низкоуровневые железнае проблемы. Когда будет 8 ядер все эти заморочки только усугубятся. Эффективных способов решения нет, и, боюсь, не будет.


Но давайте попробуем заглянуть в будующее:
— бездисковые терминалы с тонкими каналами; загрузка огромного приложения с сервра будет напоминать о загрузке с магнитофона.
— workstation, являющиеся одновременно и "personal" web server — крутится большое количество сервисов, интерпретаторов, БД и прочего. А ещё хочется mp4 посмотреть, да и не закрывать браузер с десятками открытых страниц.
ИМХО не стоит забывать, что развитие часто идёт по спирали...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 05.10.05 12:43
Оценка:1 (1) +2 -1 :)
Здравствуйте, GlebZ, Вы писали:

GZ>А ты дать определение, что такое эффективный софт. И что такое неэффективный софт?


А еще определение "оптимизации" Это мне как-то на защите диссертации довелось побывать. Там человек защищался по инструментальной системе для кросс-ассемблерной разработки. Для того, чтобы очень сильная прикладная работа имела хоть какой-то оттенок научности в диссертацию вставили что-то про "оптимизацию разработке". И вот на защите бедолага диссертант взял да и ляпнул не к месту это слово. До этого дяденьки из совета чесно дремали, т.к. большинство из них слобо понимало, о чем вообще речь. А тут! Да у большинства из них оптимизация чего-то там -- это хлеб родной. Вот и спросили товарища: "Дайте определение оптимальной функции!"... Хорошо еще, что все хорошо закончилось.

Может давай я тебе еще пару примеров приведу к тому, что Павел у себя указал?

Вот берем браузер Opera. В нем еще и RSS-ридер есть, и почтовый клиент. И поиск по почте/сообщениям за доли секунды выполняется. И сам браузер 3.5Mb в дистрибутиве занимает (без Java). И памяти при работе у меня сейчас 44Mb занимает с 14-ю открытыми табами. Кому как, а по мне Opera весьма эффективная программа.

Возьмем Janus. Когда я пишу это сообщение он у меня занимает в пямяти 53Mb. Сам инсталлятор у него маленький, но к нему же еще и .Net нужен. А к следующим версиям еще и .Net 2.0 потребуется. А уж поиск по базе сообщений по скорости с Opera вообще не сравнится. Да и объем сохраняемых сообщений на диске не маленький. Так что для меня Janus удобная программа, но вот эффективной я ее назвать не могу. А если для повышения ее эффективности для хранения сообщений вообще что-то посерьезнее Jet-та потребуется (какой-нибудь FireBird или MSSQL), то вообще...
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Cyberax 
Дата: 06.10.05 12:50
Оценка:1 (1) +4
Здравствуйте, Nickolay Ch, Вы писали:

NC>Буду краток: писать код надо так, чтобы из него можно было получить максимальную денежную прибыль.

NC>Энтузиастам и "вольным художникам" не место в индустрии.
Именно поэтому на моем винчестере остается все меньше программ, которые делались для получения максимальной денежной выгоды. Так как программы, написаные энтузиастами и вольными художниками все чаще становятся лучше коммерческих собратьев.

Хорошие коммерческие продукты, которые я использую, НЕ живут по правилу "максимальной денежной прибыли", а по правилу "Делать все, чтобы пользователям было удобно — тогда и прибыль будет".
Sapienti sat!
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Зверёк Харьковский 
Дата: 06.10.05 11:30
Оценка: +3 :))
Здравствуйте, Nickolay Ch, Вы писали:

NC>...писать код надо так, чтобы из него можно было получить максимальную денежную прибыль...

NC>...Энтузиастам и "вольным художникам" не место в индустрии...

Мда. Энтузиасты и вольные художники формируют эту индустрию.
Ну да к вечеру вернется McSeem2, он тебе подробнее объяснит
FAQ — це мiй ай-кью!
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: vladserge 
Дата: 07.10.05 13:25
Оценка: +4 -1
Здравствуйте, Centaur, Вы писали:


C>Пишите свои программы понятно, господа! Если использование показывает, что память — узкое место, найдите 10% кода, которые используют 90% памяти. Если использование показывает, что узкое место — процессорное время, найдите 10% кода, которые работают 90% времени.


Почему все легко так выстреливают — "фигня вопрос, углубить, улучшить.... пара пустяков".
А слишком поздно небудет? Что Вы будете делать если борьба с этими процентами заставит взорвать весь фундамент, пересмотреть всю архитектуру?
Я не верю, что прогу написанную без размышлений о разумном использовании рессурсов так просто сделать эффективной.
С Уважением Сергей Чикирев
Re[10]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 10.10.05 11:17
Оценка: :))) :))
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Сорри, это был VC6


Попробовал сейчас в VC7. Да, он действительно генерирует несколько своеобразный код, который быстрее примерно в 2 раза. Впрочм, тихого ужаса все равно нет.

; 19 : {
; 20 :
; 21 : for(int i = 0; i < 100000; i++)

xor eax, eax
$L19464:

; 22 : if(a[i] == 666)

cmp DWORD PTR _a$[esp+eax*4+400012], esi
je SHORT $L19461
cmp DWORD PTR _a$[esp+eax*4+400016], esi
je SHORT $L19461
cmp DWORD PTR _a$[esp+eax*4+400020], esi
je SHORT $L19461
cmp DWORD PTR _a$[esp+eax*4+400024], esi
je SHORT $L19461
cmp DWORD PTR _a$[esp+eax*4+400028], esi
je SHORT $L19461
add eax, 5
cmp eax, 100000 ; 000186a0H
jl SHORT $L19464
$L19461:

Проверил я и вариант с repne scasd. Точно, медленнее.

Так что я должен с тобой согласиться — неплохо они компилятор сделали. Жаль, у меня Intel compiler не установлен, любопытно было бы сравнить.
With best regards
Pavel Dvorkin
Re[9]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 07.10.05 18:35
Оценка:49 (3) :)
GlebZ,

> ПК>Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.


> Только вопрос в том, что для кого программирование работа, а для кого-то призвание. И первых значительно больше чем вторых.


Теперь осталось определить, в какой степени мне важны интересы первых при выборе инструментальных средств, и на этом можно будет поставить точку в этой дискуссии. Пожалуй, с чем я легко могу согласиться, так это с тем, что в высказывании, процитированном выше, мне следовало подчеркнуть, что речь идет о тех инструментах, которые интересуют меня лично. Об остальных у меня мнения, кроме того, что они мне неинтересны, нет.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: mrozov 
Дата: 06.10.05 12:26
Оценка:30 (2) +2
Видите ли, колега.

Абстракции — абстрациями, а конкретика — конкретикой.

То, что вы не призываете заниматься микрооптимизацией — это замечательно. Хотя в свете существования компиляторов, которые оптимизируют ассемблерный код лучше, чем 99% программистов — это не так уж и удивительно .Однако из ваших постов можно сделать вывод, что вы отказываете в праве на существование (доминирование?) таким системам, как Java или .net, именно на основе их неоптимальности. И в моих (например) глазах такие тезисы абсолютно равнозначны призывам массово использовать asm для построения UI.

Тезис, который до вас на разные лады пытаются донести десятки участвующих в этой дискусии таков:

Излишней является любая оптимизация, которая не направлена на изменение ситуации, при которой система не способна уложиться в определенные в проекте временные рамки на том оборудовании, для работы на котором она предназначена.

Не больше. не меньше. Иными словами — для любого ПО можно (нужно?) определить минимально допустимую конфигурацию (критерии могут быть разными) и необходимые показатели быстродействия (в основном — время отклика). И любая система, укладывающаяся в эти рамки, является достаточно оптимальной, вне зависимости от того, насколько еще можно ускорить ее работу.

И если вышеописанные критерии выбраны правильно, то дальнейшая оптимизация системы не способна принести проекту никаких дополнительных дивидендов. Время же. потраченное на дополнительную оптимизацию, наносит проекту непосредственный вред.

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

P.S. А вообще — я сам очень люблю шлифовать код. Но очень редко могу себе это позволить.
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: savaDAN 
Дата: 05.10.05 12:53
Оценка:29 (3) +1
PD> Я не настолько наивен, чтобы к этому призывать. Просто одно скажу :

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!
Давайте разберемся с критерием "насколько это возможно", судя по тому что подход используемый в индсутрии выраженный владом: "оптимизируй только там где это необходимо" смею предположить что вы проповедуете подход "чем больше тем лучше"?

А вы представляете сколько будет стоить такая программа?
И где набрать столько высококвалифицированных программистов?
И какое количество ошибок будет содержать такое highly optimized приложение?

В результате может получиться обратная ситуация:
у пользователя есть компутер с 300МHz тактовой частотой, 128Мб памяти, и
ОS windows Effective (tm) которая будет показывать чудеса производительности на данной конфигурации но одна лицензия будет стоить 15000$.

Имхо, индустрия сама отлично себя регулирует: пока труд программистов стоит дороже железяк — будет сохранятся текущая ситуация. Изменится соотношение — изменится и отношение

PS: приложений где нужны эффективные решения и тотальная оптимизация достаточно много.
Но для большинства десктоп приложений оптимизация и эффективность не нужна. Если мне предложат МС офис за 100$ но который при этом будет жрать ресурсов в два раза больше — я предпочту его, докупив нужное количество процессора и памяти
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[22]: Об эффективности программ в избранное  новое    модер.  /!\
От: WolfHound rsdn 
Дата: 19.10.05 09:06
Оценка:25 (1) -1 :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Этот код НЕ вызывается из обработчика ВЕБ-форм. В этом случае так писать действительно не стоит. Этот код берет проверенные значения из БД, где для их хранения НЕ ОТВЕДЕНО 500 char. По-прежнему будешь утверждать ?

Я тут не поленился и сделал тест...
        const char* szFirstName = "iddqd";
        const char* szLastName = "idkfa";
        for(size_t i=0;i<100000;++i)
        {
            char szTotal[500];
            sprintf(szTotal,"%s %s", szFirstName, szLastName);
        }

0.0583748
        private static string Concat(string s1, string s2)
        {
            return s1 + s2;
        }
...
                for (int i = 0; i < 100000; ++i)
                    Concat("iddqd", "idkfa");

0.02506806

Итого: C# в 2 раза быстрее чем С++ (при том что в C# при каждом сложении происходит выделение памяти и работа идет с юникодом) и самое главное то что код на C# безопасен.

ЗЫ Замеры производились 100 раз. Самые быстрые и самые медленные результаты отбрасывались, остальные усреднялись.
ЗЗЫ VS 2003
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 24.10.05 17:59
Оценка:22 (3) +1
Здравствуйте, VladD2, Вы писали:

GZ>>Влад. Только не надо говорить что все программирование ограничивается бизнес-приложениями.

VD>Я где-то такое говорил?
Ты такое недвусмысленно подразумевал.

VD>Одно дело знать, что такое блок памяти, а другое думать только ими.

Неее. Я до сих пор думаю ими. И это мне помогает понять язык. И тебе тоже. А особенно помогает работать с массивами. И смотреть чтобы не было копирования больших данных. И тут абстракция не поможет. Здесь нужно иметь привычку делать так, чтобы потом кардинально не переделывать. Это в большей степени не проблема дизайна, а алгоритмическая проблема. Хотя меру тоже надо знать.

VD>Возможно я излишне резок,

+1. Именно излишне.
VD>но меня просто выворачивает на изнанку когдя я представляю себе плоды подобного обучения.
Мы с тобой(судя по возрасту) плоды такого обучения. И я рад что прошел школу 286 процессора и CGA экрана. Очень обучает думать. Так кто там мерял скорость GDI+?
Правильно действовать легко научить. Правильно думать — значительно труднее. И для системы алгоритм+доступные_ресурсы — нужно учиться думать.

Думать абстракциями — также нужно учить. То же очень сложная штука. Но это и не обозначает отмену вышеописанного.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 05.10.05 12:06
Оценка:13 (3) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно. Ну

PD>что же — к счастью, я уже не в том возрасте, когда падение или рост рейтинга
PD>могут серьезно повлиять на самочувствие.
Минус — это знак несогласия с сообщением, а не рейтинга. А в таком большом посте, трудно найти вещь с которой абсолютно несогласен.

PD> И действительно, как было не признать! Пока программа небольшая и в память

PD>помещается — ладно, живите и радуйтесь! Ну а как побольше стала ? Тут-то и
PD>придется признать свое бессилие. А гуру, им что, всегда что-нибудь придумают.
PD>Кто-нибудь из нынешнего поколения слышал про "самоубийство программ" ? Нет, это
PD>не стирание EXE-файла во время его работы. Это когда программа во время своей
PD>работы использует память, занятую своими командами (которые уже отработали и
PD>больше не потребуются) под свои данные.
У меня это называлось overlay.

PD> В общем, если говорить серьезнее, эффективность у нас была всегда на

PD>первом плане. Не как-нибудь написать, а наиболее эффективным способом,
PD>не любой алгоритм использовать, а лучший для этого случая. На этом мы
PD>прочно стояли.
Эффективность бывает разной. Можно написать программу, которая будет выполняться в 100 раз быстрее, но и содержать в 100 раз больше ошибок. И отладить эти ошибки будет практически невозможно. Поэтому эффективность — это не только скорость и потребление ресурсов.

PD> Чудо называлось Turbo Pascal 1.0. Сказать, что он меня поразил — не то

PD>слово. И не меня только. Все, кто до этого Ямаху не видел (а их в Омск
PD>очень немного попало тогда) и кому я о нем говорил, отвечали мне одинаково-
PD>такого не может быть!
Ага, и встроенный бейсик в Ямахе тоже был.

PD> А потом компьютеры, хоть и не меньше и не больше по размерам стали, начали

PD>резко увеличивать свою память и быстродействие. Сейчас любят вспоминать
PD>пророчество Б.Гейтса — дескать, 256 Кбайт всем хватит.
Вообще-то Билли говорил о 640.

PD> Вот тут первые шаги в сторону пренебрежения оптимальностью уже и начались.

PD>Действительно, на машине 600 Кбайт свободно, машина однопрограммная,
PD>конкурентов нет, зачем мне пытаться программу в 100 Кбайт уложить ,если можно
PD>все 500 спокойно использовать. Впрочем, память памятью, а есть еще и
PD>быстродействие. Оно было еще очень маленьким, так что хотя бы в этом
PD>плане писать все же приходилось эффективно, выжимать из машины все, что можно.
PD>Так что писать старались все же эффективно, хотя десятком, а то и сотней
PD>лишних Кбайт уже не мелочились.
Ну да. Только памяти никогда не хватало. И задачи, которые надо было реализовать, становились все больше и функциональнее. И потом все эти перегрузки памяти из extented в expanded. Все ради эффективности программы. Но самое главное, можно было быть уверенным за 400 килобайт нормальной памяти, и что тебе никто в соседнем процессе мешать не будет. Если было больше 400, то у многих клиентов программы отваливались. Для запуска некоторых программ, приходилось здорово подредактировать config.sys и autoexec.bat. Так что абсолютного счастья тогда не было.

PD> Дудки вам, а не 640 Кбайт. В 640 Кбайт сейчас умеют только "Hello,

PD>World" укладывать! Пока несколько десятков Мбайт не будет, и не подходите.
Ты Турбо-Vision пользовался? Достаточно эффективная библиотека, с очень большими возможностями. Но из-за того, что возможностей много то занимала много обычной и самой дорогой conversional memory. Поэтому, либо пиши все ручками (это будет эффективно по скорости и памяти), либо используй библиотеку и борись за память. А потом проблемы ушли. Может это и к лучшему?
Я тоже горячился когда оказалось что exe файл для Delphi был больше мега(сейчас не помню, но для тех времен очень много). Но то, что я мог мышью быстро собрать приложение и получить за него деньги перевешивало. Как программисту который уважает свое творчество, это плохо. А вот для человека который пытается на хлеб масло намазать, чрезвычайно хорошо.

PD> Другой пример — сама Windows. Я прекрасно понимаю, что Windows NT 4 и

PD>Windows XP — не совсем одно и то же. Но та на 8 Мбайтах работала, а эта от
PD>128 нос воротит, подавай ей 256.
NT 4.0 на 8 мегабайтах не работала, а обслуживала саму себя. И то, если сервис паки не ставить.
PD>А ядро, вообще говоря, претерпело не такие уж большие изменения.
Так оно места то много не занимает. Оно действительно эффективно. А вот если говорить о сопутсвующих процессах, типа сервисов и т.д., или тех же картинок, то это и есть увеличение. С установкой сервис паков и добавления функциональности, ситуация выравнивается.
Хотя согласен, многое можно было-бы сделать пооптимальнее.

PD>программа занимала 8 Мбайт, если можно взять 64 ? Даже, пожалуй, наоборот-

PD>увидят, что твоя программа меньше памяти занимает, чем у конкурента — ну
PD>и решат, что та более крутая
Дудки, такого не было. Программа должна либо работать, либо не работать и тормозить. Это и есть показатель эффективности был, есть и будет.

PD> Я не против удобства и простоты. Я за. А вот что такое "достаточной" —

PD>извольте объяснить. Если машина однопрограммная — тогда, конечно, достаточно —
PD>если помещается в память и достаточно быстро работает. А в многопрограммной
PD>коммунальной квартире стоит еще и о других подумать. Потому как память хоть и
PD>большая, но не резиновая. И процессор пока что только один, как правило.
Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват? Ты можешь сформулировать когда программу можно считать избыточной?

PD>Или вот другой пример — с умножением матриц

Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.

PD>Правда, Рихтер тут же отмечает, что эта операция может оказаться слишком

PD>дорогой,да и не всегда возможной. Рихтер, безусловно, понимает, когда ее можно
PD>применять, а когда не стоит. Понимают ли это все разработчики под .Net ? Боюсь,
PD>что нет. Так что будут они этот способ использовать, не слишком задумываясь,
PD>скорее всего. Сериализуют двумерную матрицу размером в несколько Мбайт, и все
PD>дела
Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест. А также оптимизацией памяти, если ее оказалось недостаточно.

PD>Хороший, кстати, пример — ICQ. Написана она не на .Net ИМХО (давно

Жадные вы. Че вам памяти жалко?
Во первых, ICQ — это глюк официально выходящий в альфа-бета видах. Притом накрученная функциональностей, которая особо никому и не нужна.
Во-вторых, не стоит по одной-двух программах делать выводы о отрасли в целом. Во времена MSDOS, были свои глюкавые монстры.

PD>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не

PD>слишком думая об эффективности, а потом узкие места можно оптимизировать.
Подпишусь.

PD>Теоретически — совершенно безупречное рассуждение. А практически — это

PD>верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
PD>или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
PD>потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
PD>5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
PD>бы — что тут оптимизировать? Так и должно быть, все нормально сделали!
Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы. И хорошо ли ты написал, плохо ли, — клиент всегда прав. Ты можешь выжать 100 процентов оптимизации, но клиенту будет этого мало. И нравится тебе или не нравится, считаешь ли ты это нужным, или не считаешь, ты обязан это сделать. И тут никого не волнует даже то, умеешь ли ты оптимизировать, или не умеешь. Не умеешь, с голоду помрешь.

PD>В результате получаем некую самодвижущуюся повозку размером с аэроплан,

PD>ставим на нее ракетный двигатель, запускаем — едет! Едет ведь! Со скоростью
PD>60 км/час. Ну вот это и есть настоящий аэроплан, в серию его и пусть
PD>по дорогам ездит. А когда этим разработчикам объясняешь, что аэроплан
PD>должен не ездить, а летать, и не 60, а 900 км/ч давать, а если Вы автомобиль
PD>делали, то он и при двигателе внутреннего сгорания должен эти 60 (а то и 120)
PD>давать, да и размерами должен быть раз в 20 меньше — удивляются, чего, мол,
PD>привязался! Ездят же на нем, чего тебе надо!
Аналогия неуместна. Важно насколько клиенту важно чтобы он летал. Зачастую заказывают атомную подводный крейсер, а тебе выкатят Ту155 с 5 подводными винтами. И вроде двигается быстрее чем нужно. И летает, что не заказывали. И вроде винты красивые и их больше чем нужно. Но не плавает. Ну не успели научить.

PD> Создается впечатление, что рост быстродействия процессоров несколько

PD>замедлился. Может быть, я не прав, но мне кажется, что мы подошли к некоторому
PD>пределу, и если не последует технологического прорыва, то скорость сильно расти
PD>не будет. Еще раз — может быть, я не прав. Кстати, о памяти пока в этом плане
PD>говорить не приходится.
Не согласен. Уже вверх перестали развиваться такими темпами. Зато начали развиваться вширь.(двухядерные процы)
PD> Но так или иначе — этот предел есть. Очень уж четкие физические
PD>законы здесь действуют, их не обойдешь. Раньше или позже, но бурный рост
PD>мощности ПК заменится если не стагнацией, то более или менее плавным изменением,
PD>на проценты, а не в разы.
Это только что обсуждалось в соседнем топике.

PD> Не согласны ? OK, кто из вас взялся бы написать "Turbo Pascal 1.0"

PD>образца 2005 года? Который будет работать в такой маленькой памяти — 512 Мбайт
PD>и на таком медленном процессоре с частотой всего 3 GHz ? Боюсь, что Вы
PD>потребуете для этого 16 Gb памяти и не менее 30 GHz . Вы же прекрасно знаете,
PD>какие ресурсы для чего требуются, поэтому оцените их для этой задачи и получите
PD>16 Gb и 30 GHz, А где их взять? Впрочем, нет, не потребуете. Вы даже задачу
PD>такую не поставите — Вам она и в голову не придет: Боюсь, что мы даже и не
PD>узнаем, что могло бы быть написанным, если бы это эффективно делалось...
Не забывай. Компилятор Турбо-Паскаля практически полностью написан на ассемблере. И не от хорошей жизни. А письмена на ассемблере, даже тогда считались делом излишним и слишком крутым для повседневных задач. Попробовал бы ты описать паскаль в самом паскале. Тогда бы ты точно не запихнул это в 64 кил.
А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.

PD> Ну и к чему автор призывает, спросите Вы ? К поголовному возврату на

PD>ассемблер
PD>и к 64 Кбайтам ? К отказу от того пути, по которому сейчас пошло развитие ?
Знаешь, мне как программисту хочется вернуться туда. Все было интересней. Компы знали как свои пять пальцев. Но вот как главу семейства — ни в коем случае.
Я живу в своем времени. Если понятия эффективности изменились, то я их принимаю. Я делаю программный продукт, а не поделку для удовлетворения собственного эго. Я могу написать Паскаль на 64 килобайта. Но не буду. Не потому что это сложно. Ничего сложного в этом нет. Нужно просто уметь выжимать 100 процентов из компилятора и архитектуры. Это просто никому не нужно. Времена 64 килобайт прошли. Сейчас стало легче жить. И это хорошо.

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!
Слишком абстрактно. Надо сначало описать, что такое эффективность. Именно в нынешние дни.

С уважением, Gleb.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: fplabhttp://fplab.h10.ru http://fplab.blogspot.com/
Дата: 05.10.05 11:25
Оценка:4 (2) +1 :)
E>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>>это возможно!

E>Имхо, пока за скорость разработки платят больше, чем за скорость работы заказанной программы, этот призыв останется "гласом вопиющего в пустыне".


Спасибо автору топика, за то, что вернул ко временам моей программисткой юности Присоединяюсь.
В качестве продолжения посмотрите, коллеги, вот эту статью одного ассемблерщика http://www.wasm.ru/article.php?article=onebyte. Не перевелись еще богатыри
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 06.10.05 08:01
Оценка:2 (2) +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет, оверлей — это нечто иное. Я этим на СМ-4 и ЕС-1022 занимался, это вполне легальное действие, даже ассемблер не требуется. А самоубийство только на ассемблере делалось, даже ИМХО не на ассемблере тогда, а просто в кодах.

Да уж. Я тогда маленький был. Слышал о монстрах которые для того чтобы понять программу переписывали с ассемблера на коды.

PD>Чудно. А могу я эти сервисы безболезненно удалить, и освободить Мбайт так 50-60 ? Немного — получится, а остальные, увы, обязательны для системы. А мне, в общем, все равно, как это называется, ядро или сервисы, лишь бы занимали они поменьше.

Тут конечно фигня творится. Когда новую функциональность с исправлением ошибок смешивают. Но отрицать то, что увеличение функциональности сервиспаками и требования к памяти строго пропорциональны, нельзя. Таже NT4 — с последними сервис паками мег 100 занимает оперативы. Если отрубать ненужное, то можно и сильно сократить. Вопрос только в том, что инструментов недостаточно.

GZ>>Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват?


PD>А какое это имеет отношение к тому, о чем я говорил ? Если машина загружена сверх ее реальных возможностей — конечно, ты не виноват. А вот если реальные возможности машины позволяют загрузить 10 копий твоей программы (без вордов и эксцелов), будь она эффективно написана, а она написана так, что и 3 копии тормозят — виноват ты.

Я бы не стал так говорить. Можно просто программы классифицировать:
1. Резидентные программы на машинах пользователей. Они действительно должны быть компактными, не должны забирать много ресурсов компа, и не мешать пользователю выполнять его основную работу.
2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.
3. Пользовательские программы. Наверно этот класс программ ты и имел ввиду. Вот именно это и есть путь для компромиса. И компромисс между функциональностью и ресурсами. Если функциональность нужная, и она требует достаточно ресурсов, то пользователь не будет возражать, по опыту знаю. Если в требованиях к программе не записано что попутно должны генерится сцены 3D Studio Max, то ему несложно будет выгрузить ее, или понять о том, что это была именно его ошибка. Но вот если функциональность ненужная, а требует достаточно ресурсов, то здесь и я сильно возмущаюсь(а такое на каждом шагу ). Но существует еще вопрос, что значит избыточность ресурсов? Если моя программа занимает на N мегабайт больше, и при этом я уверен что количество ошибок(которые есть будут и полностью их поубивать нельзя) значительно меньше, то я займу эти N мегабайт. В принципе, это и есть некоторая цель Net Framework. Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач. Но адаптируя избыточные ресурсы компьютера к цели уменьшить количество ошибок программ, я делаю больше для пользователя, чем таже программа — хоть и маленькая но ненадежная.

PD>Ты можешь сформулировать когда программу можно считать избыточной?


PD>Попробую.

PD>Программа избыточна, когда она
PD>1. Использует памяти больше, чем требуется.
PD>2. Загружает процессор больше, чем требуется.
PD>3. Хранит на диске файлы большего размера, чем требуется.

PD>А требуется — по характеру задачи.

Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500. Если у меня есть вариант, что адаптировав эту избыточность я повышену эффективность даже не программы. а разработки, я ею воспользуюсь.

PD>>>Или вот другой пример — с умножением матриц

GZ>>Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.

PD>Дошли до того, что здесь виной перегрузка в кэше оверхеда на класс массив.Но по мне хоть кэш, хоть процессор, хоть винчестер, хоть дух святой. Не желаю я причин знать , а просто факт констатирую — машина это может в несколько раз быстрее делать, значит и должна делать!

Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки. Правда это можно сделать за пределами Net.

GZ>>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест. А также оптимизацией памяти, если ее оказалось недостаточно.


PD>Ничего у вас не получится. Потому что эти узкие места вы, может, и найдете, а вот общий уровень все равно с оверхедом будет. Там Мбайт, здесь Мбайт — в итоге 100 Мбайт и виновных нет.

Нет. Не том и дело.
1. Если ты получил понятную программу, достаточно маленьку по исходным кодам, которую прочитает любой ребенок, и которая представляет вверх искуства программирования на ООП, это совсем не значит что она есть эффективна в плане использования памяти и процессора. Даже сказал бы наоборот. Но вот то, что в ней ошибки локализованы, сопровождать ее легко — это факт. После этого ее доводят до требуемого уровня производительности. Это делается легко, поскольку дизайн программы легко сопровождаем. Но это приводит к усложнению дизайна программ. А иногда и архитектуры.
2. Если ты начал предполагать в процессе построения программы, что вот здесь есть узкое место, которое написать оптимально, то
Во — первых, ты можешь ошибиться, это происходит часто, особенно на уровне конкретного программиста большого проекта. Например предположил что здесь надо бы переписать чтобы использовалось значительно меньше тактов процессора, но оказалось что сюда программа зайдет только один раз. И нагрузка на проц, в данный момент никого не волнует. Или когда компилятор делает оптимизацию за программиста, но он об этом не представляет, и тратит даром время при этом мешая компилятору. Это хорошо проявилось например в разности времени здесь
Автор: Serginio1
Дата: 29.09.05
. Оптимизация вполне корректна со стороны программиста, только компилятор уже это сделал.
Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.

Вобщем, мое мнение, что оптимизация программ по используемым ресурсам, должны проходить в 3 плоскостях:
1. При построении архитектуры. Мы еще видим все проблемы в комплексе, и наиболее крупные можем сразу решить.
2. Алгоритмическая оптимизация. Неэффективный алгоритм на порядки хуже неоптимизированного кода.
3. Оптимизация готового продукта под конкретные требования пользователя. Свое мнение я уже описал.

PD>А у ICQ вообще когда-нибудь не-беты были ? У меня что-то впечатление такое, что она только из бет и состоит

Нет, еще альфы. По моему — релизы там не бесплатные. Хотя могу ошибаться.

GZ>>Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы.


PD>Пользователь доволен. Вполне. И если он у тебя один — решай с ним все проблемы. А вот когда речь о продуктах, используемых в миллионах копий идет — тут задавать вопрос, доволен ли пользователь — все равно, что спрашивать, оуениваете ли вы положительно работу ГосДумы . Отдельно одной программой доволен, другой — доволен, третьей доволен, все вместе запустишь — недоволен. Жалуйтесь кому хотите, хоть господу богу.

Пользуйся альтернативами Я понимаю что в случае крупных монополистов — такое плохо проходит. Слишком высока сложность программ. Но нельзя так говорить о всей отрасли. Пользуются же мирандой вместо аськи.


PD>Бывает и такое. Как в известном анекдоте, как ни собираю, а пулемет получается. Но почему аналогия неуместна — не понял.

Потому что важно чтобы летал, а не с той скоростью которую пользователь не заказывал. В старое время бесшабашных программистов одиночек, они могли плавать, и даже нырять. Но летать не получалось. Сам такие программы писал, грешен.
Так что главное достигнуть цели. Если цель не достигнута, то уже ничего не важно.


GZ>>А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.


PD>Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ?

Да. Я вполне представляю весь процесс сооружения такой программы. Если ты потратил время на то, чтобы адаптировать решение на меньшие ресурсы, когда я знаю что ресурсы заказчика(или предполагаемого заказчика) значительно больше, то безусловно. Ты проделал работу, которая никому не нужна. Мало того, ты усложнил сопровождение программы. Для программ класса серверов приложений — я не вижу исключений из этого правила.

С уважением, Gleb.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Dyomahttp://www.livejournal.com/users/dyomap/
Дата: 05.10.05 13:57
Оценка:1 (1) +3
Здравствуйте, savaDAN, Вы писали:

DAN>Давайте разберемся с критерием "насколько это возможно", судя по тому что подход используемый в индсутрии выраженный владом: "оптимизируй только там где это необходимо" смею предположить что вы проповедуете подход "чем больше тем лучше"?


Я абсолютно согласен с ортимизацией "где надо", речь не об этом. В исходном посте посте говорилось о тенденции, о появившихся привычках и том, что понятие "оптимальный" просто забывается, уходит вслед за 1Mhz компами и 640Кb памяти. И что эта тенденция очень может выйти боком в свете физических пределов GHz и Gb.

Dyoma
ALMWorks
http://deskzilla.com/
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Cyberax 
Дата: 06.10.05 10:06
Оценка:1 (1) +2 :)
Дарней wrote:

> Научить обычного, не озабоченного "оптимизацией-везде-где-можно"

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

Кто сказал, что хороший оптимизированый код — непонятен? Код той же
Miranda читается без всяких проблем, хотя она и не жрет мегабайты.

> Потому что второй всегда будет искать, как в .NET обнулить поля

> структуры с помощью ZeroMemory (да-да, это намек ) — вместо того,
> чтобы проектировать архитектуру. Да еще и считать окружающих идиотами,
> потому что они не понимают, как же это важно — обязательно залезть на
> нижний уровень по самый локоть.

Опять же, оптимизация — это не значит копание в машинных кодах. Нужно
просто следить, чтобы не было явных ляпов, где время/память тратится зря.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[3]: Нет уж, позвольте! в избранное  новое    модер.  /!\
От: mrozov 
Дата: 05.10.05 13:58
Оценка: +2 :))
Да в чем же я ошибаюсь? Везде, где это возможно, все стараются делать проще, а не эффективнее.

Причины непереписывания на .net word-а по-моему очевидны. К неэффективности .net никакого отношения они не имеют.

И вообще — я бы поставил вопрос иначе — пока ратующие за эффективность кода будут ковыряться в своем низкоуровневом коде, использующие windows forms (или VB) коллеги будут успешно сдавать заказчику один проект за другим. Замечу — результат их труда неизменно будет отвечать заявленным требованиям по эффективности.

Поделюсь одним жизненным наблюдением.

Моя фирма использует в своей работе инструментальные средства и подходы, по сравнению с которыми между .net и машинными кодами разницы почти не заметно.

Как-то раз пути одного из наших проектов пересеклись с проектом некой третьей фирмы, которая все по-мужицки делала на с++. Год за годом, версия за версией. Они с этого проекта, собственно, и кормились (насколько я понимаю).

Когда руководитель группы разработки этой фирмы во время сравнительных испытаний возможностей их системы и того, что было сделано тремя нашими разработчиками за пол-года, увидел наш вариант — у него натурально дрожжали руки. У человека началась форменная истерика — потому что от очень четко понял свое место в этой жизни. И место своего подхода к разработке ПО, соответственно.

Кесарю — кесарево, а слесарю — слесарево. И пытаться привинтить к прикладному программированию высокие идеалы экономии бесценной conventional памяти — не стоит.
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Dyomahttp://www.livejournal.com/users/dyomap/
Дата: 06.10.05 09:40
Оценка:79 (3)
Здравствуйте, Pavel Dvorkin, Вы писали:

D>>А как вам вот такой тезис, что программа просто должна быть достаточно xxx?

D>>Не надо выделять потребляемую память и быстродействие в отдельную категорию. Программа должна быть достаточно во всем и, в идеале, одинакого. Далее неупорядоченный список: достаточно функциональна; достаточно удобна; достаточно устойчива; достаточно мало жрать память; достаточно быстро работать;

PD>Если бы мы были в однопрограммной системе — готов согласиться. А в многопрограммной — нет. Потому как отдельная программа может быть вполне достаточна, а все вместе они едят ресурсов немеряно и тормозят.


PD>Кстати, сформулируй критерий достаточности, если можешь.


Для начала честно признаюсь с неспособности его сформулировать, но могу показать, где как я думаю стоит его искать в конкретных случаях.
Во первых полностью согласен с мыслями
Автор: GlebZ
Дата: 06.10.05
Glebz о достаточной оптимальности. Особенно с его классификацией и походом к оптимизации.

Далее предлагаю забыть о том что работа это не только возможность кушать, но еще и сточник кайфа и способ "поддерживать форму". И посмотреть на "достаточно" только с точки зрения бизнеса.
Во-первых наше место в делании денег на софте: Делает их кассир, в тот момент когда приходит покупатель. А приходит он потому, что отдел PR удачно прорекламировал продукт и покупатель не только узнал, но еще и решил купить. А вот теперь наше место — помочь PRщкам делать свою работу лучше. Если бизнес делается не на продаже софта, немного меняются детали моего рассуждания, но общая идея таже — наше дело делать софт, достаточно востребованный пользователем. Достаточно в смысле бизнеса.
Теперь, кто же тот самый пользователь, для которого надо быть достаточным? Ответ — тот же для кого стараются PR. Тут пользователи делятся на две группы:
1. Кто уже выбрал. Их надо удержать, новая версия (патч) должена быть достаточна, что бы пользователь не взял другой продукт и должена быть выпущена достаточно быстро.
2. Кто про продукт знает, но не пользуется. Соответственно достаточно чтобы потенциальный пользователь стал действительным.
Ксати предположения о target group и цене на продукт могут очень помошь всести многопрограммную систему к "квази" однопрограммной.
Сколько ресурсов у предполагаемого пользователя? Какие сколько из них заняты его типовыми программами? — Остальное только для нас
Сколько пользователь заплатит за наш софт? А сколько за апгрейд, что бы не тормозил?
Девелопер должен думать о том как с наибольшей пользой потратить свое рабочее время. В частности, если плохо известно для кого стараемся, то очень может быть, что стоит вообще ничего не кодить, а узнать это.

Возможна ситуация, когда начальник имеет другое представление о приоритетах (в просторечие — начальник дурак ), а рассматриваем мы ситуацию с позиции хорошо покушать, и удовлетворить вообще-то надо начальство. Тут два варианта (кроме увольнения). Донести свое видении до начальства. Или получать кайф от качественного выполнения заказанной работы, в конце-концов, может он и прав и в любом случае это его ответственность.

PD>Удобство UI прямого отношения к эффективности обычно не имеет. А вот чистота и последовательность архитектуры отнюдь не требует применения неэффективных методов. Скорее наоборот — скажи кратко, но хорошо (К. Прутков)


Не соглашусь по обоим пунткам. Тривиальный пример — это выбор платформы (процессорный код vs VM, различные языки — различного качества компиляторы/VM`ы).
Архитектура может быть достаточно гибкой для оптимизации, но при этом излишне сложной, если оптимизация не потребуется. И наоборот, очень удобной, но местами эффективные решения придется делать кривостью. В первом случае получаем много скорости мало фич, во втором — наоборот. Конечно замечательно, когда "кратко, но хорошо", но бывает озарение не пришло...
C UI теже проблемы. Все время стоишь перед выбором, усложнять реализацию или использовать не эффективные решения. Например, хочу показать всегда актульную информацию -> паттерн observer -> что наблюдаем? И тут часто оказывается, что следить за всем подряд существенно проще чем только за тем, что необходимо. А если завтра после небольших изменений необходимого станет больше?

Dyoma
ALMWorks
http://deskzilla.com/
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: Dyomahttp://www.livejournal.com/users/dyomap/
Дата: 05.10.05 12:39
Оценка:76 (2) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не

PD>слишком думая об эффективности, а потом узкие места можно оптимизировать.
PD>Теоретически — совершенно безупречное рассуждение. А практически — это
PD>верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
PD>или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
PD>потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
PD>5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
PD>бы — что тут оптимизировать? Так и должно быть, все нормально сделали!

А как вам вот такой тезис, что программа просто должна быть достаточно xxx?
Не надо выделять потребляемую память и быстродействие в отдельную категорию. Программа должна быть достаточно во всем и, в идеале, одинакого. Далее неупорядоченный список: достаточно функциональна; достаточно удобна; достаточно устойчива; достаточно мало жрать память; достаточно быстро работать; если проект после 1.0 не планируется отправить в архив то достаточно сопровождаема; и т.д. А скорость эскадры равна скорости самого медленного корабля.

Я ни в коем случае не призываю не думать об эффективности, не искать всегда и везде лучшие подходы и алгоритмы. Я предлагаю не думать об этом больше/чаще, чем о, например, удобстве UI или чистоте и последовательности архитектуры. Не забывать, что как бы быстро прога не работала, она будет бесполезна, если пользователь не сможет решить с ее помощью свои задачи.

Что касается непонимания в глазах начинающих, то это непонимание бывает в всех вопросах и оптимальность далеко не единственный из них, хотя, похоже, для Вас лично, самый больной. Но тут для того и нужен Учитель, что бы проводить Ученика его (Ученика) путем в ближайший тупик и... оставить его там подумать.

Dyoma
ALMWorks
http://deskzilla.com/
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: Centaur 
Дата: 05.10.05 16:25
Оценка:75 (3)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!

Читал. Плакал. Вспоминал статью Саттера “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software” — там тоже про то, что закон Мура уже не тот, что был раньше

Однако, в наше время таки оптимизировать всё до последнего байта есть непозволительная роскошь. Моё время как разработчика несравненно дороже времени процессора и оперативной памяти.

Я приведу пример из собственного проекта. У меня есть изображения букв в матрице 32×64, и время от времени мне приходится сравнивать их с генерируемыми в процессе работы программы изображениями в аналогичной матрице. Если бы я не поддался на идею коллеги закодировать каждую строчку пикселов DWORD’ом, и хранил их в 8-битных bitmap’ах — у меня бы для сравнения использовалась библиотека Intel Performance Primitives, тщательно вылизанная разработчиками из Intel’а под все их процессоры. И по скорости, я уверен, это было бы быстрее, чем написанные моими не идеально прямыми руками циклы. И в части внедрения изменений в код это было бы более поддерживаемо, чем эта побитовая арифметика и магические функции подсчёта битов в двойном слове.

Пишите свои программы понятно, господа! Если использование показывает, что память — узкое место, найдите 10% кода, которые используют 90% памяти. Если использование показывает, что узкое место — процессорное время, найдите 10% кода, которые работают 90% времени. Premature optimization is the root of all evil, хотя и premature pessimization тоже is the leaf of no good.
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: Nickolay Ch 
Дата: 29.10.05 07:23
Оценка:45 (2) +1
PD>+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.

Исходим от затрат, часто гораздо дешевле поставить еще один сервер.

PD>Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше.

Если Вы будете писать это дольше то "лучше" это не будет скорее всего. Опять слова "эффективность", "лучше".
В чем измеряеться Ваша "эффективность", в чем измеряется Ваше "лучше"?
В разных контекстах они могут означать противоположные или просто разные вещи.
>А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам.
Зато это достаточно трудно обнаружимые баги, ибо не всегда вы за несколько минут найдете, откуда память потекла, а битый указатель может проявится совсем не в том месте, где его "сломали". Это могут быть вполне разные программные модули. Если машина помогает избавиться от технических багов, почему б не использовать эту возможность?

PD>Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.


Кто определил сколько программе "в действительности нужно"? Бог Программистов? Опять какие то непонятные идеалы? Аппелирование к абсолютным истинам? Их несуществует, тем более в программировании, имхо.


PD>Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.

PD>Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.

Закон рынка — пока клиент готов платить, пусть платит.
Какое мне дело до того сколько они платят, если они готовы это делать? Главное, что мои доходы от этого повышаются.
Извините за некскромность, вы боретесь за какую то абсолютную правду?


PD> Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.

Вот когда будет известно что, то и можно говорить о "лучшем решении". Опять же, никто не запрещал юзать разные технологии в одном проетке, адекватные конкретной подзадаче проекта.
И, главный, имхо, вопрос: А зачем вам убеждать заказчика? Что лично ВЫ(ваша команда, компания) от этого получает? Прошу не воспринимать это как наезд, это вопросы, которые я бы сам себе задал, если б пришлось убеждать в чем то заказчика. Кстати говоря, заказчик не всегда знает, что ему конкретно надо, для этого есть этап сбора требований

PD>Ничего ты не соптимизиуешь. Не ты лично, а те, кто к эффективности не привык. Им и в голову не придет, что это все на 20 Мб может меньше требовать.

Уже было выше, им это прийдет в голову, когда начнут падать продажи продукта и клиенты побегут к конкурентам. Рынок — саморегулируемая система.
Re[6]: Нет уж, позвольте! в избранное  новое    модер.  /!\
От: kwas 
Дата: 06.10.05 19:23
Оценка:27 (1) :))
Здравствуйте, McSeem2, Вы писали:

MS>

Our prototype is up and running in C#, and we are now porting to C++.

MS>К чему бы это?

К тому, что C# — это язык для создания хороших прототипов?
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Re[45]: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 01.11.05 12:35
Оценка:6 (2) +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хотел было прекоатить — так не получается.

PD>Твое ? Тогда смотри дальше.
Да.
PD>Где здесь дают эту самую длину ? Ответь, пожалуйста.
Я показывал. Павел, я уже начинаю уставать. Я попросил тебя дать примеры того, откуда берутся строки без длины. Ты привел пример с едитом — неправда, он отдает длину. Ты утверждал, что даже если бы длина была, все равно ее пришлось бы вычислять — неправда, есть невычисляющие конструкторы. Теперь мы наконец переходим к той части аргументации, которая не является банально неверной.

PD>Где длина строки в текстовом файле ? Где она там хранится ? Там нет и нуля, конечно — по известным тебе историческим причинам. Но ограничитель там есть. (0D0A).

Ну и что? Как это нам помешает получить длину? Достаточно сделать вот так:
long initialPosition;
long finalPosition;
initialPosition = ftell(stream);
char line[4000];
fgets(line, 4000, stream);
finalPosition = ftell(stream);
int len = finalPosition - initialPosition;

Вуаля! У нас есть длина строки от fgets без вычисления.
PD>Где она после того, как fgets вернула строку?
В указателе файла, с которым работала fgets.
PD>Если мы будем делить источники на основные и неосновные, то спор уйдет в никуда.PD> Ты приводишь случаи, когда ее дают. Я — когда нет. Для того, чтобы ты был прав — необходимо, чтобы давали всегда. В противном случае твое утверждение необоснованно. Теорема, для которй есть хоть один опровергающий пример, опровергнута.
Павел, именно этим и отличается академический подход к разработке программ от прикладного. С прикладной точки зрения совершенно несущественно существование источников, которые передают информацию с потерями. Важнее — возможность воспользоваться нормальными источниками. Напомню, что ты пока не дал ни одного примера источника, который бы не позволил получить информацию о длине строки, кроме консоли.

Что это означает? Что пока что полезность строк без длины сводится к программам, интенсивно работающим с консолью. Все остальные программы, получается, только выигрывают от наличия длины.

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


PD>Нет. Они нужны для передачи этих строк в качестве входных аргументов этих самых винапи функций.

Да-да. Я и говорю — см. выделение.
PD>Я, кстати, об этом написал, но ты предпочел на эту часть моего письма не ответить, а просто выкинуть ее. Можешь все же ответить?Формулирую прямо

PD>Если в винапи используются строки с длиной, почему почти ни одной функции винапи эта длина не передается ? Почему они принимают только char* (wchar*) и вычисляют эту длину у себя внутри сами ?

Значительная часть функций винапи придумана около 20 лет назад. Конечно, далеко не все из них были продуманы. В некоторых из этих функций длина просто не очень-то и нужна — вполне можно построить достаточно эффективный алгоритм и без нее. По крайней мере, достаточно эффективный в большинстве случаев. Ну вот как в PathCombine. Длина им не нужна — я и так могу спорить, что они просто тупо копируют строки одна за другой в отведенный буфер, почти как strcat. При этом они проверяют, не наступили ли на ноль в конце этого буфера, в целях безопасности. В случае передачи буфера недостаточной длины мы узнаем об этом гораздо позже, чем в случае строк-с-длиной. Но этим явно можно пренебречь — вряд ли имеет смысл оптимизировать производительность обнаружения ошибок.

PD>И как следствие из этого — еще один вопрос


PD>Почему, если они так делают и это правильно — когда я это делаю, это неправильно ?

Из неверной посылки следует все что угодно. Они так делают и это неправильно.
PD>Их выход — мой вход, мой выход — их вход.

S>>Действительно, в ВинАПИ есть функции, которые не позволяют получить длину строки без доп. затрат (как правило, в таких случаях можно получить точную верхнюю границу длины строки — а это позволяет нам все еще писать безопасные, хотя и не столь эффективные, алгоритмы).


PD>Хм, а ведь в том примере, с которого весь сыр-бор разгорелся (с sprintf) я же битый час доказывал, что у меня есть эта самая точная верхняя граница.

Это какая? У тебя не было никакой верхней границы. У тебя была наивная вера в существование верхней границы. А когда я говорю про точную верную границу, я говорю вот про что:

Допустим, мы воспользовались функцией fgets:

void main( void )
{
   FILE *stream;
   char line[100]; // ВНИМАНИЕ! У нас буфер размером в 100 символов

   if( (stream = fopen( "fgets.c", "r" )) != NULL )
   {
      if( fgets( line, 100, stream ) == NULL) // какое совпадение - здесь тоже n = 100
         printf( "fgets error\n" );
      else
         printf( "%s", line); // и это означает, что здесь line не длиннее 100! 
            // добавим строчку в пример MSDN:
            char line2[30];
            fgets(line2, 30, stream);
            char line3[40];
            fgets(line3, 40, stream);
      fclose( stream );
   }
}

Итак, здесь мы имеем точную верхнюю границу для суммы всех длин: она равна, очевидно, 168. Мы можем спокойно использовать для конкатенации буфер этого размера. Не потому, что где-то в БД (внешней по отношению к нашей программе!) есть размер поля, и не потому, что оператор поклялся не засыпать на пробеле, а потому, что выполняются некоторые инварианты. Функция fgets так удачно написана.

PD>Но это вызвало твою негативную реакцию. Получается, коль винапи функции могут эту границу дать или ты как-то иначе оценить можешь — им доверять можно, а если я их даю — так нельзя ? Почему ?

Потому, что ты свое значение границы высасываешь из пальца, а винапи поддерживает с математической точностью.

PD>Охотно допускаю, что он не менее эффективен. Но какое это к делу имеет отношение ? И винапи PathCombine можно переписать, добавив ей длины и сделав безопасной. Но этого нет. В винапи. А то, что это есть или может быть в C# — я и не спорю.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Об эффективности программ в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 18.10.05 12:41
Оценка:3 (1) :))
Здравствуйте, Pavel Dvorkin, Вы писали:

Д>>кстати говоря, во многих серьезных конторах за использование любой функции из семейства printf нещадно бьют по рукам. И даже более серьезно — по кошельку.


PD>А это от ситуации зависит. В том проекте, в котором я участвовал, мне все было разрешено, кроме одного — низкой скорости работы. Занял бы на диске лишний Гбайт — простили бы. ОП использовал бы в 2 раза больше, чем надо — тоже простили бы. А вот уложиться я должен был в 100 мсек. Кровь из носу. Потому что если 200 мсек займет — это кончится просто тем, что данный образец будет снят с обработки по нехватке времени, а тем самым число необработанных образцов увеличится. А обрабатывается таких образцов в день примерно 30,000 только на одной машине, и на каждый образец дается не более 3 сек. И за это время к моему ПО делается 10-15 запросов плюс, естественно, то время, которое нужно на оставшуюся часть, а оно есть примерно 60% общего времени. А машин примерно 1000. Борьба шла за каждый процент. И мне все прощалось, только бы быстрее. И сделал я им вместо 100 мсек 20-30 мсек, и были они в полном восторге


PD>А лишних Гбайтов я , кстати, не использовал. И лишней ОП — тоже. Ну разве что самую малость — буфер там был один с запасом в 64 Кбайта


Зато как же обломно после таких проектов формочки на JSP рисовать и SQL запросы сочинять!
Блин, словами не передать.
Зато антураж какой! Рефакторинг, юниттестинг, код ревью, баг трекинг, UML, XML, SQL,... память нынче не ресурс... давай, давай, сроки горят... память нынче не ресурс... давай, давай, все должно было работать еще вчера... память нынче не ресурс... Об эффективности программ
Автор: Pavel Dvorkin
Дата: 05.10.05
... Re: Об эффективности программ
Автор: McSeem2
Дата: 06.10.05
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: ZevS 
Дата: 05.10.05 10:57
Оценка:2 (2) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

<...>

Подписываюсь под всем, почти.

Просто, как говорится, кто девушку обедает — тот ее и танцует. И в разработке ПО, бог — заказчик. А ему, насколько я знаю, зачастую не нужно наилучшее решение, ему нужно, чтобы быстро, более-менее качественно, документированно, сопровождаемо...
Re: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: _Obelisk_http://www.ibm.com
Дата: 05.10.05 12:44
Оценка: :)))
Здравствуйте, eao197, Вы писали:


E>Вот тогда наступит наше время.


Тогда нас уже не останется. И никто не будет знать как писать простые и эффективные программы...



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 06.10.05 10:19
Оценка: +2 -1
Здравствуйте, Cyberax, Вы писали:

C>Кто сказал, что хороший оптимизированый код — непонятен? Код той же

C>Miranda читается без всяких проблем, хотя она и не жрет мегабайты.

А кто вообще сказал, что он такой уж оптимизированный? Если ты прикрутишь к ней кучу плагинов, чтобы сравнять по всем функциям с аськой — уверен, жрать она будет ничуть не меньше. К тому же глючит она не по детски — хотя и сам ей давно пользуюсь, ибо перегруженная ненужными функциями аська меня совсем достала.
Так что — за всё надо платить.

C>Опять же, оптимизация — это не значит копание в машинных кодах. Нужно

C>просто следить, чтобы не было явных ляпов, где время/память тратится зря.

Ты можешь точно сказать, где проходит граница между "явными" и "неявными" ляпами?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: Nickolay Ch 
Дата: 06.10.05 10:59
Оценка: -3
Здравствуйте, Pavel Dvorkin, Вы писали:

<Тут много философский рассуждений>

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

Уважаемый mrozov правильно написал, что времена любителей позаниматься сексом с компом прошли в индустрии программирования. Энтузиастам и "вольным художникам" не место в индустрии.
Все вышенаписанное — мое имхо.
Re[12]: Об эффективности программ в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 07.10.05 13:04
Оценка: +2 :)
Здравствуйте, srggal, Вы писали:

S>ЗЫ ОЛЛ прошу извинить фривольный стиль, просто, я отчего-то веселый такой Сыну сегодня пол-года


Поздравляю!

А в форуме-то ты сейчас чего делаешь?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 07.10.05 18:29
Оценка: +3
mrozov,

> ПК> Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.


> <...> Не думаю, что стоит вот так категорично говорить о том, что вам должны инструментальные средства.


"Они мне должны" в простом понимании: если средства не соответствуют упомянутому критерию, я им предпочитаю имеющиеся альтернативы, предоставляющие больше возможностей программистам, у которых с ДНК все в порядке, а не облегчающие жизнь тем, у кого в ДНК проблемы в ущерб первым.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[10]: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 19.10.05 04:49
Оценка: +3
Здравствуйте, srggal, Вы писали:

S>Так вот во Франции гдн-то в средние века проверяли жениха ( в приличных домах дворянского сословия ), претенденту подавали спелый персик, который он должен был съесть именно фруктовой вилкой и ножом, не теряя собственного достоинства, и непринужденно ведя светскую беседу с будующими родственниками.


В "приличных домах дворянского сословия" людям больше нечем заняться, кроме как заботиться о "сохранении своего достоинства". Потому что работают за них другие. Вот они и придумывали специальные вилки для фруктов, специальные вилки для рыбы и правила, как всё это дело следует употреблять (и не дай бог кому-то взять не ту вилку — фи, как некультурно!).
Нормальные же люди едят так, чтобы было удобно, а не чтобы произвести впечатление на окружающих.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[20]: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 19.10.05 06:44
Оценка: +3
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну и что ? Это лишь говорит о том, что они неверно оценили максимальный размер, только и всего.


PD>Вот давай так


PD>char szTotal[500];

PD>sprintf(szTotal,"%s %s", szFirstName, szLastName);

PD>Программа делается для России. Приведи ситуацию, в которой здесь возможен buffer overrun. Фамилию и имя, please , в студию.

Очень просто. Этот код вызывается из обработчика веб формы регистрации пользователей. Злонамеренный пользователь вводит килобайт мусора. После чего твое CGI приложение делает core dump. Это называется уязвимость.
Еще более злонамеренный пользователь вводит килобайт специального мусора, и твое CGI приложение вносит нужные изменения в системные настройки, а уже потом делает core dump. Это называется эксплойт.
Продвинутый злонамеренный пользователь пишет плагин к известному сканеру сетей, который находит все инстансы твоего приложения в указанном IP — диапазоне.
Таоя компания попадает в списки рассылки "смертельно опасные уязвимости", и ее продукт попадает в черный список. Это называется "банкротство".

Дальше продолжать?
В таком сценарии оказывается значительно дешевле вовремя уволить того, кто использует подобный код, чем любая из альтернатив:
— оплачивать расходы от невовремя обнаруженной уязвимости
— нанять специальных людей, которые станут тестировать твою систему на предмет наличия подобных уязвимостей.
PD>Ну и что, опять-таки ? См. мой пример с nScreenArea. Может, оно когда-нибудь и грохнется, на 4ГПикс дисплее.
Еще раз: то, как оно грохнется от целого переполнения, не приведет к исполнению постороннего кода.
PD>Но не будешь же ставить под контроль все арифметические операции и на каждую из них писать try-catch из-за того, что при некорректно заданных операндах это может вызвать ошибку ?
Будешь, если тебе дорого твое место работы. Причем кэтчить все места тебе не потребуется: как только придет информация о том, что где-то твое приложение упало, ты получишь нормальный стек трейс, в котором ясно будет указано место падения.
Это позволит тебе очень быстро (по сравнению с анализом дампа) локализовать причины, и либо переписать код (например, используя long вместо int), либо вставить в нужных местах проверки (например там, где принимаются размеры).
PD>Если да — то неудивительно, что это будет работать очень медленно. А если нет — то при работе однажды произойдет unhandled exception, и аппарат рухнет.
PD>Нет. Не догадываюсь. Потому что любая ошибка может привести к любой наведенной ошибке. А если ты хочешь сказать, что при этом будет неопределенное поведение — так и при неправильных результатах будет то же, не только при выходе индекса.
Нет. Выброс исключения — это НЕ непределенное поведение. Это вполне определенное поведение, которое

PD>А вообще основное различие между моей и твоей позицией ИМХО в том, что ты хорошо знаешь некоторые общепринятые принципы, но рассматриваешь их как догму, которую нельзя переступать, как сказал Sinclair, под страхом смертной казни. Я же считаю, что при определенных условиях может случиться так, что делать придется, нарушая многие общепринятые правила, если это нужно для решения задачи и другого выхода нет. В конце концов лучше написать работающую программу не по правилам, чем по правилам ничего не сделать.

Ты не прав. Если влезть в исходники .Net, то можно увидеть и unsafe, и unchecked. Как раз для того, чтобы поднять производительность. Это не переступание догм, это подробное следование им. Потому, что отмененные такими опциями проверки делаются вручную. Сделать правильную программу быстрой легче, чем быструю — правильной.

Потому, что обо всех небыстростях тебе расскажет профайлер, а о неправильностях — пользователи и хакеры.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 23.10.05 16:18
Оценка: -3
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет. Я просто удивляюсь, что эти ситсемы используют алгоритмы, в которых вместо одного прохода требуется 3, вместо одного блока памяти — 2 и т.д. И мне говорят, что при этом повышается читабельность и легче сопровождение и т.д. Вот это я не понимаю и не принимаю.


Слушай, брось программировать. Береги нервы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[14]: Об эффективности программ в избранное  новое    модер.  /!\
От: Andrei N.Sobchuckwww.smalltalk.ru
Дата: 26.10.05 12:26
Оценка: :)))
Здравствуйте, GlebZ, Вы писали:

GZ>Я бы туда запихнул Миф 9 — Рефакторинг увеличивает производительность кода. Строго наоборот. Он в подавляющем числе случаев уменьшает производительность кода.


Ага. Можно даже закон вывести: для любой программы А, можно написать программу A', которая будет работать медленнее программы А.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Нет уж, позвольте! в избранное  новое    модер.  /!\
От: McSeem2http://www.antigrain.com
Дата: 05.10.05 15:51
Оценка:16 (2)
Здравствуйте, Cyberax, Вы писали:

C>Ну значит плохо на С++ писали. У нас была обратная ситуация — группа

C>С#истов полтора года делала приложение. Оно у них работало, но медленно
C>и не особо устойчиво (подумаешь, пара исключений при запске — ничего
C>ведь не падает).

C>Поэтому когда мы выкатили заказчику примерно такой же продукт с

C>поддержкой OLE2 (то есть наши документы можно, например, в Word
C>вставлять) — старое приложение торжественно удалили.

А вот слова Matthew MacLaurin из Microsoft MSX group, который зовет меня туда работать:

The project is an advanced, small-team product – an information manager for the internet age. We started it in research and are now going to ship it. It uses queries as the primary organizational construct – letting users easily build and manipulate queries as first class objects, etc. It also emphasizes tagging and distributed information. We’ve put a lot of work into a very elegant and polished user interface with translucency, drop shadows, seamless compositing everywhere, etc. Our prototype is up and running in C#, and we are now porting to C++.

К чему бы это?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[9]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 07.10.05 11:17
Оценка:15 (2)
Здравствуйте, gear nuke, Вы писали:

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



GN>Когда-то спросил старого программера, как писать оптимальные программы. Я то думал, вопрос с подковыркой (оптимизировать по скорости или по размеру можно). А он ответил просто: "упрощай их".


Хотел я в исходном постинге напомнить про один принцип. Потом решил, что введет ненужную игривость

KISS — Keep It Simple, Stupid!
With best regards
Pavel Dvorkin
Re[10]: Об эффективности программ (уровень языка) в избранное  новое    модер.  /!\
От: alexeiz 
Дата: 07.10.05 18:14
Оценка:13 (2)
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Кстати, для C++ Степановым в свое время даже был написан набор их 13 тестов, меряющих так называемую abstraction penalty. Для современных компиляторов (Intel C++, Visual C++) abstraction penalty в соответствии с этим тестом, если и проявляется, то "плавает" в пределах единиц процентов.


Вот похожая штука для контейнеров в исполнении Страуструпа: http://groups.google.com/group/comp.lang.c++.moderated/msg/731a399cb149e0df
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 06.10.05 11:46
Оценка:11 (2)
Здравствуйте, Pavel Dvorkin, Вы писали:

GZ>>2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.


PD>+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.

Тут я забыл указать некоторый термин. А именно масштабируемость. Как-то повелось, что каждый смотрит на этот термин со своей колокольни, но рискну дать определение. Масштабируемость — способность увеличивать КПД программы в зависимости от аппаратных средств. То есть, вместо того, чтобы переписывать программу когда не стало хватать пропускной способности, заказчику достаточно купить дополнительную память, или дополнительный процессор, или дополнительный компьютер для кластеризации приложения. У масштабируемых решений практически всегда присутсвует одно свойство. Оно всегда медленнее их немасштабируемых аналогов. Если один или два пользователя, то немасштабируемое приложение масштабируемое порвет как грелку. Но масштабируемость это не просто лейбл. Это действительно очень полезное средство для пользователя. Хреново когда придется переписывать программу, или заказывать другую. И дело не только в деньгах. Дело еще в обучении пользователей для нового продукта, проходить весь цикл установки и настройки. Поэтому использование аппаратных средств — важное свойство серверов приложений.
Архитектор обязан следить за масштабируемостью серверов. Вот если он не следит, то это значит недоучка. Ну а недоучки — это тема других топиков.

PD>Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше.

В данном случае да. Но можно сделать и так, в случае большого объема приложения, написать основную программу на Net Framework, а наиболее криминальные алгоритмы написать на unmanaged C++(благо он лучше умеет использовать и управлять ресурсами компьютеров).

PD>А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам.

Да. И это правда. Не все сводится к мемори ликам. Компонентность тоже провоцирует не делать ошибок. А если приложение большое и многофункционально, то недооценивать компонентность нельзя.
Кроме того, тут стоит говорить не только о Framework, но вообще о языках высокого уровня. Не секрет, что язык высокого уровня генерит избыточный код и избыточно использует память. И чем выше язык, тем труднее поддается оптимизация кода компилятором. В принципе, если взять тот-же STL, то говорить о том, что он по скорости 1 в 1 с кодом написанным вручную на С не приходится. А string вообще кошмар, но зато жутко удобный. И только великолепие и сложность компилятора более менее выравнивает ситуацию.

PD>От ошибок алгоритма меня никакой FrameWork не защащает. Складывать килограммы с метрами (вместо того, чтобы умножать) и там вполне можно, .

От этого никто не сможет защитить. Особенно от непроффесионализма. Но тут никто не властен.


>>Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач.


PD>Я бы эту фразу перевернул.

PD>Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.
Фразы не эквивалентны.
Вообще я бы сформулировал свое мнение так. Функицональность возрастает, и аппаратная часть адаптируется под нее. Или наоборот, аппаратная часть возрастает, и функциональность адаптируется под нее. Не важно какая из них верна.

GZ>>Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500.


PD>Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.

А это уже прямой путь в леса богатые дичью. Поверь мне, везде где я работал всегда думали о компьютерах пользователей. Иначе прогоришь.

>>Если у меня есть вариант, что адаптировав эту избыточность я повышену эффективность даже не программы. а разработки, я ею воспользуюсь.


PD>Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.

Обычно если заняла, то использует Если не использует — то это ошибка. Если избыточно использует — ошибка алгоритма.
Пользователей больше занимает полезность программы.

GZ>>Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки.


PD>Да ведь нам говорят, что .Net — генеральная линия развития, а те, кому она не нравится — неандертальцы. Вот и мне сегодня заказчик сообщил, что планирует нечто на .Net. Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.

Ты сам аргументировать не можешь. Если это сложная программа с множеством взаимосвязей и сложной архитектурой, то да. Это будет хороший выбор. Аналог в виде Java — не сильно отличается.

PD>"У нас никогда нет времени на то, чтобы сделать все как следует, но всегда есть время на переделки"

В сложной программе с множеством модулей, взаимосвязей и народа который все это пытается связать — сразу сделать как следует невозможно. Также как написать программу без багов, это должна быть очень простая задача.

PD>Ну и заявление! Дизайн понятен, сопровождение легко, след-но, оптимизировать будет несложно! А то, что для оптимального решения задачи, возможно, надо не в деталях оптимизировать, а все решение пересмотреть и весь дизайн переделать — это ты не допускаешь ? Совсем другим способом ее решать!

Это — ошибка архитектуры. Тяжелая ошибка. Ее боятся. К ней надо по правильному подходить, либо работать методиками которая не подразумевает первоначальное построение архитектуры(типа XP). Все ХР и построено на том, что функционал достраивается, а следовательно нужен понятный и сопровождаемый дизайн. Ради этого рефакторят. И основным свойством кода является не эффективность в плане выполнения, а именно сопровождаемость. Эффективность в плане выполнения — выравнивают потом. Там вообще не знают и не хотят знать, войдет ли или не войдет данная функциональность в том виде в котором она разрабатывалась на начальном этапе.

GZ>>Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.

PD>ИМХО это лечится рано или поздно, а первое — не всегда.
Как раз ошибки вылечить на порядок сложнее. А иногда и невозможно. В непонятном коде значительно сложней найти и локализовать ошибку. Иногда этот код легче переписать чем исправить(такое встречалось), или добавить функциональность. В простом, понятном коде, в котором функицональности все выделены в раздельные сущности, переписать что-то легко. Благо понятно что делаешь.

PD>Да, а вместо Net Framework что предложишь ?

Java. Нельзя от печки требовать, чтобы она стала сново кирпичем. Так и нельзя от net или лиспа, чтобы они управляли ресурсами компьютера также эффективно как это делает более низкоуровневый собрат С++.

PD>Вместо MS Office ?

Тут согласен. Я это и не скрывал.

PD>Опять -таки — все верно, если у тебя единственный заказчик. Ему хоть на 2Gb пиши, если у него их 4. Но я-то о других случаях говорю.

Да хоть тысячи. Перед построением программы, всегда строится примерная картина для кого эта программа предназначена, и что у него есть.

С уважением, Gleb.
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 07.10.05 18:43
Оценка:7 (1) -1
gear nuke,

>>> Излишней является любая оптимизация, которая не направлена на изменение ситуации, при которой система не способна уложиться в определенные в проекте временные рамки на том оборудовании, для работы на котором она предназначена.

>
> ПК>Только та, которая стоит дополнительного времени при разработке.
>
> ИМХО любая оптимизация будет стоить дополнительного времени, если проектировать и делать "абы работало".

Не любая. Например, есть выбор: написать сортировку "пузырьком" или использовать библиотечную std::sort. Первое делать дольше и в большинстве случаев работать будет медленнее, чем второе.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[6]: Нет уж, позвольте! в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 30.10.05 10:14
Оценка:6 (2)
VladD2,

> ПК> И да, и нет. Если переписать, то, может, оно и нормально будет — сейчас, без эксперимента, сложно наверняка говорить Но вот причина, почему они не выпускают Office, перекомпилировав его с помощью MC++ или C++/CLI, заключается как раз в заметно уменьшающейся производительности, которую показывают собранные таким образом приложения Office.


> Это информация от группы Офиса, или умозаключения?


Это информация от группы VC++, сотрудничающей с группой Office в вопросах быстродействия MC++.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 06.10.05 14:30
Оценка:1 (1) +1
Здравствуйте, Nickolay Ch, Вы писали:

NC>Буду краток: писать код надо так, чтобы из него можно было получить максимальную денежную прибыль.

Хорошие слова. Только не надо под ними подразумевать скорость написания кода. Действительно, существует достаточно много продуктов сделанных тяп-ляп. Да, они выиграли тактически. Они впихнули полуживое решение и получили за них деньги. Только это стратегический проигрыш. Если кто-то увидет такой продукт, то он его запомнит навсегда. И навсегда запомнит, что те-то и те-то пишут не программы а набор ошибок. И исправить это очень сложно. Практически невозможно.
Сейчас существуют в некоторых отраслях такие вещи как портфорлио программ. Есть и тендеры, в которых указываются не только какие программы были сделаны, но и отзывы пользователей. И они кстати зачастую проверяются, так что враки не подпихнешь. Поэтому качество программы обязано быть высоким. Это значительно важнее чем скорость написания программ.

NC>Уважаемый mrozov правильно написал, что времена любителей позаниматься сексом с компом прошли в индустрии программирования.

Нет, не прошли. Просто пришла мода на другие извращения. IMHO И количество этих извращений значительно увеличилось.
NC>Энтузиастам и "вольным художникам" не место в индустрии.
Место. И притом денежное место. Индустрия большая. Даже в замой замшелой конторе с шизофреническими процессами разработки, есть место творчеству. Просто у архитектора — одно поле для творчества, у программиста — другое. У меня есть друзья, я по одному взгляду могу сказать кто какой код писал. Потому как каждый индивидуален в своих предпочтениях.
NC>Все вышенаписанное — мое имхо.
И слава богу.

С уважением, Gleb.
Re[7]: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 10.10.05 05:21
Оценка:1 (1) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Это уже совсем несерьезно. Человек спрашивал, как технически, т.е. с помощью каких средств языка С++ можно такое сделать. Я ему и показал. Неужели я не понимаю, что 1000 может не хватить ????

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

PD>А, прошу прощения, если не знать или хотя бы предполагать общий размер, то задача вообще не разрешима в однопроходном варианте. Потому как нельзя копировать в буфер, не выделив его предварительно. А длины в С++ не хранятся, в отличие от С#. На Паскале можно, там они хранятся.

И после этого кто-то будет обвинять C# в неэффективности???
Я приводил пример пессимального кода, который на шарпе приводит к квадратичной зависимости от полной длины строки. С точки зрения того алгоритма, два прохода или один — не так важно. Все равно мы имеем O(N). Даже наличие хранимой длины не слишком изменяет ситуацию — если длины фрагментов примерно одинаковы, то их количество тоже пропорционально суммарной длине строки, и мы опять имеем O(N). Меняется только константа перед ней.
S>>а попытки задействовать хардкор типа rep scasd ни к чему хорошему не приводят.
PD>Стоит ли его использовать или нет — вопрос спорный, а вот почему не приведут — объясни, пожалуйста.
Видел своими глазами пример. Как знаток x86 — ассемблера страшно раскритиковал код, сгенерированный VC 7.1 в релизе для приведенного мной фрагмента. Действительно, его код был красивше. А студийный — тихий ужос. Какие-то лишние джампы, как-то там регистры странно использовались... Увы, когда мы сравнили время — студия победила. Видать, ее оптимизатор лучше знает особенности спаривания команд и устройство конвеера. После этого я еще немножко верю в то, что суперкрутой спец сможет написать более эффективный код вручную. Но, во-первых, для этого ему потребуется что-то типа Intel VTune, а во-вторых, чем эффективнее будет этот код, тем больше риска, что на другой модели процессора он окажется в дупе. А в компиляторе я просто переброшу ключик "Target Processor" и усё. Кстати, джиту еще лучше — ему не надо оптимизировать под "blend".
А наивные попытки улучшить код, основанные на прочитанной 10 лет назад книжке "Справочное руководство по Intel 80386" способны только просадить эффективность.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Об эффективности программ в избранное  новое    модер.  /!\
От: Кодт модератор 
Дата: 26.10.05 22:10
Оценка:1 (1) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Хуже. Она использует __declspec(thread). Иначе, сам подумай, что будет, если ее начнут из разных потоков вызывать

GZ>>Для этого достаточно одного потока.

PD>Только при некорректном использовании.


Некорректное использование — это, например, случайный реентер.
void parse_line(line* line);

void parse_text(char* text)
{
  int n = 0;
  char* line;
  for(line=strtok(text,"\n"); line; line=strtok(NULL,"\n"))
  {
    ++n;
    printf("line #%d", n);
    parse_line(line);
  }
}

void parse_line(line* line)
{
  int n = 0;
  char* word;
  for(word=strtok(line," "); word; word=strtok(NULL," "))
    ++n;
  printf(" has %d words\n", n);
}

Всё-таки, что ни говори, а strtok — ублюдочная функция. По двум причинам:
1) у неё есть внутреннее состояние, которое можно сбить
2) типичное приложение — цикл — требует двух различных, но согласованных вызовов:
for(token=strtok(source,pattern); token; token=strtok(NULL,pattern))...

а это — провокация к технологии copy-paste и различным ошибкам (начиная с очепяток).
Можно же было запомнить pattern вместе с курсором строки — раз уж вообще что-то запоминаем.
for(token=strtok(source,pattern); token; token=strtok(NULL,NULL))...


Хотя можно было написать вот такое, без внутренних состояний:
char* strtok2(char** /*inout*/ source, char* pattern)
{
  char* token = **source ? *source : NULL;
  *source += strcspn(*source, pattern);
  *(*source++) = 0;
  return token;
}

.....
while( token=strtok2(&source,pattern), token!=NULL )
.....

убивающее сразу трёх зайцев:
— реентерабельно
— приложения без копипаста
— за попытку раскоцать строковый литерал компилятор надаёт по пальцам (разумеется, это обходится... но уже не так просто и бездарно)



Беда сишной библиотеки — в том, что таких глупостей там хватает. Например, функции работы со временем.
И если компилятор не поддерживает TLS (а это, в общем, геморройное дело) — то многопоточное CRT оказывается не совместимо со стандартом (в котором эти глупости есть). Пример: VxWorks.
Перекуём баги на фичи!
Re: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 05.10.05 12:21
Оценка: -2
Здравствуйте, eao197, Вы писали:

E>Пусть наши заказчики побыстрее увидят, что не выгодно покупать неэффективный (большой, неповоротливый) софт.

Интересно почему когда говорят что большой, сразу ассоциируют с неэффективным. Если у меня камаз возит кирпичи, то это лучше чем жигуленок. Хотя жигуленок меньше топлива жрет. Другое дело когда Белазом пытаются в такси поиграться. Конечно светофоры полегче проезжать, но солярки жрет, немерено.

А ты дать определение, что такое эффективный софт. И что такое неэффективный софт?
С уважением, Gleb.
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: iehttp://ziez.blogspot.com/
Дата: 06.10.05 01:02
Оценка: +1 -1
Здравствуйте, GlebZ, Вы писали:

ie>>Действительно, мы сейчас живем в век дешевой техники и дорогой рабочей силы. Но экономя на поддержке и разработке многие, прежде всего заказчики и начальники, действительно портят программистов. Что однако не умоляет множество глупых и бездарных программ.

GZ>Это не заказчики и начальники.

Ну не скажи.... Живой пример. Я попросил своего менеджера ежедневно выделять из моего рабочего времени 1 час на ревью кода вновь пришедшего. Ну не умеет новенький эффективный код писать и это не его вина, не научили еще. Нет же, и так в сроки можем не уложиться. Сдадим этап, тогда если(!) сильно тормозить будет, возможно(!), сделаем ревью... Вот так — если и возможно! А так — работает и пес с ней с эффективностью. Вот кто виноват? Скажи, пожалуйста.
В итоге — пора сдавать, а DataGrid ну уж очень тупит при отрисовке. Студент делал его раскрасску. Хочешь расскажу какой он код в DataGridColumnStyle.Paint напихал

ie>>Вот с архитектором в проекте очень даже повезло. Сейчас используется 5 ЯП с соответсвующими им технологиями. Я бы еще пол года назад сказал бы — да зачем мне какой-то там Питон, .NET форева. (Надеюсь больше меня эти мысли посещать не будут.) Все от начала до конца можно было сделать на .NET. Однако, прилили и C++, и Питон, и Ява Скритп, и Перл. Чего добились — думали: путаницы и неразберихи — оказалось: простоты и эффективноти!

GZ>А вот это плохо. Смешивать питон с перлом.

Смотря что понимать под "смешивать". Если я не ошибаюсь Перл пришел из-за необходимости генерить Excel отчеты (могу ошибаться, сам в Перловую часть не разу не лазил). Ну нет в .NET средств эффективной генерации Excel отчетов. В Perl есть, взяли, прикрутили. Почему это плохо? Лично мне, да никому другому, не надо переключаться между всеми 5ю языками. Мне пока приходилось работать над ++ модулями и .NET. Понадобится лезть куда-то еще — есть проектная документация. Так что. А к Питону Перл никак не завязан.

GZ>Будь моя воля, я бы привел все к одному языку.


И я сначала тоже так хотел...

GZ>Очень трудно переключаться с одного языка на другой. Вроде бы очень похоже, и термины такие-же. Только дизайн программ весьма зависит от используемого языка. Есть языки которые от которых зависят выбранные технологии. Тут хочешь не хочешь надо. И это хорошо. Но если что-то можно сделать одним языком, то это нужно делать именно этим языком.


Ну вот тот же пример с тестом Павла. Он явно дает понять, что ++ код эффективней справляется с поставленной задачей. Так и сделать эту чать на ++, конечно, без фанатизма, если эта часть действительно критичная, а не бегать каждый раз делать на ++ все что там даст выйгрыш в скорости и использовании памяти.

GZ>С чего все началось. Началось с того, что к Net программам Павел начал приставлять свойства C++. Ну нет у него многих свойств С++. Точно также и нет многих свойств C# у С++. В результате, дизайн программ существенно различается. По форуму Net очень часто поступают вопросы, сквозь которого проступает C++.

GZ>И данный пост Павла(которым он наконец разродился) именно связан с темой сравнения с С++.

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

С уважением, Иван.
... << RSDN@Home 1.1.4 stable rev. 510>>
Превратим окружающую нас среду в воскресенье.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: McSeem2http://www.antigrain.com
Дата: 06.10.05 05:21
Оценка: +1 -1
Здравствуйте, Дарней, Вы писали:

Д>Научить обычного, не озабоченного "оптимизацией-везде-где-можно" программиста оптимизировать программы куда проще, чем научить "байтовыжимателя" писать нормальный и понятный код. Потому что второй всегда будет искать, как в .NET обнулить поля структуры с помощью ZeroMemory (да-да, это намек ) — вместо того, чтобы проектировать архитектуру. Да еще и считать окружающих идиотами, потому что они не понимают, как же это важно — обязательно залезть на нижний уровень по самый локоть.


Не согласен. Я бы сказал, что это вещи вещи независимые — "этого научить проще тому-то, чем вот этого — противоположному". Здесь главное — чтобы человек обладал некими общими инженерными навыками. Фишка в том, что если человек умеет оперировать байтами в памяти, он как минимум знает, как устроен компьютер. И если он является инженером по своей сущности, то он очень быстро поймет, почему этого не надо делать в дот-нет. И наоборот, если человек начал с дот-нет, но при этом он обладает некими инженерными знаниями, он очень быстро разберется в том, как надо делать эффективно. Встречаются упертые личности — одни на ASM, другие — на C#, но они — не инженеры. И вопрос переучивания — он больше психологический чем технический. Если человек является инженером по своей психологии, то он переучивается легко — хоть туда, хоть сюда. Если же это для него туго, то наилучший способ его задействовать — это поставить на ковейер — пусть работает как машина Тьюринга и выполняет команды. Не хочет? — ну и ладно, найдем другого. Все это и ко мне тоже относится — так что просьба не принимать на личный счет.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 06.10.05 09:36
Оценка: +1 -1
Здравствуйте, GlebZ, Вы писали:

GZ>Да уж. Я тогда маленький был. Слышал о монстрах которые для того чтобы понять программу переписывали с ассемблера на коды.


Нет. Они просто ее писали в кодах, с самого начала

>Таже NT4 — с последними сервис паками мег 100 занимает оперативы.


У нас еще старый класс есть, для первокурсников, там 64 Мб и NT4. Вполне работает, SP последний.

GZ>Я бы не стал так говорить. Можно просто программы классифицировать:

GZ>1. Резидентные программы на машинах пользователей. Они действительно должны быть компактными, не должны забирать много ресурсов компа, и не мешать пользователю выполнять его основную работу.

+

GZ>2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.


+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.

GZ>3. Пользовательские программы. Наверно этот класс программ ты и имел ввиду. Вот именно это и есть путь для компромиса. И компромисс между функциональностью и ресурсами. Если функциональность нужная, и она требует достаточно ресурсов, то пользователь не будет возражать, по опыту знаю. Если в требованиях к программе не записано что попутно должны генерится сцены 3D Studio Max, то ему несложно будет выгрузить ее, или понять о том, что это была именно его ошибка. Но вот если функциональность ненужная, а требует достаточно ресурсов, то здесь и я сильно возмущаюсь(а такое на каждом шагу ). Но существует еще вопрос, что значит избыточность ресурсов? Если моя программа занимает на N мегабайт больше, и при этом я уверен что количество ошибок(которые есть будут и полностью их поубивать нельзя) значительно меньше, то я займу эти N мегабайт. В принципе, это и есть некоторая цель Net Framework.


Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше. А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам. От ошибок алгоритма меня никакой FrameWork не защащает. Складывать килограммы с метрами (вместо того, чтобы умножать) и там вполне можно, .


>Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач.


Я бы эту фразу перевернул.
Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.


GZ>Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500.


Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.

>Если у меня есть вариант, что адаптировав эту избыточность я повышену эффективность даже не программы. а разработки, я ею воспользуюсь.


Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.

GZ>Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки.


Да ведь нам говорят, что .Net — генеральная линия развития, а те, кому она не нравится — неандертальцы. Вот и мне сегодня заказчик сообщил, что планирует нечто на .Net. Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.



GZ>>>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест.


"У нас никогда нет времени на то, чтобы сделать все как следует, но всегда есть время на переделки"

>А также оптимизацией памяти, если ее оказалось недостаточно.


Ничего ты не соптимизиуешь. Не ты лично, а те, кто к эффективности не привык. Им и в голову не придет, что это все на 20 Мб может меньше требовать.

GZ>1. Если ты получил понятную программу, достаточно маленьку по исходным кодам, которую прочитает любой ребенок, и которая представляет вверх искуства программирования на ООП, это совсем не значит что она есть эффективна в плане использования памяти и процессора. Даже сказал бы наоборот. Но вот то, что в ней ошибки локализованы, сопровождать ее легко — это факт. После этого ее доводят до требуемого уровня производительности. Это делается легко, поскольку дизайн программы легко сопровождаем.


Ну и заявление! Дизайн понятен, сопровождение легко, след-но, оптимизировать будет несложно! А то, что для оптимального решения задачи, возможно, надо не в деталях оптимизировать, а все решение пересмотреть и весь дизайн переделать — это ты не допускаешь ? Совсем другим способом ее решать!


GZ>Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.


ИМХО это лечится рано или поздно, а первое — не всегда.

GZ>Вобщем, мое мнение, что оптимизация программ по используемым ресурсам, должны проходить в 3 плоскостях:

GZ>1. При построении архитектуры. Мы еще видим все проблемы в комплексе, и наиболее крупные можем сразу решить.

+


GZ>2. Алгоритмическая оптимизация. Неэффективный алгоритм на порядки хуже неоптимизированного кода.


+++

GZ>3. Оптимизация готового продукта под конкретные требования пользователя. Свое мнение я уже описал.


+-

GZ>Пользуйся альтернативами Я понимаю что в случае крупных монополистов — такое плохо проходит. Слишком высока сложность программ. Но нельзя так говорить о всей отрасли. Пользуются же мирандой вместо аськи.


Да, а вместо Net Framework что предложишь ? Вместо MS Office ?




PD>>Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ?

GZ>Да. Я вполне представляю весь процесс сооружения такой программы. Если ты потратил время на то, чтобы адаптировать решение на меньшие ресурсы, когда я знаю что ресурсы заказчика(или предполагаемого заказчика) значительно больше, то безусловно. Ты проделал работу, которая никому не нужна. Мало того, ты усложнил сопровождение программы. Для программ класса серверов приложений — я не вижу исключений из этого правила.

Опять -таки — все верно, если у тебя единственный заказчик. Ему хоть на 2Gb пиши, если у него их 4. Но я-то о других случаях говорю.



GZ>С уважением, Gleb.
With best regards
Pavel Dvorkin
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 06.10.05 10:28
Оценка: -1 :)
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Оптимизация всего и вся либо же не использование заведомо неэффективных конструкций — и ты не видишь разницы ? Ну, тогда сложно сказать что-то еще.


Д>А ты прочитал статью? Там есть как раз про "заведомо неэффективные конструкции". Почитай, в частности, про страшный алгоритм сложности f(n^3)


Ну, во-первых, эта статья есть гораздо ближе, да еще и на русском.

http://www.rsdn.ru/article/philosophy/Optimization.xml
Автор(ы): Dr. Joseph M. Newcomer
Дата: 25.06.2005
В этом эссе доктор Ньюкамер делится своим опытом и соображениями по поводу преждевременной, несвоевременной или неактуальной оптимизации, призывая программистов избежать подобных ошибок.


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

Вот, кстати, дай мне ответ. Хотя это лучше в .net, но ИМХО не страшно и здесь.

Перекодирование строки из файла из 866 в 1251.

Все что я нашел, сводится к

public string MyDecoder(string str)
{
byte[] b = Encoding.GetEncoding(866).GetBytes(str);
str = Encoding.GetEncoding(1251).GetString(b);
return str;
}

или вариациям на эту тему

Имеем здесь

Память

Исходная строка — 2N байт (N- число символов). Если строка из файла, то StreamReader еще поработал, чтобы ее из 866 в юникод перевести. И внутри себя он без массива в N байт не обошелся.
Массив b — N байт
Результирующая строка — 2N байт
Вывод ее в другой файл — еще N байт в 1251 внутри StreamWriter.

Итого 7N байт

А нужно всего-то N байт.

Время

StreamReader в юникод переделывал — цикл
GetBytes — цикл
GetString — цикл
StreamWrite записывает в файл с перекодировкой — цикл.

Итого 4 цикла. А нужен всего 1.

Я вполне допускаю, что ты сейчас мне это эффективнее напишешь. Ты. А все будут именно это и делать.
With best regards
Pavel Dvorkin
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 06.10.05 13:06
Оценка: +2
Здравствуйте, pp2, Вы писали:

pp2>Маленький совет сочуствующим автору. Вы любите чистое творчество, сложные неординарные задачи, непаханные поля новых технологий? Уходите из программирования. Я имею ввиду не "телом", а "душой". Т.е. можно продолжать зарабатывать на этом поле деньги, а тем временем прорабатывать новые, хотя бы смежные, отрасли. Чертовски приятно видеть как происходит становление новой технологии! И там есть где разгуляться пока туда не нагрянули люди с огромными мешками денег и не началась грызня за эти самые мешки


Давайте это Ричарду Столлману (GCC, emacs), Линусу Торвальдсу (Linux), Тео да Радту (OpenBSD), Гвидо ван Россому (Python), Ларри Уоллу (Perl), Якиро Матцумото (Ruby), ...(список можно продолжать)..., раcскажем. А то мужики, право слово, фигней страдают. Надо их жизни-то научить.




Ребята, если вы относитесь к программированию как к обычной работе, средству заработка, то и относитесь себе так и дальше. Зачем же подобные советы давать (вот еще один: Re: Об эффективности программ
Автор: Nickolay Ch
Дата: 06.10.05
).

Посмотрите лучше на другие отрасли, которые уже не один век существуют.

На образование, например. Там что, нет возможности для творчества? А как же учителя, которых потом всю жизнь с благодарностью вспоминают?

Или медицина. Неужели Федоровы и Амосовы там всего лишь случайность?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Об эффективности программ в избранное  новое    модер.  /!\
От: Abidos 
Дата: 06.10.05 13:59
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Перекодирование строки из файла из 866 в 1251.


PD>Все что я нашел, сводится к


PD>public string MyDecoder(string str)

PD>{
PD> byte[] b = Encoding.GetEncoding(866).GetBytes(str);
PD> str = Encoding.GetEncoding(1251).GetString(b);
PD> return str;
PD>}

PD>или вариациям на эту тему


Код некорректен: строка (string) в .NET состоит из символов юникода и к ней не применимо понятие кодировки, поэтому вышеприведенный код просто напросто коверкает строку, т.к.
byte[] b = Encoding.GetEncoding(866).GetBytes(str); // получили текст из строки в массив байт в кодировке 866
str = Encoding.GetEncoding(1251).GetString(b); // интерпретировали каждый байт из b в кодировке 1251 — в результате в str одни крякозяблы

Фактически, если необходимо записать строку в кодировке 1251 то это делается просто:
byte[] b = Encoding.GetEncoding(1251).GetBytes(str);

Если же надо преобразовать кодировку массива байт, то не надо предварительно преобразовывать массив в строку:
public byte[] MyDecoder( byte[] byte866 )
{
byte[] byte1251 = Encoding.Convert( Encoding.GetEncoding(866), Encoding.GetEncoding(1251), byte866 );
return byte1251;
}

Вероятно проблема не в неэффективности концепции framework .NET, а в понимании используемых технологий
Но, как мне кажется, без понимания основ эффективно писать вообще ни на чем нельзя.
Re[7]: Об эффективности программ в избранное  новое    модер.  /!\
От: pp2 
Дата: 06.10.05 14:52
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

E>Тенденция на лицо, но это совсем не означает, что ей нужно безусловно поддаваться. Тут, имхо, так: либо ты ищещь оправдания, либо возможности. Возможности искать труднее. Я, например, пытаюсь. И поэтому мне не интересно думать о том, что искусство становится ремеслом, места для фантазии не остается, индустрия выживает изобретателей и пр. Это не конструктивно.

Согласен. Не буду "оправдываться". Исходный мой пост был несколько эмоционален и направлен на поиск этих самых оправданий и описанию тенденций. Действительно, возможности искать стоит, хотя это и не легко. Уйти из программирования — это самый простой способ (хотя иногда именно это радикальное решение помогает отдохнуть и взглянуть на ситуацию со стороны). Можно не уходить а пытаться жить и даже творить что-то в имеющихся условиях. Но исходная дискуссия насколько я понял, шла именно вокруг массового "среднего" программиста. Профессионалы врядли так просто "уйдут" из отрасли, а вот середнячку тяжелее, он может и бросить это дело, если что... Хотя многие профессионалы были замечены в соседних с ИТ областях, значит "изменяют" все-таки иногда

E>Среди заповедей для художника от Сальвадора Дали была такая: "Художник -- рисуй!"

E>Очень к месту, имхо.
Ну мы же здесь не только "художники", но и философы! А вообще конечно,
+1


Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: Mikhail Polykovskyhttp://glader.ru
Дата: 07.10.05 02:49
Оценка: +2
Здравствуйте, Павел Кузнецов, Вы писали:

>> Вообще-то особенно при работе в команде код должен быть подчинен стандарту. Суть в том, что основная часть производства софта это именно индустрия, масс-продакшн.


ПК>Это не так хотя бы по простому факту того, что выпускаемые программы отличаются друг от друга. В противном случае не понимаю, зачем их много...


Диванов тоже много разных. И все произведены серийно.
Re[8]: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 07.10.05 02:52
Оценка: +1 -1
Здравствуйте, McSeem2, Вы писали:

MS>Это я к тому, по достижении "определенной стадии просветления" (это такой само-сарказм) оказывается, что писать эффективный код — это не только приятно и интересно, но он еще и оказывается гораздо надежнее!


Ну и где он, этот эффективный и надежный код? Пойти что ли, поискать на улицах с фонарем?

MS> И что характерно, индустрия, "в которой не место энтузиастам" проявляет тенденцию к спросу на таких "динозавров".


Ну это известный факт — что хороший программист за одно и то же время сделает как более эффективный, так и более надежный код, чем плохой прогораммист. Ну и что это докажет то? Хороших программистов все равно не хватает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 07.10.05 04:09
Оценка: -1 :)
Здравствуйте, mrozov, Вы писали:

M>То, что вы не призываете заниматься микрооптимизацией — это замечательно. Хотя в свете существования компиляторов, которые оптимизируют ассемблерный код лучше, чем 99% программистов — это не так уж и удивительно .Однако из ваших постов можно сделать вывод, что вы отказываете в праве на существование (доминирование?) таким системам, как Java или .net, именно на основе их неоптимальности. И в моих (например) глазах такие тезисы абсолютно равнозначны призывам массово использовать asm для построения UI.


Нет. Я просто удивляюсь, что эти ситсемы используют алгоритмы, в которых вместо одного прохода требуется 3, вместо одного блока памяти — 2 и т.д. И мне говорят, что при этом повышается читабельность и легче сопровождение и т.д. Вот это я не понимаю и не принимаю.


M>Излишней является любая оптимизация, которая не направлена на изменение ситуации, при которой система не способна уложиться в определенные в проекте временные рамки на том оборудовании, для работы на котором она предназначена.


Определение ИМХО некорректно, и я об этом уже писал. Если речь идет о программе для одного заказчика, то бога ради, с ним и решайте, чего ему надо. Когда же речь идет о программах, используемых массово, то излишние затраты ресурсов неоправданы, поскольку есть просто бессмысленная их трата.

M>Не больше. не меньше. Иными словами — для любого ПО можно (нужно?) определить минимально допустимую конфигурацию (критерии могут быть разными) и необходимые показатели быстродействия (в основном — время отклика).



Ну и определи, пожалуйста, на примере ICQ. Первая ее версия, с которой я столкнулся, работала у меня под Windows 95 на машине с 8 Мб памяти. А сейчас ей одной надо 20.


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



Да укладывается эта ICQ в память современных машин, укладывается вполне. Еще 4-5 таких клиентов — и больше на машине в 256 Мб памяти не останется.


M>По-моему, это клинический факт. Спорить можно только с тем, насколько вольно постановщик задачи обращается с этими самыми критериями достаточности.


А не мог бы кто-то определить для этой ICQ , кто здесь постановщик задачи, и насколько вольно он обращается с этими самыми критериями ? . Что-то мне кажется, что они сами тут определили и обращаются.
With best regards
Pavel Dvorkin
Re[8]: Об эффективности программ в избранное  новое    модер.  /!\
От: gear nuke 
Дата: 07.10.05 04:43
Оценка: +2
Здравствуйте, McSeem2, Вы писали:

MS>по достижении "определенной стадии просветления" (это такой само-сарказм) оказывается, что писать эффективный код — это не только приятно и интересно, но он еще и оказывается гораздо надежнее!


Когда-то спросил старого программера, как писать оптимальные программы. Я то думал, вопрос с подковыркой (оптимизировать по скорости или по размеру можно). А он ответил просто: "упрощай их".
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[9]: Об эффективности программ в избранное  новое    модер.  /!\
От: srggal 
Дата: 07.10.05 12:26
Оценка: +1 :)
Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Павел Кузнецов, Вы писали:


ПК>>Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.


M>А вот это — более чем спорно. Я бы даже сказал, что подобные заявления отдают манией величия =)

M>Не думаю, что стоит вот так категорично говорить о том, что вам должны инструментальные средства.

Я поддерживаю Великое ИМХО Кузнецова Павла.

Вилка — инструмент, ей можно красиво есь не теря собственного достоинства, есть фруктовая вилка, ей можно есть фрукты. Это вводная.

Так вот во Франции гдн-то в средние века проверяли жениха ( в приличных домах дворянского сословия ), претенденту подавали спелый персик, который он должен был съесть именно фруктовой вилкой и ножом, не теряя собственного достоинства, и непринужденно ведя светскую беседу с будующими родственниками. В тоже время мастеровые ели руками.

Продолжить аналогию про вилки:
Если фруктовую вилку всадить себе в глаз то можно не только лишиться глаза, но и умереть чтобы этого не случилось, — можно на вилку надеть винную пробку, но тогда, имея соответсвующие навыки — нельзя съесть персик.


Такие вот интсрументы эти Ваши вилки
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[13]: Об эффективности программ в избранное  новое    модер.  /!\
От: srggal 
Дата: 07.10.05 13:15
Оценка: +1 :)
Здравствуйте, mrozov, Вы писали:

M>О! Именно об этом я и говорю. А так как "взрослых" программистов — ничтожное меньшинство, то мы и приходим к неутешительному выводу по поводу того, кому и что именно должны инструментальные средства.


Резюмируем:

Вы писали:

Заметка из жизни. Если у программиста проблемы с ДНК, то C# многое прощает, а вот шаблоны в С++ многое усугубляют.


здесь
Автор: GlebZ
Дата: 07.10.05


Я писал:

Прочитав топик про С# 3.0 С# 3.0
меня посетило подозрение, что C# взрослеет, и скоро там тоже понадобяться раздельные наборы столовых приборов


здесь
Автор: srggal
Дата: 07.10.05


То что я написал — Вы не опровергли, а вместо этого согласились.

Соответсвенно вывод:

Разработчики инструментальных средств — считают так как Я и Павел Кузнецов ( Это ИМХО ), а не так как Вы .

Если на секундочку вернуться к фривольному тону, то:

ИНструсентальные средства — это теже дети, они растут, взрослеют, и им становяться неинтересны детские наборы посуды, они подражают взрослым, они хотят, как взрослые, есть персики вилкой, и при этом — чувчтвовать себе непринужденно.

Как пример из многострадального Шарпа (я могу ошибаться так как сам на нем не пищу) вроде как в 2.0 char* стал safe дабы вызовы WIN API быдли safe — ребенка потянуло к взрослым игрушкам ???

M> Поздравляю!


Спасибо.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[11]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 10.10.05 11:34
Оценка: -1 :)
Здравствуйте, GlebZ, Вы писали:

GZ>Создается, но она не мусор. Строка в Net — immutable. Строка не может быть изменена, можно создавать только новые. Row возьмет ссылку на строку и будет оперировать именно им. Он спокойно может сохранять у себя ссылку на строку, передавать ее другим, не боясь что кто-то изменит ее.


Это все верно, но тут ты играешь на том, что эти подстроки нужны и дальше (в данном случае будут использованы в rows). А вот когда они дальше как таковые не нужны (т.е нигде храниться не будут) — тут-то ты и проиграешь.

p=strtok(myString,",");
while(p)
{
printf("%d\n",p);
p = strtok(NULL,",")
}

Здесь эти временные подстроки никому не нужны после печати. Если ты это перепишешь на С#, то получится

int i, l=0;
while ((i=myString.IndexOf(",", l))!=-1)
{
Console.WriteLine(myString.Substring(i, l-i);
l=i;
}


В итоге для того, чтобы распечатать подстроки, ты создал их, напечатал, и, конечно, они стали добычей GC. А я их не создавал. Правда, строку испортил, но это уж так strtok сделана. Могу свою функцию написать, которая то же сделает, но строку портить не будет.

Если считешь мой пример искусственным — хорошо, пусть в задаче требуется разбить на слова, а потом каждое слово проверить каким-то образом. Я опять-таки подстроки делать не буду, а ты будешь.
With best regards
Pavel Dvorkin
Re: Об эффективности программ - мои замечания в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 11.10.05 05:13
Оценка: +1 -1
Прочитал я то. что написали участники дискуссии. В общем, со многим можно согласиться. С тезисом "клиент всегда прав" не поспоришь. Да и тот факт, что нынешнее программирование — это работа за деньги, а кто платит, тот и заказывает музыку, тоже вне сомнения. Хотя средства разраюотки — прерогатива не только заказчика, но и разработчика.

Но вот утверждение, что, дескать в этом и заключается новая ситуация в IT-индустрии — ИМХО спорно. Боюсь, что она не новая, а очень даже старая.

Есть такой класс программистов — программисты на Visual Basic. VB как-то в России не слишком популярен ИМХО и признаваться, что на нем пишешь, даже как-то стыдно считалось . А вот в мире он весьма популярен, где-то мне встретилось утверждение, что в мире около 1 млн. программистов на VB. За то. что мне память здесь не изменяет — не поручусь, так что критиковать это утверждение не надо. И потом, неизвестно кого они туда включили — может, школьников средних школ тоже

Так вот, эти самые программисты на VB свою работу делали, а вот эффективности от них никто и не ждал. Потому что программы для массового использования они не делали, а делали для данного конкретного случая, порой для себя, или для заказчика, которому она нужна, а торговать он ей вовсе не собирается. Кстати, если во времена своих химических расчетов имел бы PC с VB — вполне возможно, на нем бы и начал свою карьеру. Просто, удобно, легко...

Что касается эффективности — кто ее от Бейсика когда ждал ? К нему традиционное отношение как к чему-то неэффективному — интерпретатор же! И пусть VB никакой не интерпретатор — от однажды завоеванной репутации так легко не отделаешься

Так вот, у меня впечатление такое, что этот стиль VB попросту начинает проникать в те области, куда программистов VB раньше и на пушечный выстрел не подпускали, да они и сами не стремились, так как знали, что им там делать нечего — не влезут они с VB в имеющиеся ресурсы, не добьются нужной производительности. А ресурсы увеличились — и они пошли!
With best regards
Pavel Dvorkin
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: AndrewVK модераторhttp://blogs.rsdn.ru/avk
Дата: 13.10.05 11:26
Оценка: +2
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это не так хотя бы по простому факту того, что выпускаемые программы отличаются друг от друга. В противном случае не понимаю, зачем их много...


Неверная аналогия (тут рядом это уже обсуждалось). Разработка программы это не изготовление конкретного дивана, а проектирование конкретной модели дивана.
... << RSDN@Home 1.2.0 alpha rev. 617>>
Re[21]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 19.10.05 07:22
Оценка: -1 :)
Здравствуйте, Дарней, Вы писали:


Д>Как я уже говорил, ведущие собаководы говорят — "читаемость и легкость расширения кода стоят превыше всего, в том числе и оптимальности по объему/производительности/любой иной"


По второму кругу пойдем. Ведущие автомобилестроители говорят. что удобства разборки и сборки автомобиля важнее его характерстик.


Д>отвечу заранее — нет, я не согласен с тем, что более простой код будет и более оптимальным. Совпадение одного с другим вполне возможно, но в большинстве случаев это вещи взаимоисключающие.


И да, и нет... В большинстве — не согласен, а бывать — конечно, бывает.


PD>>Программа делается для России. Приведи ситуацию, в которой здесь возможен buffer overrun. Фамилию и имя, please , в студию.


Д>фамилия очень простая — "Ивановвввввввввввввввввввввввввввввввв" (повторить нужное количество раз). Просто оператор заснул на клаве. Ах, такого не бывает, говоришь?


Нет, не бывает. Потому как в моей задаче данные брались из SQL сервера, там попросту не могло быть такого — места нет.

Д>Я уж не говорю о том, что это решение не только опасно, но еще и очень далеко от оптимума по производительности, которого тебе так сильно хотелось. Не догадываешься, почему? Рекомендую немного помедитировать над текстом sprintf


А не надо медитировать. Я sprintf просто для примера привел. Реально у меня была ConcatenateStrings собственной разработки. Черт ее. sprintf, знает, как она там по форматам преобразует


Д>как я уже говорил, твой пример к рассматриваемой ситуации с sprintf не имеет ни малейшего отношения. Поэтому смотреть тут особо и не на что.


Ну не на что так не на что.

Д>разница в том, что ошибку переполнения можно обработать программно, ибо к порче сторонних данных она не ведет. Потертый стек — это однозначно полный трындец программе.


Ну и ставь себе try-catch на каждый оператор. Не много их найдется, которые в принципе не могли бы ошибку сгенерировать.

Д>Эти самые "общепринятые принципы" были изучены мной на своей собственной шкуре, и на немаленьком количестве набитых шишек. Именно поэтому я говорю, что если ты вдруг подумал, что нужно нарушить один из них, потому что "это нужно для решения задачи и другого выхода нет" — значит, садись и думай еще раз.


Да зачем мне об этом опять думать ? Проект этот я давно сдал, он и сейчас там работает, и будет еще бог знает сколько времени работать, и жалоб не было, хотя обработаны миллионы, если не десятки миллионов образцов, так что уж давно бы баг проявился бы

Д>Я в свое время тоже увлекался написанием мега-оптимизированных программ. Написал например для эксперимента дизассемблер для Z80, который целиком помещался в 1.5 килобайта. Но с тех пор я набил немало шишек, стал несколько мудрее и перестал заниматься подобной ерундой.


Ну и на здоровье. Я все равно придерживаюсь той точки зрения, что лучше сделать с нарушением правил, чем по правилам ничего не сделать.

Вот ответь прямо на вопрос. Тебе предлагается проект. К нему жесткие требования по времени работы, не уложишься — не примут. Написать со всеми твоими проверками — знаешь сам, что не уложишься. Но знаешь и, что если займешься "написанием мега-оптимизированных программ" — уложишься. Ядерным реактором это не управляет, самолеты не водит, крах если раз в месяц произойдет — не смертельно, перезапустят. Твои действия ?

PD>>В конце концов лучше написать работающую программу не по правилам, чем по правилам ничего не сделать.


Д>А еще лучше — написать работающую программу, которая не будет использовать никаких грязных хаков. См также пример по sprintf выше
With best regards
Pavel Dvorkin
Re[24]: Об эффективности программ в избранное  новое    модер.  /!\
От: srggal 
Дата: 19.10.05 13:40
Оценка: :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>
PD>    private static string Concat(string s1, string s2)
PD>        {
PD>            return s1 + s2;
PD>        }
PD>        [STAThread]
PD>        static void Main(string[] args)
PD>        {
PD>            DateTime dStart = DateTime.Now;
PD>            for (int i = 0; i < 10000000; ++i)
PD>                Concat("iddqd", "idkfa");
PD>            DateTime dEnd = DateTime.Now;
PD>            Console.WriteLine(dEnd - dStart);
PD>        }
PD>


Хоть Вы и читтер уважаемый, ан все равно приятно увидеть Думмера, ( поглаживая свой БФЖ ), и вспоминать как БФЖ рулит на 7мом уровне в дедматч. Эххх.

ЗЫ Решпект
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[27]: Об эффективности программ в избранное  новое    модер.  /!\
От: alexeiz 
Дата: 20.10.05 07:26
Оценка: +1 -1
Здравствуйте, GlebZ, Вы писали:

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


A>>Так не пойдет. Чтобы было эквивалентно С++ варианту нужно ещё из StringBuilder получить String.

GZ>Почему?

В C++ версии на входе две строки на выходе одна. В C# — на выходе какой-то буфер (StringBuilder то есть). Чтобы его использовать как строку, нужно еще совершить преобразование.
Re[26]: Об эффективности программ в избранное  новое    модер.  /!\
От: srggal 
Дата: 20.10.05 09:36
Оценка: +1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

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


S>>Здравствуйте, Pavel Dvorkin, Вы писали:



S>>Хоть Вы и читтер уважаемый, ан все равно приятно увидеть Думмера, ( поглаживая свой БФЖ ), и вспоминать как БФЖ рулит на 7мом уровне в дедматч. Эххх.


PD>Ради бога, переведи на русский, а то я даже не знаю, как на все это реагировать .


PD>P.S. Код, который ты цитируешь — не мой, см.


Уппс, ошибочка вышла.... Еще одна проблема с копипастом
Выделенные строки это читкоды легендарного дума, если не ошибаюсь:

iddqd — God mode
idkfa — all weapon
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[25]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 20.10.05 09:44
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


WH> StringBuilder sb = new StringBuilder();

WH>...
WH> for (int i = 0; i < 100000; ++i)
WH> {
WH> sb.Length = 0;
WH> sb.Append(szFirstName);
WH> sb.Append(szLastName);
WH> }
WH>[/c#]
WH>0,04493758

WH>Оптимизированый вариант на C# получается на уровне С++ Ну чуть медленнее.


Проверять не буду, приму на веру. Все верно, я так и ожидал. Только одно имей в виду — StringBuilder постоянно хранит и изменяет поле длины. И это не бесплатно. Ты уже заплатил за вычисление этой длины вот здесь

string szFirstName = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
string szLastName = "22222222222222222222222222222222222222222222222222222222222222222222222222222

(именно здесь, может, и нет, так как строки константые, но в других случаях — да)

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

WH>Кстати для корректности теста перепиши свои на wchar_t.


А зачем ? Надо будет — перепишу. А пока мне и так хорошо — там, как я знаю, только 0-127. И незачем мне делать 50% оверхед. Я могу и не переписывать. А вот ты можешь на ASCII переписать ?
With best regards
Pavel Dvorkin
Re[33]: Об эффективности программ в избранное  новое    модер.  /!\
От: alexeiz 
Дата: 21.10.05 09:26
Оценка: -2
Здравствуйте, GlebZ, Вы писали:

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


A>>Приемущество языка С заключается в том, что он позволяет (не требует а позволяет) спуститься на уровень железа. Для С# это очень и очень ограничено. Все размышления о выходе за границы массива идут лесом. Это просто отдельный разговор.

GZ>Закон относительности. Можно повернуть и по другому. Преимущества C# то, что он не позволяет делать ошибки выхода за границы массива. Хотя и это неправда. Я прямо написал, что можно так делать, но это особый случай называемый unsafe кодом. Так что и C# умеет работать с памятью и указателями. Так что преимущества здесь нет.

Я посмотрю, как ты будешь со строками в unsafe коде работать. То, что ты можешь работать с памятью и указателями, для строк не имеет ни малейшего значения.
Re[27]: ОФФТОП в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 24.10.05 10:04
Оценка: -2
Здравствуйте, srggal, Вы писали:

S>Ламмеров — отучил бы, а я — выходил бы на круг по которому Вы бегаете с пистолетом, и не сделав бы ни одного выстрела смотрел бы как тело врага, возможно Ваше, оседает на пол


Ну, то что ты трепачь я уже давно понял.

S>БФГ в Думе2 — надо уметь пользоваться, не нужно стрелять им в голову, выстрел в стену и стрейф без иззменения угла, после выстрела — и все что видит владелец БФЖ, пока кипит на стене выстрел ( в том числе и за стеной ), — все умирает.


Переставай дружить с Маней Величко. Это плохая подруга.
Вместо этого лучше представляй себе что разговаривашь с людми опыт которых как минимум не меньше твоего.

S>Но это так азы... Просто ностальгией повеяло


Это безграмотное обяснение. Реальное обяснение намного сложнее.
Стрэйфить никуда не нужно. Просто при попадании снаряда ВБГ в стену или оппонента проводился мысленный веер состоящий из 43 (за точное число не ручаю) "лучей смерти". Центр веера проводися от туловища стрелвшего по напавлениб к месту поподания. По этому совершенно все равно куда ты смотришь или как ты сртэйфишся. Можно было отвернусться и ждать пока все перадохнут. Вот только с удалением лучи расходятся и наносят все меньше и меньше урона. Да и в узком месте пучок не столь широк чтобы можно было безнаказанно убивать все на своем пути. 100%-ная смерь наступала только при прямом попадании или на небольшом растоянии и малом угле. Плюс к тому огромный лаг при выстреле и характерный звук. Собствнно это позволяло очень многих любителей семерки класть банальным ружьем. Главное было вовремя зайти к ним за спину.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[33]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 26.10.05 09:16
Оценка: -2
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Pavel Dvorkin, Вы писали:


Д>какая разница — одна и та же, или разные? Длина строки просто вычисляется где-то в другом месте (точнее — в коде, который читает данные из базы. но это уже детали)


Код, который читает данные из базы, длину не вычисляет. Нет такого в SQL SELECT, к примеру. Внутри себя этот SELECT на сервере я не знаю что делает, но мне на клиент в итоге строка попадает как последовательность ASCIIZ. Последовательность ASCIIZ — "сырые" данные, откуда они взялись — не важно. А в объекте string на входе конструктора эти же сырые данные (а как ты еще string сконструируешь, если не по ASCIIZ или по другому string ?), а вот в полученном объекте — уже с длиной. Т.е. длину при создании экземпляра string вычислили.

Давай простой пример, искусственный, конечно. Есть огромный файл (1GB , в нем одна текстовая строка, в конце ее , конечно, 0D0A . Я открываю этот файл, делаю на него MMF, позиционируюсь в конец файла, заменяю 0D на 0, имею таким образом строку ASCIIZ. Обрати внимание — файл я не читал. Все — у меня char* pString готов.

А теперь то же самое, но сооруди мне string из данных этого файла. И ты обязан будешь файл прочитать.

Д>Конкатенация ASCIIZ строк неэффективна в принципе, вот что я пытаюсь до тебя довести.


Да ведь во входном мире ничего другого нет. Есть некий входной массив байт (из файла, из сети, ...). Этот набор нам дают и все. И чем-то заканчивают, чтобы знали, когда остановиться.
gets банальный, например. А дальше уж наше дело — то ли string из него соорудить, длину мимоходом посчитав и время потратив, то ли не считать длину, отложить до того момента, когда понадобится (может, и не понадобится) . Кстати, в моем примере с конкатенацией я эту длину мог мимоходом вычислить.

>Читал историю про маляра Шлемиэля?


Нет.
With best regards
Pavel Dvorkin
Re[36]: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 27.10.05 05:07
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Как он хранит — не мое дело. А вот возвращает он из без длины.


возвращает не он. Возвращает библиотека доступа к нему, причем — тот конкретный экземпляр, который ты используешь.

PD>Бог с тобой, зачем же ? Ты вообще с MMF знаком ? Там прямой доступ. Если уж мне надо расширить файл, то я просто создам мэппинг на размер, больший, чем текущий размер файла на требуемую величину.


то есть, в данном случае размер хранится где-то отдельно. Иными словами, это не ASCIIZ строка
ноль ты конечно можешь добавить в конец, но в данном случае это будет из разряда "не пришей кобыле хвост"

PD>Да в общем-то ничего интересного. По крайней мере ничего нового для себя я не нашел. Довольно наивные рассуждения, особенно забавно вот это


>>Строка не может содержать нулевые байты. Так что хранить произвольные двоичные данные вроде картинки в формате JPEG в строке нельзя.


PD>Между прочим, JPEG очень неудобно хранить так же в виде стека, линейного списка, двоичного дерева и т.д. И не надо — не предназначены эти структуры для хранения JPEG . Как и строка. Кстати, ты готов хранить JPEG в виде string ?


Я буду хранить в том, что будет удобно для моей задачи. Хоть в массиве, хоть в строке, хоть в дереве.

Забавно, что ты обратил внимание только на это.
Я даже не могу сказать, что ты не видишь леса из-за деревьев. Потому что ты настолько погрузился в разглядывание травы под своими ногами, что даже про существование деревьев забыл.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Закон Мура умер в избранное  новое    модер.  /!\
От: FR 
Дата: 30.10.05 08:40
Оценка: +2
Здравствуйте, gear nuke, Вы писали:

GN>Думаю для определённых (узких) классов задач решения будут постепенно возникать. Я бы и сам с радостью купил писюк, который весь (кроме монитора) находится в клавиатуре .


Давно забытое старое? (синклер, микроша, вектор, поиск)
Да и сейчас есть тот же mac-mini
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: WolfHound rsdn 
Дата: 31.10.05 10:54
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Кстати, об эффективности программ, требованиям к памяти и т.д. Наткнулся вот на это

PD>http://www.rsdn.ru/Forum/Message.aspx?mid=1460511&only=1
Автор: squiz
Дата: 28.10.05

PD>Почитайте весь тред, не пожалеете.
Ну читал и дальше что?
1)У меня решарпер кушает на много меньше памяти на проекте который побольше будет.
2)Если ты думаешь что будь решарпер написанан на С++ он бы жрал меньше ресурсов то ты заблуждаешься. Ибо он память не просто так жрет.
3)Плюсы которые дает решарпер значительно перевешивают его прожорливость.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: IT админblogs.rsdn.ru
Дата: 02.11.05 03:47
Оценка: :))
Здравствуйте, AndrewVK, Вы писали:

PD>>Почитайте весь тред, не пожалеете.


AVK>Если бы весь софт был на уровне Решарпера, у нас бы было значительно меньше проблем.


Ага. Как-нибудь я соберусь и выскажу всё что о нём думаю
... << RSDN@Home 1.2.0 alpha rev. 0>>
If nobody helps us, then we, too, will show no mercy.
Re[15]: Об эффективности программ в избранное  новое    модер.  /!\
От: Коваленко Дмитрийhttp://www.ibprovider.com
Дата: 02.11.05 07:36
Оценка: +1 :)
Здравствуйте, Hydrogen, Вы писали:

H>А если так:

H>for(int i=0, cnt=GetCount();i<cnt;i++){....}
H>.......
H>for (int j=0, cnt=GetCount();j<сnt;j++){....}

H>

Не, реальные пацаны пишут
for(int i=0, cnt=GetCount();i<cnt;++i){....}

-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[8]: Закон Мура умер в избранное  новое    модер.  /!\
От: OnThinkhttp://vassilsanych.livejournal.com
Дата: 03.11.05 12:35
Оценка: +1 :)
GN>Mac может и хороший комп, но для себя не вижу никакого смысла в нём... разве что для понтов .

Ну почему. Руки греть зимой хорошо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[49]: Об эффективности программ в избранное  новое    модер.  /!\
От: IT админblogs.rsdn.ru
Дата: 05.11.05 02:30
Оценка: :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все, извини, но это письмо будет точно последним. Времени больше на эти дискуссии нет — увы, заказчик прислал наконец спецификации проекта, и он именно на С# .

Заказчик всегда прав!
... << RSDN@Home 1.2.0 alpha rev. 0>>
If nobody helps us, then we, too, will show no mercy.
Re[5]: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: Nickolay Ch 
Дата: 29.10.05 06:50
Оценка:20 (1)
E>Тут уже кто-то сказал, что это "потом" никогда не наступает.

Это "потом" наступить может лишь тогда, когда этого потребует заказчик, сиречь заплатит еще денег.(Естественно, если в первоначальных требованиях этого не было).
В свободных же проектах это "потом" может наступить в зависимости от энтузиазма разработчиков, и, имхо, главное, от наличия у них времени, так что не надо приводить в пример некоммерческие проекты в данном случае.
Re[10]: Об эффективности программ в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 07.10.05 12:39
Оценка:14 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

GN>>Когда-то спросил старого программера, как писать оптимальные программы. Я то думал, вопрос с подковыркой (оптимизировать по скорости или по размеру можно). А он ответил просто: "упрощай их".


PD>Хотел я в исходном постинге напомнить про один принцип. Потом решил, что введет ненужную игривость


PD>KISS — Keep It Simple, Stupid!


В ту же тему: Re[3]: КОНЦЕПЦИЯ ЧИСТЫХ ЛИНИЙ
Автор: IT
Дата: 17.08.05
, Re[4]: КОНЦЕПЦИЯ ЧИСТЫХ ЛИНИЙ
Автор: eao197
Дата: 19.08.05
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Закон Мура умер в избранное  новое    модер.  /!\
От: raskin 
Дата: 10.10.05 05:08
Оценка:14 (1)
gear nuke wrote:
> GZ>Мне не интересен сам вопрос про кэш. Кэш неуправляем и эвристичен. Я
> предполагаю более управляемую архитектуру.
>
> По сути, Вы предлагаете управляемый кэш. Это способно дать выигрыш. И
> сущесвующие методики работы с кэшем тоже дают выигрыш. Вопрос в том,
> *почему* до сих пор нет ни одного компилятора использующего это эффективно?

Современное управление кешем неполно (у кеша всегда есть и своё мнение
кроме prefetchnta) и непереносимо, поэтому никто не заморачивается?
Posted via RSDN NNTP Server 2.0 beta
Re[17]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 18.10.05 12:15
Оценка:13 (1)
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>1.Не сотвори себе кумира!


Д>мы ведь говорили про принцип KISS? вот у меня есть предположение, что люди, которые стояли у истоков Юникс, знают намного больше нас с тобой о его точном значении


Не понял. Или ты имеешь в виду, что я неправильно расшифровал аббревиатуру ?



Д>мы ведь говорим о программах, а не о машинах?

Д>а вот как раз они глохнут. и "взрываются". причем регулярно

Не без этого, не спорю. Но бороться за то, чтобы этого не было, надо с соразмерными затратами. Если, конечно, речь не идет о программе управления ядерным реактором. Если ICQ раз в месяц падает, то еще вопрос — нужна ли мне ICQ, которая падает раз в 3 месяца и жрет памяти в 3 раза больше.

Д>поэтому давайте сделаем сначала то, что будет нормально ездить и возить грузы. Пусть и не очень быстро, зато с гарантированной доставкой из точки А в точку Б. Причем в целом и непритронутом виде.


Нет, не пойдет. Потому что если с меня за эту поездку на самоновейшем самолете возьмут из Омска в Москву $1000, я предпочту обычный российский поезд, который довезет меня за $100, хотя, возможно, слегка опоздает. Кстати, и риск аварии там не больше, чем у самоновейшего самолета.

А программ без ошибок — не бывает. Вспомни

"Программа, свободная от ошибок, есть абстрактное теоретическое понятие".


Д>многие так думали. пока жареный петух в одно место не клюнул


Ну несерьезно это. Есть страна, для которой я это делал. Есть у них в стране некая информация (извини, но деталей рассказывать не буду). Эта информация там появилпась, когда еще никаких компьютеров на свете не было, а может, и автомобилей не было. И вот я эту информацию в некий буфер заношу. И то, что она никак не может быть больше, чем 500 символов — гарантия в 101%. Никогда не может, ну так же, как имя русское не может быть длиной в 500 символов. А времени считать эту длину абсолютно нет, потому как на все про все мне дано 100 мсек. И в этих условиях ты все же будешь утверждать, что buffer overrun возможен ?


Д>разница в том, что этот код не вызовет порчу стека. а sprintf — вызовет

Д>улавливаешь разницу?

Нет, не улавливаю. все равно это кончится неверным поведением программы и в конце концов крахом. Причем скорее всего не здесь, а где-то еще. Так что разницы я не улавливаю. Или ты хочешь сказать, что buffer overrun — это намного хуже, чем integer overflow ? По мне, один черт — все равно дальше ничего хорошего не будет.

На тебе, пожалуйста

int nScreenArea = nScreenWidth * nScreenHeight;
int nSquareLength = sqrt(nScreenArea); // а какого бы размера был квадратный дисплей с таким же числом пикселей ?

и получи sqrt domain error (не помню, как он сейчас называется правильно) — корень из отрицательного числа.

Д>кстати говоря, во многих серьезных конторах за использование любой функции из семейства printf нещадно бьют по рукам. И даже более серьезно — по кошельку.


А это от ситуации зависит. В том проекте, в котором я участвовал, мне все было разрешено, кроме одного — низкой скорости работы. Занял бы на диске лишний Гбайт — простили бы. ОП использовал бы в 2 раза больше, чем надо — тоже простили бы. А вот уложиться я должен был в 100 мсек. Кровь из носу. Потому что если 200 мсек займет — это кончится просто тем, что данный образец будет снят с обработки по нехватке времени, а тем самым число необработанных образцов увеличится. А обрабатывается таких образцов в день примерно 30,000 только на одной машине, и на каждый образец дается не более 3 сек. И за это время к моему ПО делается 10-15 запросов плюс, естественно, то время, которое нужно на оставшуюся часть, а оно есть примерно 60% общего времени. А машин примерно 1000. Борьба шла за каждый процент. И мне все прощалось, только бы быстрее. И сделал я им вместо 100 мсек 20-30 мсек, и были они в полном восторге

А лишних Гбайтов я , кстати, не использовал. И лишней ОП — тоже. Ну разве что самую малость — буфер там был один с запасом в 64 Кбайта
With best regards
Pavel Dvorkin
Re[11]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 24.10.05 14:29
Оценка:8 (1)
Здравствуйте, IT, Вы писали:

IT>Алгоритмы тут не причём. Упрощать нужно не их самих, а их реализацию.


Опять неверный совет. Что значит упрощать реализацию? Более длинная и запутанная реализация может оказаться эффективнее в виду того, что запутанность — это оптимизации.

Так что урощать нужно грамотным абстрагированием. Любой код можно сдалать понятнее если выразить его через более высокоуровневые абстракции. Возможно при этом он станет и короче, но это уже дело десятое.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[3]: Неэффективности программ -- ДА! в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 26.10.05 05:35
Оценка:6 (1)
Здравствуйте, Voblin, Вы писали:

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


ZS>>- туфли на неснашиваемой подошве (казалось бы — чего проще пустить туда резину как в авто-покрышках)


V>Один мой знакомый делает обувь "Lifetime warranty". Когда я узнал об этом ( => о том, что такое бывает), у меня был шок.


"Мне предложили вечную иглу для примуса, а я не купил. Мне не нужна вечная игла, я не собираюсь жить вечно"

(C) Ильф и Петров, цитирую по памяти
With best regards
Pavel Dvorkin
Re[4]: Закон Мура умер в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 29.10.05 14:42
Оценка:4 (1)
Здравствуйте, gear nuke, Вы писали:

GN>А когда начнут интегрировать RAM в корпус CPU (что бы избавиться от проблем с печатными платами), то как будем добавлять память?


А надо? Для каждого периода времени есть некие негласные принятые объемы памяти. Ввести три градации:
1. Лоэнд — сейчас где-то 128 метров.
2. Лоэнд+ — 256 на сегодня.
3. Мидлэнд — 512.
4. Хайэнд — 1 Гиг.
5. Мечта идиота 4 Гб.

Если это будет статическая память (попросу кэш), то ее можно тактировать частотой ядра и получать офигительные решения. Каждый класс к тому же будет иметь разное число ядер, разную тактовую частоу и т.п.

На будющее просто выростут объемы памяти и частоты. Классы же останутся.

Это кстати позволит делать девайсы миниатюрнее.

Можно пойти и таким путем. делать матери сразу под много процессоров с доставляемыми процессорными блоками. Каждый блок доставляет не только процессор но и память.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: pp2 
Дата: 06.10.05 12:48
Оценка:3 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно.

Не видать что-то минусов... Зачем же так сразу пессимистически начинать?

PD> Когда компьютеры были большими, память у них была маленькой и

PD>быстродействие тоже. И поэтому гуру от этих ЭВМ ничего, кроме ассемблера
PD>(автокода, по-тогдашнему) и не признавали.
Давайте условно расставим факты между "тем" и текущим временем.
Что было раньше:
— программирование не было массовым, там работали Профессионалы, но из другой специальности, собственно такой профессии как программист и не существовало
— компьютеры были "хилые", поэтому просто приходилось писать программы компактно и оптимально, по другому они просто были не работали
— сроки разработки программ были большие, соответственно разрабатывались они тщательнее и больше времени уделялось оптимизации (конкуренция и борьба за рынок не были так выражены)
— в ИТ-сфере крутились не очень большие деньги, отрасль только становилась на ноги
— такие свойства как сопровождаемость и архитектура у программ были постоянно совершенствовались до определенного момента (времени этому уделялось больше, да и работали профессионалы, т.е. средний уровень был высокий)

Что имеем сейчас:
— компьютеры стали мощные
— сроки разработки программ заметно сократились, а сложность их возросла (возросла за счет подключения расчетов из смежных отраслей, которые "увидели" в ИТ отдушину)
— программирование стало массовым, туда потянулись "простые смертные", общий средний уровень квалификации упал (чего стоят нынешние индусы)
— в ИТ-сферу пришли большие деньги и правила бизнеса, и оттуда ушли творчество, остатки наук и искусство, теперь деньги определяют многое, хотя и не все
— появились мыльные пузыри — это следствие больших денег (дотком 2001, например), возникла куча смежных с ИТ мелких бизнесов кормящихся с него и заинтересованных с раздувании этих пузырей в дальнейшем, началась рыночная грызня: нечестные игры с пользователями, скупка конкурентов, монополизация и пр.
— качество программ упало, это очевидно, с другой стороны количество программ возросло (в природе не бывает бесплатного сыра — если вы пишите быстрее, сложнее и больше — качество будет плохим, это закон)
— массовый софт да и хард стал вопиюще несопровождаемым и "кривым" архитектурно — это просто следствие всех вышеперечисленных пунктов да еще и поддержка совместимости сказывается, тем не менее большое внимание сейчас уделяют исправлению архитектуры (новые языки, массовые правила, паттерны банды 4-х и т.п.)
— программирование стало занудной рутиной во многих своих проявлениях

Так что криминала не вижу. Так все отрасли развиваются и ИТ — не исключение. Отсутствие "эффективных" программ сейчас вполне объяснимо и терпимо. Так просто надо сейчас и все.

Кстати, заметили ли вы что большинство фундаментальных открытий в ИТ отрасли было сделано в 60-80-е годы? Нет, сейчас тоже что-то открывают, но это эволюционные открытия, а не революционные. Например из-за возросшего быстродействия теперь стало возможным использовать те более эффективные алгоритмы, которые раньше считались слабо перспективными и т.п. И самые "новые" процессоры, шины и алгоритмы уже придумали "дядьки" из 60-х. Но! Это я не к тому, что в отрасли настал кризис, нет! Наоборот — это значит что отрасль сформировалась как таковая, "повзрослела" что-ли, и это здорово. И теперь она будет именно такой (по крайней мере до очередной метаморфозы связанной с кризисом бизнеса в ней, например, но это уже другая история).

Теперешних программистов можно понять. Многие, например, неявно заинтересованы в том чтобы новая версия windows содержала больше ошибок, занимала больше места на диске и в памяти и работала медленнее (и похоже так и будет — исключений здесь не бывает так как того требуют ускорения сроков разработки, увы чудес не бывает). Это позволит им кормиться "на ней" разрабатывая такие же "неэффективные" программы (по занимаемому объему и быстродействию) потому что пользователь вынужден будет улучшить свой компьютер. А значит писать эти программы они будут еще быстрее — а это сейчас главное! Программирование как таковое многим уже не интересно — интересны лишь деньги, которые можно на этом заработать. Зачем что-то оптимизировать, искать ошибки, прорабатывать архитектуру? Как сейчас говорят — "пипл хавает" и баста, главное опередить (ну или скупить на корню) конкурентов. Программирование уже давно не наука, а бизнес!

PD> И вот тогда этот неэффективный стиль программирования даст себя знать!

PD>Сейчас можно просто рассуждать — чего я буду 20 Мбайт экономить, если
PD>пользователь без проблем 256 может докупить ? А вот когда опять в жестких
PD>лимитах работать придется — окажется, что некоторые программы, которые вполне
PD>могли бы быть написаны, написаны не будут, или же будут написаны лет через 10
PD>после того момента, когда они могли бы появиться! Потому что эффективно
PD>работать большинство не умеет. Привычки у них такие — что нам стоит лишних
PD>десяток Мбайт взять!
Вы в корне не правы. Когда (и если) наступят такие времена, что надо будет делать снова "хорошие" программы — за дело опять возьмутся профессионалы, только теперь уже матерые программисты-профессионалы (опыт-то есть!). И они напишут и компилятор паскаля в 64к и еще много чего другого. Людей такого скалада не много, но они есть, и когда часы пробьют — они окажутся востребованней, чем те кто пришел в программисты за легкими деньгами...

Маленький совет сочуствующим автору. Вы любите чистое творчество, сложные неординарные задачи, непаханные поля новых технологий? Уходите из программирования. Я имею ввиду не "телом", а "душой". Т.е. можно продолжать зарабатывать на этом поле деньги, а тем временем прорабатывать новые, хотя бы смежные, отрасли. Чертовски приятно видеть как происходит становление новой технологии! И там есть где разгуляться пока туда не нагрянули люди с огромными мешками денег и не началась грызня за эти самые мешки :-)

Да и еще. Я не хотел обижать нынешних массовых программистов. Даже пресловутых индусов. Никоим образом! Они молодцы и достойно развивают отрасль ставя производство программ на конвейер и шлифуя его и оттачивая в мелочах в т.ч. и на своих ошибках. Это титанический труд!

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!
Перефразируя, можно дать более правильный совет (ИМХО): работу надо стараться делать хорошо, потому что плохо оно само получится. А эффективность программ здесь не причем, если сейчас выгоднее писать быстрее — значит именно это и надо делать. Да и где четкие критерии этой самой эффективности? Они же меняются со временем... Надо писать соответственно текущему уровню развития отрасли. Раньше это было компактно и не спеша, сейчас дешево и быстро, завтра будет еще что-то и т.д... Но при этом — если вы профессионал вы должны уметь писать по-любому из этих критериев и держать руку "на пульсе".

p.s. Все вышеизложенное — это сугубо мое мнение, хотя я старался быть максимально объективным. Ничего личного.
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: gear nuke 
Дата: 07.10.05 04:53
Оценка:3 (1)
Здравствуйте, Павел Кузнецов,

>> Излишней является любая оптимизация, которая не направлена на изменение ситуации, при которой система не способна уложиться в определенные в проекте временные рамки на том оборудовании, для работы на котором она предназначена.


ПК>Только та, которая стоит дополнительного времени при разработке.


ИМХО любая оптимизация будет стоить дополнительного времени, если проектировать и делать "абы работало".
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: Dyomahttp://www.livejournal.com/users/dyomap/
Дата: 06.10.05 12:31
Оценка:1 (1)
Здравствуйте, savaDAN, Вы писали:

DAN>И чем же она может выйти боком? тем что народ разучится писать эффективные программы? Но это ж не секрет дамасской стали.

DAN>К тому же большинство из нас писать эффективные программы могут, и даже любят... но им этого менеджеры не дают... и правильно делают, я писал выше почему.

Есть разница оптимизить, потому что это нравится и потому что это надо. Любят оптимизить именно там, где нравится, доводя эффективность до предела в (почти) неиспользуемом коде, а сам код до предельной нечитаемости.

DAN>А тенденция не поменяется пока не закончатся гигагерцы и гигабайты.


Лично я воспринял исходный пост, как предупреждение, что понятие "оптимальный", в частноти, у меня сейчас совсем не такое, как было у автора лет 20 в фигом назад, и даже не такое как было у меня лет 10 назад. Кое что потеряно ради быстрого написания приемлимого для современных компов кода. Призыв писать программы эффективно на сколько возможно, я понимаю как не расслабляться и быть готовым думать про эффективность больше. Именно думать, а не наворачивать супер алгоритмы где умею.

Dyoma
ALMWorks
http://deskzilla.com/
Re[6]: Об эффективности программ в избранное  новое    модер.  /!\
От: eao197http://eao197.blogspot.com
Дата: 06.10.05 14:30
Оценка:1 (1)
Здравствуйте, pp2, Вы писали:

pp2>Варианты конечно всегда есть, но даже если софт "свой", и на продажу в конечном счете, то рынок одинаково "безжалостен" ко всем. Как опередить конкурентов? Как предложить больше всяких фич и сэкономить бюджет проекта? Ну и т.д., соответственно "творчество" здесь весьма на любителя. И кстати частично даже не в области программирования вообще.


+1

pp2>Если софт открытый или не на продажу — то да, возможны варианты. Хотя общая тенденция на лицо.


Тенденция на лицо, но это совсем не означает, что ей нужно безусловно поддаваться. Тут, имхо, так: либо ты ищещь оправдания, либо возможности. Возможности искать труднее. Я, например, пытаюсь. И поэтому мне не интересно думать о том, что искусство становится ремеслом, места для фантазии не остается, индустрия выживает изобретателей и пр. Это не конструктивно.

Среди заповедей для художника от Сальвадора Дали была такая: "Художник -- рисуй!"
Очень к месту, имхо.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 10.10.05 03:49
Оценка:1 (1)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>> char szTotal[1000];

PD>> char * szStrings[3] ={"abc", "def", "ghi"};
PD>> int nStrings = 3;
PD>> char* pCurrent = szTotal;
PD>> for(int i = 0; i < nStrings; i++)
PD>> pCurrent += sprintf(pCurrent,"%s",szStrings[i]);

S>Гм. Мне не хотелось бы прослыть человеком, приносящим дурные вести, но ты только что продемонстрировал способ внести в программу buffer overrun vulnerability.

S>Если не дай байт кто-то изменит содержимое szStrings так, что оно перестанет помещаться в szTotal (который ты предусмотрительно разместил на стеке), то спринтф чудесным образом разрушит стек.

Это уже совсем несерьезно. Человек спрашивал, как технически, т.е. с помощью каких средств языка С++ можно такое сделать. Я ему и показал. Неужели я не понимаю, что 1000 может не хватить ????


S>Это, на мой взгляд, не вполне адекватная плата за однопроходность.

S>Еще я бы хотел отметить, что в твоем примере все живет за счет сверхмалых размеров строк. На таких объемах можно хоть перевыделениями заниматься — существенного падения производительности ты не добъешся. А как только мы заговорим о более реалистичном мире, где действительно станет нужна оптимизация строковых операций, выделение фиксированного буфера в стеке моментально исчезнет из поля нашего зрения.

А, прошу прощения, если не знать или хотя бы предполагать общий размер, то задача вообще не разрешима в однопроходном варианте. Потому как нельзя копировать в буфер, не выделив его предварительно. А длины в С++ не хранятся, в отличие от С#. На Паскале можно, там они хранятся.

S>Поэтому настоящие программисты всегда используют нормальный оо-код из std:: вместо всяких спринтфов и прочей небезопасной ерунды.


Нормальные герои всегда идут в обход (C) Доктор Айболит.

S>З.Ы. Кстати, поиск целого в массиве тоже лучше честно делать через

S>
S>for(int i=0; i< arrayLen; i++) if array[i] == searched return i;
S>

S>а попытки задействовать хардкор типа rep scasd ни к чему хорошему не приводят.

Стоит ли его использовать или нет — вопрос спорный, а вот почему не приведут — объясни, пожалуйста.
With best regards
Pavel Dvorkin
Re: Об эффективности программ в избранное  новое    модер.  /!\
От: bkat 
Дата: 05.10.05 10:48
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько

PD>это возможно!

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

В общем призыв "оптимизируйте везде" так же далек от жизни,
как и призыв "забейте на оптимизации и просто докупите память".
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 06.10.05 03:49
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Pavel Dvorkin, Вы писали:



PD>> И действительно, как было не признать! Пока программа небольшая и в память

PD>>помещается — ладно, живите и радуйтесь! Ну а как побольше стала ? Тут-то и
PD>>придется признать свое бессилие. А гуру, им что, всегда что-нибудь придумают.
PD>>Кто-нибудь из нынешнего поколения слышал про "самоубийство программ" ? Нет, это
PD>>не стирание EXE-файла во время его работы. Это когда программа во время своей
PD>>работы использует память, занятую своими командами (которые уже отработали и
PD>>больше не потребуются) под свои данные.
GZ>У меня это называлось overlay.

Нет, оверлей — это нечто иное. Я этим на СМ-4 и ЕС-1022 занимался, это вполне легальное действие, даже ассемблер не требуется. А самоубийство только на ассемблере делалось, даже ИМХО не на ассемблере тогда, а просто в кодах.

PD>> Дудки вам, а не 640 Кбайт. В 640 Кбайт сейчас умеют только "Hello,

PD>>World" укладывать! Пока несколько десятков Мбайт не будет, и не подходите.
GZ>Ты Турбо-Vision пользовался?

Немного.

GZ>Я тоже горячился когда оказалось что exe файл для Delphi был больше мега(сейчас не помню, но для тех времен очень много). Но то, что я мог мышью быстро собрать приложение и получить за него деньги перевешивало. Как программисту который уважает свое творчество, это плохо. А вот для человека который пытается на хлеб масло намазать, чрезвычайно хорошо.




GZ>NT 4.0 на 8 мегабайтах не работала, а обслуживала саму себя. И то, если сервис паки не ставить.


Ну пусть на 16

GZ>Так оно места то много не занимает. Оно действительно эффективно. А вот если говорить о сопутсвующих процессах, типа сервисов и т.д., или тех же картинок, то это и есть увеличение. С установкой сервис паков и добавления функциональности, ситуация выравнивается.


Чудно. А могу я эти сервисы безболезненно удалить, и освободить Мбайт так 50-60 ? Немного — получится, а остальные, увы, обязательны для системы. А мне, в общем, все равно, как это называется, ядро или сервисы, лишь бы занимали они поменьше.

GZ>Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват?


А какое это имеет отношение к тому, о чем я говорил ? Если машина загружена сверх ее реальных возможностей — конечно, ты не виноват. А вот если реальные возможности машины позволяют загрузить 10 копий твоей программы (без вордов и эксцелов), будь она эффективно написана, а она написана так, что и 3 копии тормозят — виноват ты.

Ты можешь сформулировать когда программу можно считать избыточной?

Попробую.
Программа избыточна, когда она
1. Использует памяти больше, чем требуется.
2. Загружает процессор больше, чем требуется.
3. Хранит на диске файлы большего размера, чем требуется.

А требуется — по характеру задачи.




PD>>Или вот другой пример — с умножением матриц

GZ>Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.

Дошли до того, что здесь виной перегрузка в кэше оверхеда на класс массив.Но по мне хоть кэш, хоть процессор, хоть винчестер, хоть дух святой. Не желаю я причин знать , а просто факт констатирую — машина это может в несколько раз быстрее делать, значит и должна делать!

GZ>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест. А также оптимизацией памяти, если ее оказалось недостаточно.


Ничего у вас не получится. Потому что эти узкие места вы, может, и найдете, а вот общий уровень все равно с оверхедом будет. Там Мбайт, здесь Мбайт — в итоге 100 Мбайт и виновных нет.

PD>>Хороший, кстати, пример — ICQ. Написана она не на .Net ИМХО (давно

GZ>Жадные вы. Че вам памяти жалко?
GZ>Во первых, ICQ — это глюк официально выходящий в альфа-бета видах. Притом накрученная функциональностей, которая особо никому и не нужна.

А у ICQ вообще когда-нибудь не-беты были ? У меня что-то впечатление такое, что она только из бет и состоит

GZ>Во-вторых, не стоит по одной-двух программах делать выводы о отрасли в целом. Во времена MSDOS, были свои глюкавые монстры.


Ну другие примеры уже привели, не буду повторяться.

PD>>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не

PD>>слишком думая об эффективности, а потом узкие места можно оптимизировать.
GZ>Подпишусь.

Имеешь право

GZ>Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы.


Пользователь доволен. Вполне. И если он у тебя один — решай с ним все проблемы. А вот когда речь о продуктах, используемых в миллионах копий идет — тут задавать вопрос, доволен ли пользователь — все равно, что спрашивать, оуениваете ли вы положительно работу ГосДумы . Отдельно одной программой доволен, другой — доволен, третьей доволен, все вместе запустишь — недоволен. Жалуйтесь кому хотите, хоть господу богу.


GZ>Аналогия неуместна. Важно насколько клиенту важно чтобы он летал. Зачастую заказывают атомную подводный крейсер, а тебе выкатят Ту155 с 5 подводными винтами. И вроде двигается быстрее чем нужно. И летает, что не заказывали. И вроде винты красивые и их больше чем нужно. Но не плавает. Ну не успели научить.


Бывает и такое. Как в известном анекдоте, как ни собираю, а пулемет получается. Но почему аналогия неуместна — не понял.

GZ>Не согласен. Уже вверх перестали развиваться такими темпами. Зато начали развиваться вширь.(двухядерные процы)


Я же не утверждаю, что я прав. Дай бог, чтобы я неправ в этом был.

GZ>А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.


Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ?
With best regards
Pavel Dvorkin
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 06.10.05 06:19
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

MS>Не согласен. Я бы сказал, что это вещи вещи независимые — "этого научить проще тому-то, чем вот этого — противоположному". Здесь главное — чтобы человек обладал некими общими инженерными навыками. Фишка в том, что если человек умеет оперировать байтами в памяти, он как минимум знает, как устроен компьютер. И если он является инженером по своей сущности, то он очень быстро поймет, почему этого не надо делать в дот-нет. И наоборот, если человек начал с дот-нет, но при этом он обладает некими инженерными знаниями, он очень быстро разберется в том, как надо делать эффективно. Встречаются упертые личности — одни на ASM, другие — на C#, но они — не инженеры. И вопрос переучивания — он больше психологический чем технический. Если человек является инженером по своей психологии, то он переучивается легко — хоть туда, хоть сюда. Если же это для него туго, то наилучший способ его задействовать — это поставить на ковейер — пусть работает как машина Тьюринга и выполняет команды. Не хочет? — ну и ладно, найдем другого. Все это и ко мне тоже относится — так что просьба не принимать на личный счет.


Я конечно и не спорю, если человек вменяем — переучить его не проблема. Но слишком уж часто охота за байтами превращается в навязчивую манию, с которой чертовски трудно бороться — по себе знаю . Именно поэтому обучение надо начинать "сверху", а не "снизу", ИМХО
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[2]: Закон Мура умер в избранное  новое    модер.  /!\
От: Valentin Butakov 
Дата: 06.10.05 06:48
Оценка: :)
Здравствуйте, gear nuke, Вы писали:

GN>ИМХО не стоит забывать, что развитие часто идёт по спирали...

Это не развитие идет по спирали, это просто отдельные люди любят повторять старые и давно известные ошибки...
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 06.10.05 09:04
Оценка: +1
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Но вот одно либо я недостаточно четко изложил, либо меня не поняли, либо не хотели понять. Я не призыаваю к тотальной оптимизации, это просто глупо, в конце концов. И те, кто меня в этом упрекают, зря стучатся в открытую дверь. Я выступаю за то, чтобы код на своем уровне писался эффективно. Чтобы не использовались явно избыточные по памяти или времени конструкции, когда это совсем не обязательно и вполне ясно, как без них обойтись, отнюдь не поступаясь при этом ясностью и четкостью.


Д>Что в лоб, что по лбу — особой разницы я не вижу


Оптимизация всего и вся либо же не использование заведомо неэффективных конструкций — и ты не видишь разницы ? Ну, тогда сложно сказать что-то еще.
With best regards
Pavel Dvorkin
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 06.10.05 09:15
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Оптимизация всего и вся либо же не использование заведомо неэффективных конструкций — и ты не видишь разницы ? Ну, тогда сложно сказать что-то еще.


А ты прочитал статью? Там есть как раз про "заведомо неэффективные конструкции". Почитай, в частности, про страшный алгоритм сложности f(n^3)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: savaDAN 
Дата: 06.10.05 10:44
Оценка: +1
D>Я абсолютно согласен с ортимизацией "где надо", речь не об этом. В исходном посте посте говорилось о тенденции, о появившихся привычках и том, что понятие "оптимальный" просто забывается, уходит вслед за 1Mhz компами и 640Кb памяти. И что эта тенденция очень может выйти боком в свете физических пределов GHz и Gb.
И чем же она может выйти боком? тем что народ разучится писать эффективные программы? Но это ж не секрет дамасской стали.
К тому же большинство из нас писать эффективные программы могут, и даже любят... но им этого менеджеры не дают... и правильно делают, я писал выше почему.
А тенденция не поменяется пока не закончатся гигагерцы и гигабайты.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: McSeem2http://www.antigrain.com
Дата: 06.10.05 13:35
Оценка: +1
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Мда. Энтузиасты и вольные художники формируют эту индустрию.

ЗХ>Ну да к вечеру вернется McSeem2, он тебе подробнее объяснит

ЗХ>Конечно, а зачем?




http://www.rsdn.ru/Forum/Message.aspx?mid=1422736&only=1
Автор: McSeem2
Дата: 06.10.05
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 06.10.05 13:58
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Перекодирование строки из файла из 866 в 1251.


PD>Все что я нашел, сводится к


PD>public string MyDecoder(string str)

PD>{
PD> byte[] b = Encoding.GetEncoding(866).GetBytes(str);
PD> str = Encoding.GetEncoding(1251).GetString(b);
PD> return str;
PD>}

Гон. В файле нет строки. В файле есть байты.
Поэтому достаточно использовать ровно один Encoding.Convert.
Если ты из файла получил строку, то ты сам виноват — делаешь три Convert вместо одного.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Nickolay Ch 
Дата: 06.10.05 15:26
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Nickolay Ch, Вы писали:


NC>>Буду краток: писать код надо так, чтобы из него можно было получить максимальную денежную прибыль.

GZ>Хорошие слова. Только не надо под ними подразумевать скорость написания кода. Действительно, существует достаточно много продуктов сделанных тяп-ляп. Да, они выиграли тактически. Они впихнули полуживое решение и получили за них деньги.
Уже 2 раза тут писал, что под этим понимается каждый раз разное. И далеко не всегда скорость написания, так же как и далеко не всегда "нересурсоемкость" и т.п.

NC>>Уважаемый mrozov правильно написал, что времена любителей позаниматься сексом с компом прошли в индустрии программирования.

GZ>Нет, не прошли. Просто пришла мода на другие извращения. IMHO

И слава богу (С)

NC>>Энтузиастам и "вольным художникам" не место в индустрии.

GZ>Место. И притом денежное место. Индустрия большая. Даже в замой замшелой конторе с шизофреническими процессами разработки, есть место творчеству. Просто у архитектора — одно поле для творчества, у программиста — другое. У меня есть друзья, я по одному взгляду могу сказать кто какой код писал. Потому как каждый индивидуален в своих предпочтениях.

Вообще-то особенно при работе в команде код должен быть подчинен стандарту. Суть в том, что основная часть производства софта это именно индустрия, масс-продакшн.
Выдержали отдельно взятые ремесленники конкуренцию с мануфактурой? А ведь каждый из них был МАСТЕРОМ?
Да, и сейчас есть, мастера, делающий некие продукты руками, скажем какую-нибудь резную мебель, не придерживаясь стандартов производства и т.п. Только много ли их? И много ли они производят в процентном соотношении от всей произведенной мебели?
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 06.10.05 23:48
Оценка: +1
mrozov,

> Излишней является любая оптимизация, которая не направлена на изменение ситуации, при которой система не способна уложиться в определенные в проекте временные рамки на том оборудовании, для работы на котором она предназначена.


Только та, которая стоит дополнительного времени при разработке.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 07.10.05 00:26
Оценка: +1
pp2,

> Многие, например, неявно заинтересованы в том чтобы новая версия windows содержала больше ошибок, занимала больше места на диске и в памяти и работала медленнее (и похоже так и будет — исключений здесь не бывает так как того требуют ускорения сроков разработки, увы чудес не бывает)


В отношении количества ошибок прогноз не вполне оправдывается: чем дальше после Windows 95, тем их меньше. В следующих версиях обещают еще лучше, т.к. вкладывают деньги в повышение качества разработки.
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 07.10.05 08:29
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Кстати, вот еще пример. Из официального руководмтва Микрософт, между прочим


PD>Есть строка myString в формате CSV


PD>myDataSet.Tables["Table 1"].Rows.Add(myString.Split(char.Parse(",")));


PD>Берем строку, делаем из нее массив строк и по запихиваем этот массив в Rows. А нельзя ли без того, чтобы массив создавать ? В C++ я бы просто прошел по этой строке strtok и добавил строки — без всяких дополнительных массивов.

Павел. Ситуация со строками значительно интересней. Строка — это неvalue объект. И она не будет копироваться. Просто передается ссылка. А выделение маленького объекта в С# на порядок дешевле чем в С++. Поэтому это достаточно простой способ и эффективный.
Функции strtok нету(неприятная функция, я ее не люблю, в таких случаях работаю обычным поиском), точно также как нет split в С, но написать такую функцию легко. В принципе,
int i, l=0;
while ((i=myString.IndexOf(",", l))!=-1)
{
      rows.Add(myString.Substring(i, l-i);
      l=i;
}

Делает именно то, что заказывали. Без массива.
Сравните с тем-же самым в C++ только с strtok.

С уважением, Gleb.
ЗЫ. Интересно, если я напишу так
int l, i=0;
while ((i=myString.IndexOf(",", (l=i)))!=-1)
      rows.Add(myString.Substring(i, i-l);

Хоть не читабельно, но зато красиво
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 07.10.05 10:55
Оценка: :)
Здравствуйте, GlebZ, Вы писали:


GZ>{

GZ> rows.Add(myString.Substring(i, l-i);

А здесь не создается временная строка в результате работы Substring ? Если так написать

string sTemp = myString.Substring(i, l-i);
rows(Add);

то ясно, что создается. А это отличается только тем, что ссылка на эту строку записывается во временную переменную.


GZ>Делает именно то, что заказывали. Без массива.


Зато с временными строками (== те же массивы)
With best regards
Pavel Dvorkin
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 07.10.05 11:01
Оценка: :)
Здравствуйте, RobinBobin, Вы писали:

RB>Здравствуйте, Pavel Dvorkin, Вы писали:



RB>

RB>На C++ конкатенацию массива строк в новую строку (я имею в виду не string из STL, а char*) я все же напишу однопроходным алгоритмом и при этом не будут использоваться никакие промежуточные буферы.



RB>Как ?


char szTotal[1000];
char * szStrings[3] ={"abc", "def", "ghi"};
int nStrings = 3;
char* pCurrent = szTotal;
for(int i = 0; i < nStrings; i++)
pCurrent += sprintf(pCurrent,"%s",szStrings[i]);
With best regards
Pavel Dvorkin
Re[4]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 07.10.05 11:15
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Sinclair, sorry, а не мог бы ты подсказать, как здесь эффективно сконкатенировать все же массив строк при том, что количество их определится в момент конкатенации?

S>С массивом все вообще просто. См. string.Join.

+

PD>>Твой первый пример хорош, но там жестко 3 строки. На C++ конкатенацию массива строк в новую строку (я имею в виду не string из STL, а char*) я все же напишу однопроходным алгоритмом и при этом не будут использоваться никакие промежуточные буферы. Потому что задача по определению однопроходная.

S>Это как, интересно?

Не понял, ты спрашиваешь, как в C++ сделать ? Я уже отвечал.

http://www.rsdn.ru/Forum/Message.aspx?mid=1424567&only=1
Автор: Pavel Dvorkin
Дата: 07.10.05



S>Не так ли:

S>
S>public static string Join(IEnumerable<string> strings)
S>{
S>  int len=0;
S>  foreach(string s in strings)
S>      len+=s.Length;
S>    StringBuilder sb = new StringBuilder(len); // избегаем перевыделений
S>  foreach(string s in strings)
S>      sb.Append(s);
S>    return sb.ToString();
S>}
S>

S>?

Да, то же самое. Спасибо.

PD>>Здесь это можно, используя только string, а не StringBuilder ?

S>Можно. Но уволят.

With best regards
Pavel Dvorkin
Re[8]: Об эффективности программ в избранное  новое    модер.  /!\
От: mrozov 
Дата: 07.10.05 12:09
Оценка: -1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.


А вот это — более чем спорно. Я бы даже сказал, что подобные заявления отдают манией величия =)
Не думаю, что стоит вот так категорично говорить о том, что вам должны инструментальные средства.
Re[13]: Об эффективности программ в избранное  новое    модер.  /!\
От: srggal 
Дата: 07.10.05 13:07
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>А в форуме-то ты сейчас чего делаешь?


СПАСИБО

А я не в форуме — я на работе
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 07.10.05 13:10
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD> char szTotal[1000];

PD> char * szStrings[3] ={"abc", "def", "ghi"};
PD> int nStrings = 3;
PD> char* pCurrent = szTotal;
PD> for(int i = 0; i < nStrings; i++)
PD> pCurrent += sprintf(pCurrent,"%s",szStrings[i]);

Гм. Мне не хотелось бы прослыть человеком, приносящим дурные вести, но ты только что продемонстрировал способ внести в программу buffer overrun vulnerability.
Если не дай байт кто-то изменит содержимое szStrings так, что оно перестанет помещаться в szTotal (который ты предусмотрительно разместил на стеке), то спринтф чудесным образом разрушит стек.

Это, на мой взгляд, не вполне адекватная плата за однопроходность.
Еще я бы хотел отметить, что в твоем примере все живет за счет сверхмалых размеров строк. На таких объемах можно хоть перевыделениями заниматься — существенного падения производительности ты не добъешся. А как только мы заговорим о более реалистичном мире, где действительно станет нужна оптимизация строковых операций, выделение фиксированного буфера в стеке моментально исчезнет из поля нашего зрения.

Поэтому настоящие программисты всегда используют нормальный оо-код из std:: вместо всяких спринтфов и прочей небезопасной ерунды.

З.Ы. Кстати, поиск целого в массиве тоже лучше честно делать через
for(int i=0; i< arrayLen; i++) if array[i] == searched return i;

а попытки задействовать хардкор типа rep scasd ни к чему хорошему не приводят.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 07.10.05 13:12
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

>> Заметка из жизни. Если у программиста проблемы с ДНК, то C# многое прощает, а вот шаблоны в С++ многое усугубляют.

Не думал что подобная заметка из жизни вызывет флейм о вилках и детской посуде.

ПК>Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.

Только вопрос в том, что для кого программирование работа, а для кого-то призвание. И первых значительно больше чем вторых.
Так что если говорить о промышленных языках, то я бы сказал что они есть компромисс — помочь первым, и не мешать вторым.

С уважением, Gleb.
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: WolfHound rsdn 
Дата: 07.10.05 13:29
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>    char szTotal[1000];
PD>    char * szStrings[3] ={"abc", "def", "ghi"};
PD>    int nStrings = 3;
PD>    char* pCurrent = szTotal;
PD>    for(int i = 0; i < nStrings; i++)
PD>        pCurrent += sprintf(pCurrent,"%s",szStrings[i]);


Вот так и получаются программы с переполнением буфера.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Об эффективности программ в избранное  новое    модер.  /!\
От: Nickolay Ch 
Дата: 07.10.05 19:55
Оценка: -1
Здравствуйте, eao197, Вы писали:

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


pp2>>Маленький совет сочуствующим автору. Вы любите чистое творчество, сложные неординарные задачи, непаханные поля новых технологий? Уходите из программирования. Я имею ввиду не "телом", а "душой". Т.е. можно продолжать зарабатывать на этом поле деньги, а тем временем прорабатывать новые, хотя бы смежные, отрасли. Чертовски приятно видеть как происходит становление новой технологии! И там есть где разгуляться пока туда не нагрянули люди с огромными мешками денег и не началась грызня за эти самые мешки


E>Давайте это Ричарду Столлману (GCC, emacs), Линусу Торвальдсу (Linux), Тео да Радту (OpenBSD), Гвидо ван Россому (Python), Ларри Уоллу (Perl), Якиро Матцумото (Ruby), ...(список можно продолжать)..., раcскажем. А то мужики, право слово, фигней страдают. Надо их жизни-то научить.


E>


E>Ребята, если вы относитесь к программированию как к обычной работе, средству заработка, то и относитесь себе так и дальше. Зачем же подобные советы давать


Т.к., в основном, в этом разделе пустой фелйм, то могу ответить Вам симметрично:
Если вы относитесь у программированию как к искусству, то и относиесь себе и дальше, советы давать то зачем
Мы с вами будем одинаково правы в подобных советах.
Я достатосно резко написал так потому, что исходный призыв был столь же эмоционален сколь и пуст.
"Пишите эффективно" — и Столлман пишет эффективно, и армия индусов в МС(или где там еще), просто "эффективность" у каждого своя...
Всех то стричь под одну гребенку зачем?
Re[6]: Об эффективности программ в избранное  новое    модер.  /!\
От: gear nuke 
Дата: 08.10.05 00:14
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Например, есть выбор: написать сортировку "пузырьком" или использовать библиотечную std::sort. Первое делать дольше и в большинстве случаев работать будет медленнее, чем второе.


Вот, кстати, хороший пример Вы привели. А если человек не понимает, что и почему лучше, он запросто может реализовать то, что первое придёт в голову (пузырёк) .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[7]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 08.10.05 00:21
Оценка: +1
Cyberax,

>> Гм. Мне не хотелось бы прослыть человеком, приносящим дурные вести, но

>> ты только что продемонстрировал способ внести в программу buffer
>> overrun vulnerability.

> Вот политкорректный вариант:

>
> std::string res;
> res.reserve(100); //Разумное число
> for(int f=0;f<nStrings;f++)
>     str.append(szStrings[f]);
>

> Безопасно, причем если результирующая строка меньше 100 символов, то не
> будет лишних переаллокаций.

А при желании можно даже сохранить начальное выделение памяти в стеке для строк:
fast_buffer<char, 100> res;
for(int f=0; f < nStrings; f++)
     res.append(szStrings[f]);
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[2]: Об эффективности программ в избранное  новое    модер.  /!\
От: Cyberax 
Дата: 08.10.05 13:12
Оценка: +1
iZEN wrote:

> Есть такая парадигма: service-oriented architecture (SOA).

> Она есть и успешно работает в MacOS X. Грубо — это когда пользователь
> вместо покупки программы за $400 с навороченным интерфейсом и
> ненужными (для него) фичами обходится мимтемным сервисом, но с нужной
> ему фичей за $25.
> Сервис проверки орфографии ВО ВСЕХ текстовых полях, а не только в
> конкретном текстовом редакторе одной известной фирмы — вот одно из
> следствий такого подхода. Маленький и не тормозит.

Надо сказать, что API для Вордовской системы проверки правописания
свободно доступны. У меня, например, они прикручены к Far'у.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: Закон Мура умер в избранное  новое    модер.  /!\
От: gear nuke 
Дата: 10.10.05 08:47
Оценка: +1
Здравствуйте, raskin,

>> *почему* до сих пор нет ни одного компилятора использующего это эффективно?


R>Современное управление кешем неполно (у кеша всегда есть и своё мнение

R>кроме prefetchnta) и непереносимо, поэтому никто не заморачивается?

Вот именно. ИМХО для этого по-хорошему нужен JIT компилятор, а такое есть пока только под .NET, можно сказать. В зачаточном состоянии, скорее всего. Обычные компиляторы сколько лет до ума доводили.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[13]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 11.10.05 00:38
Оценка: -1
Здравствуйте, GlebZ, Вы писали:

GZ>Да уж. Действительно сильно искуственный пример.

GZ>strok — злобная функция, так как она использует static данные на уровне CRT.

Хуже. Она использует __declspec(thread). Иначе, сам подумай, что будет, если ее начнут из разных потоков вызывать


>И соответсвенно, два выполнения strtok — прямой путь к нетрадиционному сексу. Лучше всего вообще забыть о ее существовании.


Вообще да. Я свою писал

GZ>Именно. А если у кого-то была ссылка на строку, то тебе надо делать копии. Но чаще придется делать копии, из-за того что ты не можешь предположить, будет строка изменяться, или нет.


Во многих и даже очень многих могу

const char* p — и я имею право предположить, что не будет.


GZ>По крайней мере одну придется делать(и не дай бог что TestWord тоже использует strtok):



GZ>
GZ>void MyWords(const char* str)
GZ>{
GZ>   char* myString=new char[strlen(str)+1];
GZ>   strcpy(myString, str);
GZ>   p=strtok(myString,",");
GZ>   while(p)
GZ>   {
GZ>     TestWord(p);
GZ>     p = strtok(NULL,",")
GZ>   }
GZ>}
GZ>


Да зачем же ? Пусть TestWord себе благополучно эту строку исследует (например, является ли слово палиндромом). Начало — p, конец — '\0', зачем мне тут подстроки в отдельный буфер копировать, когда и на месте все ясно ?
With best regards
Pavel Dvorkin
Re[14]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 11.10.05 12:46
Оценка: +1
Pavel Dvorkin,

> когда речь идет о коде, разработанном для данного проекта, то во многих случаях Copyright на этот код получит заказчик. Так что повторно его использовать законным путем можно только в том случае <...>


Пожалуй, при разговорах о повторном использовании речь идет о других проектах, делающихся "для себя". Особенно актуально это для (относительно) маленьких команд и/или (относительно) долгоживущих проектов.

> Интересно было бы узнать — насколько часто программисты действительно повторно используют свой код? Т.е не идеи из него используют для нового кода, а прямо-таки класс/функцию/компонент свой берут и в новый проект втыкают.


Мы стараемся делать это настолько часто и в таком объеме, насколько у нас получается, т.к. это напрямую связано с эффективностью работы над очередным проектом (больше повторно используемого кода -- меньше работы над данным проектом).

> Естественно, речь не идет о библиотеках.


При достаточном приложении усилий к повышению удельного "веса" кода, используемого повторно, он почти неизбежно со временем превращается в более-менее изолированные компоненты, библиотеки или фрэймворки (в последнем случае об изоляции, естественно, речь идет в значительно меньшей степени).
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[4]: Об эффективности программ - мои замечания в избранное  новое    модер.  /!\
От: Igor Sukhov rsdn 
Дата: 13.10.05 14:15
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Игорь, я вовсе не утверждаю этого И более того, если есть 1 млн. программистов на нем, то они за что-то деньги свои получают. Я о другом говорю. До сих пор была определенная разница между тем, что можно было хотя бы в принцие писать на VB и тем, для чего VB не может рассматриваться как среда разработки вообще.


PD>Например, я сильно сомневаюсь, что Adobe могла бы рассматривать VB как среду для разработкт своих продуктов. И даже на порядок более простой какой-нибудь file downloader тоже на VB никто писать не стал бы. Не то средство.


если приглядеться — у формы автоапдейтера Microsoft AntiSpyware просвечивает VB икона =)

PD>А вот будет ли Adobe переписывать PhotoShop на .net — не знаю. Надеюсь, что нет

главное чтобы программа была удобная, а на чем ее переписывали — мне уже не интересно.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
* thriving in a production environment *
Re[19]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 19.10.05 06:03
Оценка: +1
Здравствуйте, Дарней, Вы писали:

Д>расшфировал аббревиатуру — правильно. Понял смысл — неправильно.

Д>Не вижу вообще смысла спорить на эту тему. Есть общепринятое значение, которое вкладывается в это выражение. А если ты решил для себя, что будешь называть стол стулом — то это исключительно твои частные проблемы.

Допустим, что я понял это неправильно (хотя, честное слово, впервые об этом принципе я прочитал еще в 80-е годы, и в книге, которая к Unix не имела отношения. В таком случае будь добр объяснить, в чем неправильность моего понимания. Заявлять же — "ты неправ, и я не вижу смысла соприть на эту тему" — не есть аргумент.

Д>раз в месяц? да вы, батенька, оптимист


Нет, я ее просто не держу. . Поэтому статистики не знаю. Триллиан падал за несколько лет раз 5, и то обычно при Windows shutdown (что-то они там не учли, видимо)


PD>>Ну несерьезно это. Есть страна, для которой я это делал. Есть у них в стране некая информация (извини, но деталей рассказывать не буду). Эта информация там появилпась, когда еще никаких компьютеров на свете не было, а может, и автомобилей не было. И вот я эту информацию в некий буфер заношу. И то, что она никак не может быть больше, чем 500 символов — гарантия в 101%. Никогда не может, ну так же, как имя русское не может быть длиной в 500 символов. А времени считать эту длину абсолютно нет, потому как на все про все мне дано 100 мсек. И в этих условиях ты все же будешь утверждать, что buffer overrun возможен ?


Д>сразу вспоминается случай, когда разработчики решили, что длина серии паспорта не может быть больше 10 символов (может быть и не десять, не помню точно)

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


Ну и что ? Это лишь говорит о том, что они неверно оценили максимальный размер, только и всего.

Вот давай так

char szTotal[500];
sprintf(szTotal,"%s %s", szFirstName, szLastName);

Программа делается для России. Приведи ситуацию, в которой здесь возможен buffer overrun. Фамилию и имя, please , в студию.

Д>еще могу напомнить про случай, когда разработчики решили "ну не может эта переменная переполниться! ни никак! потому что этого не может быть никогда!"

Д>а потом в траекторию полета внесли изменения, и аппарат с треском рухнул.

Ну и что, опять-таки ? См. мой пример с nScreenArea. Может, оно когда-нибудь и грохнется, на 4ГПикс дисплее. Но не будешь же ставить под контроль все арифметические операции и на каждую из них писать try-catch из-за того, что при некорректно заданных операндах это может вызвать ошибку ? Или впрямь будешь писать везде так

int nScreenWidth = ..., nScreenHeight = ...;
int nScreenArea;
try
{
nScreenArea = nScreenWidth * nScreenHeight;
}
catch(...) {}

Если да — то неудивительно, что это будет работать очень медленно. А если нет — то при работе однажды произойдет unhandled exception, и аппарат рухнет.



Д>намного, намного хуже. А ты не догадываешься, почему?


Нет. Не догадываюсь. Потому что любая ошибка может привести к любой наведенной ошибке. А если ты хочешь сказать, что при этом будет неопределенное поведение — так и при неправильных результатах будет то же, не только при выходе индекса.


PD>>А лишних Гбайтов я , кстати, не использовал. И лишней ОП — тоже. Ну разве что самую малость — буфер там был один с запасом в 64 Кбайта


Д>и зря. Вполне возможно, что это позволило бы поднять скорость без ущерба для надежности.


Может , и позволило бы, вот тут я с тобой готов согласиться. Но мне просто не надо было. Ну не сидеть же мне и придумывать, где бы еще лишних 100 Мб израсходовать

А вообще основное различие между моей и твоей позицией ИМХО в том, что ты хорошо знаешь некоторые общепринятые принципы, но рассматриваешь их как догму, которую нельзя переступать, как сказал Sinclair, под страхом смертной казни. Я же считаю, что при определенных условиях может случиться так, что делать придется, нарушая многие общепринятые правила, если это нужно для решения задачи и другого выхода нет. В конце концов лучше написать работающую программу не по правилам, чем по правилам ничего не сделать.
With best regards
Pavel Dvorkin
Re[21]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 19.10.05 07:10
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

PD>>Программа делается для России. Приведи ситуацию, в которой здесь возможен buffer overrun. Фамилию и имя, please , в студию.

S>Очень просто. Этот код вызывается из обработчика веб формы регистрации пользователей.

Этот код НЕ вызывается из обработчика ВЕБ-форм. В этом случае так писать действительно не стоит. Этот код берет проверенные значения из БД, где для их хранения НЕ ОТВЕДЕНО 500 char. По-прежнему будешь утверждать ?

Я же говорю — истина конкретна. Если данные не вызывают доверия — один разговор. Если они вызывают доверие — другой. В моей задаче — вызывали.

S>Еще раз: то, как оно грохнется от целого переполнения, не приведет к исполнению постороннего кода.


Еще раз — истина конретна.

S>Будешь, если тебе дорого твое место работы. Причем кэтчить все места тебе не потребуется: как только придет информация о том, что где-то твое приложение упало, ты получишь нормальный стек трейс, в котором ясно будет указано место падения.


Придет. Равно как и в Win32 это можно сделать — StackWalk64 и вообще Send Error Report


S>Это позволит тебе очень быстро (по сравнению с анализом дампа) локализовать причины, и либо переписать код (например, используя long вместо int), либо вставить в нужных местах проверки (например там, где принимаются размеры).


В общем, мы Вас не защищаем уже от багов, мы лишь обеспечиваем, чтобы Вы могли их найти, когда приложение рухнет

PD>>А вообще основное различие между моей и твоей позицией ИМХО в том, что ты хорошо знаешь некоторые общепринятые принципы, но рассматриваешь их как догму, которую нельзя переступать, как сказал Sinclair, под страхом смертной казни. Я же считаю, что при определенных условиях может случиться так, что делать придется, нарушая многие общепринятые правила, если это нужно для решения задачи и другого выхода нет. В конце концов лучше написать работающую программу не по правилам, чем по правилам ничего не сделать.

S>Ты не прав. Если влезть в исходники .Net, то можно увидеть и unsafe, и unchecked. Как раз для того, чтобы поднять производительность. Это не переступание догм, это подробное следование им. Потому, что отмененные такими опциями проверки делаются вручную. Сделать правильную программу быстрой легче, чем быструю — правильной.

S>Потому, что обо всех небыстростях тебе расскажет профайлер, а о неправильностях — пользователи и хакеры.


ИМХО не стоит продолжать. Не договоримся. Разные позиции. Я готов с уважением относиться к твоей, но признавать ее как догму не могу.
With best regards
Pavel Dvorkin
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 19.10.05 08:50
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>У нас еще старый класс есть, для первокурсников, там 64 Мб и NT4. Вполне работает, SP последний.


Ну, это ничего. Скоро они начнут дохнуть. Все же техника не вечна.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[5]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 19.10.05 08:50
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.


Гы 100 000 даже для газет это офигительный тираж. А при ценах софта — это просто суперприбыли. При таких доходах можно позволить себе разрабатывать софт хоть на ассемблере. Так что это случай особый. Намного чаще стречаются малотиражные разработки с ограниченными бюджетами или вообще заказные разработки. Вот их точно лучше разрабатывать на средствах обеспечивающих более высокую надежность.

PD>Да ведь нам говорят, что .Net — генеральная линия развития, а те, кому она не нравится — неандертальцы.


Не нестандартны, а не дальновидны, и как это не обидно звучит, не плохие аналитики.

PD> Вот и мне сегодня заказчик сообщил, что планирует нечто на .Net. Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.


Может потому что твой заказчик более дальновидный человек?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[23]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 19.10.05 10:17
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Этот код НЕ вызывается из обработчика ВЕБ-форм. В этом случае так писать действительно не стоит. Этот код берет проверенные значения из БД, где для их хранения НЕ ОТВЕДЕНО 500 char. По-прежнему будешь утверждать ?

WH>Я тут не поленился и сделал тест...

<skipped>

WH>Итого: C# в 2 раза быстрее чем С++ (при том что в C# при каждом сложении происходит выделение памяти и работа идет с юникодом) и самое главное то что код на C# безопасен.


Ну и ну... Уж чего-чего, а такого не ждал. Сравнивать конкатенацию строк и форматное копирование , включающее в себя разборку форматной строки и бог знает что еще!
Естественно, в моей программе никакого sprintf не было. А была моя собственная функция ConcatenateStrings. А sprintf я просто привел, чтобы показать, как это можно сделать.
With best regards
Pavel Dvorkin
Re[24]: Об эффективности программ в избранное  новое    модер.  /!\
От: srggal 
Дата: 19.10.05 10:42
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Нет. Это не жизнь, это парадигма такая. Несмотря ни на какте реальные условия — предполагать, что может все что угодно произойти По деревянному мосту танк пойдет, великан ростом в 33 метра явится, экран будет в 4Г пикселей и т.д. Если нужна максимальная надежность — я за. А в текстовом редакторе — извините, я против того, чтобы ради этой надежности он в размерах в 2 раза увеличивался и работал медленно. Потому как меня как пользователя больше достает, что мне памяти не хватает. что ползет как черепаха и т.д. А упадет один раз в месяц этот текстовый редактор — ну и черт с ним. В крайнем случае, сделайте, как в Ворде — сохранение в temp файл раз в n минут.



Решил помочь с примером:
Есть в физике понятие материальная точка — это точка, размерами которой можно пренебречь, соответсвенно есть просто точка — её размерами пренебрегать не стоит.


Соответсвенно, в Вашем коде, если я правильно понял спринтф — материальная точка .
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[30]: Об эффективности программ в избранное  новое    модер.  /!\
От: Дарней 
Дата: 19.10.05 10:45
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Глупо.


вот и я о том же
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[23]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 19.10.05 11:46
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


WH>ЗЫ Замеры производились 100 раз. Самые быстрые и самые медленные результаты отбрасывались, остальные усреднялись.

WH>ЗЗЫ VS 2003

Вот мои результаты. Количество итераций цикла увеличил в 100 раз — не люблю я слишком малые значения

Твой код на C#. VS 2003, Release


    private static string Concat(string s1, string s2)
        {
            return s1 + s2;
        }
        [STAThread]
        static void Main(string[] args)
        {
            DateTime dStart = DateTime.Now;
            for (int i = 0; i < 10000000; ++i)
                Concat("iddqd", "idkfa");
            DateTime dEnd = DateTime.Now;
            Console.WriteLine(dEnd - dStart);
        }


100 раз пропускать не стал, вот первые 5 результатов

2.28
2.16
2.07
2.07
2.12

На C++ соорудил вот такой код — не слишком долго думая. VS 2003, Release



int _tmain(int argc, _TCHAR* argv[])
{ 
    DWORD dwTimeStart = GetTickCount();
    char* szFirstName = "iddqd";
        char* szLastName = "idkfa";
        char szTotal[500];
    char * pszTmpTotal,*pszTmpFirst, *pszTmpLast;
        for(size_t i=0;i<10000000;++i)
        {
            for(pszTmpTotal = szTotal,pszTmpFirst = szFirstName ; *pszTmpFirst;*pszTmpTotal++=*pszTmpFirst++); 
            for(pszTmpLast = szLastName; *pszTmpLast;*pszTmpTotal++=*pszTmpLast++); 
            *pszTmpTotal = '\0';
        }
    DWORD dwTimeEnd = GetTickCount();
    printf("%f\n",float(dwTimeEnd - dwTimeStart) / 1000);
    return 0;
}




Результаты

0.31
0.33
0.33
0.36
0.33

А теперь strcpy — strcat попробуем


int _tmain(int argc, _TCHAR* argv[])
{ 
    DWORD dwTimeStart = GetTickCount();
    char* szFirstName = "iddqd";
        char* szLastName = "idkfa";
        char szTotal[500];
        for(size_t i=0;i<10000000;++i)
        {
            strcpy(szTotal, szFirstName);
            strcat(szTotal, szLastName);
        }

    DWORD dwTimeEnd = GetTickCount();
    printf("%f\n",float(dwTimeEnd - dwTimeStart) / 1000);
    return 0;
}


0.27
0.30
0.27
0.28
0.28

Ай-яй-яй!!! Как же это я так оплошал . Говорил, что , мол, нет времени на длину строки, проход мол, а ведь strcat — тоже проход, а оказывается, это быстрее, чем мой однопроходной код! Вот и делай после этого заявления про оптимизацию

Ничего, реабилитируемся. Просто уж строки слишком короткие.Заменим их на

char* szFirstName = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
char* szLastName = "22222222222222222222222222222222222222222222222222222222222222222222222222222";


C++, мой вариант

4.18
4.11
4.15
4.11
4.30


С++, strcat

4.64
4.72
4.75
4.56
4.67

Не так уж много, верно, процентов 10-15. Только вот здесь всего 2 строки конкатенируются, а у меня их было обычно 5-10. При concat второй строки проходится первая (поиск конца строки в szTotal) , при concat третьей — первая со второй, и т.д. В общем, двойной цикл

Ну а вот что здесь C# дает

11.44
11.94
11.50
11.81
11.50
3.05
3.09
3.08
With best regards
Pavel Dvorkin
Re[25]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 20.10.05 04:05
Оценка: :)
Здравствуйте, srggal, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:



S>Хоть Вы и читтер уважаемый, ан все равно приятно увидеть Думмера, ( поглаживая свой БФЖ ), и вспоминать как БФЖ рулит на 7мом уровне в дедматч. Эххх.


Ради бога, переведи на русский, а то я даже не знаю, как на все это реагировать .

P.S. Код, который ты цитируешь — не мой, см.

http://www.rsdn.ru/Forum/Message.aspx?mid=1443856&only=1
Автор: WolfHound
Дата: 19.10.05
With best regards
Pavel Dvorkin
Re[24]: Об эффективности программ в избранное  новое    модер.  /!\
От: WolfHound rsdn 
Дата: 20.10.05 05:46
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не так уж много, верно, процентов 10-15. Только вот здесь всего 2 строки конкатенируются, а у меня их было обычно 5-10. При concat второй строки проходится первая (поиск конца строки в szTotal) , при concat третьей — первая со второй, и т.д. В общем, двойной цикл


PD>Ну а вот что здесь C# дает

            string szFirstName = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
            string szLastName = "22222222222222222222222222222222222222222222222222222222222222222222222222222";

                    string str = szFirstName + szLastName;

0,1317845
            StringBuilder sb = new StringBuilder();
...
                for (int i = 0; i < 100000; ++i)
                {
                    sb.Length = 0;
                    sb.Append(szFirstName);
                    sb.Append(szLastName);
                }

0,04493758

Оптимизированый вариант на C# получается на уровне С++ Ну чуть медленнее.
Кстати для корректности теста перепиши свои на wchar_t.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 20.10.05 08:15
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

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


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


A>>>Так не пойдет. Чтобы было эквивалентно С++ варианту нужно ещё из StringBuilder получить String.

GZ>>Почему?

A>В C++ версии на входе две строки на выходе одна. В C# — на выходе какой-то буфер (StringBuilder то есть). Чтобы его использовать как строку, нужно еще совершить преобразование.

Неа. На выходе один и тот же буфер содержащий строку. 100 байт стека. StringBuilder.ToString() — это не преобразование строки, а возврат буфера в виде строки. То есть все абсолютно аналогично.
Другой вопрос в Net с одним и тем же буфером создавать две строки нельзя. Поэтому аналогичным будет создание всегда новой строки.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 20.10.05 09:20
Оценка: :)
Воистину, Манька Величко страшная баба. Недай бог с ней познакомиться...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[30]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 20.10.05 09:54
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

GZ>>Другой вопрос в Net с одним и тем же буфером создавать две строки нельзя. Поэтому аналогичным будет создание всегда новой строки.

A>В этом тесте используется конкретная возможность C — создание строк на стеке с прямой целью, чтобы показать приемущество этого языка по сравнению с C#.
Да нет тут никакого преимущества. Преимущество имеет значительно более большее значение чем просто производительность. Про один буфер я прогнал. Можно и в одном буфере с помощью unsafe кода. Только использование unsafe дает большую производительность для конкретной задачи, но меньшую эффективность. Потому как нафигарить можно не хуже чем в C++.
Во вторых — это не создание строк, а заполнение буфера строками в цикле. Разница в этих терминах есть и существенная.
В третьих, если ты не получал ошибок когда ты выходишь за границы массива, значит ты никогда не писал на C. Так что данное упражнение отнюдь не показывает эффективность языка. Оно больше показывает его недостатки.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Об эффективности программ в избранное  новое    модер.  /!\
От: WolfHound rsdn 
Дата: 20.10.05 10:21
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Проверять не буду, приму на веру. Все верно, я так и ожидал. Только одно имей в виду — StringBuilder постоянно хранит и изменяет поле длины. И это не бесплатно. Ты уже заплатил за вычисление этой длины вот здесь

По сравнению с копированием строк особенно если строки длинные это ничтожные затраты времени.
А если случится промах кеша то...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 20.10.05 10:53
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

A>Только с той разницей, что чтобы преобразовать буфер в строку в C, не нужно делать ничего. Например, нам надо передать строку после конкатенации в функцию foo(char*). В C — просто передаём этот самый буфер. В C# функция будет выглядеть как foo(string), и чтобы передать туда результирующую строку нам нужно сначала преобразовать StringBuffer в String.

Ты сильно преувеличиваешь стомость этой операции. Посмотри исходники StringBuilder.ToString() рефлектором.
З.Ы. Не все, что занимает меньше асм-команд, тратит меньше тактов
З.З.Ы. Не все вызовы одинаково дороги.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 20.10.05 12:08
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Проверять не буду, приму на веру. Все верно, я так и ожидал. Только одно имей в виду — StringBuilder постоянно хранит и изменяет поле длины. И это не бесплатно. Ты уже заплатил за вычисление этой длины вот здесь

WH>По сравнению с копированием строк особенно если строки длинные это ничтожные затраты времени.

Нет, не ничтожные. На входе у тебя буфер из байтов или ushort. Строка, в сыром виде пришедшая, из файла, к примеру,. И длину ее найти можно только просмотрев символы в поисках некоего признака конца (0xD из файла). Это не копирование, но все же массовая операция. И делать ее у тебя кто-то будет, не ты сам, так кто-то из библиотеки. А вот я указатель на эту строку в memory-mapped файле возьму и дальше мое дело — искать ее длину или нет. Надо — найду. не надо — подожду пока что, может, и не понадобится.
With best regards
Pavel Dvorkin
Re[27]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 21.10.05 04:44
Оценка: :)
Здравствуйте, Дарней, Вы писали:


Д>небольшой эксперимент показал, что лишенный проблем с безопасностью вариант с использованием std::string еще и работает куда быстрее, чем твой вариант — ценой потери небольшого количества памяти из тех гигабайтов, которые были у тебя в наличии, но которые ты не использовал

Д>Вот мне и стало интересно — чего ты в конце концов хотел добиться своими "оптимизациями"?

Ты бы хоть внимательно посмотрел, что ты со string сделал

std::string firstName = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
std::string lastName = "22222222222222222222222222222222222222222222222222222222222222222222222222222";
std::string astr = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
std::string bstr = "11111111111111111111111111111111111111111111111111111111111111111111111111111";

Это, между прочим, вызов конструктора. Который при этом вычисляет длину (поле string::_MySize) и теперь эта длина используется в операциях = и +=. А вызываешь этот конструктор ты один раз, а не 10000000 раз. Вот поставь так

        std::string res;
        for(size_t i=0;i<10000000;++i)
        {
        std::string firstName = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
        std::string lastName = "22222222222222222222222222222222222222222222222222222222222222222222222222222";
        std::string astr = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
        std::string bstr = "11111111111111111111111111111111111111111111111111111111111111111111111111111";

            res = firstName;
            res += lastName;
            res += astr;
            res += bstr;
        }


тогда и сравнивай.
Конечно, в этом случае и в моем коде надо сделать то же


char szTotal[500];
char * pszTmpTotal,*pszTmpFirst, *pszTmpLast;
for(size_t i=0;i<10000000;++i)
{
   char* szFirstName = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
   char* szLastName =  "22222222222222222222222222222222222222222222222222222222222222222222222222222";
   char* astr = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
   char* bstr = "11111111111111111111111111111111111111111111111111111111111111111111111111111";
   for(pszTmpTotal = szTotal,pszTmpFirst = szFirstName ; *pszTmpFirst;*pszTmpTotal++=*pszTmpFirst++); 
   for(pszTmpLast = szLastName; *pszTmpLast;*pszTmpTotal++=*pszTmpLast++); 
   for(pszTmpLast = astr; *pszTmpLast;*pszTmpTotal++=*pszTmpLast++); 
   for(pszTmpLast = bstr; *pszTmpLast;*pszTmpTotal++=*pszTmpLast++); 
   *pszTmpTotal = '\0';
}


только вот у меня будет в каждой из этих строчек одно-единственное присваивание указателю (szFirstName и т.д.), от длины строки вообще не зависящее, ну а у тебя массовая операция.

P.S. А вообще-то я придумал способ сделать еще быстрее. Примерно в 2 раза быстрее, чем мой вариант. Жаль, что в свое время до него не додумался.
Причем даже с нахождением длины, т.е. двухпроходный. Так что одна причина, почему я позволил себе потенциально небезопасный код, отпадает.. Вот только буфер все же придется оставить статическим — при попытке вставить в цикл выделение памяти и освобождение он проигрывает даже string. Так что полностью безопасным сделать все равно не удастся. Ну а кроме того, в реальной программе этот буфер жил очень долго, и строки в него добавлялись по мере надобности. И не только строки
With best regards
Pavel Dvorkin
Re[32]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 21.10.05 08:54
Оценка: +1
Здравствуйте, alexeiz, Вы писали:

A>Приемущество языка С заключается в том, что он позволяет (не требует а позволяет) спуститься на уровень железа. Для С# это очень и очень ограничено. Все размышления о выходе за границы массива идут лесом. Это просто отдельный разговор.

Закон относительности. Можно повернуть и по другому. Преимущества C# то, что он не позволяет делать ошибки выхода за границы массива. Хотя и это неправда. Я прямо написал, что можно так делать, но это особый случай называемый unsafe кодом. Так что и C# умеет работать с памятью и указателями. Так что преимущества здесь нет.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[36]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 21.10.05 13:47
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Не совсем понял. Я так понял, что при дозаписи в StringBuffer меняется полученная раннее строка. Я не правильно понял суть ошибки?

Да. Неправильно. При любом дополнительном изменении StringBuilder после вызова ToString() выделяется новый буфер для изменений. Проблема примерно такая:
StringBuilder strBuilder=new StringBuilder("строка");
string str1=strBuilder.ToString();
string str2=strBuilder.ToString();
......
//здесь unsafe код который меняет строку
unsafe{fixed(char* pstr=str1){pstr[1]='F';}};
....
if (str2!='строка') Console.WriteLine("непонятный обломс");

этот код идентичен такому
StringBuilder strBuilder=new StringBuilder("строка");
string str1=strBuilder.ToString();
string str2=str1;
......
//здесь unsafe код который меняет строку
unsafe{fixed(char* pstr=str1){pstr[1]='F';}};
....
if (str2!='строка') Console.WriteLine("здесь мы хорошо знаем чем рискуем так как сознательно конкатенировали");


С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 23.10.05 16:17
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>олько одно имей в виду — StringBuilder постоянно хранит и изменяет поле длины. И это не бесплатно. Ты уже заплатил за вычисление этой длины вот здесь...


И этот человек препадет в институте!

Какие там на фиг абстракции? Мы за за длинну платим!!!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[28]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 24.10.05 14:29
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да уж... Не думал, что дело дойдет до личных наездов. Вот и спорь с такими личностями.


Какие споры? Я в ужасе!!!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[6]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 24.10.05 14:29
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

VD>>Слушай, брось программировать. Береги нервы.


PD>Слушай, брось давать неумные советы.


По-моему, совет очень уместный. Ну, не должны программировать люди рассуждающие на уровне блоков памяти.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[13]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 24.10.05 17:48
Оценка: +1
Здравствуйте, gear nuke, Вы писали:

GN>Как я понял при первом прочтении, это означает в том числе и не злоупотребление ими?


Мне кажется слово "грамотно" подразумевает разумность использования. Конечно с дури можно и микроскоп не эффективно применять если им гвозди начать прибивать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[10]: Об эффективности программ в избранное  новое    модер.  /!\
От: VladD2 модераторwww.nemerle.org
Дата: 24.10.05 18:55
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>>>Влад. Только не надо говорить что все программирование ограничивается бизнес-приложениями.

VD>>Я где-то такое говорил?
GZ>Ты такое недвусмысленно подразумевал.

Телепат?

VD>>Одно дело знать, что такое блок памяти, а другое думать только ими.

GZ>Неее. Я до сих пор думаю ими.

Слабо верится.

GZ>И это мне помогает понять язык. И тебе тоже.


И как тебе помогает понять скажем идиому интерфейсов раздумья о блоках памяти? Ну, или как это тебе помогает понимать паттерны проектирования вроде Посетителя?

GZ> А особенно помогает работать с массивами. И смотреть чтобы не было копирования больших данных. И тут абстракция не поможет. Здесь нужно иметь привычку делать так, чтобы потом кардинально не переделывать. Это в большей степени не проблема дизайна, а алгоритмическая проблема. Хотя меру тоже надо знать.


Я такой проблемы вообще не встречал. По-моему, и так понятно, что чем больше данных ты бестолку копируешь, тем болше времени и памти таратися зря.

GZ>Мы с тобой(судя по возрасту) плоды такого обучения. И я рад что прошел школу 286 процессора и CGA экрана.


От части, да. И мне стоило не малых усилий бороться с этими комплексами. Не раз ловил себя на мысли, что нехочу использовать виртуальный вызов просто потому что он медленее обычного. Причем с точки зрения дизайна отказ от виртауального вызова приводил к серьезному усложнению. Это смешно, но мне пришлось провести не один эксперемент чтобы осознать, что стоимость даже самого медленного виртуального вызова — это наносекунды, и что бы от него получить зримое замедление его нужно запихнуть в очень объемный цикл. Если же меня учили сначала создавать грамотный дизайн приложения, а потом уже оптимизировать по-необходимости, то таких проблем никогда не вознило бы.

Так вот я осознанно предалел (и продолжаю преодалевать) психологические проблемы борьбы за производительность. А некоторые товарищи даже не задумываются над необходимостью делать это. И то что эти товарищи старше лет на 10 нисколько их не оправдывает.

GZ> Очень обучает думать. Так кто там мерял скорость GDI+?


Ничего. Я потом опубликую результаты измерений и боюсь многие будут удивлены в какие мифы они верили. Забегая вперед скажу, что GDI+ не так тормозна как его многие описывают. При грамотном применении эта библиотека на сильно медленнее чем GDI.

GZ>Правильно действовать легко научить. Правильно думать — значительно труднее. И для системы алгоритм+доступные_ресурсы — нужно учиться думать.


Я не вижу потуги думать у учителя. И почти уверен, что именно этому в превую очередь научатся его ученики. Они всю жизнь будут вызимать биты из байтов. Ведь сломать привычку не так то просто. Любой кто бросал курить или переучивался печатать вслепую поймет о чем речь.

GZ>Думать абстракциями — также нужно учить. То же очень сложная штука. Но это и не обозначает отмену вышеописанного.


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

Ведь езжу понятно, что быстрее выделения памяти в стэке быть ничего не может. Но это ведь не приводит разумных программистов к отказу от использования тех же строковых классов?

Я вижу следующую цепочку рассуждений.

Программы жрут больше ресурсов чем могли бы...
Надо писать так чтобы использовать минимально достаточный объем ресусров...
Абстракции зачастую увеличивают объем используемых ресуросв...
Так откажемся от абстаркций и будем долбить все в стиле С.

При этом, правда, приводятся примеры с использованием тормознеших sprintf-ов, ну, да сути дела это не меняет.

Итог один — формирование стойкой неприязни к абстракциям в следствии погони за битами.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Вышел Nemerle 1.2


Все что нас не убивает, потом сильно об этом жалеет :).
Re[13]: Об эффективности программ в избранное  новое    модер.  /!\
От: Павел Кузнецов rsdnhttp://engineering.meta-comm.com
Дата: 25.10.05 02:19
Оценка: +1
IT,

> Упрощению поддаётся любой код, даже сверх-оптимизированный.


Со сверх-упрощенным этот номер отколоть сложнее
Posted via RSDN NNTP Server 2.0 beta
Discussion is an exchange of knowledge; an argument is an exchange of ignorance.
Discussion is an expression of logic; an argument is an expression of temper.
Discussion tries to prove what is right; an argument tries to prove who is right.
Re[11]: Об эффективности программ в избранное  новое    модер.  /!\
От: GlebZ 
Дата: 25.10.05 14:36
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


GZ>>>>Влад. Только не надо говорить что все программирование ограничивается бизнес-приложениями.

VD>>>Я где-то такое говорил?
GZ>>Ты такое недвусмысленно подразумевал.
VD>Телепат?
Нее, телепузик.
Просто не все есть программы для IBM PС для OS MS Windows. Я в свое время поигрался с эмуляторами технических процессоров. Там такие-же подходы какие мы применяем для бизнес-приложений не подходят. Там приходится всегда думать не об абстракциях, а о системе команд и строении памяти. А этих тварей много, и ведь кто-то их программирует.

VD>>>Одно дело знать, что такое блок памяти, а другое думать только ими.

GZ>>Неее. Я до сих пор думаю ими.
VD>Слабо верится.
Верь. Тут есть и плюс и минус. С одной стороны не плодю заранее оптимальный код(не путать с дизайном). С другой стороны иногда действительно обидно что приходится писать неоптимальный код(ради дизайна). Переживаю.

GZ>>И это мне помогает понять язык. И тебе тоже.

VD>И как тебе помогает понять скажем идиому интерфейсов раздумья о блоках памяти? Ну, или как это тебе помогает понимать паттерны проектирования вроде Посетителя?
Дизайн — это одно. А вот циклы и рекурсии — это другое.

GZ>> А особенно помогает работать с массивами. И смотреть чтобы не было копирования больших данных. И тут абстракция не поможет. Здесь нужно иметь привычку делать так, чтобы потом кардинально не переделывать. Это в большей степени не проблема дизайна, а алгоритмическая проблема. Хотя меру тоже надо знать.

VD>Я такой проблемы вообще не встречал. По-моему, и так понятно, что чем больше данных ты бестолку копируешь, тем болше времени и памти таратися зря.
Именно. А еще неплохо бы учитывать что-это стек или динамическая память. И количество циклов. И StringBuild и string в C#. И аллокация в STL. Это не должно отражаться в дизайне. Но на непосредственном уровне самого формирования кода — по-моему вещь достаточно важная.

GZ>>Мы с тобой(судя по возрасту) плоды такого обучения. И я рад что прошел школу 286 процессора и CGA экрана.

VD>От части, да. И мне стоило не малых усилий бороться с этими комплексами. Не раз ловил себя на мысли, что нехочу использовать виртуальный вызов просто потому что он медленее обычного. Причем с точки зрения дизайна отказ от виртауального вызова приводил к серьезному усложнению.
VD> Это смешно, но мне пришлось провести не один эксперемент чтобы осознать, что стоимость даже самого медленного виртуального вызова — это наносекунды, и что бы от него получить зримое замедление его нужно запихнуть в очень объемный цикл. Если же меня учили сначала создавать грамотный дизайн приложения, а потом уже оптимизировать по-необходимости, то таких проблем никогда не вознило бы.
После определенного момента — меня греет мысль о суперумном компиляторе. Поэтому о виртуальных вызовах вообще не задумываюсь. Но во многих случаях, как уже писал, точно также.
А насчет учебы, так получилось что я самоучка. Меня никто не учил. Все познавал сам.
VD>Так вот я осознанно предалел (и продолжаю преодалевать) психологические проблемы борьбы за производительность.
Аналогично.
VD>А некоторые товарищи даже не задумываются над необходимостью делать это. И то что эти товарищи старше лет на 10 нисколько их не оправдывает.
Иногда в некоторых задачах это действительно важно. Особенно связанных с математикой. Я когда-то работал на науку, потому знаю. Для большинства бизнес-приложений это действительно неважно. Для McSeem2, я думаю, это и сейчас актуально.

GZ>> Очень обучает думать. Так кто там мерял скорость GDI+?

VD>Ничего. Я потом опубликую результаты измерений и боюсь многие будут удивлены в какие мифы они верили. Забегая вперед скажу, что GDI+ не так тормозна как его многие описывают. При грамотном применении эта библиотека на сильно медленнее чем GDI.
А при грамотном граф. процессоре еще менее тормозная? И похоже время достойных процессоров пришло. Новая революция прокралась незаметно. Ура товарищи!!!! Я угадал?

GZ>>Правильно действовать легко научить. Правильно думать — значительно труднее. И для системы алгоритм+доступные_ресурсы — нужно учиться думать.

VD>Я не вижу потуги думать у учителя. И почти уверен, что именно этому в превую очередь научатся его ученики. Они всю жизнь будут вызимать биты из байтов. Ведь сломать привычку не так то просто. Любой кто бросал курить или переучивался печатать вслепую поймет о чем речь.
VD>Я вижу, что товарищь учитель просто приципиально нежелает думать абстракциями так как они зачастую привносят накладные расходы.
VD>Ведь езжу понятно, что быстрее выделения памяти в стэке быть ничего не может. Но это ведь не приводит разумных программистов к отказу от использования тех же строковых классов?
VD>Я вижу следующую цепочку рассуждений.
VD>Программы жрут больше ресурсов чем могли бы...
VD>Надо писать так чтобы использовать минимально достаточный объем ресусров...
VD>Абстракции зачастую увеличивают объем используемых ресуросв...
VD>Так откажемся от абстаркций и будем долбить все в стиле С.
VD>При этом, правда, приводятся примеры с использованием тормознеших sprintf-ов, ну, да сути дела это не меняет.
VD>Итог один — формирование стойкой неприязни к абстракциям в следствии погони за битами.
[imho]
Нет. Давай так. Павел привел действительно верные факты если брать алгоритмы программ. После этого — он перенес выводы на уровень архитектуры. Выводы в данном контексте становятся неверны. Как бы человек давно не работает на фронтах бизнес-приложений. Ему высказали все что думали. Но тут и ты начал абсолютно верные факты для дизайна программ переносить на алгоритмы(точнее даже, не учитывать их). И теперь твои факты становятся неверными.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[35]: Об эффективности программ в избранное  новое    модер.  /!\
От: Pavel Dvorkin 
Дата: 27.10.05 04:45
Оценка: -1
Здравствуйте, Дарней, Вы писали:

Д>это как раз не "сырые" данные — ни один сервер БД не хранит данные в ASCIIZ


Как он хранит — не мое дело. А вот возвращает он из без длины.

PD>>Давай простой пример, искусственный, конечно. Есть огромный файл (1GB , в нем одна текстовая строка, в конце ее , конечно, 0D0A . Я открываю этот файл, делаю на него MMF, позиционируюсь в конец файла, заменяю 0D на 0, имею таким образом строку ASCIIZ. Обрати внимание — файл я не читал. Все — у меня char* pString готов.


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

Д>Хороший пример ты привел, ничего не скажешь.

Бог с тобой, зачем же ? Ты вообще с MMF знаком ? Там прямой доступ. Если уж мне надо расширить файл, то я просто создам мэппинг на размер, больший, чем текущий размер файла на требуемую величину. После чего возьму указатель, возвращаемый MapViewOfFile, приведу его к char*, добавлю к нему длину файла, получу указатель на конец данных, добавлю там что надо. Остается только закрыть мэппинг , для фала вызвать SetFilePointer и SetEndOfFile. Все. Исходный файл так и остался непросмотренным.

А даже и без MMF можно. Открываем файл, SetFilePointer на конец-1 (эта операция не читает файл), дописываем данные, закрываем файл. Все.


PD>>Да ведь во входном мире ничего другого нет. Есть некий входной массив байт (из файла, из сети, ...). Этот набор нам дают и все. И чем-то заканчивают, чтобы знали, когда остановиться.

PD>>gets банальный, например. А дальше уж наше дело — то ли string из него соорудить, длину мимоходом посчитав и время потратив, то ли не считать длину, отложить до того момента, когда понадобится (может, и не понадобится) . Кстати, в моем примере с конкатенацией я эту длину мог мимоходом вычислить.

Д>не во входном мире, а в той библиотеке, которой ты пользуешься


Библотека откуда данные получает ? Не из входного мира ли ? ИМХО кроме как из входного мира данные брать вообще неоткуда . А вот чтобы из входного мира строки с длиной подавали — как правило, так не делают. А если даже и сделают, это тебе не поможет в случае со string — все равно констуктор string будет исходную строку просматривать и ноль искать. По крайней мере пока это string из STL, а не что-то в Паскале, Перле и т.д.

>>>Читал историю про маляра Шлемиэля?


PD>>Нет.


Д>http://russian.joelonsoftware.com/Articles/BacktoBasics.html


Д>не наводит на размышления?


Да в общем-то ничего интересного. По крайней мере ничего нового для себя я не нашел. Довольно наивные рассуждения, особенно забавно вот это

>Строка не может содержать нулевые байты. Так что хранить произвольные двоичные данные вроде картинки в формате JPEG в строке нельзя.


Между прочим, JPEG очень неудобно хранить так же в виде стека, линейного списка, двоичного дерева и т.д. И не надо — не предназначены эти структуры для хранения JPEG . Как и строка. Кстати, ты готов хранить JPEG в виде string ?
With best regards
Pavel Dvorkin
Re[34]: Об эффективности программ в избранное  новое    модер.  /!\
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 27.10.05 05:45
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Код, который читает данные из базы, длину не вычисляет.
Еще как вычисляет. Неудачный пример.
PD> Нет такого в SQL SELECT, к примеру. Внутри себя этот SELECT на сервере я не знаю что делает, но мне на клиент в итоге строка попадает как последовательность ASCIIZ.
Неправда. Строка попадает в довольно сложном виде. Никаким ASCIIZ там и не пахне