Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Поправка: по сути операция выделения памяти в дотнете еще быстрее, чем interlocked increment. Вот, вытряхнул таки пыль из Рихтера о дотнете 2.0: S>>
S>>Выделение памяти без синхронизации
S>>В многопроцессорной системе поколение 0 управляемой кучи разделено на несколько арен памяти — по одной на каждый поток. Это позволяет нескольким потокам выделять память одновременно, не требуя монопольного доступа к куче.
V>Это касается только маленьких объектов. Для больших, по-прежнему пулы показывают оч. высокую эффективность, в сравнении с GC. Например пуллы массивов байт/символов.
Я не против пулов, лишь уточнял по поводу interlocked. Очень большие объекты в дотнете выделяются в Large Object Heap, которая не дефрагментируется сборщиком. Поэтому, во избежание фрагментации пулы могут использоваться и в дотнете.
Здравствуйте, Sinclair, Вы писали:
S>На практике даже заменой стандартного аллокатора занимаются единичные мегагуры C++.
Хм... Много найдешь разработчиков С++, старше 5-ти лет опыта, которые никтогда не писали или не поддерживали/использовали в проекте уже писанные кем-то аллокаторы. Боюсь, у тебя неверное представление. Я еще не видел ни одного более-менее большого проекта на С++, в котором не использовалась бы целая россыпь различных аллокаторов.
S>На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью.
ГВ>>Хм. А GC разве не занимается регулярными проверками состояния памяти?
DG>в managed есть лишь лишние проверки при доступе к массиву. DG>Большая часть, конечно, их убирается на этапе статического анализа, но какие-то доли процента остаются
Популярное заблуждение, достаточно просмотреть на сгенеренный бинарный код. Наоборот, подавляющая часть проверок остается, а уходят считанные доли процента в ручном "хакерском" коде (С), имеющим дело непосредственно с массивами. Всегда, когда реальных данных меньше, чем размер массива, имеем такие проверки в рантайм. Например, внутри стандартных контейнеров, которые используются в 99.99% случаев.
Здравствуйте, Cyberax, Вы писали:
C>Я бы не отказался от языка с явной проверкой границ и безопасными кастами, но при этом с ручным управлением памятью.
D?
Хотя для этого не обязательно новый язык, достаточно рантайма и чуть измененного кодогенератора в компиляторе как
например у гуглевского Native Client.
C>Хм. Написать что-ли статический проверяльщик, который ровно это делает?..
Сомнительно что для С++ получится, разве для ограниченного подмножества.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>... В общем, похоже, что нересурсам грядёт неиллюзорный лимит и это начинают всё громче и громче признавать.
Не троллинга ради а справедливости для: Java и С по скорости сложно сравнивать — в ряде случаев Java делает скомпилированный при максимальной оптимизации сишный код. Это не голословное утверждение, проверено на практике (был код написанный на чистом С — рекурсивная процедура поиска решения методом перебора — в основном операции с массивами, рекурсия и операции с битовыми флагами, перенос почти 1:1 на java и последующие проверки показали, что результаты при запуске с настройками не уступают аналогичным в С после нескольких проходов — первые 2-3 вызова процедуры на java выполняются дольше раза в 2-3, потом, видимо jvm-овский оптимизатор распознает часто вызываемый код и довольно хорошо его оптимизирует).
Для сравнения у меня вышло под x86, как и ожидалось:
C# for (int i = 0; i < ArrSize; ++i): 4134,00722 ms
C# for (int i = 0, ie = arr.Length; i < ie; ++i): 4056,00706 ms
C# for (int i = 0; i < arr.Length; ++i): 2892,24506 ms
Обещанная оптимизация дала профит.
Для x64:
C# for (int i = 0; i < ArrSize; ++i): 889,20154 ms
C# for (int i = 0, ie = arr.Length; i < ie; ++i): 2037,36356 ms
C# for (int i = 0; i < arr.Length; ++i): 1344,72234 ms
Непонятно, с чего такая разница x86/x64 в быстродействии, под С++ такой разницы нет.
Ну и расстановка результатов совсем другая.
Здравствуйте, vdimas, Вы писали:
S>>На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью.
V>Нет подобных возможностей.
Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно. Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
Здравствуйте, konsoletyper, Вы писали:
ГВ>> Первый раз я это услышал от спеца, принёсшего весть не то с конференции MS, не то с какой-то UG в 1997-м: что, мол, "сейчас главное — разрабатывать программы быстро, а то, что форма рисуется не за 200 микросекунд, а за 200 миллисекунд — так кому какая разница!" и тут же: "MS считает, что сейчас цикл разработки программы — 2 месяца" (последняя цифра мне особенно в память врезалась).
K>Вот уж не знаю, везде ли так, как у меня, или не везде. Но и скорость работы спеца нафиг никому не упёрлась. Я тут со своей эффективностью сижу и жду, когда же бизнес решит, чего он хочет. От нечего делать попиваю чаёк и читаю RSDN. Так что мем зародился именно из-за безалаберности. При желании можно и эффективный код писать быстро. Я понимаю, были бы какие-то сложные алгоритмы, где надо полгода думать, как от вместо O(n*log(n)) перейти к полиномиальной сложности. А тут же формочки с БД! Написание эффективного кода в таких условиях превращается из сложной задачи в банальный навык, зашитый в спинном мозге.
В абсолютном большинстве тех мест, где мне довелось побывать, картина похожая: самые большие тормоза — выделение и формализация задачи, а это скоростью работы программистов никак не лечится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Неправильно. Это аргумент в пользу отказа от классических менеджеров памяти. Ещё варианты есть? S>>Хорошо, сформулируем по-другому: фрагментация свободной памяти возникает в ручном подходе к выделению памяти. И является, таким образом, аргументом для отказа от ручного распределения в пользу автоматического выделения памяти, т.е. GC.
ГВ>Снова неправильно. Фрагментация возникает тогда, когда реализованная в программе политика управления жизненным циклом объектов подразумевает такую фрагментацию. Ещё варианты?
И много ты знаешь людей, которые способны реализоваь качественную политику управления жизненным циклом объектов ? Из Сиплюсников таких единицы
Здравствуйте, vdimas, Вы писали:
ГВ>>Хорошо, пусть тогда это будет апериодический процесс, который вызывается по заполнении очередного сегмента (area). Скажи пожалуйста, как понимать выражение: "строится граф живых объектов"? AFAIK, чтобы построить такой граф, нужно пройти по ссылкам и как минимум, убедиться, что проверенные ссылки не нулевые. Или нет? V>Угу, и когда объектов много и у этих объектов очень ветвистые графы в памяти, то сборка GC может занимать заметные доли секунд и даже несколько секунд. Сочетание параллельного GC и фонового немного смягчает этот эфект, растягивая сборку поэтапно по времени.
Дык. Но меня же тут пытаются убедить, что это чуть ли не бесплатно.
Вернее — как. В теории-то оно понятно: если вся работа системы сводится, грубо говоря, к функциональной модели — когда возврат управления из функции означает вычисление value-типа и выбрасывание всех промежуточных результатов, то GC может дать очень приличную скорость. По сути тут GC будет работать не как GC (со всеми его графами, периметрами, маркировками-перемаркировками), а скажем так, по-минимуму: пометил освободившуюся память — и всё. Только на практике функциональный стиль сам по себе не всегда даёт большую скорость, и из-за этого благие представления разбиваются о суровою реальность. Плюс добавим сюда перемещения объектов в памяти с сопутствующей коррекцией ссылок — тоже не бесплатный сыр.
Собственно, понятно, откуда растут ноги у апологии stateless (были когда-то горячие споры в АПО). Это здесь самая адекватная модель: быстро выполнили запрос, сгенерировали ответ, промежуточные результаты выкинули или повесили в долгоживущий кэш. Ответ ушёл по сети, и значит, промежуточный объект, содержавший результат — тоже выкинули. Чисто, аккуратно, только априори медленно, поскольку вся работа с состоянием вытесняется куда-нибудь аж на сервер БД. Зато .Net стоит весь "в белом": всегда можно сказать, что это SQL-сервер не справляется.
Это же более или менее проясняет, почему системы вроде SQL Server, скорее всего, никогда не будут переведены на .Net (во всяком случае, в нынешнем его виде) — у них-то нет такой счастливой возможности избегать хранения часто обновляющегося состояния. Для примера: уж сколько Oracle занимается любовью с Java, а сам сервер на Java так и не переписан (AFAIK). И конечно, говоря об MS, это лишний аргумент в защиту позиции Синофски — ну не враг же он сам себе, чтобы ухудшать потребительские качества своего продукта? Так что, всё становится на свои места.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ikemefula, Вы писали:
ГВ>>Снова неправильно. Фрагментация возникает тогда, когда реализованная в программе политика управления жизненным циклом объектов подразумевает такую фрагментацию. Ещё варианты? I>И много ты знаешь людей, которые способны реализоваь качественную политику управления жизненным циклом объектов ? Из Сиплюсников таких единицы
Ну как тебе сказать. Я знаю довольно много плюсовиков (во всяком случае, совсем не единицы), которые просто не станут реализовывать свои механизмы управления памятью, поскольку имеющихся общедоступных средств вполне достаточно. Хотя это вполне в их силах. Кстати, никаких "качественных" или "некачественных" политик управления памятью не бывает. Они соответствуют либо одним требованиям, либо другим. И собственно говоря, управление памятью почти всегда согласуется с архитектурой приложения, впрочем, это отдельный разговор.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
ГВ>>>Так именно такой сценарий и следует из слов gandjustas. И в принципе, он имеет право на существование. S>>Право имеет, но вряд ли такой сценарий в большей мере относится именно к программистам C++. V>ХЗ... В С++ короткоживующие объекты, являющиеся полями других объектов, обычно хранятся как value-type (т.е. имеют семантику значений). Перетягивая эту привычку на дотнет я зачастую делаю так же, а не то, что изобретает себе gandjustas.
gandjustas, как выяснилось, имел в виду несколько иной сценарий, но тот, о котором говорил я, ИМХО, вполне может проявляться. Знаешь же эти размашистые ёлки Больших Объектов™, которые хранят состояния, промежуточыне результаты...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, kaa.python, Вы писали:
KP>А почему тогда приложения на плюсах работают быстрее?
Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
KP>>А почему тогда приложения на плюсах работают быстрее?
AVK>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
Лично у меня сложилось впечатление, чтобы создавать качественные приложения под .NET, нужно иметь гораздо большую квалификацию, чем для создания приложения при помощи C++.
По крайней мере, .NET уже сколько существует, а приложений все нет и нет. Единственное приличное, что могу вспомнить, это Paint.NET, все остальное встреченное было, как правило, УГ
Здравствуйте, konsoletyper, Вы писали:
K>Вот уж не знаю, везде ли так, как у меня, или не везде. Но и скорость работы спеца нафиг никому не упёрлась. Я тут со своей эффективностью сижу и жду, когда же бизнес решит, чего он хочет.
Это всего лишь означает, что распределение задач ваш PM делает неэффективно. У меня, к примеру, почти всегда есть парочка параллельных задач разного приоритета (это специально так сделано). Если по одной пауза, занимаюсь второй. Кроме того, планов на будущее столько, что можно несколько лет что то писать. Так что если и бывают дни, когда получается относительная пауза, то это максимум 2-3 дня в год, и связано это, обычно, с выпуском очередного релиза.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Marty, Вы писали:
M>Лично у меня сложилось впечатление, чтобы создавать качественные приложения под .NET, нужно иметь гораздо большую квалификацию, чем для создания приложения при помощи C++.
Нет, не нужно. Нужно иметь немного другую квалификацию, и сравнить это не так просто.
M>По крайней мере, .NET уже сколько существует, а приложений все нет и нет.
Каких таких приложений нет?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, A13x, Вы писали:
ГВ>>... В общем, похоже, что нересурсам грядёт неиллюзорный лимит и это начинают всё громче и громче признавать. A>Не троллинга ради а справедливости для: Java и С по скорости сложно сравнивать — в ряде случаев Java делает скомпилированный при максимальной оптимизации сишный код. Это не голословное утверждение, проверено на практике (был код написанный на чистом С — рекурсивная процедура поиска решения методом перебора — в основном операции с массивами, рекурсия и операции с битовыми флагами, перенос почти 1:1 на java и последующие проверки показали, что результаты при запуске с настройками не уступают аналогичным в С после нескольких проходов — первые 2-3 вызова процедуры на java выполняются дольше раза в 2-3, потом, видимо jvm-овский оптимизатор распознает часто вызываемый код и довольно хорошо его оптимизирует).
Понятно, что в некоторых случаях Java может работать лучше C, только все-то программы к этим отдельным случаям не сведёшь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Marty, Вы писали:
M>Лично у меня сложилось впечатление, чтобы создавать качественные приложения под .NET, нужно иметь гораздо большую квалификацию, чем для создания приложения при помощи C++. M>По крайней мере, .NET уже сколько существует, а приложений все нет и нет. Единственное приличное, что могу вспомнить, это Paint.NET, все остальное встреченное было, как правило, УГ
Всё сильно зависит от того, какого типа приложения вас интересуют. Скажем, Outlook Web Access — одно из лучших веб-приложений, которые я когда-либо видел. Сделать такое на С++, имхо, просто нереально.
Сделать аналог шарепоинта (который хоть и глючный, но всё же) — тоже.
А на десктопе — да, тут всё как-то неинтересно до сих пор. Не вполне понимаю, почему.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А на десктопе — да, тут всё как-то неинтересно до сих пор. Не вполне понимаю, почему.
Потребляемые ресурсы, необходимость тащить FW, невнятная политика MS в отношении GUI. На сервере эти проблемы не так актуальны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Боюсь, у тебя неверное представление. Я еще не видел ни одного более-менее большого проекта на С++, в котором не использовалась бы целая россыпь различных аллокаторов.
