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

ПК>Mikhail Polykovsky,

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

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

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

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

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

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

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

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


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

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

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


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


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


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


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

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

Здравствуйте, 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 прохода все же ?

Я не "подначиваю" , я просто сам пока не знаю.

Mikhail Polykovsky,

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

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

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

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

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

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

Здравствуйте, Павел Кузнецов,

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

ПК>Только та, которая стоит дополнительного времени при разработке.

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

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

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

При этом гигабайтом памяти она не умеет нормально пользоваться. Как только приложение сворачивают в систрей, она начинает сбрасывать его память в page-файл, даже если свободной памяти в системе — хоть задницей жуй. В результате — всё тот же могучий своп при свободной на 50%-60% памяти
Во всяком случае, таково поведение по умолчанию — с помощью твикеров ситуацию можно несколько выправить.

Здравствуйте, 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. Но это в любом случае эффекты второго порядка малости.

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

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

Здравствуйте, pp2, Вы писали:
pp2>В догонку — с mrozov я как раз не согласен. Я нигде не говорил что деньги определяют все. Я лишь посетовал, что увы все больше (в массовом коммерческом

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

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

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

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

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

С уважением, Gleb.

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

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

С уважением, Gleb.

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

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

С уважением, Gleb.

Кстати, вот еще пример. Из официального руководмтва Микрософт, между прочим

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

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

Берем строку, делаем из нее массив строк и по запихиваем этот массив в Rows. А нельзя ли без того, чтобы массив создавать ? В C++ я бы просто прошел по этой строке strtok и добавил строки — без всяких дополнительных массивов.

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

Надо было мне сюда написать:
Еще о гигабайтах

Автор: Chamele0n
Дата: 07.10.05

Здравствуйте, 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);

Хоть не читабельно, но зато красиво

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

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

Как ?

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

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

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

Здравствуйте, Odi$$ey, Вы писали:

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

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

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

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

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

Здравствуйте, gear nuke, Вы писали:

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

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

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

С уважением, Gleb.