Здравствуйте, gandjustas, Вы писали:
g> Каким образом имея 32-битный указатель можно обратить за пределы четырех гигов? g> Возможно сама ось может увидеть много памяти, а для 32-битного приложения 4 гига — предел.
NBN>>>>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки G>>>Я нормально выделял на шарпе под 2 гига. Вроде как 32-битная ось больше выделить не позволит. CC>>до 64Gb позволит. Больше современный 32бит проц адресовать не может. G>Каким образом имея 32-битный указатель можно обратить за пределы четырех гигов?
PSE и PAE — 36 bit addressing.
64GB можно адресовать только в некоторых серверных OS (Win2kX Server Enterprise на сколько я помню).
G>Возможно сама ось может увидеть много памяти, а для 32-битного приложения 4 гига — предел.
Обычно и того меньше — до 2GB, что можно переконфигурировать в boot.ini и получить до 3х.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, gandjustas, Вы писали:
G>>Я сталкивался с пользователями, которые вполне нормально мирились с генерацияей отчета на 1с (которая на С++) которая длилась двадцать минут. NBN>Вообще-то на васике.
Здравствуйте, Erop, Вы писали: E>Ну и поспотришь ты профайлером, и что дальше будет? Если у тебя проектирования не было, а задача сложная, то будет тормозное г., при этом факт того, что это тормозное г. будет задокументирован профайлером
Я понимаю, головой думать — это тяжелая работа. Ок, специально для тех, кто не представляет себе, что бывает "дальше" после просмотра профайлером, маленькая история вот здесь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote:
> Я понимаю, головой думать — это тяжелая работа. Ок, специально для тех, кто не представляет себе, что бывает "дальше" после просмотра профайлером, маленькая история вот здесь.
В англицком к примеру я не силен. В трех словах пожалуйста опиши что там происходит. Насколько я понял — чел добился существенного увеличения производительности, или нет?
Здравствуйте, gandjustas, Вы писали:
H>>Отсутствие большого объема свободной памяти и отстутствие свободной памяти вообще, сравнивать, как бы, нельзя G>Это к тому что тормозов дополнительных нету независимот от .NET или native.
Реальность с тобой не согласна. Увы.
H>>>>Не жалко. Просто ты говорил о редких сборках мусора, а я тебе примеры привожу, которые показывают обратное. G>>>3 раза в секунду это часто? G>>>На гигагерцовом процессоре за секунду выполняется 1000000000 тактов. При этом если в приложении ничего не происходит, то все поколение становится мксором и не происходит фактически уплотнения кучи. H>>Это демагогия. G>Демагогия это делать выводы о производительности основываясь на мифилогизированных представлениях о GC.
Я делаю выводы исключительно на основе личного опыта работы с .Net софтом.
G>>>Сборщик мусора на многопроцесорной машине работает в фоновом режиме по большей части. G>>>Так что влияние на производительность минимальная.
H>>Сборщик мусора, даже на многопроцессорной машине, даже "серверный", вынужден останавливать выполняющиеся потоки. Concurent GC требует синхронизации, что на производительности не может не сказаться. G>Но ты не забывай что GC не требуется проходи по списку на каждое выделение-освобождение.
А я этого и не говорил Современным нативным аллокаторам тоже не требуется.
H>>Поколения конечно хорошо, но приводимый мною пример с XML-RPC.NET вызывает таки сборку во втором поколении (причем размер кучь у поколений постоянно меняется) G>Как это влияет на производительность?
Отрицательно.
G>Покажите код (.NET и нативный) и результаты замеров, тогда вам кто-нибудь поверит.
Код чего показать? Как делается вызов XML-RPC метода? OK (но что тебе это дасть?). (пишу по памяти)
C#:
[XmlRpcUrl("http://127.0.0.1/")]
public interface IScreenshot
{
[XmlRpcMethod("keyhole.getScreenshot64")]
byte[] getScreenshot64(int x, int y);
}
...
Picture.Image := Bitmap.FromStream(new MemoryStream(XmlRpcProxyGen.Create<IScreenshot>().getScreenshot64(320, 200)));
Код библиотеки XML-RPC.NET можешь скачать с ее домашней страницы. Для мониторинга использовал ProcessExplorer. В итоге, на 170 вызовов XML-RPC метода имеем: 101 сборка во втором поколении, 111 сборок в первом поколении, 295 сборок в нулевом поколении.
H>>>>Когда у меня кое как начинает шевелиться WLW вылезая из свопа, я очень хорошо сопоставления делаю. Не думаешь же ты, что для запуска этой мелочевки, я буду выгружать софт из своего рабочего окружения. G>>>А че, нативное приложение в свом не выгружается? Что ты пытаешься показать этой фразой? H>>Я говорю о том, что Paint.NET откушавший больше чем Turbo Delphi IDE, отправляется в утиль и остается там навсегда. G>Такое чувство что кода ты был маленький к тебе приходил дядька из Microsoft и отобрал у тебя конфетку. Теперь ты выплескиваешь свою обиду на форуме.
Ничего личного. Психоанализ явно не твой конек
G>Вообще за все время ты ни разу не привел аргументы почему .NET работает медленнее, все сводилось к каким-то левым наблюдениям (которые еще и не у всех воспроизводятся) и недалеким выводам.
А как надо наблюдать, чтоб наблюдения стали правыми? Использую, что имеется в наличии (софт т.е.), мониторю чем сам МС велел (perfmon-счетчики, они и в ProcessExplorer'е). Выводы исключительно по результатам
G>Кроме того ты очень активно в своих суждениях опираешься на библиотеку XML-RPC.NET, которая вообще непонятно как работает.
Библиотека XML-RPC.NET используется по нескольким причинам: 1) XML-RPC мне интересен. 2) При его реализации не обойтись без многократных выделений памяти, что в свою очередь позволяет увидеть, как на это реагирует GC. В общем, ссылку на сурсы я дал. Стоит ждать критики?
Здравствуйте, gandjustas, Вы писали:
G>>>Кстати о базах: есть couchDB, которая написана на Erlang, который является одним из самых медленных языков. И ниче, всем кто пользуется — нравится.
H>>У Borland/CodeGear тоже есть SQL сервер -- BlackFish, на Java и .Net. Я не в курсе, как там с перформансом, но и ежу понятно, что основная нагрузка при работе с БД ложится на дисковую систему, а вовсе не на управляемый код. G> G>Там кроме диска еще оооочень много факторов, влияющих на производительность.
Здравствуйте, gandjustas, Вы писали:
G>Собиралось 2008 студией, релиз, запуск из проводника. G>C++ — 562 мсек, C# — 92 мсек.
G>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
Несмотря на всю бессмысленность синтетики, скажи, на какой машинке делал замер? Процессор (частота), память (тип, PC...)?
Здравствуйте, Sheridan, Вы писали:
S> Sinclair wrote:
S> > Я понимаю, головой думать — это тяжелая работа. Ок, специально для тех, кто не представляет себе, что бывает "дальше" после просмотра профайлером, маленькая история вот
S> здесь. S> В англицком к примеру я не силен. В трех словах пожалуйста опиши что там происходит. Насколько я понял — чел добился существенного увеличения производительности, или нет?
Преамбула: "если программа рсаботает со скоростью, указаной в ТЗ, нет смысла оптимизировать ее скорость дальше. Необходимо сосредоточить усилия на исправлении багов, безопасности, документации и т.п." Созвучно с Эриксоновским "сделай так, чтобы фещь работала, а потом, если необходимо, сделай так, чтобы она работала быстро"
Амбула:
Чел проганл профайлером свою программу и увидел, что 43% времени проводится в методе Contains. В .NET'е уже есть тип данных, который может быстро сообщить, есть в нем такой элемент, или нет, и сам хранит только уникальные (distinct) значения.
Таким образом замена этого кода:
var racks = (from rack in ReplaceQuestionMarks(originalRack)
select Canonicalize(rack)).Distinct().ToArray();
на
var racks = new HashSet<string>(
from rack in ReplaceQuestionMarks(originalRack)
select Canonicalize(rack));
Приводит к тому, что Contains теперь занимает всего 3% от времени программы.
Новый профайлинг показывает, что следующее узкое место — это комбинация метода ReadLine и каноникализации строки.
А там уже можно думать — кэшировать словарь (меньше запросо к диску, увеличение требований к памяти), заранее расчитывать индекс для словаря в канонической форме (увеличение места на диске, усложнение программы, уменьшение времени) и т.п.
ЗЫ. Локальный вывод типов рулит в плане читаемости
Здравствуйте, Sheridan, Вы писали:
S>В англицком к примеру я не силен.
Как же ты живешь-то? S>В трех словах пожалуйста опиши что там происходит. Насколько я понял — чел добился существенного увеличения производительности, или нет?
Как я уже много раз говорил, есть только один разумный способ написать производительное приложение.
(Оффтоп: идеальное слово, производительное, привыкайте!) Вот он:
Задать осмысленные, измеримые, направленные на потребителя цели.
Написать код как можно яснее и правильнее.
Аккуратно сравнить производительность с заданными целями
Цели достигнуты? Отлично! Не тратьте времени на анализ производительности. Вложите своё ценное время в фичи, документацию, отладку, надежность, безопасность, во что угодно.
Если цели не достигнуты, используйте инструменты чтобы выяснить, какое из исправимых мест тормозит сильнее всего, и исправьте его
Повторяйте этот процесс, исправляя при необходимости цели, до тех пор, пока вы либо не достигнете цели, либо не сдадитесь.
Моей явной целью для моей маленькой программы поиска по словарю была способность выдавать результаты достаточно быстро, чтоб я не сидел в нетерпении больше нескольких секунд.
Это вполне направленная на потребителя цель, если считать меня единственным потребителем этой программы. После минимальной настройки моя программа сразу добилась этой цели, так с чего бы мне тратить время на дальнейшее улучшение? Программа успевает выдать результат типичного запроса чуть меньше, чем за две секунды, что быстрее, чем я могу его прочитать.
Но представьте, что мы захотели улучшить ее производительность по какой-то причине. Как? Давайте пойдем по списку. У нас есть цели, есть очень понятный код, мы можем достаточно легко измерить производительность. Предположим, мы не достигли цели. Последний пункт в списке — "используйте инструменты чтобы выяснить, какое из исправимых мест тормозит сильнее всего".
Один из комментаторов предположил, что узкое место этой программы связано с дисковым вводом/выводом. Каждый раз при выполнении запроса мы перечитываем двухмегабайтный словарь десятки раз. Это имеет преимущество использования минимума памяти; мы никогда не держим больше одной строки словаря в памяти одновременно, вместо всех четырёх мегабайт, которые бы потребовались на весь словарь (напомню, что словарь в ASCII на диске, но в двухбайтовых символах Unicode в памяти, так что потребление удваивается).
Это предположение — разумное предположение — но тем не менее, это всего лишь догадка. Если я и выучил хоть что-то про анализ производительности, так это то, что мои догадки о расположении узких мест зачастую неверны. Так что я сразу скажу, что да, производительность диска плоха, но это не самая плохая часть в этой программе, далеко не самая. Где же реальное горлышко? Есть идеи? Сможете угадать без инструментов?
Вот результаты профилирования поиска семибуквенных слов с одной пропущенной, повторенного 20 раз:
Святые угодники! Вызовы экстеншн-метода Contains для проверки, содержится ли слово в списке каркасов, занимают почти половину времени работы программы!
Что имеет смысл, как только перестаешь о нём думать. Метод "Contains" по своей очень обобщенной природе вынужден быть весьма наивным.
Получив массив, в 99.9% случаях он должен просмотреть все 26 элементов потому что в 99.9% слово не совпадет ни с одним из возможных каркасов. Он не может воспользоваться "ранним возвратом", как сделал бы ты при выполнении линейного поиска по отсортированному списку. И для каждого элемента он должен сделать полное сравнение строки; здесь нету моднявых проверок, пользующихся неизменностью строк или хеш-кодами или типа того.
У нас есть структура данных, которая разработана чтобы быстро отвечать, входит ли элемент в множество. И, что еще лучше, в нее уже встроена логика "distinct". Когда я заменил
var racks = (from rack in ReplaceQuestionMarks(originalRack)
select Canonicalize(rack)).Distinct().ToArray();
на
var racks = new HashSet<string>(
from rack in ReplaceQuestionMarks(originalRack)
select Canonicalize(rack));
производительность внезапно и значительно улучшилась. "Contains" упал до 3% общих затрат, и, естественно, общие затраты теперь вдвое меньше.
Еще один нюанс: заметьте как при смене типа переменной racks с "массива строк" на "множество строк", мне не пришлось вручную менять тип — благодаря неявной типизации локальных переменных. Я хочу подчеркнуть семантику, а не способ хранения. Если бы я думал, что выражение способа хранения является важной частью кода — потому что это так сильно влияет на производительность — то, возможно, я бы подчеркнул тип, разжевав "var".
После этого изменения, производительность программы улучшается примерно до одной секунды на запрос, и профиль теперь выглядит вот так:
39%: ReadLine
23%: Sort
11%: ToUpperInvariant
7%: всякая фигня в итераторе в FileLines
5%: ToArray (called by Join)
15%: всё остальное
Теперь узкое место явно в комбинации постоянного чтения строки из файла (48%) и каноникализации каждой строки словаря снова и снова (37%).
С учетом этой информации, мы теперь можем сделать осмысленное вложение времени и усилий. Мы могли бы кэшировать порции словаря в памяти, чтобы избежать повторных затрат на ввод/+вывод. Стоит ли потенциальный выигрышь в скорости потенциального значительного роста потребления памяти? Мы можем тут повыпендриваться, и, к примеру, кэшировать только семи- и восьмибуквенные слова.
Мы можем также навалиться на проблему производительности каноникализации. Стоит ли, к примеру, заранее строить индекс к словарю, где каждая строка уже в канонической форме?
Это фактически обменивает рост потребления дискового пространства, рост сложности программи и рост избыточности на уменьшение времени работы. А может, надо взять совсем другой алгоритм каноникализации?
Все эти решения принимаются на основе того факта, что я уже превзошел поставленную цель, так что ответ на все вопросы "нет". Достаточно хорошо, это, по определению, достаточно хорошо.
Если бы я применил этот алгоритм для построения реального игрового AI, он был бы уже недостаточно хорош, и я бы применил какое-нибудь более умное решение. Но этого не случилось.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote:
> S>В англицком к примеру я не силен. > Как же ты живешь-то?
Да неплохо в общем то живу.
> S>В трех словах пожалуйста опиши что там происходит. Насколько я понял — чел добился существенного увеличения производительности, или нет? >
...
Спасибо. Все правильно написано. Оптимизировать нужно в разумных пределах.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Отсутствие большого объема свободной памяти и отстутствие свободной памяти вообще, сравнивать, как бы, нельзя G>>Это к тому что тормозов дополнительных нету независимот от .NET или native.
H>Реальность с тобой не согласна. Увы.
У тебя видимо альтернативная реальность.
Сильнуе галлюцинации вызванные GC-фобией.
H>>>>>Не жалко. Просто ты говорил о редких сборках мусора, а я тебе примеры привожу, которые показывают обратное. G>>>>3 раза в секунду это часто? G>>>>На гигагерцовом процессоре за секунду выполняется 1000000000 тактов. При этом если в приложении ничего не происходит, то все поколение становится мксором и не происходит фактически уплотнения кучи. H>>>Это демагогия. G>>Демагогия это делать выводы о производительности основываясь на мифилогизированных представлениях о GC. H>Я делаю выводы исключительно на основе личного опыта работы с .Net софтом.
Ты не написал ни одной строчки production кода на .NET.
А делать выводы, основанные на просмотре каких-то говнопрограмм как минимум глупо, ты ведь даже не знаешь почему они тормозят, если вообще тормозят (про галлюцианации смотри выше).
G>>>>Сборщик мусора на многопроцесорной машине работает в фоновом режиме по большей части. G>>>>Так что влияние на производительность минимальная.
H>>>Сборщик мусора, даже на многопроцессорной машине, даже "серверный", вынужден останавливать выполняющиеся потоки. Concurent GC требует синхронизации, что на производительности не может не сказаться. G>>Но ты не забывай что GC не требуется проходи по списку на каждое выделение-освобождение. H>А я этого и не говорил Современным нативным аллокаторам тоже не требуется.
Я привел пример кодаЮ доказывающий обратное.
Можешь конечно повторять свой тезис, но правдивее он не станет.
H>>>Поколения конечно хорошо, но приводимый мною пример с XML-RPC.NET вызывает таки сборку во втором поколении (причем размер кучь у поколений постоянно меняется) G>>Как это влияет на производительность? H>Отрицательно.
Доказательства?
G>>Покажите код (.NET и нативный) и результаты замеров, тогда вам кто-нибудь поверит. H>Код библиотеки XML-RPC.NET можешь скачать с ее домашней страницы. Для мониторинга использовал ProcessExplorer. В итоге, на 170 вызовов XML-RPC метода имеем: 101 сборка во втором поколении, 111 сборок в первом поколении, 295 сборок в нулевом поколении.
А замеры производительности? Без них от этого толку нет. Лучше профайлером, чтобы сразу было видно где и от чего тормозит.
H>>>>>Когда у меня кое как начинает шевелиться WLW вылезая из свопа, я очень хорошо сопоставления делаю. Не думаешь же ты, что для запуска этой мелочевки, я буду выгружать софт из своего рабочего окружения. G>>>>А че, нативное приложение в свом не выгружается? Что ты пытаешься показать этой фразой? H>>>Я говорю о том, что Paint.NET откушавший больше чем Turbo Delphi IDE, отправляется в утиль и остается там навсегда. G>>Такое чувство что кода ты был маленький к тебе приходил дядька из Microsoft и отобрал у тебя конфетку. Теперь ты выплескиваешь свою обиду на форуме. H>Ничего личного. Психоанализ явно не твой конек
Да я просто стебаюсь.
G>>Вообще за все время ты ни разу не привел аргументы почему .NET работает медленнее, все сводилось к каким-то левым наблюдениям (которые еще и не у всех воспроизводятся) и недалеким выводам. H>А как надо наблюдать, чтоб наблюдения стали правыми? Использую, что имеется в наличии (софт т.е.), мониторю чем сам МС велел (perfmon-счетчики, они и в ProcessExplorer'е). Выводы исключительно по результатам
По каким? Ты делаешь вывод о производительености, при этом не приводя ни одного факта, касающегося непостредственно этой самой производительности.
Анализ — явно не твой конек
G>>Кроме того ты очень активно в своих суждениях опираешься на библиотеку XML-RPC.NET, которая вообще непонятно как работает. H>Библиотека XML-RPC.NET используется по нескольким причинам: 1) XML-RPC мне интересен. 2) При его реализации не обойтись без многократных выделений памяти, что в свою очередь позволяет увидеть, как на это реагирует GC. В общем, ссылку на сурсы я дал. Стоит ждать критики?
Где XML-RPC.NET найти я знаю, дай сырцы натвного исполнеия для сравнения.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>Собиралось 2008 студией, релиз, запуск из проводника. G>>C++ — 562 мсек, C# — 92 мсек.
G>>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
H>Несмотря на всю бессмысленность синтетики,
Работа с динамической памятью является основной операцией в большенстве программ .
H>скажи, на какой машинке делал замер? Процессор (частота), память (тип, PC...)?
Ноут, Intel Core2Duo 1800 или около того, памяти 2 гб DDR2, ОС — виста.
Для сравнения запустил на домашнем компе, у него одноядерный Athlon 64 (GC точно не concurrent), 3 гига памяти, ОС — Windows Server 2008 x64.
Замеры C++ — 562 мсек, C# — 135 мсек.
Опять даже если учесть что в реальном случае .NET может работать в два раза медленее, то все равно не в пользу C++.
Приложение на C# запустилось как 64-битное, что многло дать задержки на операции присваивания.
Здравствуйте, Sheridan, Вы писали:
S>Sinclair wrote:
>> S>В англицком к примеру я не силен. >> Как же ты живешь-то? S>Да неплохо в общем то живу.
>> S>В трех словах пожалуйста опиши что там происходит. Насколько я понял — чел добился существенного увеличения производительности, или нет? >>
...
S>Спасибо. Все правильно написано. Оптимизировать нужно в разумных пределах.
Самое главное
Если я и выучил хоть что-то про анализ производительности, так это то, что мои догадки о расположении узких мест зачастую неверны
Здравствуйте, hattab, Вы писали: H>Я делаю выводы исключительно на основе личного опыта работы с .Net софтом.
Личный опыт — штука субъективная. Вот, к примеру, что пишут ведущие собаководы:
As user-interface folks know, perceived performance and actual performance can often be different things. I [Steven] remember when I was writing a portion of the Windows UI for Visual C++ and when I benchmarked against Borland C++ at the time, we were definitely faster (measured by seconds). However the reviews consistently mentioned Borland as being faster and providing feedback in the form of counts of lines compiled flying by. So I coded up a line count display that flashed a lot of numbers at you while compiling (literally flashy so it looked like it couldn't keep up). In clock times it actually consumed a non-zero amount of time so we got "slower" but the reviewers then started giving us credit for being faster. So in this case slower actually got faster.
Здравствуйте, criosray, Вы писали:
C>Обычно и того меньше — до 2GB, что можно переконфигурировать в boot.ini и получить до 3х.
Уточню, процесс видит адресного пространства 4Gb/Segment, но использовать под свои нужды может тока младшие 2(3)Gb. Остальным распоряжается система.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
VS 2003 + ICC 11, C++ : 188
VS 2008, C# : 117
G>Собиралось 2008 студией, релиз, запуск из проводника. G>C++ — 562 мсек, C# — 92 мсек.
Дааа, хреновый С++ стал в 2008й студии. Наводит на интересные мысли.
G>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
У меня как видишь, рядышком.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Вы что же картинки в base64 гоняете? Вот такие, простите, индусоалгоритмизаторы и есть причина репутации .NET как медленной среды.
Хардкодинг урлов в атрибутах — моветон.
Java-like нотация записи методов (getScreenshot64) — моветон.
В С# нет оператора :=
Неиспользование using для MemoryStream — утечка ресурсов.
Читабельность Picture.Bitmap.LoadFromStream(TXmlRpcBase64(XmlRpcServerProxy('http://127.0.0.1/').keyhole.getScreenshot64(320, 200)).AsStream); -- отвратительная.
Если у тебя проектирования не было, а задача сложная, то будет тормозное г., при этом факт того, что это тормозное г. будет задокументирован профайлером 
Современным нативным аллокаторам тоже не требуется.
(причем размер кучь у поколений постоянно меняется)
Вот такие, простите, индусоалгоритмизаторы и есть причина репутации .NET как медленной среды. 
