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

S>Я понимаю, головой думать — это тяжелая работа.
А переход на личности -- это такой способ ведения дискуссий от MVP?

S>Ок, специально для тех, кто не представляет себе, что бывает "дальше" после просмотра профайлером, маленькая история вот здесь.

Это всё конечно очень интересно, но при чём тут GC?

Кроме того, то, что он сразу же искал неэффективным образом (хотя, как я понял, это основная функциональность в проге!!!), говорит о том, что проектировать это дело он и не пытался. А пытался типа написать, потом профильнуть, потом трясти...

Что бы получилось, если бы он сначала таки подумал как сделать его прогу быстрой, потом это запроектировал, а только потом уже бомбил, не известно. Мне так кажется, что 2 секунды для этой программки -- ЭТО ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ ДОЛГО.
Правда он сам себе выдал ТЗ, что "и так сойдёт", исправил грубую ошибку проектирования и получил в результате "саксесс стори". Но когда ты сам себе орбитр не трудно всегда побеждать.
А вот, если в дело вмешиваются клиенты и конкуренты, ситуация несколько меняется...

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

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

G>>>>Кстати о базах: есть couchDB, которая написана на Erlang, который является одним из самых медленных языков. И ниче, всем кто пользуется — нравится.

H>>>У Borland/CodeGear тоже есть SQL сервер -- BlackFish, на Java и .Net. Я не в курсе, как там с перформансом, но и ежу понятно, что основная нагрузка при работе с БД ложится на дисковую систему, а вовсе не на управляемый код.
G>>
G>>Там кроме диска еще оооочень много факторов, влияющих на производительность.
H>Читаем вдумчиво.
Наверное надо было доабавить что работа с диском в меньшей степени влияет на производительность реальных СУБД, потому что там алгоритмической сложности нету, надо только подстроить под особенности работы ОС с диском.

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

S>Здравствуйте, Хвост, Вы писали:
Х>>немного непонятно что ты в етой задаче нашёл такого "сложноописуемого" на с++
S>Не вижу сортировки по алфавиту.

multiset

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

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

CC>CPUID: Intel(R) Pentium(R) D CPU 2.66GHz

CC>VS 2003 + ICC 11, C++ : 188
CC>VS 2008, C# : 117
Можно только порадоваться за компилятор интела.
А сколько ядер на машине?

G>>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
CC>У меня как видишь, рядышком.
Тем не менее в полтора раза.
При желании алгоритм в программе на C# можно построить так чтобы результат оказался близким к результату синтетического теста.
В целях оптимизации вполне можно так поступить.

gandjustas wrote:

> Самое главное
>

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

> Тебе стоит это учесть.

То что последнее слово за профайлером я и так знаю.

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

S>gandjustas wrote:

>> Самое главное
>>

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

>> Тебе стоит это учесть.

S>То что последнее слово за профайлером я и так знаю.

Неверно.
За профайлером должно быть первое слово.

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

C>Неиспользование using для MemoryStream — утечка ресурсов.
Разве?

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

E>Кроме того, то, что он сразу же искал неэффективным образом (хотя, как я понял, это основная функциональность в проге!!!), говорит о том, что проектировать это дело он и не пытался. А пытался типа написать, потом профильнуть, потом трясти...
Совершенно верно. И это — единственный способ писать хорошие программы.

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

E>Мне так кажется, что 2 секунды для этой программки -- ЭТО ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ ДОЛГО.
Напомню, что цели должны быть ориентированы на потребителя, а не высосаны из пальца. Сколько, по-твоему, должна работать эта программа? Почему?

E>А вот, если в дело вмешиваются клиенты и конкуренты, ситуация несколько меняется...
Читать последнюю строчку в его статье.

Здравствуйте, gandjustas,
кстати, скажи пожалуйста, а сколько лично у тебя установлено .NET приложений уровня desktop?

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

H>>>>Сборщик мусора, даже на многопроцессорной машине, даже "серверный", вынужден останавливать выполняющиеся потоки. Concurent GC требует синхронизации, что на производительности не может не сказаться.
G>>>Но ты не забывай что GC не требуется проходи по списку на каждое выделение-освобождение.
H>>А я этого и не говорил Современным нативным аллокаторам тоже не требуется.
G>Я привел пример кодаЮ доказывающий обратное.
G>Можешь конечно повторять свой тезис, но правдивее он не станет.

Смотри мой следующий пост Сурпрайз будет

G>>>Покажите код (.NET и нативный) и результаты замеров, тогда вам кто-нибудь поверит.
H>>Код библиотеки XML-RPC.NET можешь скачать с ее домашней страницы. Для мониторинга использовал ProcessExplorer. В итоге, на 170 вызовов XML-RPC метода имеем: 101 сборка во втором поколении, 111 сборок в первом поколении, 295 сборок в нулевом поколении.
G>А замеры производительности? Без них от этого толку нет. Лучше профайлером, чтобы сразу было видно где и от чего тормозит.

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

G>>>Вообще за все время ты ни разу не привел аргументы почему .NET работает медленнее, все сводилось к каким-то левым наблюдениям (которые еще и не у всех воспроизводятся) и недалеким выводам.
H>>А как надо наблюдать, чтоб наблюдения стали правыми? Использую, что имеется в наличии (софт т.е.), мониторю чем сам МС велел (perfmon-счетчики, они и в ProcessExplorer'е). Выводы исключительно по результатам
G>По каким? Ты делаешь вывод о производительености, при этом не приводя ни одного факта, касающегося непостредственно этой самой производительности.

Количество сборок мусора я привел

G>>>Кроме того ты очень активно в своих суждениях опираешься на библиотеку XML-RPC.NET, которая вообще непонятно как работает.
H>>Библиотека XML-RPC.NET используется по нескольким причинам: 1) XML-RPC мне интересен. 2) При его реализации не обойтись без многократных выделений памяти, что в свою очередь позволяет увидеть, как на это реагирует GC. В общем, ссылку на сурсы я дал. Стоит ждать критики?
G>Где XML-RPC.NET найти я знаю, дай сырцы натвного исполнеия для сравнения.

Я не могу тебе дать сурсы закрытой библиотеки. Но ты не понял главной мысли. Я не пытаюсь сравнить XML-RPC.NET с моей нативной реализацией, т.к. это бессмысленно по причине разных алгоритмов парсинга пакетов. Она тут в пример приводится только для демонстрации поведения GC. Пойми это наконец.

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

H>>Несмотря на всю бессмысленность синтетики,
G>Работа с динамической памятью является основной операцией в большенстве программ.

Да, только эта синтетика с реальностью ничего общего не имеет

H>>скажи, на какой машинке делал замер? Процессор (частота), память (тип, PC...)?
G>Ноут, Intel Core2Duo 1800 или около того, памяти 2 гб DDR2, ОС — виста.

G>Для сравнения запустил на домашнем компе, у него одноядерный Athlon 64 (GC точно не concurrent), 3 гига памяти, ОС — Windows Server 2008 x64.
G>Замеры C++ — 562 мсек, C# — 135 мсек.
G>Опять даже если учесть что в реальном случае .NET может работать в два раза медленее, то все равно не в пользу C++.
G>Приложение на C# запустилось как 64-битное, что многло дать задержки на операции присваивания.

Теперь обещаный сурпрайз

Turbo Delphi 2006:

Type

 TIntArray = Array [0 .. 63] Of Integer;
 PIntArray = ^TIntArray;

Var

 Index : Integer;
 arr   : PIntArray;
 sw    : THighResStopwatch; // на основе QueryPerformanceCounter

begin

 sw.Start;

 For Index := 1 To 1000000 Do
  Begin

   New(Arr);
   Dispose(Arr);

  End;

 sw.Stop;

 ShowMessageFmt('Time: %d', [sw.ElapsedTime]);

end;

Pentium M 1.7GHz. Память PC2700. Время: 67ms.

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

H>>Я делаю выводы исключительно на основе личного опыта работы с .Net софтом.
S>Личный опыт — штука субъективная. Вот, к примеру, что пишут ведущие собаководы:
S>http://blogs.msdn.com/e7/archive/2008/12/15/continuing-our-discussion-on-performance.aspx
S>Забавно, не правда ли?

Все в нашем мире субъективно.

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

H>>Не то чтобы мне было жалко денег (~$170 за 2Gb)
CC>Ох мать, а чего так дорого то?

$74 стоимость 1Gb планки (SODIMM PC2700 200pin 2.5v) на Никсе + 15% моего продавца И это еще не самая дорогая...

gandjustas wrote:


> S>То что последнее слово за профайлером я и так знаю.
> Неверно.
> За профайлером должно быть первое слово.
Слушаю и повинуюсь, о грозный Ганджустас!!!

Здравствуйте, Хвост, Вы писали:
Х>multiset
А он неявно сортирует??? Офигеть. Я как отвык от того, что для множества нужно задавать отношение частичного порядка.
Я надеюсь, уточнение сортировки в Case-insensitive/accent-sensitive для турецкой локали не усложнит эту безусловно прекрасную программу?

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

H>>Код чего показать? Как делается вызов XML-RPC метода? OK (но что тебе это дасть?). (пишу по памяти)

H>>C#:
H>>

H>>[XmlRpcUrl("http://127.0.0.1/")] 
H>>public interface IScreenshot
H>>{ 
H>>  [XmlRpcMethod("keyhole.getScreenshot64")]  
H>>  byte[] getScreenshot64(int x, int y);
H>>}

H>>...

H>>Picture.Image := Bitmap.FromStream(new MemoryStream(XmlRpcProxyGen.Create<IScreenshot>().getScreenshot64(320, 200)));
H>>

H>>Delphi:
H>>

H>>Picture.Bitmap.LoadFromStream(TXmlRpcBase64(XmlRpcServerProxy('http://127.0.0.1/').keyhole.getScreenshot64(320, 200)).AsStream);
H>>

C>Вы что же картинки в base64 гоняете? Вот такие, простите, индусоалгоритмизаторы и есть причина репутации .NET как медленной среды.

Base64 -- единственный способ передать бинарные данные в XML-RPC.

C>Хардкодинг урлов в атрибутах — моветон.

Это тестовый пример

C>Java-like нотация записи методов (getScreenshot64) — моветон.

Это негласный стандарт в XML-RPC.

C>В С# нет оператора :=

Писал по памяти. Pascal мой основной язык.

C>Неиспользование using для MemoryStream — утечка ресурсов.

Чего-то я не понял, а каким ресурсом, кроме собственно памяти, владеет MemoryStream?

C>Читабельность Picture.Bitmap.LoadFromStream(TXmlRpcBase64(XmlRpcServerProxy('http://127.0.0.1/').keyhole.getScreenshot64(320, 200)).AsStream); -- отвратительная.

Еще раз: это тестовый пример.

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

H>>>>У Borland/CodeGear тоже есть SQL сервер -- BlackFish, на Java и .Net. Я не в курсе, как там с перформансом, но и ежу понятно, что основная нагрузка при работе с БД ложится на дисковую систему, а вовсе не на управляемый код.
G>>>
G>>>Там кроме диска еще оооочень много факторов, влияющих на производительность.
H>>Читаем вдумчиво.
G>Наверное надо было доабавить что работа с диском в меньшей степени влияет на производительность реальных СУБД, потому что там алгоритмической сложности нету, надо только подстроить под особенности работы ОС с диском.

Ты же вроде отметился в ветке, где приводили пример работы MSSQL с базой на диске и в памяти... Основные задержки, это, как раз таки, выборка данных с диска.

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

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

H>>>>>У Borland/CodeGear тоже есть SQL сервер -- BlackFish, на Java и .Net. Я не в курсе, как там с перформансом, но и ежу понятно, что основная нагрузка при работе с БД ложится на дисковую систему, а вовсе не на управляемый код.
G>>>>
G>>>>Там кроме диска еще оооочень много факторов, влияющих на производительность.
H>>>Читаем вдумчиво.
G>>Наверное надо было доабавить что работа с диском в меньшей степени влияет на производительность реальных СУБД, потому что там алгоритмической сложности нету, надо только подстроить под особенности работы ОС с диском.

H>Ты же вроде отметился в ветке, где приводили пример работы MSSQL с базой на диске и в памяти... Основные задержки, это, как раз таки, выборка данных с диска.
Но оптимизировать эти издержки не сильно получится, только компромисс время-память.
Зато есть куча других мест в СУБД, в которых придется сильно понапрягаться чтобы вытянуть производительность.

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

G>А сколько ядер на машине?
2 честных (не НТ)

G>В целях оптимизации вполне можно так поступить.
Могу ли я в таком случае оптимизировать С++ код?
Простое убирание блокировки (CriticalSection) через применение Per-Thread Allocator дает уже 47

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

G>>А сколько ядер на машине?
CC>2 честных (не НТ)

G>>В целях оптимизации вполне можно так поступить.
CC>Могу ли я в таком случае оптимизировать С++ код?
CC>Простое убирание блокировки (CriticalSection) через применение Per-Thread Allocator дает уже 47

в Delphi без блокировок 24