I>>>>·>Заблуждаешься. I>>>>Разве не ты говорил про off-heap приседания ? I>>·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет. I>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap dot>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.
А вместо например MyObj[] что? И кто и как создаст эти newMyObj?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>>Разве не ты говорил про off-heap приседания ? I>>>·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет. I>>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap dot>>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту. EP>А вместо например MyObj[] что?
ну например List<MyObj> или какие-нибудь буферы, Disruptor, пулы, етс.
EP>И кто и как создаст эти newMyObj?
Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>·>Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть. _>>·>В java есть JNI, unsafe режим — издевательство какое-то. _>>Это как же JNI интересно раскрывает? ) Он же не позволяет делать замену нативному коду, а как раз наоборот позволяет реализовывать часть функциональности нативным кодом. ))) ·>Не понял. Скажем, установка affinity для потока — делаешь через JNI-вызов ядерной функции. Реализовывать ничего не надо.
Т.е. ты считаешь, что ограничения виртуальной машины связаны исключительно с доступом к OS API? )
Здравствуйте, ·, Вы писали:
_>>>>А какая вообще связь между константностью/иммутабельностью и наличием деструкторов? _>>·>Что иммутабельный объект после вызова деструктора меняет своё состояние. _>>Иммутабельные объект после вызова деструктора не имеет никакого состояние, потому как самого объекта после этого уже не существует. ·>А запросить состояние — можно. И даже может что-то вернуться похожее на правду.
Здравствуйте, alex_public, Вы писали:
_>>>·>Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть. _>>>·>В java есть JNI, unsafe режим — издевательство какое-то. _>>>Это как же JNI интересно раскрывает? ) Он же не позволяет делать замену нативному коду, а как раз наоборот позволяет реализовывать часть функциональности нативным кодом. ))) _>·>Не понял. Скажем, установка affinity для потока — делаешь через JNI-вызов ядерной функции. Реализовывать ничего не надо. _>Т.е. ты считаешь, что ограничения виртуальной машины связаны исключительно с доступом к OS API? )
Я считаю, что ты фигню какую-то говоришь, что я перестал тебя понимать. Да, Джава не всемогутер, а хороший инструмент. Да, можно найти области, где этот инструмент не работает или работает плохо. Скажем, дравйвер видеокарты на Яве писать бессмысленно, если вообще возможно, а вот критичный LL код — вполне. Когда мы обсуждаем конкретные пункты, то можно уже сравнивать. Тут приводились какие-то пункты, по ним Джава, как выяснилось, не уступает и имеет некоторые преимущества.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>А запросить состояние — можно. И даже может что-то вернуться похожее на правду. _>Ну и зачем обсуждать заведомо некорректный код? )
Затем что в Джаве эта проблема решена. Такого типа некорректный код — невозможен. Это является сильным преимуществом в некоторых ситуациях.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
_>>Ох, ты похоже не понимаешь... Если переписать тот же 1C или скажем Питон с C++ на C#, то получившийся скриптовой язык станет только медленнее. Так понятно? ) S> А зачем переписывать? Если можно сразу писать на C#? Мало того можно сравнить Питон на C++ и IronPython на C#
Затем, что все тормоза 1C следуют из этого. Но и основные преимущества (DSL) тоже происходят из этого же.
_>>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред. S> Зато сравнивать C# и С++ это нормально. У них разная ниша. Если на C# написать код аля 1С это не далеко от оригинала. Приблизительно как TS от JC S>то разница между 1С и С++ это уже разные миры.
C++ и C# — это оба языка общего назначения, а не DSL. Конечно их целевые ниши различаются, но на фоне разницы со скриптовыми языками это не принципиально.
И я очень сомневаюсь, что какие-то профильные задачи решаются похоже на C# и 1C. Озвучь задачи тогда уж... Может это не профильные задачи 1C, а что-то Обычное? ) Тогда оно и на C++ будет выглядеть тривиально.
_>>Дело не только в этом, а ещё и в том, что 1C — это DSL. И соответственно в своей узкой области он в любом случае будет удобнее, чем любые универсальные языки. S> Я утвеждаю, что C# для решения подобных задач удобнее как TS vs JS. А я пишу на этих языках. Единственно, что нужно заменить англоязычные операторы на русские.
Здравствуйте, Serginio1, Вы писали:
S>>> Давай сравним с Microsoft Dynamics решающий аналогичную задачу _>>Если ты про Microsoft Dynamics ERP, то причём тут .net? ) S>Например https://msdn.microsoft.com/en-us/library/hh547453.aspx
По ссылке у тебя Microsoft Dynamics CRM. Там да, .net, но какое отношение CRM имеет к 1C?
Здравствуйте, Serginio1, Вы писали:
_>>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред. S>Казалось бы. Вот посмотри http://rsdn.ru/forum/dotnet/6185588.1
S>С помощью этого можно делать Сайт, Вэб сервисы на Asp.Net но никому это не нужно. 1С ник не знает .Net, а писатели Вэб приложения не знают структуру 1С. S>Поэтому проще написать вэб сервис на 1С, чем использовать быстрый доступ через Net. S>А ты говоришь скорость. Никому она не нужна. Ни одного комментария.
А где кто-то говорил, что в задачах 1C нужна скорость? )
Здравствуйте, ·, Вы писали:
_>>В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности. _>>В аналогичном случае на Java имеет ссылку на объект (коллекцию) в куче, в котором массив ссылок на объекты в куче (причём расположенные не факт что последовательно). В итоге имеем тройную косвенность, убивающую всякие намёки на работу кэша процессора. ·>Если ты в коде сделаешь ArrayList<MyClass> то объект ArrayList может так же разместиться на стеке, ибо он маленький — содержит только ссылку на MyClass[] и пару примитивов. Мало того, если размер самого Object[] так же окажется маленьким, то EA тоже может решить разместить на стеке. И в итоге вместо тройной косвенности может получиться та же одинарная.
Может будет, а может нет — гарантий нет.
Да, ну и для кэша гораздо важнее последовательное расположение данных в памяти, а это у тебя тут никак не выходит.
·>А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя.
Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT.
Здравствуйте, ·, Вы писали:
I>>IDE и по сей день пишутся на плюсах. ·>Eclipse? IntelliJ? Да даже Студию уже на # переписывают.
IDE на C++ достаточно много. Причём как специализированных для C++ (Qt Creator, Code::Blocks, CodeLite), так и универсальных (Anjuta, KDevelop, Geany). Это только то, что с ходу вспомнилось.
Здравствуйте, ·, Вы писали:
EP>>>>И не в покер, а в преферанс. И не выиграл, а проиграл. EP>>>>И не ссылку, а сам объект. И не unique_ptr, а просто стэковый объект. dot>>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr. EP>>То есть имелось в виду scoped_ptr — более ограниченная версия unique_ptr. Например unique_ptr можно возвращать из функции. dot>EA работает и с множеством функций. Сделай "byte[] func() {return new byte[100500];}"- ничего страшного.
Ближе, но всё равно не то — unique_ptr можно передавать хоть вверх, хоть вниз, хоть сохранить в массиве, и это всё работает даже без инлайнинга.
Да даже в одном scope EA далеко не всегда сможет доказать что нет escape — банально упрётся в halting problem.
EP>>>> vector<Widget> values(N); dot>>>И молись что N не слишком большой и не получится stack overflow на пустом месте. _>>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? ) dot>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.
Да нет никакого запутывания. Если бы ты знал язык, без всякого углубления в advanced фичи — ты бы никогда не запутался.
Это типичный миф обитающий в среде Java/C# — мол на каждый наш new, будет какой-нибудь *_ptr в C++. Ты его в очередной раз подтвердил.
Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984
Причём по сути это относится не только к *_ptr — а и в общем очень много мифов относительно C++. И в общем не так страшен чёртC++, как его малюют.
dot>>>массив не убегает за пределы, то при выходе из стека объект грохнется EP>>Каким образом грохнется? Речь только про некомпактифицируемые кучи? dot>Самое тривиальное — копирующим GC.
Каким образом? Положили в память эти non-escape данные, дальше вызвали какую-нибудь стороннюю функцию (не давая ей наши non-escape) — она сделала дальше какие-то аллокации, которые пошли следом за нашими non-escape данным.
Выходим из scope — дальше какие действия? Какое преимущество даст EA в этом случае?
EP>>>>Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика EP>>>>Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал. dot>>>Бррр... Я уж надеялся, что голые указатели постепенно изничтожаются. EP>>Ты что, они же есть в реальности данной нам в ощущениях железом. Это же например самый быстрый способ указать на конкретный элемент массива, или передать куда-нибудь его часть. dot>Железом нам даны адреса, а не указатели.
А указатель что по-твоему хранит?
EP>>>>Упёрлись в потолок, GC начинает очень долго освобождать за O(N), отбирая ресурсы у других потоков, общая пропускная способность снижается (забиты каналы памяти, и аллокации происходят медленней), извне приходят всё новые задачи для которых в свою очередь нужна всё новая память, в конце концов либо OOM либо DoS. dot>>>Это же сценарий high throughput, а не low latency. В такой ситуации и C++ грохнется — он будет делать ту же работу, просто в рабочих тредах, а на в отдельных gc-тредах как java. EP>>Не грохнется — у него нет зависимости O(N) от количества живых объектов. dot>new/malloc и delete/free работают не за O(1) внезапно.
Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.
dot>Если у тебя gc работает в режиме, что у него есть зависимость O(N) (т.е. худший случай), то ты делаешь что-то не то.
Эта зависимость есть всегда.
dot>Как известно, gc работает хорошо при короткоживущих и длинноживущих объектах.
То есть при любых?
dot>А проверяет он по грязным регионам, а не по всем живым.
Да без разницы, пусть он даже при каждой проверке не будет бегать по OG — сложность это не меняет.
dot>Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.
Конечно значит, именно поэтому в реализациях std::sort используется introsort, которая хоть и основана на quicksort, но выдаёт линеаритмическую сложность
EP>>>>Такой Array и другие контейнеры нужно делать для каждого типа данных. У тебя будут FooArray, BarArray, FooPriorityQueue, BarPriorityQueue и т.д. EP>>>>Либо как вариант добавлять лишней динамичности, но от неё будут свои тормоза, причём как размеры заранее не известны. dot>>>В LL не так уж и много разных структур. EP>>Ты постоянно говоришь о каком-то одном use-case'ы. EP>>Даже если и мало — всё равно придётся опускаться на очень низкий уровень, исключительно из-за самого языка. dot>Я и не изобретаю общую теорию всего, а решаю практические задачи.
А кто-то изобретает? В Java нет структур — это практический недостаток и факт
dot>>>И, как и в С++, и, скорее, всего будут поверх array. EP>>Это ты о чём? EP>>Например на C++ есть выгода от структур (в смысле хранения по значению) даже для вещей типа сбалансированных деревьев — так как уменьшает количество индерекций — само значение хранится в узле, а не указатель на значение. dot>Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему.
Проблема в том для каждого типа элемента нужен будет отдельный Java код.
dot>Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.
Деревья используются на практике. Хранение данных в самом узле позволяет избавится от лишней индерекции.
dot>>>>>Да, выглядит некрасиво, но обычно составляет <0.1% кода и сложностей никаких не доставляет. EP>>>>Это одна из главных причин тормозов в языках с превалирующей pointer semantics. Положил класс с несколькими полями-объектами в массив — уже на ровном месте выросло целое дерево индерекций и аллокаций. dot>>>В C++ можно тоже кучу главных причин тормозов придумать. Скажем, передача by-value. Непонятно только к чему это. EP>>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры dot>by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.
Далеко не всегда. Да и почему внезапно-то?
dot>by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.
В 99.999% случаях ничего "засучивать" не нужно, и никакие *_ptr не нужны.
EP>>>>Хуже, намного. Разве пример со структурами тебя не убедил? — это реально уровень ниже чем C, на ровном месте. Так это только один аспект. EP>>>>Быстрый код на C++ можно писать на высоком уровне абстракции — не нужно отказываться ни от замыканий, ни от классов, ни от ФВП и полиморфизма — и при этом он будет давать точно такое же (либо практически такое же) быстродействие как и такой же код написанный на низком уровне вручную — в этом одна из главных фишек C++. dot>>>Тут не фичи и уровни абстракции, а хранение и передача данных главное. И там и там об этом надо заботиться. В Яве — не создавать лишних индирекций, в плюса — не делать лишних копий и аккуратно заботиться о владении. Ведь тоже ничего хорошего в том, когда все эти уровни абстракции только и делают, что решают проблемы владения, тогда как в яве оно само, из коробки. EP>>Это уже передёргивание. Да, работу с памятью GC упрощают (при этом не гарантируя отсутствие утечек). dot>Зато гарантируется отсутствие битых ссыслок.
Да, это плюс — с этим никто не спорил
EP>>Да, на C++ нужно думать/помнить о владении (это не означает что каждый new на Java превращается в *_ptr). EP>>Нет, уровни абстракции о которых я говорю решают далеко не только проблемы владения — они позволяют писать высокоуровневый И быстрый код. dot>Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.
А мы ВНЕЗАПНО не JVM обсуждаем, а вполне конкретную Java. Если брать JVM — то например если в неё скомпилировать C++ — то он там положит всех на лопатки
dot>и прочее, которые позволяют и многие твои любимые абстракции
Я говорю не просто про абстракции, а про бесплатные, либо крайне дешёвые.
dot>Выразительность языка с другой стороны стреляет отстутсвием нормальной IDE.
Это тоже передёргивание.
Нормальные IDE есть. Да автоматический анализ кода сложнее, но сложнее не из-за выразительности, а из-за внутренних особенностей сложившихся исторически. Языку больше тридцати лет, а если брать с базу C (из которой многие недостатки и произрастают) — то больше сорока.
При этом аналогичную выразительность можно достичь не делая проблемы анализаторам. Те же структуры есть в C#.
_>Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.
Смотря где. Прошивки чипов (например WiFi, BT или LTE) — дело не в инерции. С язык сильно проще. Легче контролировать результаты, меньше требований к программистам. А в этой области нужно очень много знания самой области. Люди которые могут на высоком уровне при этом программировать встречаются редко.
Здравствуйте, ·, Вы писали:
_>>Я ничего подобного не упоминал, т.к. это совсем не моя область. Да, и кстати, насколько я понял данные продукты упоминались в том контексте, что мол посмотрите как надо извратить Java, чтобы была возможность конкурировать в данной области. ·>Вот возьми что-нибудь из http://codedependents.com/2014/01/27/11-best-practices-for-low-latency-systems/ и подумай что именно тут java-specific? Все те же извраты будут и в плюсах.
Ну если смотреть на этот список с точки зрения C++, то там вообще нет никаких извращений. Вполне нормальные архитектурные элементы не приводящие ни к каким ужасам.
Если же взглянуть с точки зрения Java, то один пункт действительно становится извратом, реализация которого будет требовать страшного кода. Это пункт "Keep your reads sequential". Кстати как раз это мы обсуждали в соседнем сообщение.
_>>·>Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь. _>>Всё правильно описано. Только я не понял что из этого следует. Да, между этими задачами есть разница, но они обе требуют low latency. ·>И они потребуют всех тех же извращений. За что яву-то опустили?
И обрати внимание, что в случае C++ никаких специальных извращений для такого результата не потребовалось — это самый обычный код.
_>>·>И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput. _>>Это не я мешаю, а реальные задачи возникают такие, что требуют этого всего одновременно. ))) ·>Но почему ты решил, что выход один единствтвенный — С++? Как видно из опыта тех компаний — java тоже подходит, и даже лучше.
Из опыта каких компаний? Где java системы реалтаймого видео? )
Здравствуйте, alex_public, Вы писали:
_>>>В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности. _>>>В аналогичном случае на Java имеет ссылку на объект (коллекцию) в куче, в котором массив ссылок на объекты в куче (причём расположенные не факт что последовательно). В итоге имеем тройную косвенность, убивающую всякие намёки на работу кэша процессора. _>·>Если ты в коде сделаешь ArrayList<MyClass> то объект ArrayList может так же разместиться на стеке, ибо он маленький — содержит только ссылку на MyClass[] и пару примитивов. Мало того, если размер самого Object[] так же окажется маленьким, то EA тоже может решить разместить на стеке. И в итоге вместо тройной косвенности может получиться та же одинарная. _>Может будет, а может нет — гарантий нет.
Эти гарантии нужны далеко не всегда. Главная цель же не размещение на стеке, а чтобы работало с требуемыми характеристиками скорости и безопасности.
_>Да, ну и для кэша гораздо важнее последовательное расположение данных в памяти, а это у тебя тут никак не выходит.
Надо будет — выйдет. Но в 99% случаев — не надо.
_>·>А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя. _>Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT.
Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.
А как же абстракция и прочие умные слова? Вместо простого "список объектов" начинаешь рассуждать как же оно будет в памяти, куча, стек, индирекции, индексы, указатели... И это чуть ли не для каждой строчки кода, а не для того 1% строчек где это действительно важно.
Аргумент похож на использование SQL. Да, можно написать свои структуры данных, размещать в файлах, писать запросы под свои нужны, т.к. видите ли, "я уверен, что во всех случаях сделаю это лучше чем SQL optimizer".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
I>>>IDE и по сей день пишутся на плюсах. _>·>Eclipse? IntelliJ? Да даже Студию уже на # переписывают. _>IDE на C++ достаточно много. Причём как специализированных для C++ (Qt Creator, Code::Blocks, CodeLite), так и универсальных (Anjuta, KDevelop, Geany). Это только то, что с ходу вспомнилось.
Много конечно, но по сложности они как notepad на фоне Eclipse/InteliJ (хотя мне доводилось видеть не всё вышеперечисленнное, может и ошибаюсь).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Т.е. ты считаешь, что ограничения виртуальной машины связаны исключительно с доступом к OS API? ) ·>Я считаю, что ты фигню какую-то говоришь, что я перестал тебя понимать. Да, Джава не всемогутер, а хороший инструмент. Да, можно найти области, где этот инструмент не работает или работает плохо. Скажем, дравйвер видеокарты на Яве писать бессмысленно, если вообще возможно, а вот критичный LL код — вполне. Когда мы обсуждаем конкретные пункты, то можно уже сравнивать. Тут приводились какие-то пункты, по ним Джава, как выяснилось, не уступает и имеет некоторые преимущества.
Лично я знаю ровно одно преимущество Java/C#. Это возможность достаточно безопасного использования низкоквалифицированных программистов. Возможно с точки зрения технологии это звучит и не очень. Но с точки зрения бизнеса это очень существенное преимущество, правда актуальное в основном для не IT компаний. Так что благодаря этому преимуществу Java/C# заслуженно занимают доминирующее положение во внутрикорпоративном энтерпрайзе. И если их там кто-то и подвинет, то разве что JS, если обретёт соответствующую инфраструктуру (кстати шаги к этому уже наблюдаются). ))) А вот использование Java/C# в других областях, особенно со сложным кодом или тяжёлыми условиями, мне кажется неразумным. Но в нашей индустрии вообще много всего неразумного встречается. )))
Здравствуйте, ·, Вы писали:
_>>·>А запросить состояние — можно. И даже может что-то вернуться похожее на правду. _>>Ну и зачем обсуждать заведомо некорректный код? ) ·>Затем что в Джаве эта проблема решена. Такого типа некорректный код — невозможен. Это является сильным преимуществом в некоторых ситуациях.
И в Java и в C++ будет одинаковый расклад для таких ситуаций — исключение (правда в C++ системное, а не родное).
delete x; х=nullptr;
x->v=1;
x=null;
x.v=1;
Но это на самом деле не важно, т.к. подобные проблемы являются уделом разве что студентов.
Здравствуйте, ·, Вы писали:
EP>>>>Причём это происходит по вине самого GC. dot>>>Ну подкрути параметры чуток, не проблема. EP>>Это уберёт линейную сложность? dot>Да. Линейная сложность это худший случай, когда у тебя постоянно меняются указатели в большинтсве живых объектов и постоянно создаются новые.
Не обязательно в большинстве живых, достаточно в относительно малом количестве.
dot>В такой ситуации С++ тоже не поздоровится — и фрагментация кучи, и возрастающая сложность malloc/free.
Алгоритмическая сложность не "растёт" — это характеристика алгоритма. Например если брать Buddy — то она логарифмическая.
Да, — чем больше N, тем будет дольше, но чтобы прикинуть как это "дольше" зависит от N — как раз и используют алгоритмическую сложность.
dot>>>>>Не понимаю каким образом ты избежишь ООМ в таком случае в плюсах? EP>>>>Нет линейной зависимости времени очистки от количества живых объектов. В случае же GC, на одной и той же скорости входящего потока он может либо успевать очищать, либо нет — и это сильно зависит от текущего количества живых объектов. dot>>>Если ты в С++ заведёшь очередь для очистки — столкнёшься ровно с той же проблемой. Не вижу разницы. EP>>В очереди объекты которые уже готовы для очистки. А вот сколько там живых reachable объектов — не важно, пусть хоть десять миллиардов. dot>Ты представляешь как поплохеет системе когда туча тредов будет пихать миллиарды объекты в одну единственную очередь,
Ещё раз, очередь у каждого потока своя, thread-local.
dot>обрабатываемую одним несчастным потоком?
Необязательно одним
EP>>>>Зачем? dot>>>Определить граф-остаток. EP>>Зачем его определять? Что это даст? EP>>Пока не превысим бюджет времени — удаляем сами, как только времени осталось меньше чем требует max объект — ставим остаток в очередь. dot>Так как мы конкретно будем этот бюджет считать?
Бюждет зависит от конкретной задачи.
EP>>>>Очередь может быть thread local. dot>>>И кто из этой очереди будет обрабатывать элементы? Сам thread — не может отвлекаться, он LL, в любую наносекунду может прийти новый запрос. EP>>От задачи зависит, может и сам thread. А может и отдельный thread, при этом contention с другими потоками всё равно не будет — так как очередь SPSC. dot>Мы вроде рассматриваем случай, когда sharedPtr.release может начаться из разных тредов. Как ты собираешься использовать single writer структуру?
Объект управляемый shared_ptr всегда удаляется одним потоком, каким из них — определяется тем самым атомарным wait-free счётчиком. Это всё есть даже без отложенной очистки.
dot>>>Это тоже подзадача GC — решать сразу или отложить. EP>>А ещё в подзадачах GC есть сложение целых. dot>Хорошо, не подзадача, а средство достижения заявленных характеристик.
Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
EP>>>>Разница в том, что написанная библиотека используется внутри самого host-языка. То есть эти gc_ptr — они используется не внутри какой-то виртуальной среды созданной библиотекой, а внутри вызывающего host-языка. dot>>>Так и деструкторы и прочие С++ фишки можно реализовать в java, EP>>Каким образом ты реализуешь деструкторы? Какое будет использование? Каким образом реализуешь например Expression Templates и прочие compile-time EDSL? dot>А зачем compile time? Я знаю, что C++ compile time — Turing Complete, но в общем-то и в Java можно сделать плугин для компилятора или load-time кодогенерацию.
Так фишка EDSL (Embedded Domain Specific Language) именно в том что он embedded.
Здравствуйте, ·, Вы писали:
_>>·>А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя. _>>Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT. ·>Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.
Фокус в том, что дефолтное в C++ как раз и есть самое быстрое для 99% задач. )
·>А как же абстракция и прочие умные слова? Вместо простого "список объектов" начинаешь рассуждать как же оно будет в памяти, куча, стек, индирекции, индексы, указатели... И это чуть ли не для каждой строчки кода, а не для того 1% строчек где это действительно важно.
А что, разве не все программисты такое обдумывают на автомате в процессе проектирования?
