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


E>Есть уровень сложности задачи, например текстовый редактор, где GC работает очень хорошо, но с ростом сложности задачи ситуация портится. Скажем при написании базы данных тебе уже придётся очень крепко думать про то как же у тебя данные будут с GC взаимодействовать...
Ты так говоришь как-будто все каждый день пишут базы данных.

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

E>>>Кстати, в C++ наработано много всяких подходов к этому месту, так что обычно можно быть по крайней мере не хуже в области массовых аллокаций, чем GC...
G>>Да, в C++ надо думать о том когда и как выдеоять и освобожать память.
G>>В .NET об этом думать не надо. Если будет тормозить тогда смотреть профайлером.
E>Ну и поспотришь ты профайлером, и что дальше будет?
Исправлю код там где торомзит.


E>>>Например, можно на каждый запрос на каждой нити создавать отдельный стековый аллокатор, и на нём ничего не освобождать, а только выделять. По окончании запроса данные, которые нужно сохранить мигрируют на обычный аллокатор, а стековый грохается целиком в начальное состояние, и мы снова готовы обработать запрос. В целом для очень многих задач такая стратегия аллокации НАМНОГО ЭФФЕКТИВНЕЕ GC...
G>>Это теория, покажите такие программы на практике.
E>Какие "такие"? Быстрые и написанные на неуправляемом языке? Ядро линукса, например, устроит?
Утстроит, где там C++? Там голый С.
Ядро винды тоже на С вроде как написано.
Если почитаешь ветку я многократно говорил что performance-critical части можно и иногда нужно писать на С.


G>>Обычно ручная возьня с ресурсами очень сильно увеличивает время разработки программ. Такую возьню могут позволить себе только очень крупные фирмы.
E>Обычно, ручная возня с ресурсами занимает очень маленькую часть затрат на разработку действительно сложного ПО (например переводчика, или операционной системы)...
Ну на управляемых языках это так, на неупрвляемых — зависит от разработчика.

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

MK>>Вот-вот! Только представь, каждый день на работу и обратно таскать эти два тяжелых чемоданчика с .net runtime. Там по 20 кг в каждом! Порог вхождения очень высок
___>Осталость только домыслить "привяжешь себя к виндам" — привязал себя веревкой к оконной раме.
И придется ее тоже с собой таскать, на спине, в рюкзачке!

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

И>>>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь.
G>>>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
CC>>Ты не в тот таскманагер смотришь, тебе уже сообщали.
G>Пор цифирке в таскабаре — не ко мне, они меня мало интересуют. Я производидтельность профайлером меряю.
И давно ты "кол-во используемой памяти" меряешь профайлером?

G>>>Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET.
CC>>Кстати, как там на данный момент обстоит дело с GC в условиях наличия за-pin-ованых объектов?
G>То что выделено до запиненного объекта — не уплотняется.
G>Перерасход памяти из-за большого количесва запиненных объекктов — признак неграмотности программиста
Т.е. использование одного компонента, написанного говнокодером херит всю стройную систему?

G>>>Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором.
CC>>Это как напишешь. В unmanaged в реальном коде где надо performance выделение/освобождение памяти выносят "за скобки" и делают крайне редко.
G>Это примерно тоже самое что performance-critical код написать на С, а потом интеропать с ним из managed.
И не близко даже.

И>>>>а) есть стэк;
G>>>Стек заставляет копировать объекты чаще, чем нужно.
CC>>С чего бы вдруг?
G>Передача объектов по значению вызывает копирование.
Обьясни поподробнее какая связь между аллокацией на стеке и передачей объектов по значению?

И>>>>b) есть placement new;
G>>>Теже яйца что и кастомный аллокатор, только сбоку
CC>>Только без затрат на выделение памяти. Т.е. совсем бесплатный считай.
G>А откуда возьмется память в которой будет делаться placement new ?
Откуда угодно. Любая свободная память. Сам по себе placement new не равняется аллокатору.

И>>>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части;
G>>>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
CC>>Как показывает практика — есть. В таком контексте С++ от С мало чем отличается, только поудобнее разве что. Не надо только на нём александрескить и говнокодить.
G>Испоьзовать C++ как C_с_классами конечно можно, только это получается ну очень низкоуровневое программирование.
"С с классами" как и "функциональщина из буста" это крайности. Я не про них.

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

H>Ага, заметил некоторые траблы с использованием.
Там траблов на самом деле еще много Например никак не делалась обработка динамически подгружаемых DLL и т.п.
Писалась "под задачу" и "надо вчера", потому остановилась на этапе как тока на требуемом exe стала показывать результаты аллокаций.

H> Но вообще, интересная софтинка
Надо будет как нить ее доделать. Там самое полезное — DLL. EXE занимается инжектом DLL в процесс, приемом от нее данных с записью в файл и потом показ намерянного.

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

g> E>Есть уровень сложности задачи, например текстовый редактор, где GC работает очень хорошо, но с ростом сложности задачи ситуация портится. Скажем при написании базы данных тебе уже придётся очень крепко думать про то как же у тебя данные будут с GC взаимодействовать...

g> Ты так говоришь как-будто все каждый день пишут базы данных.

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

Слющай, зачэм couchdb? В поставку Эрланга входит тоже неплохая база — mnesia. Написана тоже на Эрланге

Не говоря уж о двух хороших, быстырых веб-серверах

g> E>Ну и поспотришь ты профайлером, и что дальше будет?
g> Исправлю код там где торомзит.

"Сделай так, чтобы вещь заработала. Потом, если необходимо, сделай так, чтобы вещь работала быстро" © философия разработчиков Эрланга

И это вполне правильный подход

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

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

И>>>>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь.
G>>>>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
CC>>>Ты не в тот таскманагер смотришь, тебе уже сообщали.
G>>Пор цифирке в таскабаре — не ко мне, они меня мало интересуют. Я производидтельность профайлером меряю.
CC>И давно ты "кол-во используемой памяти" меряешь профайлером?
А я где-то говрил что меряю количество памяти?
Я же написал что эти цифирки не интересуют. Если нужно быстродействие, то меряю его профайлером.

G>>>>Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET.
CC>>>Кстати, как там на данный момент обстоит дело с GC в условиях наличия за-pin-ованых объектов?
G>>То что выделено до запиненного объекта — не уплотняется.
G>>Перерасход памяти из-за большого количесва запиненных объекктов — признак неграмотности программиста
CC>Т.е. использование одного компонента, написанного говнокодером херит всю стройную систему?
Оно всегда так, любой маленький кусок говнокода может испортить прогу.
А способов надолго запинить память не так много.

И>>>>>а) есть стэк;
G>>>>Стек заставляет копировать объекты чаще, чем нужно.
CC>>>С чего бы вдруг?
G>>Передача объектов по значению вызывает копирование.
CC>Обьясни поподробнее какая связь между аллокацией на стеке и передачей объектов по значению?
А возвращение объектов при выделении памяти на стеке как происходит?

И>>>>>b) есть placement new;
G>>>>Теже яйца что и кастомный аллокатор, только сбоку
CC>>>Только без затрат на выделение памяти. Т.е. совсем бесплатный считай.
G>>А откуда возьмется память в которой будет делаться placement new ?
CC>Откуда угодно. Любая свободная память. Сам по себе placement new не равняется аллокатору.
Ну не равняется, и что с того?


G>>Испоьзовать C++ как C_с_классами конечно можно, только это получается ну очень низкоуровневое программирование.
CC>"С с классами" как и "функциональщина из буста" это крайности. Я не про них.
А в среднем случае C++ сильно уступает по выразительности современныхм языкам.

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

E>>Скажем на С++ можно делать так

Автор: Erop
Дата: 27.02.07

...
G>В нормальных языках такого не нужно делать в принципе.

Что значит "не нужно"?
В С++ тоже не нужно, пока в каком-то месте не понадобится чтобы было реально быстро...
И вот тогда в том самом месте в С++ так сделать можно.
А в "нормальных" языках можно рассказать, что GC -- это уже верх совершенства, а память стоит дёшево...
А что можно сделать в тех самых "нормальных"?

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

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

Но если проге реально нужно МНОГО памяти, то всё ещё хуже. Особенно если её надо много, но небольшими блоками. Вот в моих С++ прогах часто заканчивается адресное пространство 32-й винды, например. И всякие прототипы на С# показывают радикально худшую производительность/эффективность по памяти

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

E>>уже придётся очень крепко думать про то как же у тебя данные будут с GC взаимодействовать...
G>Ты так говоришь как-будто все каждый день пишут базы данных.
Во-первых, те, кто решают сложные задачи, они этим заняты обычно каждый день. Написать большой проект -- это не быстро.
Во-вторых, я утверждаю следующее:

Есть некоторый уровень сложности задач, довольно средний, под который GC оптимизирован и на котором он работает неплохо, хотя и с некоторыми известными особенностями и косяками. Этот уровень задачи -- сложный GUI. Для задач на порядок-другой более сложных GC работает хреново. И тогда сказывается то, что GC -- это автоматическая хреновина, которую хрен настроишь по месту, так что требования к точности продумывания архитектуры сложного проекта намного жёстче, чем в случае неуправляемых языков.

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

E>>Ну и поспотришь ты профайлером, и что дальше будет?
G>Исправлю код там где тормозит.
Если неправильная архитектура, то тормозит везде...

G>Утстроит, где там C++? Там голый С.
G>Если почитаешь ветку я многократно говорил что performance-critical части можно и иногда нужно писать на С.
Как С и С++ отличаются с точки зрения управляемости и GC? В С++ типобезопасность есть и конструкторы с деструкторами. А ещё там есть виртуальные функции, исключения и шаблоны. И что? Как это всё вообще влияет на обсуждаемые проблемы? Это всего лишь на процесс разработки может повлиять...

Тем не мнее я знаю много довольно быстрого С++ кода, который ворочает большими объёмами данных и весьма быстро. Но не могу его тут опубликовать.

E>>Обычно, ручная возня с ресурсами занимает очень маленькую часть затрат на разработку действительно сложного ПО (например переводчика, или операционной системы)...
G>Ну на управляемых языках это так, на неупрвляемых — зависит от разработчика.
Нет. Не зависит. Плохой разработчик потратит на реализацию сложного проекта бесконечное время Причём на ЛЮБОМ ЯЗЫКЕ...

А вообще-то я согласен с тем, что C++ не терпит лохов, в отличии от C#. То, что C# -- это очень хороший язык для индусов, никто вроде бы и не оспаривает... Думаю, что его смело можно называть ХиндиС (шутка)

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

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

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

E>А что можно сделать в тех самых "нормальных"?

Видимо ты знаешь, что можно сделать? Да? От чего скрываешь?

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

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

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

E>Но если проге реально нужно МНОГО памяти, то всё ещё хуже. Особенно если её надо много, но небольшими блоками. Вот в моих С++ прогах часто заканчивается адресное пространство 32-й винды, например. И всякие прототипы на С# показывают радикально худшую производительность/эффективность по памяти
И что за программа которой столько памяти нужно?

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

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

E>>>уже придётся очень крепко думать про то как же у тебя данные будут с GC взаимодействовать...
G>>Ты так говоришь как-будто все каждый день пишут базы данных.
E>Во-первых, те, кто решают сложные задачи, они этим заняты обычно каждый день. Написать большой проект -- это не быстро.
Эти размышления к чему?
Сколько сейчас существует СУБД, которые реально используются? Десятка три наберется, а сколько приложений, посльзующихся этимы самыми БД?
Причем приложения по сложности могут быть сравнимыми с самой БД.

E>Во-вторых, я утверждаю следующее:

Есть некоторый уровень сложности задач, довольно средний, под который GC оптимизирован и на котором он работает неплохо, хотя и с некоторыми известными особенностями и косяками. Этот уровень задачи -- сложный GUI. Для задач на порядок-другой более сложных GC работает хреново. И тогда сказывается то, что GC -- это автоматическая хреновина, которую хрен настроишь по месту, так что требования к точности продумывания архитектуры сложного проекта намного жёстче, чем в случае неуправляемых языков.

Непонятно какая метрика используется для сложности.
Вот есть приложение на .NET — www.microsoft.com, там какая сложность?

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

E>>>Ну и поспотришь ты профайлером, и что дальше будет?
G>>Исправлю код там где тормозит.
E>Если неправильная архитектура, то тормозит везде...
Вопросы архитектуры ортогональны вопросам быстройдействия.

G>>Утстроит, где там C++? Там голый С.
G>>Если почитаешь ветку я многократно говорил что performance-critical части можно и иногда нужно писать на С.
E>Как С и С++ отличаются с точки зрения управляемости и GC? В С++ типобезопасность есть и конструкторы с деструкторами. А ещё там есть виртуальные функции, исключения и шаблоны. И что? Как это всё вообще влияет на обсуждаемые проблемы? Это всего лишь на процесс разработки может повлиять...
И опять приходим к тому что для того случая где нужно быстродействие используем C, а для всего остального высокоуровневые средства.

E>>>Обычно, ручная возня с ресурсами занимает очень маленькую часть затрат на разработку действительно сложного ПО (например переводчика, или операционной системы)...
G>>Ну на управляемых языках это так, на неупрвляемых — зависит от разработчика.
E>Нет. Не зависит. Плохой разработчик потратит на реализацию сложного проекта бесконечное время Причём на ЛЮБОМ ЯЗЫКЕ...
А кто говорит о плохом разработчике?

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

G>>>Посмотрел то что я писал, для программы показатель COMMITED памяти редко переваливает за 300 метров, это очень много?
G>У меня прога занимается расчетами и их визуализацией.
А для расчётов много памяти надо? Так сказать вне связи с языком? И как эта память выделяется? Большими кусками (ну там пять матриц по 50 метров) или небольшими объектами?

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

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

S>У Intel-a была такая попытка — Itanium64. Так был послан далеко и надолго, вернулись на Amd64.

Странно. А это что? :
http://www.itaniumsolutions.org/technology
http://h20341.www2.hp.com/integrity/cache/342254-0-0-178-352.html?jumpid=reg_R1002_RURU

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

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

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

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

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

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

G>>>>Посмотрел то что я писал, для программы показатель COMMITED памяти редко переваливает за 300 метров, это очень много?
G>>У меня прога занимается расчетами и их визуализацией.
E>А для расчётов много памяти надо? Так сказать вне связи с языком? И как эта память выделяется? Большими кусками (ну там пять матриц по 50 метров) или небольшими объектами?
Для расчетов — большими, матрицы примерно 100х100.
Для визуализации — куча маленьких.
Я вообще говоря не следил за выделением памяти в этой программе.

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

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

И>>>>>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь.
G>>>>>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
CC>>>>Ты не в тот таскманагер смотришь, тебе уже сообщали.
G>>>Пор цифирке в таскабаре — не ко мне, они меня мало интересуют. Я производидтельность профайлером меряю.
CC>>И давно ты "кол-во используемой памяти" меряешь профайлером?
G>А я где-то говрил что меряю количество памяти?
G>Я же написал что эти цифирки не интересуют. Если нужно быстродействие, то меряю его профайлером.
Ты придуриваешься или всегда такой? Специально оставил поквоченную всю историю вопроса. Речь шла про (см. выше) память. Перечитай внимательно.

G>>>Перерасход памяти из-за большого количесва запиненных объекктов — признак неграмотности программиста
CC>>Т.е. использование одного компонента, написанного говнокодером херит всю стройную систему?
G>Оно всегда так, любой маленький кусок говнокода может испортить прогу.
G>А способов надолго запинить память не так много.
Беда то в том, что входной порог в managed сильно низкий, и обложенный памперсами нуб может спокойно говнокодить не получая при этом за свой говнокод по рукам — работает же, и не падает.

И>>>>>>а) есть стэк;
G>>>>>Стек заставляет копировать объекты чаще, чем нужно.
CC>>>>С чего бы вдруг?
G>>>Передача объектов по значению вызывает копирование.
CC>>Обьясни поподробнее какая связь между аллокацией на стеке и передачей объектов по значению?
G>А возвращение объектов при выделении памяти на стеке как происходит?
Если объект сколь либо серьезных размеров возвращают то никто его на стеке в здравом уме не станет размещать.
Кстати в случае если все таки размещают то ситуацию несколько спасает RVO.

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

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

G>Много ли у вас кода на C++ (с классами, шаблонами, полиморфизмом, эксепшенами и динамической памятью) в тех местах где нужно высокое быстродействие?
С классами, шаблонами — навалом. На производительности результата они не сказываются.
Полиморфизм через виртуальное наследование и исключения — в HPC используются только тогда, когда без них ну совсем ВАЩЕ никак.
Динамическая память используется, но выделение/освобождение из критического кода выносятся по максимуму — всё выделяется заранее.

NBN>>А если вы владеете С++ недостаточно — то исчезает последняя почва для спора С++ — язык сложный и филиграный и использовать его в качестве лома действительно не стоит.
G>Вообще сложность C++ такова что его использовать почти нигде не стоит.
Это всего лишь твоё мнение.
Хочешь реальных сложностей — на асме под мелкие контроллеры попиши.

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

NBN>>А чем мешают шаблоны и классы там где нужна высокая производительность?
G>Вряд ли они там мешают, но не помогают — это точно.
Код писать с ними удобнее чем в С стиле.

NBN>>Ага, кроме как для игр, приложений затрагивающих эмбеддед сложнее простейших контроллеров, кроссплатформенных приложений которым требуется шустрая работа.
G>С играми отдельная песня — там сейчас во всю идет перенос тяжелых вычислений на аппартаные ускорители.
Да ты еще и геймдевелопер я смотрю И спец по переносу расчетов на GPU.
Ну-ка расскажи что там и как в геймдеве, а я послушаю.

G>Кроме того .NET не такой медленный как тут некоторые пытаются показать.
Уже всё всем давно показали: Cellfactor

G>А многим ли приложениям на десктопе нужная шустрая работа?
По мне так всем.

G>У меня таких только два — браузер и среда разработки. Причем опера (которая на C++) тормозит гораздо сильнее чем VS (которая на треть из managed модулей).
Ужас какой. Бери FF — она у меня тормозит куда меньше чем VS2003/2005/2008, которые у меня тут установлены.