Re[7]: Об эффективности программ
От: Mikhail Polykovsky Россия http://glader.ru
Дата: 07.10.05 05:08
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Mikhail Polykovsky,


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


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


>> Диванов тоже много разных. И все произведены серийно.


ПК>Разница: программы все разные, а диванов, выпускаемых серийно, много одинаковых. Соответственно, изготовление партий (одинаковых) диванов -- серийное производство, а изготовление (уникальных) диванов/программ -- штучное.


Другой пример — корпусная мебель. Части одинаковые, а шкаф каждому свой нужен. Сборка — отверткой.
Re[3]: Об эффективности программ
От: Pavel Dvorkin Россия  
Дата: 07.10.05 05: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[2]: Об эффективности программ
От: Pavel Dvorkin Россия  
Дата: 07.10.05 05:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

>- эффективно, а за

S>
S>...(IEnumerable<string> strings)
S>{
S>  string s = string.Empty;
S>        foreach(string a in strings) s=s+a;
S>    return s;
S>}
S>

S>надо бить линейкой.

Sinclair, sorry, а не мог бы ты подсказать, как здесь эффективно сконкатенировать все же массив строк при том, что количество их определится в момент конкатенации? Твой первый пример хорош, но там жестко 3 строки. На C++ конкатенацию массива строк в новую строку (я имею в виду не string из STL, а char*) я все же напишу однопроходным алгоритмом и при этом не будут использоваться никакие промежуточные буферы. Потому что задача по определению однопроходная. Здесь это можно, используя только string, а не StringBuilder ? А если использовать StringBuilder, то ведь потом нужно копировать в string и в итоге 2 прохода все же ?

Я не "подначиваю" , я просто сам пока не знаю.
With best regards
Pavel Dvorkin
Re[8]: Об эффективности программ
От: Павел Кузнецов  
Дата: 07.10.05 05:32
Оценка:
Mikhail Polykovsky,

> ПК>Разница: программы все разные, а диванов, выпускаемых серийно, много одинаковых. Соответственно, изготовление партий (одинаковых) диванов -- серийное производство, а изготовление (уникальных) диванов/программ -- штучное.


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


Теперь осталось показать, что при разработке программ процесс происходит более-менее также...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[8]: Об эффективности программ
От: gear nuke  
Дата: 07.10.05 05: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[4]: Об эффективности программ
От: gear nuke  
Дата: 07.10.05 05: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[3]: Об эффективности программ
От: Дарней Россия  
Дата: 07.10.05 06:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ХРюша может запустить на 32 метрах, но оптимизирована она на 256+.


При этом гигабайтом памяти она не умеет нормально пользоваться. Как только приложение сворачивают в систрей, она начинает сбрасывать его память в page-файл, даже если свободной памяти в системе — хоть задницей жуй. В результате — всё тот же могучий своп при свободной на 50%-60% памяти
Во всяком случае, таково поведение по умолчанию — с помощью твикеров ситуацию можно несколько выправить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[3]: Об эффективности программ
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.10.05 06:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Sinclair, sorry, а не мог бы ты подсказать, как здесь эффективно сконкатенировать все же массив строк при том, что количество их определится в момент конкатенации?

С массивом все вообще просто. См. string.Join.

PD>Твой первый пример хорош, но там жестко 3 строки. На C++ конкатенацию массива строк в новую строку (я имею в виду не string из STL, а char*) я все же напишу однопроходным алгоритмом и при этом не будут использоваться никакие промежуточные буферы. Потому что задача по определению однопроходная.

Это как, интересно?
Не так ли:
public static string Join(IEnumerable<string> strings)
{
  int len=0;
  foreach(string s in strings)
      len+=s.Length;
    StringBuilder sb = new StringBuilder(len); // избегаем перевыделений
  foreach(string s in strings)
      sb.Append(s);
    return sb.ToString();
}

?
PD>Здесь это можно, используя только string, а не StringBuilder ?
Можно. Но уволят.
PD>А если использовать StringBuilder, то ведь потом нужно копировать в string и в итоге 2 прохода все же ?
Нет. Там в большинстве случаев никакого копирования нету. UTSL, т.е. Reflector.
Код, который я привел, должен приводить к практически идеальному результату. Можно потестировать, что быстрее — подсчитывать суммарную длину или нет — в зависимости от количества строк в IEnumerable. Но это в любом случае эффекты второго порядка малости.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Об эффективности программ
От: pp2  
Дата: 07.10.05 07:18
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

>> Многие, например, неявно заинтересованы в том чтобы новая версия windows содержала больше ошибок...

ПК>В отношении количества ошибок прогноз не вполне оправдывается: чем дальше после Windows 95, тем их меньше. В следующих версиях обещают еще лучше, т.к. вкладывают деньги в повышение качества разработки.
Вопрос спорный. Начиная от Windows 3.0 системы резко усложнялись (число даже строк кода росло в разы, где-то таблицу видел сравнительную, рост там нелинейный), а время разработок только сокращалось или оставалось прежним. Кроме того на все системы давит прессом обратная совместимость (со старыми ошибками и архитектурными промахами), но без этого нельзя, потому что несовместимая ни с кем ОС — никому не интересна. Ну и как в таких условиях обеспечить непрерывный рост надежности кода? Ведь чудес не бывает — пишешь быстро и много — получается хуже, как ни крутись... Вот например, Windows 2003 SP1 (исправление ошибок) занимает 270Mb в архиве (!), и содержит исправление практически к 95% всех компонент системы (Windows 2003 чистая занимает 350Mb в архиве). Ну и где тут рост качества кода? Бюллетени со знаком "критично" выходят почти каждый месяц — может это рост качества? Это рост популярности (ошибки стали искать и находить чаще, потому что это стало выгоднее), но не качества — число ошибок по-прежнему огромно! Да, та же Microsoft предпринимает шаги по улучшению качества и безопасности своих продуктов, но реальный конечный толк для пользователей (а не красивые слова от производителя) от этих шагов пока невелик. Наверное, из-за той же популярности продукции и сущестования целых линеек старых версий ОС...
Re[4]: Об эффективности программ
От: mrozov  
Дата: 07.10.05 08:13
Оценка:
Здравствуйте, pp2, Вы писали:
pp2>В догонку — с mrozov я как раз не согласен. Я нигде не говорил что деньги определяют все. Я лишь посетовал, что увы все больше (в массовом коммерческом

pp2>Может Вы меня с кем-то путаете?


Помоему, это вы путаете с кем-то меня
Я как раз про деньги не сказал ни слова.
Re[7]: Об эффективности программ (уровень языка)
От: GlebZ Россия  
Дата: 07.10.05 08:51
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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

Согласен. Но это специфичные решения.

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

ПК>Это к уровню языка отношения не имеет.
В честь чего. В С++ два основных типа строк.(пишу именно основных, чтоб не наезжали) Строка и нестрока, то есть string и char[]. string объект ООП — char[] наследие С. Кто из них высокоуровневая конструкция, а кто тормозная?

С уважением, Gleb.
Re[9]: Об эффективности программ
От: GlebZ Россия  
Дата: 07.10.05 08:55
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Теперь осталось показать, что при разработке программ процесс происходит более-менее также...

Все к этому движется. Только все медленнее и медленнее.

С уважением, Gleb.
Re[6]: Об эффективности программ
От: GlebZ Россия  
Дата: 07.10.05 08:59
Оценка: 23 (2) +3 :))) :)))
Здравствуйте, Павел Кузнецов, Вы писали:

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

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

С уважением, Gleb.
Re[3]: Об эффективности программ
От: Pavel Dvorkin Россия  
Дата: 07.10.05 08:59
Оценка:
Кстати, вот еще пример. Из официального руководмтва Микрософт, между прочим

Есть строка myString в формате CSV

myDataSet.Tables["Table 1"].Rows.Add(myString.Split(char.Parse(",")));

Берем строку, делаем из нее массив строк и по запихиваем этот массив в Rows. А нельзя ли без того, чтобы массив создавать ? В C++ я бы просто прошел по этой строке strtok и добавил строки — без всяких дополнительных массивов.
With best regards
Pavel Dvorkin
Re[2]: Об эффективности программ
От: Chamele0n  
Дата: 07.10.05 09:09
Оценка:
Здравствуйте, McSeem2, Вы писали...

Надо было мне сюда написать:
Еще о гигабайтах
Автор: Chamele0n
Дата: 07.10.05
Re[4]: Об эффективности программ
От: GlebZ Россия  
Дата: 07.10.05 09: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[3]: Об эффективности программ
От: RobinBobin  
Дата: 07.10.05 09:32
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


На C++ конкатенацию массива строк в новую строку (я имею в виду не string из STL, а char*) я все же напишу однопроходным алгоритмом и при этом не будут использоваться никакие промежуточные буферы.



Как ?
Re[3]: Неэффективности программ -- ДА!
От: Odi$$ey Россия http://malgarr.blogspot.com/
Дата: 07.10.05 09:39
Оценка:
Здравствуйте, eao197, Вы писали:

E>Возьмем Janus.

E> А уж поиск по базе сообщений по скорости с Opera вообще не сравнится.

насколько я понимаю им (поиском) никто не то что всерьез, а практически вообще не занимался — прикрутили и забыли, тут ни при чем ни .net ни что другое, просто не-за-ни-ма-лись
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Неэффективности программ -- ДА!
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.10.05 09:47
Оценка:
Здравствуйте, Odi$$ey, Вы писали:

E>>Возьмем Janus.

E>> А уж поиск по базе сообщений по скорости с Opera вообще не сравнится.

OE>насколько я понимаю им (поиском) никто не то что всерьез, а практически вообще не занимался — прикрутили и забыли, тут ни при чем ни .net ни что другое, просто не-за-ни-ма-лись


Про .net я написал просто чтобы показать, что его объем нужно учитывать для определения объема инсталляции Janus. А совсем не к тому, что Janus тормозной из-за .net-а. Прошу не провоцировать

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

Тут уже кто-то сказал, что это "потом" никогда не наступает.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Закон Мура умер
От: GlebZ Россия  
Дата: 07.10.05 11:41
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>ИМХО проблема не в языках. Многие алгоритмы имеют зависимости по данным (нельзя продолжать выполнение, пока не известен результат предыдущей операции). Да возьмём для примера любимый компилятор — даже если распараллелим компиляцию отдельных файлов, то как быть с линкером?

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

GN>Можно вспомнить много таких "революционных" технологий даже на x86 — MMX, SSE, ... реальных выигрышей они не дают, если бы обычных регистров добавили, да нормальный (не стековый) FPU сделали — результат бы мог и лучше получиться. Но это бы была только *эволюция*.

Вот если бы сам x86 был стековый. Вот бы была крутизна.

GN>Ну это для тех, кто решает в какие акции деньги вкладывать .

GN>Меня больше смущают медленные, загогулистые шины CPU <-> RAM. Перед тем, как ядро начнёт что-то там считать на своей мега-скорости, ему нужно что-то прочитать из медленной памяти. И если расширяя шину памяти можно немного поднять скорость, то от латентности никак не избавиться.
Я тебе и намекал, что средства для снятия нагрузки с общей памяти там есть. Это и локальные памяти, и те же шина между процами, с помощью которых можно пересылать результаты. С такой архитектурой можно спокойно делать и параллельные автоматы, и ступенчатый параллелизм.

С уважением, Gleb.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.