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

NBN>>>На яве и шарпе нельзя написать качественный продукт удовлетворяющий требованиям
CC>>Зависит от требований.
NBN>Нашим требованиям — создать лучший продукт. Я бы с радостью на шарпе писал, но он, как и ява недостаточно кроссплатформенны и слишком тормозявы на девайсах, для нашей достаточно сложной программы. Каждого из этих факторов достаточно, чтобы от них отказаться в пользу С++.
Это все понятно. Просто разные проекты — разные требования.
Есть такие проекты с такими требованиями (чаще это не коробочный продукт) в которых С# отлично подходит.

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

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

CC>>Написал я как то монитор выделяемой произвольным процессом памяти. Дабы значицца, посмотреть что там да как происходит в закулисье.
CC>>И что я только не гонял сей прогой, но пресловутой фрагментации увидеть так и не удалось.
CC>>HeapAlloc, который уже давным давно используется вместо говноаллокатора ранних версий CRT, отлично справлялся сам.

S>Скажите пожалуйста на каких компиляторах вы тестировали и если это VS начиная с какой версии компилятор/crt нет проблем с фрагментацией.
Сам компилятор не имеет никакого отношения к тому, как в CRT реализованы операции выделения памяти.
Без понятия каким компилером собирались те проги, которые я проверял.

Но уже в MSVC 7.1 в CRT следующее:

int __cdecl _heap_init (int mtflag)
{
    ...
    __active_heap = __heap_select();
    ...
}

int __cdecl __heap_select(void)
{
...
  if ( (_osplatform == VER_PLATFORM_WIN32_NT) && (_winmajor >= 5) )
    return __SYSTEM_HEAP;
...
}

void * __cdecl _heap_alloc_base (size_t size)
{
...
    if ( __active_heap == __V6_HEAP )
    {...}
    else if ( __active_heap == __V5_HEAP )
    {
        ...
        return HeapAlloc( _crtheap, 0, size );
    }
    
  return HeapAlloc(_crtheap, 0, size);
}

Т.е. вся аллокация в ОС начиная от W2k производится через HeapAlloc, который является WinAPI функцией и к С/С++ уже никакого отношения не имеет.
А судя по картам аллокаций, которые я наблюдал на реальных приложениях фрагментации не наблюдается.

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

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

H>>>Ты сейчас о чем говоришь, об общих случаях или о той синтетике с 7-8 байтовыми ячейками? Если о синтетике, то там выделение нафиг не нужно, достаточно динамического массива с размером ячейки в 8 байт. Получим при этом оверхед в 1 байт на ячейку. Если же ты об общих случаях, то тут существующий софт тому доказательство.

G>>Почитай как работает выделение памяти в .NET. Там нету никакого оверхеда.

H>Рихтер:
H>

У каждого объекта есть пара таких полей: указатель на
H>таблицу методов и SyncBlocklndex. В 32-разрядной системе для каждого из них
H>требуется 32 бита, что увеличивает размер каждого объекта на 8 байтов, а в
H>64-разрядной системе каждое поле занимает 64 бита, добавляя к каждому объекту
H>по 16 байт

H>Это оверхед не аллокатора, а организации данных. Но тем не менее.
указатель на таблицу виртуальных методов есть почти всегда и в неуправляемых языках, так что реальный оверхед создает SyncBlockIndex, который меньше оверхеда стандартного аллокатора C++.

G>>Оверхед может возникнуть из-за того что создается больше обеъктов, но это уже зависит от программы, а не от аллокатора.
H>На практике мы видим, что .Net софт потребляет больше нежели нативный со всеми его пулами. Это позволяет говорить о том, что вся инфраструктура управления памятью в .Net имеет больший оверхед нежели в нативном софте.
Большее потребление памяти вовсе не означает оверхеда аллокатора или какой-то-там "ифнраструктуры управления памятью".

Это больше зависит от объектной модели. В .NET, как и в java, как и в Delphi(!) все обеъекты создаются в куче, причем учитывая неопределенное время жизни объектов в упрвыляемых языках в среднем объектов получается больше примерно на размер двух поколений GC (это не так много).
В C++ большая часть короткоживущих объектов создается на стеке.
Кроме того для работы аллокаторы .NET необходимы непрерывные куски памяти, а это требует резервирования и выделегния большего объема оперативной памяти, чем реально испольхуется программой (это к тому что не надо верить цифирке в Task Manager).
Причем все эти особенности выделения паяти в .NET только ускоряют работу.

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

Все это создает статическую прибавку к потребляемой памяти и практически не влияет на быстродействие.

Черезмерное потребление памяти программами на .NET — исключительно вина разработчиков.

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

S>>Скажите пожалуйста на каких компиляторах вы тестировали и если это VS начиная с какой версии компилятор/crt нет проблем с фрагментацией.

NBN>У шестёрки в первых версиях был галимый аллокатор, точно помню...

Большое спасибо за ответ.

Может вы вкурсе, они его исправили в sp5 or sp6 или нет?

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

G>>Теперь о GC
G>>6)Выделение памяти в .NET происходит очень просто — инкремент указателя. Никаких дополнительных операций не происходитю
A>Это, если память есть свободная.
Это всегда так. память перед инкрементом свободная.

G>>8)Кроме того что выделение памяти выполняется моментально, эта операция еще и потокобезопасна.
A>Конечно потокобезопасно, еще бы. Только потокобезопасность — не бесплатная.
Любая потокобезопасноть небесплатная, но пока быстрее intelokcedAdd не существует.

G>>9)такое распределение памяти увелиичивает cache-locality
G>>10)GC собирает мусор не тогжа когда захочется, а при нехватке памяти в нулевом поколении
G>>11)Для нулевого поколения объем памяти — пара сотен КБ, этот кусок очень хорошо ложится в кеш процессора.
G>>12)Единственный критический недостаток GC заключается в том, что он очень плохо работает когда кончается свободная физическая память, сборка мусора во втором поколении заставляет поднимать все страницы памяти из свопа и это может нереально тормозить.
A>Реальный недостаток GC — это его непредсказуемость. Эта сущность не управлется из клиентского кода никак.
Управляется: есть классы GC и GCSettings. только практика показывает что чем больше лезешь в ручное управление GC, тем хуже все работает.

A>Она может проснуться когда посчитает нужным.
Он работает по строгому алгоритму, если вы не будете писать код, который завтавляет срабатывать GC очень часто, то все будет хорошо.

A>Если бы GC давал равномерную нагрузку на CPU, то никто бы от него не плевался.
Ага, его бы просто не использовали.
Сейчас GC такой что при правльном использовании можно добиться высокого быстродействия, выше чем со всеми стандартными аллокаторами для unmanaged языков, причем без каких-либо трудозатрат. А при неправльном использовании можно просадить производительность в разы.

A>У идеального GC не должно быть "всплесков" и "провалов" активности, он должен просыпаться через фиксированные промежутки времени и отрабатывать каждый раз фиксированный квант времени, а не "залипать" разгребая образовавшиеся завалы.
Странные у вас представления о CG. Кстати описанный вами GC вполне можно сделать на C++, почему до сих пор не применяют?

G>>13)Но даже этот недостаток можно побороть. Можно сборку мусора во втором поколении маскировать под каую-либо длительную операцию (например сохранение или открытие файла), а при расчетах использовать рецепт описанный здесь
A>Это все ужимки и бег на месте, навроде java.lang.System.gc(), который ничего не гарантирует.
Ну тогда единственный правльный путь — писать на ассемблере и выделять память ручками.

A>К сожалению, имидж управляемых сред был сильно подпорчен первыми версиями Java. Так что вы тут хоть 1000 аргументов в пользу C# приведите, стереотипы забороть очень тяжело.
Меня стериотипы не итересуют уже давно. Я тут факты привел.

A>Еще одна проблема C# — низкий порого вхождения для новичков. Собственно это не проблема — это вроде как его преимущество, теоретически.
Да и практически. Формаклепание и написание говнокода будет востребовано еще очень долго.
Причем чем дешевле обходится написание говнокода, тем более востребованно.
Для критических по производительности или потреблению памяти задач надо еще и головой думать.

A>На C++ писать надо аккуратно, чтобы хотя бы как-то работало. В управляемой среде писать дерьмовый код проще — утечки памяти (не все знают что такое WeakReference и зачем они нужны) маскируются мусоросборщиком, никих тебе AV и прочих мерзостей которые заканчиваются crash dump.
+1

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

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

H>>>Рихтер:
H>>>У каждого объекта есть пара таких полей: указатель на
H>>>таблицу методов и SyncBlocklndex. В 32-разрядной системе для каждого из них
H>>>требуется 32 бита, что увеличивает размер каждого объекта на 8 байтов, а в
H>>>64-разрядной системе каждое поле занимает 64 бита, добавляя к каждому объекту
H>>>по 16 байт

H>>>Это оверхед не аллокатора, а организации данных. Но тем не менее.
MK>>Ну без указателя на таблицу виртуальных методов врядли какой ООП язык обходится и в той же Делфи, если мне не изменяет память, функция New неявно по смещению сохраняет еще и объем выделенной памяти.

H>Я ведь не сказал, что в Delphi нет оверхеда Это была фраза на отсутствие оверхеда в .Net. В Delphi еще можно вспомнить о выравнивании, пусть и отключаемом, которое тоже увеличивает оверхед но положительно влияет на производительность. Но не смотря на все это, мы имеем то о чем я уже написал
В Delphi вообще много чего есть, например аналог сборшика мусора, который работает для строк и динамических массивов.
Причем эта фигня глючит при интеропе с DLL.

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

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

BZ>>потому, что malloc/free на каждый глобальный объект может быть медленней, чем последовательное выделение памяти и затем gc, который за один раз собирает весь мусор

M>Даю подсказку
M>int a = 0;
M>int b = 3 + a;

M>Очень память дефрагментирует ? затратит линейное время на на выделение памяти и т.п. ?

напишите этот же код на Java, .NET, причем буква в букву. работать везде одинаково будет.

У вас как в древней присказке "слышу звон, да не знаю где он".

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

NBN>>У шестёрки в первых версиях был галимый аллокатор, точно помню...

S>Большое спасибо за ответ.

S>Может вы вкурсе, они его исправили в sp5 or sp6 или нет?

Да. В первых версиях деаллокация работала с линейной скоростью, а к SP5 — уже нет.

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

M>Понятно , значит незнание.

M>Задумайтесь почему программы на С++ быстрее с таким плохим аллокатором?

С чего вы взяли что программы на C++ всегда быстрее работают?
Я например видел много обратных примеров.

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

CC>Т.е. вся аллокация в ОС начиная от W2k производится через HeapAlloc, который является WinAPI функцией и к С/С++ уже никакого отношения не имеет.
CC>А судя по картам аллокаций, которые я наблюдал на реальных приложениях фрагментации не наблюдается.

Большое спасибо за ваш ответ.

Сейчас проверил в vc6 sp5

void * __cdecl _heap_alloc_base (size_t size)
...
if (size == 0)
size = 1;
size = (size + BYTES_PER_PARA — 1) & ~(BYTES_PER_PARA — 1);
return HeapAlloc(_crtheap, 0, size);
}

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

NBN>>У шестёрки в первых версиях был галимый аллокатор, точно помню...
S>Большое спасибо за ответ.
S>Может вы вкурсе, они его исправили в sp5 or sp6 или нет?

Дык свой напиши на HeapAlloc, если сомневаешься в качестве стандартных.
Перекрой глобальные new/delete если на С++

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

MK>>>В конце концов тот же rpc-xml может это сам явно делать по каким-то своим умозаключениям. У меня вот в WPF'ной проге, окна иной раз не собираются по 10-20 минут. Можно ли быть уверенным, что моя прога в сто раз быстрее твоей?

H>>В коде xmlrpc.net явного вызова GC.Collect нет.

A>Сборщики бывают нескольких типов. Может у вас параллельный сборщик работает, который в Idle time просто собирает статистику для настоящей сборки мусора, которая, благодаря такой предварительной подготовке работает очень быстро.

В идле ничего не шевелиться, шевеления возникают в процессе работы.

A>ЗЫ: А может и сами компоненты написаны неряшливо...

Все может быть. Код, как по мне, вообще то неряшлив... Но есть другой пример: запускаем Creative Docs .Net (наверняка подойдет и Paint.Net) и начинаем его мониторить водя мышкой над панелями инструментов. В результате многократные вызовы GC и не нулевой %Time in GC. Важно понимать: я ни в коем разе не хочу этим примером показать какую-то кривизну GC, это просто еще один пример.

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

H>>Рихтер:
H>>

У каждого объекта есть пара таких полей: указатель на
H>>таблицу методов и SyncBlocklndex. В 32-разрядной системе для каждого из них
H>>требуется 32 бита, что увеличивает размер каждого объекта на 8 байтов, а в
H>>64-разрядной системе каждое поле занимает 64 бита, добавляя к каждому объекту
H>>по 16 байт

H>>Это оверхед не аллокатора, а организации данных. Но тем не менее.
G>указатель на таблицу виртуальных методов есть почти всегда и в неуправляемых языках, так что реальный оверхед создает SyncBlockIndex, который меньше оверхеда стандартного аллокатора C++.

Аллокатору нужны списки блоков? Нужны. Нужны размеры блоков? Нужны. Эти вещи, используемые любым аллокатором, считать оверхедом нельзя. Считать оверхедом можно большее, нежели было запрошено, выделение памяти, что присутствует в приведенном в качестве примера дельфийском менеджере (но учитывая эффективность пулов, этот оверхед обсуждать смешно).

G>>>Оверхед может возникнуть из-за того что создается больше обеъктов, но это уже зависит от программы, а не от аллокатора.
H>>На практике мы видим, что .Net софт потребляет больше нежели нативный со всеми его пулами. Это позволяет говорить о том, что вся инфраструктура управления памятью в .Net имеет больший оверхед нежели в нативном софте.
G>Большее потребление памяти вовсе не означает оверхеда аллокатора или какой-то-там "ифнраструктуры управления памятью".

Я и не говорю про оверхед аллокатора, я конкретно указал о каком оверхеде идет речь.

G>Это больше зависит от объектной модели. В .NET, как и в java, как и в Delphi(!) все обеъекты создаются в куче, причем учитывая неопределенное время жизни объектов в упрвыляемых языках в среднем объектов получается больше примерно на размер двух поколений GC (это не так много).

Ok. Можем назвать это оверхедом объектной модели .Net, только сути это не изменит -- кушать все равно хочется сильнее К слову сказать, в Delphi я могу, при желании, создать объект и на стеке, только чаще всего необходимости в этом нет.

G>В C++ большая часть короткоживущих объектов создается на стеке.
G>Кроме того для работы аллокаторы .NET необходимы непрерывные куски памяти, а это требует резервирования и выделегния большего объема оперативной памяти, чем реально испольхуется программой (это к тому что не надо верить цифирке в Task Manager).
G>Причем все эти особенности выделения паяти в .NET только ускоряют работу.

Во-первых, я не мониторю TaskManager'ом, а использую ProcessExplorer (там цифирки более другие ) Во-вторых, в Delphi менеджер памяти тоже предварительно создает пулы (в текущей версии в количестве 55(!) штук. Общая эффективность использования пулов для 12000 различных объектов составляет ~95% (это показания трекинга)), но при этом перерасхода памяти не наблюдается. В-третьих, под задачу можно аллокатор поменять (существуют и комммерческие и бесплатные решения).

G>Черезмерное потребление памяти программами на .NET — исключительно вина разработчиков.

Есть .Net софтинка: одна форма с кнопкой и картинкой (PictureBox). При нажатии на кнопку происходит вызов XML-RPC сервера и получение от него картинки 320x200x24 в формате BMP. После запуска клиент занимает 11.1Mb памяти. С каждым нажатием на кнопку потребление памяти растет. Постепенно вырастает до 21.2Mb, и на этой цифре останавливается (ну с мелкими мотыляниями туда-сюда). В аналогичном нативном клиенте потребление не превышает 5Mb. В цем тут вина .Net разработчика (там кода -- одна строка)?

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

H>>>>Это оверхед не аллокатора, а организации данных. Но тем не менее.
MK>>>Ну без указателя на таблицу виртуальных методов врядли какой ООП язык обходится и в той же Делфи, если мне не изменяет память, функция New неявно по смещению сохраняет еще и объем выделенной памяти.

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

Это далеко не аналог сборщика мусора Это автоматическая расстановка финализирующих блоков

G>Причем эта фигня глючит при интеропе с DLL.

Это сведения из далекого прошлого С 2005/2006 FastMM, используемый по умолчанию, обеспечивает свободный шаринг.

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

CC>>Т.е. вся аллокация в ОС начиная от W2k производится через HeapAlloc, который является WinAPI функцией и к С/С++ уже никакого отношения не имеет.
CC>>А судя по картам аллокаций, которые я наблюдал на реальных приложениях фрагментации не наблюдается.

S>Большое спасибо за ваш ответ.
Носи на здоровье.
Если не забуду то приволоку завтра тул, который карту строит — поиграешься, посмотришь.

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

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

G>>>Теперь о GC
G>>>6)Выделение памяти в .NET происходит очень просто — инкремент указателя. Никаких дополнительных операций не происходитю
A>>Это, если память есть свободная.
G>Это всегда так. память перед инкрементом свободная.

G>>>8)Кроме того что выделение памяти выполняется моментально, эта операция еще и потокобезопасна.
A>>Конечно потокобезопасно, еще бы. Только потокобезопасность — не бесплатная.
G>Любая потокобезопасноть небесплатная, но пока быстрее intelokcedAdd не существует.
Что-то мне кажется, что одним intelokcedAdd дело там не ограничивается.

G>>>9)такое распределение памяти увелиичивает cache-locality
G>>>10)GC собирает мусор не тогжа когда захочется, а при нехватке памяти в нулевом поколении
G>>>11)Для нулевого поколения объем памяти — пара сотен КБ, этот кусок очень хорошо ложится в кеш процессора.
G>>>12)Единственный критический недостаток GC заключается в том, что он очень плохо работает когда кончается свободная физическая память, сборка мусора во втором поколении заставляет поднимать все страницы памяти из свопа и это может нереально тормозить.
A>>Реальный недостаток GC — это его непредсказуемость. Эта сущность не управлется из клиентского кода никак.
G>Управляется: есть классы GC и GCSettings. только практика показывает что чем больше лезешь в ручное управление GC, тем хуже все работает.
GCSettings нашел, GC — не нашел. Из того что нашел складывается ощущение, что толку от него, как от поводка для носорога. Да и не должно быть средств для управления нормальным GC, он незаметно для программы должен работать, а не выскакивать как бандит из подворотни

A>>Она может проснуться когда посчитает нужным.
G>Он работает по строгому алгоритму, если вы не будете писать код, который завтавляет срабатывать GC очень часто, то все будет хорошо.
Затачивать код под алгоритм GC? Полагаю, что это одного уровня сложности задача, как и настройка управления памтью в C++ проекте.

A>>Если бы GC давал равномерную нагрузку на CPU, то никто бы от него не плевался.
G>Ага, его бы просто не использовали.
А что есть выбор?

G>Странные у вас представления о CG.
Расскажите как должно быть по вашему.

G>Кстати описанный вами GC вполне можно сделать на C++, почему до сих пор не применяют?
В С++ GC не нужен.

G>>>13)Но даже этот недостаток можно побороть. Можно сборку мусора во втором поколении маскировать под каую-либо длительную операцию (например сохранение или открытие файла), а при расчетах использовать рецепт описанный здесь
A>>Это все ужимки и бег на месте, навроде java.lang.System.gc(), который ничего не гарантирует.
G>Ну тогда единственный правльный путь — писать на ассемблере и выделять память ручками.
Из одну крайности в другую...

A>>К сожалению, имидж управляемых сред был сильно подпорчен первыми версиями Java. Так что вы тут хоть 1000 аргументов в пользу C# приведите, стереотипы забороть очень тяжело.
G>Меня стериотипы не итересуют уже давно.
А зачем тогда, спрашивается, вы в этой ветке так активно участвуете?

A>>Еще одна проблема C# — низкий порого вхождения для новичков. Собственно это не проблема — это вроде как его преимущество, теоретически.
G>Да и практически. Формаклепание и написание говнокода будет востребовано еще очень долго.
Это будет востребовано всегда.

Алексей

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

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

A>>Что JVM написан на C? А на чем их еще писать, если их надо запихивать черте куда, где вменяемого C++ компилятора и не стояло?
A>>Телефонный софт — это как правило море legacy кода, древнего как, даже и не знаю что
A>>Symbian — формально там конечно есть C++, но какой-то он на вид своеобразный.

NBN>Я писал под брю и его потомков — WIZE и PDK, там было много старого кода на С и не меньше нового на С++, в частности вся гуйня.
BREW — та еще радость: watch dog timer, ручная многозадачность, сказка, блин

Алексей

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

NBN>>Я писал под брю и его потомков — WIZE и PDK, там было много старого кода на С и не меньше нового на С++, в частности вся гуйня.
A>BREW — та еще радость: watch dog timer, ручная многозадачность, сказка, блин

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

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

G>В Delphi вообще много чего есть, например аналог сборшика мусора, который работает для строк и динамических массивов.
G>Причем эта фигня глючит при интеропе с DLL.

А там разве не подсчет ссылок?

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

S> Где гарантия, что следующие 2-3 года не выдет новая версия радикально изменяющая предыдущие? Ведь MS — монополист и может навязывать любые условия.

Есть такая гарантия. Они за 3 года новую студию не напишут.