Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
iv_an_ruибо что мне писать на платформе со stop-the-world GC? А кто-нибудь смотрел устройство явовского GC? У меня подозрения, что он это минимум примитивный memory management + логика для определения моментов, когда/где/сколько чистить. И дальше мои подозрения: это никак не может быть быстрее, чем просто memory management. Т.о. можно как-то за счёт "опта" выгадать в быстродействии? Ну и, не знаю, гипотетическая логика этого GC как-то напрягает: допустим, у меня исполняется критический код, а ему вдруг вздумалось почистить память... или это всё мелочи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 09:21 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
iv_an_rumaytonКстати очень хорошо что был упомянут golang. Если мы обсуждали недостатки программирования try-catch то мы должны были выставить в сравнение Метод который принят в этом языке. Иван! Где вы!Когда я смотрел на только-только свежеопубликованный go, в нём try-catch вообще не было. Ну, тоже метод :) Как там сейчас, через 10 лет --- не знаю, не смотрел, ибо что мне писать на платформе со stop-the-world GC? Мне кажется вы - гиперболизируете проблему stop-the-world. На чем вы кст. разрабатываете? На QNX? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 09:22 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Кстати по поводу детерминизма отклика обычного memory management. Представил себе казуальное С-приложение которое активно работает со строками разной длины (JSON?,XML?). И после некоторых эпох malloc/free структура памяти должна представлять собой "решето". И после затребования malloc чуть больше чем доступный непрерывный кусок мы незбежно должны войти в операцию дефрагментации. Разумеется это не идет в сравнение в stop-the-world управляемой вселенной .Net/Golang/Java но у меня возникают вопросы. Это реалтайм? А как много времени мы можем просидеть в этой секции? Какие регуляторные механизмы или хинты у нас есть в наличии? Разумеется я не предлагаю писать свои аллокаторы. Это вывело-бы спор о пользе и вреде GC на новый уровень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 09:32 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
CEMbiv_an_ruибо что мне писать на платформе со stop-the-world GC? А кто-нибудь смотрел устройство явовского GC? У меня подозрения, что он это минимум примитивный memory management + логика для определения моментов, когда/где/сколько чистить. Этих GC было много. Думаю что если нас интересует It-история или археология то мы должны начать с LISP. Ваши подозрения по поводу "сколько чистить" - не совсем корректны. Для Java чистится полностью все (в eden-space). То что имеет рефералов - просто переносится в другие spaces. Кстати это ставит вопрос о свободном пространстве на совершенно новый уровень. Для Java вообще нет понятия доступное или свободное пространство как таковое. Есть minimal footprint приложения которое вышло в стационарный режим и есть некие рабочие тренды плавающей части памяти (на графике они всегда видны как характерная "пила"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 09:39 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonТо что имеет рефералов - просто переносится в другие spacesэто ещё больше накладных расходов, получается. maytonРазумеется я не предлагаю писать свои аллокаторы.Если бы это дало прирост, то почему бы и нет? Другое дело, что в 99% случаев разработка своего аллокатора не нужна, потому что всё решается правильной организацией данных и продуманной работой с памятью в приложении. Да и объекты, которые связаны с работой с памятью (контейнеры) сейчас могут настраиваться и устраивать свой внутренний микро-мемори-менеджмент (например, сколько выделять памяти при исчерпании выделенных ресурсов) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 10:48 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Основная проблема GC это асинхронность уборки. А в джаве еще к тому же и отсутсвие деструкторов (по выходу из области видимости). Это усложняет дизайн кода. А скорость GC там приемлемая для большинства задач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 11:32 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonКстати по поводу детерминизма отклика обычного memory management.Обычно он в диапазоне от "плохо" до "ужасно" :) Как по временам отклика, так и по фрагментации. Зато в хорошем случае он раздаёт почти всю память. Хочется детерминизм --- жертвуйте отношением "полезно" выделенной памяти к числу страниц, отожраных процессом и средним временем отклика, используя что-то вроде TLSF. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 12:09 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyА в джаве еще к тому же и отсутсвие деструкторов (по выходу из области видимости). В C# та же проблема, там порешали интерфейсом IDisposable и оператором using() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 13:06 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
CEMbmaytonТо что имеет рефералов - просто переносится в другие spacesэто ещё больше накладных расходов, получается. maytonРазумеется я не предлагаю писать свои аллокаторы.Если бы это дало прирост, то почему бы и нет? Другое дело, что в 99% случаев разработка своего аллокатора не нужна, потому что всё решается правильной организацией данных и продуманной работой с памятью в приложении. Да и объекты, которые связаны с работой с памятью (контейнеры) сейчас могут настраиваться и устраивать свой внутренний микро-мемори-менеджмент (например, сколько выделять памяти при исчерпании выделенных ресурсов) Нет. Работа java gc базируется на предположении что 99% аллокаций в eden space не переживут первую эпоху. Они будут удалены. Оставшийся процент выживших копируются в survival. Поскольку очистка eden это лёгкая Операция. По сути это обрушение счётчика. То мы считаем что здесь мы выиграли и дефрагментация eden нам не нужна. Разумеется это справедливо для стационарного режима приложения. Не для старта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 13:24 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Dima TAnatoly MoskovskyА в джаве еще к тому же и отсутсвие деструкторов (по выходу из области видимости). В C# та же проблема, там порешали интерфейсом IDisposable и оператором using() если бы эти приблуды ещё память освобождали.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 13:30 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
ИзопропилDima Tпропущено... В C# та же проблема, там порешали интерфейсом IDisposable и оператором using() если бы эти приблуды ещё память освобождали....Экий вы еретик. Вам мало того, что там чего-то внутри происходит, вам ещё и конечный результат подавай? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 13:32 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Мне кажется в спорах о m.management можно выделить две крайности. Два антогонизма. 1. Мемори leaks вызванные ошибкай разработчика при обработке исключения или просто ошибкой. 2. Накладные расходы на управляемую кучу в виде стоп-вселенная и потребления мегафлопов. Оба тезиса имеют место. Но многие ораторы не ищут компромисса между 1 и 2 а просто доказывают Правильность линии свой партии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 13:48 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonCEMbпропущено... это ещё больше накладных расходов, получается. пропущено... Если бы это дало прирост, то почему бы и нет? Другое дело, что в 99% случаев разработка своего аллокатора не нужна, потому что всё решается правильной организацией данных и продуманной работой с памятью в приложении. Да и объекты, которые связаны с работой с памятью (контейнеры) сейчас могут настраиваться и устраивать свой внутренний микро-мемори-менеджмент (например, сколько выделять памяти при исчерпании выделенных ресурсов) Нет. Работа java gc базируется на предположении что 99% аллокаций в eden space не переживут первую эпоху. Они будут удалены. Оставшийся процент выживших копируются в survival. Поскольку очистка eden это лёгкая Операция. По сути это обрушение счётчика. То мы считаем что здесь мы выиграли и дефрагментация eden нам не нужна. Разумеется это справедливо для стационарного режима приложения. Не для старта. это называется TLAB https://shipilev.net/jvm-anatomy-park/4-tlab-allocation/ именно заточка под классическое web приложение (сервлет) - тред получил запрос, нааллоцировал себе в TLAB, ответ отдал, все в TLAB прибил. а вот GUI для приложения это уже не работает, и именно поэтому все эти ваши Java IDE отличаются абсолютно непредсказуемыми тормозами. при этом отдельный ржач - в продакшине есть даже методика, когда выключают принудительно очистку old-generation, дескать дешевле просто на выходных приложение рестартовать и заново загрузить кеши из базы данных. вполне себе подход, чо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 13:48 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
dbpatchпри этом отдельный ржач - в продакшине есть даже методика, когда выключают принудительно очистку old-generation, дескать дешевле просто на выходных приложение рестартовать и заново загрузить кеши из базы данных. вполне себе подход, чо Вы наверное не в курсе. Вы просто не разрабатывали подобные приложения. Например ПО обработки equities, options имеет ярко выраженный сутошный лайф-цикл. Биржа открывается в определённое время суток. А потом закрывается. На момент закрытия приложение никому не нужно. И его можно ребутнуть. Какую из этого можно получить пользу? Я думаю - очевидно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 21:35 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
ИзопропилDima Tпропущено... В C# та же проблема, там порешали интерфейсом IDisposable и оператором using() если бы эти приблуды ещё память освобождали.... То что написан Анатолий - требует уточнения. Формально Java language позволяет создать класс с деструктором. Однако вам будет нелегко придумать и обосновать полезный use-case где этот деструктор будет действительно необходим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 21:43 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonФормально Java language позволяет создать класс с деструктором. Мы здесь про деструкторы, а не про финалайзеры. maytonОднако вам будет нелегко придумать и обосновать полезный use-case где этот деструктор будет действительно необходим. Например, немедленное освобождение кратковременно используемых ограниченных ресурсов (всякие мьютексы, сокеты и тп, особенно в сочетании с JNI). Хотя по мне так сначала придется придумать и обосновать полезный use-case для использования джавы ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 23:06 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskymaytonФормально Java language позволяет создать класс с деструктором. Мы здесь про деструкторы, а не про финалайзеры. Вроде не пятница еще а вброс уже сделан ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2017, 23:11 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonОба тезиса имеют место. Но многие ораторы не ищут компромисса между 1 и 2 а просто доказывают Правильность линии свой партии.Умные указатели разве не приводят к этому компромиссу? 1. Мы почти исключили вероятность ошибок, приводящих к ML 2. Мы можем не заниматься самостоятельной очисткой памяти, за нас это делают деструкторы. Но при этом мы сами может делать это в любой момент. Причём в плюсах этот механизм в разы гибче, чем в GC-языках. пятница наступила ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 07:34 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyМы здесь про деструкторы, а не про финалайзеры. В синтаксис C# замечательные грабли для новичков встроили: Код: c# 1. 2. 3. Выглядит как деструктор, но как деструктор не вызывается, потому что финализер. Кроме того MS в документации это деструктором называет . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 08:10 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Какие у вас претензии к финалайзеру? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 08:13 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Dima T, "Новички" описание языка читать пробовали? К с++ тоже относится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 08:17 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonКакие у вас претензии к финалайзеру? Пользы от него ноль. Какие претензии могут быть к бесполезному? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 08:18 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonКакие у вас претензии к финалайзеру? Пользы от него ноль. Какие претензии могут быть к бесполезному? Ты можешь на C# написать пример как-бы ты хотел использовать финалайзер по "полезному" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 08:30 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
По поводу QNX. Иван решил отмолчаться. Ну ОК. Из топиков по сабж я могу вспомнить только мой спор с неким Petrav на тему ПО и самолетов. А также с Базистом по поводу создания СУБД с нулевым откликом. Вообще у меня сложилось стойкое впечатление что в форуме мало людей которые по существу могут пояснить, а зачем им собственно вообще нужен реал-тайм. Обычно в 99% бизнес задач такой вопрос вообще не стоит. Этот аспект может быть описан так называемых NFR (Non functional requirements) где-то одим из подпунктов. Там может быть что flow, заявки на покупку или продажу акций должен быть отработан не более чем за 300 мс. Но это будет требование только для нашей системы. Не для внешних микросервисов. Они могут лагать как им удобно. По поводу UI для систем с MM (managed memory). Для UI приложений написанных на Java, есть коробочная рекомендация - включать +UseConcMarkSweepGC. Навскиду не помню но кажется эта опция включена во все дефолтные конфигурации пусковых скриптиков bash для продуктов комании Jetbrains. Этого достаточно чтобы комфортно работать и не видеть т.н. stop-the-world о которых так много говорят в топике. P.S. Я прошу прощения что пишу только по Java. C .Net я давно не работал и не в курсе как там и чего. Если кто в теме - то дополните. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 08:49 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytoniv_an_ruпропущено... Когда я смотрел на только-только свежеопубликованный go, в нём try-catch вообще не было. Ну, тоже метод :) Как там сейчас, через 10 лет --- не знаю, не смотрел, ибо что мне писать на платформе со stop-the-world GC? Мне кажется вы - гиперболизируете проблему stop-the-world. На чем вы кст. разрабатываете? На QNX?На POSIX :) У нас одно время выходило примерно 40 релизов одной версии --- под разные платформы. Сейчас, слава Торвальдсу, почти все эти HP/UXы, AIX-ы и т.п. сошли с дистанции, зоопарк поменьше стал. С другой стороны, если учесть, что у нас своё --- управление памятью --- управление сокетами --- кластерный IPC --- диспетчеризация доступа к дискам ... и даже, к примеру, поддержка нитей на том железе, где OS их не имеет, а при этом нам надо не "настоящий" реал-тайм, а interactive/near-interactive, то QNX нам вовсе не обязателен. Один ньюанс. Статистику по нашим процессам top запросто показывает с суффиксом не "m", и не "g", а "t". Ни один GC не будет вести себя прилично, если в колонках VIRT и RES маячат суффиксы "t" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 09:09 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39495750&tid=1340092]: |
0ms |
get settings: |
12ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
169ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
75ms |
get tp. blocked users: |
1ms |
| others: | 284ms |
| total: | 573ms |

| 0 / 0 |
