Здравствуйте, Sinclair, Вы писали:
S>Скажем, Outlook Web Access — одно из лучших веб-приложений, которые я когда-либо видел. Сделать такое на С++, имхо, просто нереально.
Нереально... Нереально прогнать бесконечный цикл за конечное время, остальное — вопрос технический.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, DarkGray, Вы писали:
DG>в managed есть лишь лишние проверки при доступе к массиву. DG>Большая часть, конечно, их убирается на этапе статического анализа, но какие-то доли процента остаются
Да, это серьезная проблема. Сам МС с ней борется весьма просто — переходит на unsafe. Тем паче что в 4 версии шарпа добавили синтаксис взятия адреса n-ного элемента массива вместо явной адресной арифметики.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Угу, и когда объектов много и у этих объектов очень ветвистые графы в памяти, то сборка GC может занимать заметные доли секунд и даже несколько секунд.
Верно. Если специально стараться, GC таки можно поставить раком. Но варианты избежать проблем всегда есть.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
The JIT establishes write barriers that are triggered every time there is a write into a reference field in an object. If the value of the reference (which is basically a pointer, after all) is in the ephemeral segment (which is where gen0 and gen1 reside), the write barrier knows that it must update a global data structure, called a card table, with a bit that indicates that we might have a condition where a young object is referenced by an old object.
If every old object would have a bit in the card table, the card table would have been too big. Consider that the minimum object size is 12 bytes, and assuming that we can access about 1.6GB of memory for gen2, we can have up to 143 million objects, which would require almost 18MB of memory just for the card table to be properly synched. Therefore, the card table contains a bit for every 128-byte range, which requires a single DWORD for every page (4KB) on x86.
When a GC occurs, at a later point, it consults the card table to see whether there were any "dirty" writes to objects in an older generation, thus not allowing objects that are still referenced from an older generation to be incorrectly sweeped.
...
Every time the JIT sees that an update to a reference field is about to be emitted, it emits a call to the write barrier thunk. It can be examined using the SSCLI in the jithelp.asm file (for the x86 implementation). The code ensures that the address being written to (the destination) is in the GC heap, and then checks whether the address being written (the source) is within the ephemeral segment.
Note that whenever the ephemeral segment is moved, the JIT thunk must be updated to contain the correct segment low and high addresses.
...
The question I was talking about, then, is why doesn't the .NET GC use this built-in memory watch mechanism, supplied by the Win32 API? The following blog entry notes this possibility (in section 3.2.4), but does not elaborate regarding the reasons behind the particular choice made in .NET. I have several speculations (which are just that — speculations) and am still pursuing a more definitive answer:
* The aforementioned API is not supported on Windows 95 (which is, perhaps, not so surprising), but it is not supported on Windows 2000 as well. This would limit the .NET framework's compatibility with these platforms (although in those particular cases the JIT-thunk approach could be adopted).
* The aforementioned API is Windows-specific and does not provide any compatibility with other platforms. The JIT-generated write barrier is generic and theoretically can work on any platform.
* The performance penalty of using the MEM_WRITE_WATCH flag for writing to a region of memory is bigger than the thunk generated by the JIT. Note that a very primitive measurement I've performed indicates an 8% performance penalty when writing to memory protected by a write watch as opposed to writing to memory that is not protected by a write watch (don't quote me on this .
Эта механика, кстати, указывает на еще одну разновитность тормозов, связанную с GC — он не любит, когда очень много и часто пишутся ссылки. Но это, надо понимать, очень небольшие тормоза, вылазящие в весьма специфичных ситуациях.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Дык. Но меня же тут пытаются убедить, что это чуть ли не бесплатно.
Ес-но не бесплатно, но оказалось в тему для неравномерных нагрузок. Тут говорили, что GC запускается только тогда, когда памяти не хватает — это малость не так (вернее, не только так), по крайней мере с тех пор, как в ход пошел фоновый GC, потому как шедуллер GC ориентируется еще на счетчики производительности. В этом случае GC поможет выровнять, например, нагрузку на сервер.
ГВ>Плюс добавим сюда перемещения объектов в памяти с сопутствующей коррекцией ссылок — тоже не бесплатный сыр.
Да, но тоже неплохо работает в фоне.
ГВ>Это же более или менее проясняет, почему системы вроде SQL Server, скорее всего, никогда не будут переведены на .Net (во всяком случае, в нынешнем его виде) — у них-то нет такой счастливой возможности избегать хранения часто обновляющегося состояния. Для примера: уж сколько Oracle занимается любовью с Java, а сам сервер на Java так и не переписан (AFAIK). И конечно, говоря об MS, это лишний аргумент в защиту позиции Синофски — ну не враг же он сам себе, чтобы ухудшать потребительские качества своего продукта? Так что, всё становится на свои места.
Ну... для таких задач в дотнете полно еще помех, помимо GC. Например, в C++ мы куски памяти непосредственно можем интерпретировать, в дотнете в safe-режиме это невозможно, а зачитка нативной памяти (десериализация) как показывают замеры — вещь очень и очень постепенная.
По большому счету меня сам байт-код не смущает. Его можно рассматривать как YA формат объектного файла и способ распространения программ. На CLR/C++ уже сейчас вполне можно генерить переносимые программы полностью в терминах байткода, используя как unsafe и ручное управление памятью где надо и safe где и так сойдет. Библиотек полно под любой чих, опять же. В моих экспериментах по однопоточному локальному эмулированию GC handle у меня в 3-4 раза выходило быстрее получать соответствие объектов unsafe->safe, чем через стандартные ср-ва, т.е. бороться с острыми моментами можно. Загвоздка, как постоянно говорю, лишь в большой разнице кач-ва генерируемого кода компилятором C++ перед JIT или ngen, а с этим бороться никак.
Здравствуйте, Ikemefula, Вы писали:
I>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно. Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
Не преувеличивай, есть всего 2 основных способа, относящихся конкретно к дотнету:
— это создание относительно "больших" value-type, специально быть приватными полями других объектов.
— хранение таких же value-type в массивах.
Оба способа требуют пересмотра внутреннего интерфейса, понятное дело. Твой ref нужен вовсе не всегда, это зависит от того, где ты разместишь функциональность, и какую зависимость ей назначишь — от всего объемлющего value-type, или от его маленькой запчасти, которой по значению будет эффективней оперировать. Далее, константные объекты (иммутабельные), или еще забытое тобой, но не менее важное уменьшение уровня косвенности данных — это не специфично для дотнета, а общая практика. Разумеется, использование в дотнете повсюду value-type тоже снижает уровень косвенности, но этого недостаточно, если уж вылизывать. Сами принципы отношения объектов м/у собой, объектов и данных, и т.д. приходится пересматривать.
Имеющийся неприятный момент еще в том, что в официальных гайдлайнах, если не изменяет склероз, рекомендуют исполнять типы как value-type, если их размер не превышает 16 байт... Несусветнейшая чушь, ИМХО, которую оппоннеты часто используют как возражение (ведь оно идет аж от самого MS). На самом деле, можно подобрать сценарий, где и 16-байтовый тип лучше сделать ref, или наоборот, подобрать такой, где 256-байтовый объект будет в виде value-type самым эффективным решением.
Здравствуйте, vdimas, Вы писали:
ГВ>>Дык. Но меня же тут пытаются убедить, что это чуть ли не бесплатно. V>Ес-но не бесплатно, но оказалось в тему для неравномерных нагрузок. Тут говорили, что GC запускается только тогда, когда памяти не хватает — это малость не так (вернее, не только так), по крайней мере с тех пор, как в ход пошел фоновый GC, потому как шедуллер GC ориентируется еще на счетчики производительности. В этом случае GC поможет выровнять, например, нагрузку на сервер. ГВ>>Плюс добавим сюда перемещения объектов в памяти с сопутствующей коррекцией ссылок — тоже не бесплатный сыр. V>Да, но тоже неплохо работает в фоне.
В контексте топика важно только то, что эти затраты есть. Понятно, что в фоне, но источник питания один и бесконечно понижать энергопотребление единичного вентиля на кристалле тоже нельзя...
ГВ>>Это же более или менее проясняет, почему системы вроде SQL Server, скорее всего, никогда не будут переведены на .Net (во всяком случае, в нынешнем его виде) — у них-то нет такой счастливой возможности избегать хранения часто обновляющегося состояния. Для примера: уж сколько Oracle занимается любовью с Java, а сам сервер на Java так и не переписан (AFAIK). И конечно, говоря об MS, это лишний аргумент в защиту позиции Синофски — ну не враг же он сам себе, чтобы ухудшать потребительские качества своего продукта? Так что, всё становится на свои места.
V>Ну... для таких задач в дотнете полно еще помех, помимо GC. Например, в C++ мы куски памяти непосредственно можем интерпретировать, в дотнете в safe-режиме это невозможно, а зачитка нативной памяти (десериализация) как показывают замеры — вещь очень и очень постепенная.
Тем более.
V>[...] Загвоздка, как постоянно говорю, лишь в большой разнице кач-ва генерируемого кода компилятором C++ перед JIT или ngen, а с этим бороться никак.
ИМХО, это означает, что бороться с действительно острыми моментами нельзя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Например в создании долгоживущих объектов без необходимости. Вроде создания пула объектов для уменьшения количества выделений памяти (довольно частая оптимизация в unmanaged) в managed может приводить к отрицательным результатам.
V>Может, не может... что за гадания на кофейной гуще?
V>Когда вводят пул объектов, то делают это под постоянным присмотром через результаты тестирования производительности. Я даже боюсь себе представить твою ситуацию "умозрительного" применения пула объекта, т.е. вне процедур по увеличению эффективности кода, со всем тем, что эти процедуры сопровождает.
Я многократно видел как программисты C++ инстинктивно применяют те или иные методы "оптимизации" в управляемом коде. А когда спрашиваешь зачем они это делают, то отвечают что всегда так делали раньше в С++ и это увеличивало быстродействие.
Здравствуйте, gandjustas, Вы писали:
G>Я многократно видел как программисты C++ инстинктивно применяют те или иные методы "оптимизации" в управляемом коде. А когда спрашиваешь зачем они это делают, то отвечают что всегда так делали раньше в С++ и это увеличивало быстродействие.
Если ты это на своей работе видел, то у вас бардак, поздравляю.
Похоже, работа над эффективностью смешивается с разработкой функционала. ИМХО, конкретно технология пулов — это настолько изолированная штука... которую можно прикручивать и откручивать, не трогая ничего вокруг, что я плохо себе представляю работать над полезным функционалом одновременно прикручивая/отлаживая пул объектов... Если они и на плюсах так писали, то конкретно плюсы тут уж точно не при чем. Это классичесский бардак и хаос в махровой стадии, который всегда бывает в отсутствии регулярного взаимного ревью кода. (даже у опытных разработчиков, угу)
V>>Угу, и когда объектов много и у этих объектов очень ветвистые графы в памяти, то сборка GC может занимать заметные доли секунд и даже несколько секунд.
AVK>Верно. Если специально стараться, GC таки можно поставить раком. Но варианты избежать проблем всегда есть.
Плодить домены, разве что... Похоже, это единственный способ масштабировать дотнетные приложения на сейчас.
Здравствуйте, A13x, Вы писали:
A>Не троллинга ради а справедливости для: Java и С по скорости сложно сравнивать — в ряде случаев Java делает скомпилированный при максимальной оптимизации сишный код. Это не голословное утверждение, проверено на практике (был код написанный на чистом С — рекурсивная процедура поиска решения методом перебора — в основном операции с массивами, рекурсия и операции с битовыми флагами, перенос почти 1:1 на java и последующие проверки показали, что результаты при запуске с настройками не уступают аналогичным в С после нескольких проходов — первые 2-3 вызова процедуры на java выполняются дольше раза в 2-3, потом, видимо jvm-овский оптимизатор распознает часто вызываемый код и довольно хорошо его оптимизирует).
А можно ссылку на посмотреть? А то первый раз вижу упоминание, что Java делает C не на задачах, требующих активного выделения памяти.
Здравствуйте, Ikemefula, Вы писали:
S>>>На той же практике мегагуру дотнета/джавы аналогичного уровня тоже умеют трюки с управлением памятью. V>>Нет подобных возможностей.
I>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно.
Вот любишь же ты этим своим "качественно" цокать по поводу и без. Неужели GC способен что-нибудь потерять?
I>Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
Сочувствую, без шуток. Это же не столько трюки управления памятью, сколько трюки непрямого управления garbage collector-ом, у которого ещё и алгоритмы могут меняться от версии к версии. Занятие довольно скользкое, ИМХО, должно выносить мозг похлеще шаблонов. Да ещё и отсутствие const может здесь усложнять жизнь (хотя привыкнуть можно, не спорю). Всякая реинтерпретация памяти и адресная арифметика по трудоёмкости тут и рядом не стояли.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Я многократно видел как программисты C++ инстинктивно применяют те или иные методы "оптимизации" в управляемом коде. А когда спрашиваешь зачем они это делают, то отвечают что всегда так делали раньше в С++ и это увеличивало быстродействие.
V>Если ты это на своей работе видел, то у вас бардак, поздравляю.
Да именно бардак и был. Набирали программиостов на .NET проект, когда .NET программистов в нашем городе еще не было. Тупо брали тех кто на плюсах пишет и переучивали под .NET. Много чего насмотрелся тогда.
V>Похоже, работа над эффективностью смешивается с разработкой функционала. ИМХО, конкретно технология пулов — это настолько изолированная штука... которую можно прикручивать и откручивать, не трогая ничего вокруг, что я плохо себе представляю работать над полезным функционалом одновременно прикручивая/отлаживая пул объектов... Если они и на плюсах так писали, то конкретно плюсы тут уж точно не при чем. Это классичесский бардак и хаос в махровой стадии, который всегда бывает в отсутствии регулярного взаимного ревью кода. (даже у опытных разработчиков, угу)
Есть подозрение что многие разработчики страдают заболеванием типа "хронического оптимизаторства" и пытаются писать априори быстрый код уже на уровне спинного мозга. Используя ссылки чтобы не вызывать копирования, пулы и преаллокацию чтобы не дергать кучу, массивы на стеке с шаблонными функциями вместо векторов.
Здравствуйте, vdimas, Вы писали:
AVK>>Верно. Если специально стараться, GC таки можно поставить раком. Но варианты избежать проблем всегда есть. V>Плодить домены, разве что...
Нет, не использовать развесистые графы, активнее использовать immutable объекты и т.п.
V> Похоже, это единственный способ масштабировать дотнетные приложения на сейчас.
Ну, у кого то может и так.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, gandjustas, Вы писали:
G>Есть подозрение что многие разработчики страдают заболеванием типа "хронического оптимизаторства" и пытаются писать априори быстрый код уже на уровне спинного мозга. Используя ссылки чтобы не вызывать копирования, пулы и преаллокацию чтобы не дергать кучу, массивы на стеке с шаблонными функциями вместо векторов.
Угу, вот так взять свалить в одну кучу приемы, которые ничего не стоят, и которые просто правила хорошего тона и способы улучшения типобезопасности времени компиляции, с теми, которые требуют анализа, заметных трудозатрат и даже отладки. Круто.
Здравствуйте, AndrewVK, Вы писали:
AVK>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
Был Evernote 3.5 написанный на WPF и заметно более тормозной чем нативные 3.1 и 4.0.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так у Facebook в том и прикол, что они не могли отказаться от использования PHP при всём желании.
Я знаю только об одном случае переписывания серьезного продукта с языка высокого уровня на С++ — это яховский веб-магазин. Результат был плачевным. Яху утратил позиции лидера.
Трансляции в С++ тут вообще не причем. Это не более чем способ оптимизировать производительность разных интерпретируемых сред. Для дотнета и явы он имеет мало смысла. К тому же при этом глупо генерировать С++-код. Куда разумнее генерировать С-шный код. Переносимость выше и практически нет неявного оверхэда. А все возможности С++ для генерированного кода на фиг не упали.
Так что не обольщайся. С++ популярнее не станет. Он живет по инерции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Don Reba, Вы писали:
DR>>Был Evernote 3.5 написанный на WPF
AVK>С WPF разговор отдельный.
А как кто-то приводит конкретный пример, дотнетовцы сразу говорят что вот уж в данном случае разговор отдельный. Тут должно тормозить, а вот в целом все очень быстро. Очень знакомо
.
Это же не столько трюки управления памятью, сколько трюки непрямого управления garbage collector-ом, у которого ещё и алгоритмы могут меняться от версии к версии. Занятие довольно скользкое, ИМХО, должно выносить мозг похлеще шаблонов. Да ещё и отсутствие const может здесь усложнять жизнь (хотя привыкнуть можно, не спорю). Всякая реинтерпретация памяти и адресная арифметика по трудоёмкости тут и рядом не стояли.
