Re[12]: Об эффективности программ
От: mrozov  
Дата: 07.10.05 13:59
Оценка:
S>Соответсвенно, взрослым, или как Вы изволили вырвзиться

S>

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


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


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


S>ВЫВОД:

S> Для
S>

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

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

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


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


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


Поздравляю!
Re[8]: Закон Мура умер
От: GlebZ Россия  
Дата: 07.10.05 14:00
Оценка:
Здравствуйте, gear nuke, Вы писали:

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

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

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

GZ>>Вот если бы сам x86 был стековый. Вот бы была крутизна.
GN>Не уверен. Forth хороший язык, но что-то я видел мало людей, кто на нём пишет .
Forth устарел. Но зато я видел много хороших людей которые знают о нем.
Я не имел язык как таковой. Я имел ввиду архитектуру вычислений. Она кстати была реализована в Эльбрусе.

GN>Куда там в эту локальную память поместятся современные гигабайтные проги? .

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

С уважением, Gleb.
Re[12]: Об эффективности программ
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.10.05 14:04
Оценка: +2 :)
Здравствуйте, srggal, Вы писали:

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


Поздравляю!

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Об эффективности программ
От: srggal Украина  
Дата: 07.10.05 14:07
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>А в форуме-то ты сейчас чего делаешь?


СПАСИБО

А я не в форуме — я на работе
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[5]: Об эффективности программ
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.10.05 14: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 14:12
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

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

Не думал что подобная заметка из жизни вызывет флейм о вилках и детской посуде.

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

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

С уважением, Gleb.
Re[9]: Закон Мура умер
От: gear nuke  
Дата: 07.10.05 14:13
Оценка:
Здравствуйте, GlebZ, Вы писали:

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

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

С третьей задачей пролема такая: кеш сильно засоряется.

GN>>Куда там в эту локальную память поместятся современные гигабайтные проги? .

GZ>Где ты видел гигабайтные проги? Миф о гигабайтных массивах многим сносит голову.

Ну я немного преувеличил .

GZ>Структуры и данные больше не стали. Просто увеличилось их количество.


Возьмём обычную программу в 5 мегабайт, даже без данных. А кеш всего-то 128Кб на Celeron (на все процессы!). Вот и получим в результате, постоянный "swap" из кеша в оперативку .

GZ>Ну а вопрос с оптимальностью заполнения локальных областей памяти конечно остается.

GZ>Мое IMHO, что компилятор может их распределять более детерменированно и след., эффективно чем это делает кэш процессоров.

Как раз таки это близко к NP полной проблеме — кеш у каждого процессора по своему работает, да ещё и контроллер памяти вмешивается. Есть базовые правила, вроде выравнивания, но на современных процессорах это как раз не очень влияет. Говорить о хоть о какой-то автоматической оптимизации под кешь можно только относительно intel C++ compiler. здесь просто цыфры посмотрите, даже в код можно не вникать — "запросто" делается ускорение в 3 раза. Средний компилятор о таких трюках не знает совсем.
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]: Об эффективности программ
От: srggal Украина  
Дата: 07.10.05 14: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[9]: Об эффективности программ
От: srggal Украина  
Дата: 07.10.05 14:19
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


GZ>Не думал что подобная заметка из жизни вызывет флейм о вилках и детской посуде.


Дети, вилки — все это аналогии

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


Именно к этому я и подвожу уважаемого коллегу mrozov, но только делаю это непринужденно и по аналогии

Позволю себе Вас перефразировать:

Т.е. ИНструментальные средства должны помочь первым и должны не мешать вторым ИМХО есстественно
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[2]: Об эффективности программ
От: vladserge Россия  
Дата: 07.10.05 14:25
Оценка: +4 -1
Здравствуйте, Centaur, Вы писали:


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


Почему все легко так выстреливают — "фигня вопрос, углубить, улучшить.... пара пустяков".
А слишком поздно небудет? Что Вы будете делать если борьба с этими процентами заставит взорвать весь фундамент, пересмотреть всю архитектуру?
Я не верю, что прогу написанную без размышлений о разумном использовании рессурсов так просто сделать эффективной.
С Уважением Сергей Чикирев
Re[10]: Об эффективности программ
От: mrozov  
Дата: 07.10.05 14:28
Оценка:
Уважаемый коллега всего-навсего подверг резкой критике высказывание другого, не менее уважаемого коллеги:
"Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке."
Так как он (т.е. я) считает его слишком сильным и указывает на то, что считающие себя очень крутыми товарищи в этом бизнесе не одни.
Так что не думаю, что меня стоит "подводить" к этому тезису. Я вроде как именно на нем и стою. Обеими ногами.
Re[5]: Об эффективности программ
От: WolfHound  
Дата: 07.10.05 14: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[4]: Об эффективности программ
От: WolfHound  
Дата: 07.10.05 14:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>Это как, интересно?
S>Не так ли:
хъ
ИМХО лучше так
public static string Join(IEnumerable<string> strings)
{
    ICollection<string> collection = strings as ICollection<string>;
    if (collection != null)
        return Join(collection);
    int n = 0;
    foreach(string s in strings)
        ++n;
    string[] arr = new string[n];
    n = 0;
    foreach(string s in strings)
        arr[n++] = s;
    return Join(arr);
}

public static string Join(ICollection<string> strings)
{
    ICollection<string> collection = strings as ICollection<string>;
    string[] arr = new string[strings.Count];
    strings.CopyTo(arr, 0);
    return Join(arr);
}

public static string Join(string[] strings)
{
    return string.Concat(strings);
}

Таким образом мы избегаем двойного копирования строк.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Об эффективности программ
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.05 14:31
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

А почему нет упоминания об 1С. Она очень эффективно для определенного круга задач.
И ее можно считать эффективной. Хотя перемножение матриц на ней ....
и солнце б утром не вставало, когда бы не было меня
Re[11]: Об эффективности программ
От: srggal Украина  
Дата: 07.10.05 14:41
Оценка:
Здравствуйте, mrozov, Вы писали:

M>Уважаемый коллега всего-навсего подверг резкой критике высказывание другого, не менее уважаемого коллеги:

M>"Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке."
M>Так как он (т.е. я) считает его слишком сильным и указывает на то, что считающие себя очень крутыми товарищи в этом бизнесе не одни.
M>Так что не думаю, что меня стоит "подводить" к этому тезису. Я вроде как именно на нем и стою. Обеими ногами.

Ок, Резюмируем окончательно:

Уважаемый коллега (Вы), не стойте 2мя ногами, сядьте:

всего-навсего подверг резкой критике высказывание другого, не менее уважаемого коллеги


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

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


Взята не менее уважаемым коллегой, не Вами (Павлом) здесь
Автор: GlebZ
Дата: 07.10.05
из сообщения уважаемого коллеги GlebZ.

Так что с Вашей стороны ошибочка вышла

ЗЫ Досадно мне, такие высокие аналогии были использованы мной исключительно из-за приземленной невнимательности коллеги mrozov
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[12]: Об эффективности программ
От: mrozov  
Дата: 07.10.05 14:47
Оценка:
Коллега, вы меня откровенно пугаете.
Я бы даже рискнул предположить, что один из нас явно сошел с ума.

Разговор, по моим представлениям, развивался так:
— С# позволяет комрадам с проблемами в ДНК жить на белом свете, а с++ — мешает
Павел на это:
— Задача инструментальных средств помогать не убогим, а нормальным.
Я на это:
— Задачи инструментальных средств каждый понимает по-своему.

И тут приходите вы и... ?
Re[6]: Об эффективности программ
От: Cyberax Марс  
Дата: 07.10.05 14:59
Оценка:
Sinclair wrote:

> Гм. Мне не хотелось бы прослыть человеком, приносящим дурные вести, но

> ты только что продемонстрировал способ внести в программу buffer
> overrun vulnerability.

Вот политкорректный вариант:
std::string res;
res.reserve(100); //Разумное число
for(int f=0;f<nStrings;f++)
    str.append(szStrings[f]);

Безопасно, причем если результирующая строка меньше 100 символов, то не
будет лишних переаллокаций.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: НеОб эффективности программ ОФФТОП
От: srggal Украина  
Дата: 07.10.05 15:00
Оценка:
Здравствуйте, mrozov, Вы писали:

Ок, я понял

Так как он (т.е. я) считает его слишком сильным и указывает на то, что считающие себя очень крутыми товарищи в этом бизнесе не одни.


Я воспринял, чот Вы ополчились исключительно на Проблеммы с ДНК, а не на стойкую поззицию Павла

Ок, виновать нелопонял, но при это мир снова ликует, аналогии в деле, и мной доказано здесь
Автор: srggal
Дата: 07.10.05
, что позиция Павла верна

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

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


Предлагаю, таки на этом, с возросшим друг к другу уважением, завершить обсуждение
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[5]: Об эффективности программ
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.10.05 15:25
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>ИМХО лучше так
WH>
WH>public static string Join(IEnumerable<string> strings)
WH>{
WH>    ICollection<string> collection = strings as ICollection<string>;
WH>    if (collection != null)
WH>        return Join(collection);
WH>    int n = 0;
WH>    foreach(string s in strings)
WH>        ++n;
WH>    string[] arr = new string[n];
WH>    n = 0;
WH>    foreach(string s in strings)
WH>        arr[n++] = s;
WH>    return Join(arr);
WH>}
Ну то есть ты пытаешься свести все к массиву, потому что для него есть встроенный метод string.Concat. На самом деле, ничего сверхестественного этот метод не делает. Он всего лишь заменяет null на string.Empty и подсчитывает длину, а затем вызывает
[c#]
private static string ConcatArray(string[] values, int totalLength)
{
      string text1 = string.FastAllocateString(totalLength);
      int num1 = 0;
      for (int num2 = 0; num2 < values.Length; num2++)
      {
            string.FillStringChecked(text1, num1, values[num2]);
            num1 += values[num2].Length;
      }
      return text1;
}

Если поковыряться в стрингбилдере, то он выдаст более-менее аналогичный код.
Ну то есть там на самом деле используется военная тайна string.AppendInPlace:
internal unsafe void AppendInPlace(string value, int currentLength)
{
      int num1 = value.Length;
      int num2 = currentLength + num1;
      fixed (char* local1 = &this.m_firstChar)
      {
            fixed (char* local2 = &value.m_firstChar)
            {
                  string.wstrcpy(local1 + currentLength, local2, num1);
            }
            local1[num2] = '\0';
      }
      this.m_stringLength = num2;
}


Основное отличие касается межпотоковой синхронизации.
В итоге, особой производительности ты тут не наиграешь. Зато налицо заметное усложнение кода, которое замазывает простую и стройную логику.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Об эффективности программ (уровень языка)
От: Павел Кузнецов  
Дата: 07.10.05 19: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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.