Здравствуйте, hattab, Вы писали:
G>>Включай мозг: все что требуется от такого "графа" только возможность проверить присуствует ли объект в нем. Это значит что достаточно битовго флага.

H>Давай ты последуешь своему совету и подумаешь, что такое граф и, как с помощью битового флага (а точнее речь идет битовом массиве, как я понимаю) можно определить находжение объекта в куче для последующих манипуляций с оным.
Увы, всё так и есть. Упорство в заблуждениях никого не красит. Никакого "отдельного" графа GC не строит. Он раскрашивает существующий.
Объем памяти, нужный для Register Map, крайне мал.

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

G>Сколько у тебя на компютере программ "одноврменно работают" без твоего участия?
По пять — десять на каждом...

E>>Если да, то это всего-навсего 8 метров... Так что твоя прока тупо профукала 250 из 300, то есть более 80% использованной памяти!!!
G>О ужас, горе мне.
G>А вообще меня это нисколько не волнует.
Я понимаю, что тебя это не волнует. Но те, кого парит эффективность их программ, несколько недовольны таким положением вещей...

Hi gandjustas

Начал читать это
G>2)Платформа .NET, на которой работает C# — это не только десктопные программы,

И сразу вспомнил:

Кролики — это не только ценный мех ...

Без обид. Я пишу не имея камня за пазухой. Просто само и сразу же всплыло в голове.

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

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

E>>>А подробности будут?
E>>>Я всё равно не верю, что, Ada и С++ имеют одинаковый показатель.
G>>Можете не верить.
E>Дык данные-то есть? Методика, что и как измеряли? На каких примерах? Какая получилась статистика?

E>>>Кроме того, на чём же тогда статистика для С# собрана, если только КРУПНЫЕ проекты идут в счёт? На сингулярити, что ли?
G>>На C# очень много крупных проектов, с миллионами строк кода.
E>"Очень много" -- это наверное больше 10? Не затруднит привести 5 C# проектов, которые на миллион строк тянут?
E>Кстати, миллион строк кода -- это не очень крупный проект...
E>Крупный проект, это от 100-300 человеколет, например...


Могу привести пример ediEnterprise ЕРП система для логистики(подробностей не знаю). Штат разработчиков — около 90 человек, полностью написано на C#, тянет на 300-400 человеколет =)

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

S>Могу привести пример ediEnterprise ЕРП система для логистики(подробностей не знаю). Штат разработчиков — около 90 человек, полностью написано на C#, тянет на 300-400 человеколет =)

Да, согласен, это уже крупный проект. Интересно, кстати, какое там соотношение между SQL и C#?

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

G>>>Ключевое выделил.
H>>Угу, а при его отсутствии начнется деградация производительности (ведь алгоритмы перестанут работать эффективно, как следует из цитаты)
G>Я например замечаю что память кончается конда показатель выделенной физической памяти подбирается к 98 процентам.
G>В таких условиях тормозит все.

Отсутствие большого объема свободной памяти и отстутствие свободной памяти вообще, сравнивать, как бы, нельзя

H>>Во ведении там есть несколько слов, найдешь А вообще, слова теже самые, что и у Рихтера. Я вообще удивлен, чего ты этот очевидный и признаваемый факт отрицаешь...
G>Ага, видно что прочитал введение и заключение.

Я тебе уже цитировал Рихтера, и не вижу ни какой необходимости цитировать тоже самое еще раз

H>>Не жалко. Просто ты говорил о редких сборках мусора, а я тебе примеры привожу, которые показывают обратное.
G>3 раза в секунду это часто?
G>На гигагерцовом процессоре за секунду выполняется 1000000000 тактов. При этом если в приложении ничего не происходит, то все поколение становится мксором и не происходит фактически уплотнения кучи.

Это демагогия.

G>Сборщик мусора на многопроцесорной машине работает в фоновом режиме по большей части.
G>Так что влияние на производительность минимальная.

Сборщик мусора, даже на многопроцессорной машине, даже "серверный", вынужден останавливать выполняющиеся потоки. Concurent GC требует синхронизации, что на производительности не может не сказаться. Поколения конечно хорошо, но приводимый мною пример с XML-RPC.NET вызывает таки сборку во втором поколении (причем размер кучь у поколений постоянно меняется)

G>>>Надо бы ло внимательнее статью читать, "вдруг" не бывает. тем более это тоже контролируется.
H>>Именно вдруг. Работу GC ты можешь "типа контролировать" подстраивая алгоритм под его текущую стратегию. Зря чтоль Рихтер советует вызывать GC.Collect маскируя его за "тяжелыми операциями"?
G>Мдя... не надо так явно показывать свою недалекость. Читайте про GCSettrings.LatencyMode.

Это не управление, это декларация желаний

H>>Синтетика все что угодно показать может, главное приготовить как надо. Ты, как надо было тебе, приготовил.
G>Ну приготовь как тебе надо, покажи обратное.

Перейдем сразу к оглашению результатов: у меня толще!

H>>Когда у меня кое как начинает шевелиться WLW вылезая из свопа, я очень хорошо сопоставления делаю. Не думаешь же ты, что для запуска этой мелочевки, я буду выгружать софт из своего рабочего окружения.

G>А че, нативное приложение в свом не выгружается? Что ты пытаешься показать этой фразой?

Я говорю о том, что Paint.NET откушавший больше чем Turbo Delphi IDE, отправляется в утиль и остается там навсегда.

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

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

У Borland/CodeGear тоже есть SQL сервер -- BlackFish, на Java и .Net. Я не в курсе, как там с перформансом, но и ежу понятно, что основная нагрузка при работе с БД ложится на дисковую систему, а вовсе не на управляемый код.

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

G>>Посмотрел то что я писал, для программы показатель COMMITED памяти редко переваливает за 300 метров, это очень много?
E>От программы зависит. Для тачки с 512 Мб на борту это больше половины доступного RAM...
E>Так что, если прога -- это часы, например, то привет...

Более того, из 512, после загрузки системы, занято ~200 Не то чтобы мне было жалко денег (~$170 за 2Gb), просто пока меня реально не припрет покупать не буду, а .Net софт меня не припирает

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

G>Я сталкивался с пользователями, которые вполне нормально мирились с генерацияей отчета на 1с (которая на С++) которая длилась двадцать минут.

У меня был контракт с конторой, в которой зарплата расчитывалась 2.5 суток (!) (большая контора). Они тоже считали это нормальным, пока мы не сократили время до 40 минут (переписали с нуля)

G>Проснись, далеко не всем нужна запредельная производительность. А на практике получается что скорость работы программы упирается в диск\сеть и прочее.
G>Только в игрушках может исключение.

Скажи, а во что упирается меню в WLW, отзывчивость которого меня жутко печалит (при установке он прогоняется ngen'ом, так что это не JIT)?

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

___>Хорошо а как быть с программой печати акцизных марок фирмы Атлас написанной на дельфи жрущей 300Мб оперативы, и текущей как дырявое ведро? (Это было года 3 назад).

Странный вопрос... Я разве где-то утверждал, что Delphi или любой другой натив есть решение всех проблем?

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

H>>Давай ты последуешь своему совету и подумаешь, что такое граф и, как с помощью битового флага (а точнее речь идет битовом массиве, как я понимаю) можно определить находжение объекта в куче для последующих манипуляций с оным.
S>Увы, всё так и есть. Упорство в заблуждениях никого не красит. Никакого "отдельного" графа GC не строит. Он раскрашивает существующий.
S>Объем памяти, нужный для Register Map, крайне мал.

Русский перевод Рихтера ввел в заблуждение (я его цитировал) Прозрение пришло в виде другого перевода Рихтера

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

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

G>>>>Ключевое выделил.
H>>>Угу, а при его отсутствии начнется деградация производительности (ведь алгоритмы перестанут работать эффективно, как следует из цитаты)
G>>Я например замечаю что память кончается конда показатель выделенной физической памяти подбирается к 98 процентам.
G>>В таких условиях тормозит все.

H>Отсутствие большого объема свободной памяти и отстутствие свободной памяти вообще, сравнивать, как бы, нельзя
Это к тому что тормозов дополнительных нету независимот от .NET или native.

H>>>Не жалко. Просто ты говорил о редких сборках мусора, а я тебе примеры привожу, которые показывают обратное.
G>>3 раза в секунду это часто?
G>>На гигагерцовом процессоре за секунду выполняется 1000000000 тактов. При этом если в приложении ничего не происходит, то все поколение становится мксором и не происходит фактически уплотнения кучи.
H>Это демагогия.
Демагогия это делать выводы о производительности основываясь на мифилогизированных представлениях о GC.


G>>Сборщик мусора на многопроцесорной машине работает в фоновом режиме по большей части.
G>>Так что влияние на производительность минимальная.

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

H>Поколения конечно хорошо, но приводимый мною пример с XML-RPC.NET вызывает таки сборку во втором поколении (причем размер кучь у поколений постоянно меняется)
Как это влияет на производительность?
Покажите код (.NET и нативный) и результаты замеров, тогда вам кто-нибудь поверит.

H>>>Синтетика все что угодно показать может, главное приготовить как надо. Ты, как надо было тебе, приготовил.
G>>Ну приготовь как тебе надо, покажи обратное.
H>Перейдем сразу к оглашению результатов: у меня толще!


H>>>Когда у меня кое как начинает шевелиться WLW вылезая из свопа, я очень хорошо сопоставления делаю. Не думаешь же ты, что для запуска этой мелочевки, я буду выгружать софт из своего рабочего окружения.
G>>А че, нативное приложение в свом не выгружается? Что ты пытаешься показать этой фразой?
H>Я говорю о том, что Paint.NET откушавший больше чем Turbo Delphi IDE, отправляется в утиль и остается там навсегда.
Такое чувство что кода ты был маленький к тебе приходил дядька из Microsoft и отобрал у тебя конфетку. Теперь ты выплескиваешь свою обиду на форуме.

Вообще за все время ты ни разу не привел аргументы почему .NET работает медленнее, все сводилось к каким-то левым наблюдениям (которые еще и не у всех воспроизводятся) и недалеким выводам.
Кроме того ты очень активно в своих суждениях опираешься на библиотеку XML-RPC.NET, которая вообще непонятно как работает.

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

G>>Проснись, далеко не всем нужна запредельная производительность. А на практике получается что скорость работы программы упирается в диск\сеть и прочее.
G>>Только в игрушках может исключение.

H>Скажи, а во что упирается меню в WLW, отзывчивость которого меня жутко печалит (при установке он прогоняется ngen'ом, так что это не JIT)?
Незнаю во что у тебя меню упирается, только что проверил — все летает.

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

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

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

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

Там кроме диска еще оооочень много факторов, влияющих на производительность.

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

G>Незнаю во что у тебя меню упирается, только что проверил — все летает.
Ну у тебя всегда всё летает. Это не ново.
подумалось мне тут, что не на память-там-шмамять и на камни деньгу тратить надо, чтобы "все летало", а на траву позабористее, что-то типа лайт-версии чёрно-белого плана...

Ганджустас! (И как я раньше тайну ника-то не просёк!!!) Будь человеком, отсыпь кораблик?..

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

G>Но ты не забывай что GC не требуется проходи по списку на каждое выделение-освобождение.

Это никому не требуется, кроме древних-предревних кучь...

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

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

G>>Незнаю во что у тебя меню упирается, только что проверил — все летает.
E>Ну у тебя всегда всё летает. Это не ново.
E>подумалось мне тут, что не на память-там-шмамять и на камни деньгу тратить надо, чтобы "все летало", а на траву позабористее, что-то типа лайт-версии чёрно-белого плана...

E>Ганджустас! (И как я раньше тайну ника-то не просёк!!!) Будь человеком, отсыпь кораблик?..
Я уже бросил

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

E>>Ганджустас! (И как я раньше тайну ника-то не просёк!!!) Будь человеком, отсыпь кораблик?..
G>Я уже бросил
Пока не долетело ;(
Ждёмс...

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

G>>А программа на C++ будет корректировать выделние памяти в зависимости от загруженности компьютера? Конечно нет.
G>>И GC не будет.
NBN>Потому что не сможет
Не только может но и делает.
Подумай на досуге зачем приложения на .NET мониторят \KernelObjects\LowMemoryCondition

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

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

G>>Но ты не забывай что GC не требуется проходи по списку на каждое выделение-освобождение.

E>Это никому не требуется, кроме древних-предревних кучь...

Ну давайте чтобы не быть голословным приведу код:
На c++

#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD ticks = GetTickCount();

    for(int i=0; i<1000000; i++)
    {        
        int* arr = new int[64];
        delete [] arr;
    }

    printf("%d", GetTickCount() - ticks);
    getchar();
    return 0;
}

На C#

static void Main(string[] args)
{
    var sw = new System.Diagnostics.Stopwatch();
    sw.Start();

    for (int i = 0; i < 1000000; i++)
    {
        var arr = new int[64];
        arr[0] = arr[1]; //иначе оптимизатор грохает цикл
    }
    GC.Collect();//чтобы быть уверенным что вся память освободилась

    Console.WriteLine(sw.ElapsedMilliseconds);
    Console.ReadKey();
}

Собиралось 2008 студией, релиз, запуск из проводника.
C++ — 562 мсек, C# — 92 мсек.

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