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

dot>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели

Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.

dot>https://www.youtube.com/watch?v=-6nrhSdu--s

К чему это видео? Там сорок минут рассказывается об affinity

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

I>>Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.

EP>Значит весь оверхед от случаев где ref-counting это исключительно подстраховка — это inc/dec (которых на C++11 существенно меньше). О чём я и говорил

Алё, я эти издержки вообще не считаю. На кой ляд ты доказываешь мне, что они ничтожны ?

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

I>>>·>Enterprise apps, web apps, finance, IDE в конце концов.
I>>>Кроме finance, С++ уже давно ушел из этих областей, там нет
I>·>Не "ушел" а тупо не взлетел. Взлетали всякие бейсики, перлы, питоны, пхп, и прочее.
I>Все эти вещи когда то писали на Си/С++. Питон, перл, пхп — все это выстрелило уже после того, как С++ оттуда ушел.
Что-то сомневаюсь. C ещё может быть, С++ — очень вряд ли. Но С просто старше. А уж LAMP всегда был классикой. Веб на С — это либо экзотика, либо старьё.

I>>>IDE и по сей день пишутся на плюсах.
I>·>Eclipse? IntelliJ? Да даже Студию уже на # переписывают.
I>Это единственные IDE что ли ?
Из наиболее развитых. Сравнивать QT Creator с MSVS... Даже Delphi и то были мощнее чисто-С++ IDE (по крайней мере мне известных). А так я и на бейсике IDE напишу.

I>>> finance — в HFT плюсы в полный рост.
I>·>Наравне с Java.
I>Джава в роли догоняющего.
Примерно как С++ догоняет Кобол.

I>>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap
I>·>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.
I>По факту запрещено многие вещи вызывать именно из за этого ограничения.
Что запрещено? Не понял мысль.

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

I>>>Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.
EP>>Значит весь оверхед от случаев где ref-counting это исключительно подстраховка — это inc/dec (которых на C++11 существенно меньше). О чём я и говорил
I> Алё, я эти издержки вообще не считаю. На кой ляд ты доказываешь мне, что они ничтожны ?

В этом случае других издержек нет

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

dot>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели
EP>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
И что GC-free? На плюсах так же будешь писать allocation free.
И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого. А в плюсах выбора нет.
Да и GC-free не так страшен, как его малюют.

dot>>https://www.youtube.com/watch?v=-6nrhSdu--s
EP>К чему это видео?
К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL, и java позволяет делать ровно то же что и С++, может быть синтаксис не очень, и код непривычен, но помехой не является.

EP>Там сорок минут рассказывается об affinity
Не только об аффинити, но ещё о тулзах разных. Да и, как оказывается, просто поставить affinity — станет только медленнее.

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

dot>>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели
EP>>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
dot>И что GC-free?

И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.

dot>На плюсах так же будешь писать allocation free.

Отдельный/специальный аллокатор это не allocation free.

dot>И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого.

Zing например не решит проблему индерекций/структур.

dot>А в плюсах выбора нет.

GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
Причём реализации возможны как библиотечные, так и runtime.

dot>>>https://www.youtube.com/watch?v=-6nrhSdu--s
EP>>К чему это видео?
dot>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,

Из этого видео никак не следует что "большинство выкрутасов это не извращения java".

dot>и java позволяет делать ровно то же что и С++,

Всё же не то же, но допустим.

dot>может быть синтаксис не очень, и код непривычен, но помехой не является.

И уровень кода ниже чем C, и больше его во много раз.

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

EP>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>Причём реализации возможны как библиотечные, так и runtime.

И как эти ГЦ делают обход указателей в структуре? По-моему, без рефлексии времени компиляции это трудновато.

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

EP>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>>Причём реализации возможны как библиотечные, так и runtime.
TB>И как эти ГЦ делают обход указателей в структуре? По-моему, без рефлексии времени компиляции это трудновато.

Да, но есть варианты. В библиотечных GC например рефлексия на макросах (а-ля BOOST_FUSION_*), либо gc_ptr<T> в конструкторе взводит флаг в битовом массиве. Runtime GC обычно консервативные.

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

EP>Да, но есть варианты. В библиотечных GC например рефлексия на макросах (а-ля BOOST_FUSION_*), либо gc_ptr<T> в конструкторе взводит флаг в битовом массиве. Runtime GC обычно консервативные.

Рефлексия на макросах — это когда поля объявляются не через Type name, а через BOOST_FUSION_FIELD(Type, name)?

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

EP>>Да, но есть варианты. В библиотечных GC например рефлексия на макросах (а-ля BOOST_FUSION_*), либо gc_ptr<T> в конструкторе взводит флаг в битовом массиве. Runtime GC обычно консервативные.
TB>Рефлексия на макросах — это когда поля объявляются не через Type name, а через BOOST_FUSION_FIELD(Type, name)?

Почти, например BOOST_FUSION_DEFINE_STRUCT.

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

dot>>Не сможет — чуть тормозить начнёт. А если человек не сможет доказать передачу указателей — всё круто и непредсказуемо навернётся.
EP>А зачем человеку доказывать? Например:
EP>Результат может содержать ссылку на этот unique, а может не содержать. Человек может например просто знать из документации что в результирующем объекте нет этого unique.
Тут мне кто-то рассказывал, что надо голые указатели использовать при передаче между потоками.

EP>Анализатору же придётся это доказывать проинлайнив весь код.
Да пусть доказывает, он железный, зарплату не просит.

dot>>Да знаю я язык прекрасно, опыта 5+ лет, просто уже несколько лет не использовал на работе.
EP>Так ведь по-разному используют. Есть действительно много когда где лепят *_ptr на каждый чих. Виной тому отчасти например некоторые книги — есть авторы которые пишут сразу по трём языкам C++/C#/Java, просто копируя примеры с небольшими изменениями из книги в книгу. И отчасти те кто застрял в начале 90-х.
К сожалению официального кода нет. Каждый пишет по разному.

EP>>>Это типичный миф обитающий в среде Java/C# — мол на каждый наш new, будет какой-нибудь *_ptr в C++.
dot>>... либо битый указатель.
EP>*_ptr не спасают от битых указателей, их основанная цель это выражение семантики владения в коде, отсюда и имена shared/unique/scoped.
Как более безопасный подход — оно вроде работает. Если ты будешь использовать в коде _ptr а не * и &, то нарваться на битый указатель практически невозможно.

EP>Это изменение контракта, которое прекрасно выражается в системе типов — у doSomething поменяется тип параметра и приведённый код не скомпилируется
Поменяется с чего на что? как было (Widget &w) так и останется, если не лепить _ptr на каждый чих.

EP>>>Выходим из scope — дальше какие действия? Какое преимущество даст EA в этом случае?
dot>>Тем что объект пойдёт на стек или в регистры. Какие аллокации?
EP>Ещё раз. Прочитай свои слова выше (выделено), и ниже:
EP>

dot>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

EP>Теперь скажи каким образом здесь поможет EA.
Что-то я тут фигню какую-то написал. Ссылка на стеке, конечно, как и unique_ptr, а сам массив в куче, как и unique_ptr, при выходе из стека — пропадёт ссылка. При сборке Eden Space оно и грохнется, не совсем при выходе из стека, но очень близко.
А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr.

EP>>>>>Ты что, они же есть в реальности данной нам в ощущениях железом. Это же например самый быстрый способ указать на конкретный элемент массива, или передать куда-нибудь его часть.
dot>>>>Железом нам даны адреса, а не указатели.
EP>>>А указатель что по-твоему хранит?
dot>>Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё.
EP>Конечно, и в типе разница — на C++ можно иметь указатель на элемент массива, на Java — нет.
Ты так говоришь, как будто это что-то плохое.

EP>>>>>Не грохнется — у него нет зависимости O(N) от количества живых объектов.
dot>>>>new/malloc и delete/free работают не за O(1) внезапно.
EP>>>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.
dot>>Так и разные алгоритмы GC есть. И столько всего можно крутить... И я уверен, что вариантов даже больше, ибо ссылка в jvm более абстрактна чем указатели в плюсах, а значит больше простора для оптимизаций.
EP>Так вот покажи GC не с сублинейной сложностью, желательно ещё чтобы был более-менее популярен.
Если вдруг GC начинает работать в режиме, что его сложность становится O(N) — ты делаешь что-то не то, тебе надо крутить настройки или даже изменять код.

dot>>>>Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.
EP>>>Конечно значит, именно поэтому в реализациях std::sort используется introsort, которая хоть и основана на quicksort, но выдаёт линеаритмическую сложность
dot>>Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC.
EP>Штуки типа cuckoo hashing не на ровном месте появились.
Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).

EP>Для hashtable есть альтернативы с гарантированной сублинейной сложностью, и там где гарантия нужна — их и используют. Причём можно комбинировать — снаружи hashtable, а внутри узлов при превышении лимита что-то логарифмическое — тогда будет суб-линейная гарантия.
Так и gc не лыком шиты.

dot>>>>Я и не изобретаю общую теорию всего, а решаю практические задачи.
EP>>>А кто-то изобретает? В Java нет структур — это практический недостаток и факт
dot>>Зато он даёт больший простор для JVM/JIT/etc.
EP>Какой простор? Всё равно есть те же int/double, с семантикой как у структур
Примитивы — значения фиксированного размера, структуры — произвольного.

dot>>Ну вот есть структуры в C# — а толку? Где LL?
EP>В C# свои проблемы. У тех же структур есть много ограничений. Но тем не менее они есть, и не нужно их эмулировать руками.
Они есть, конечно, но какой от них смысл?

dot>>>>Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему.
EP>>>Проблема в том для каждого типа элемента нужен будет отдельный Java код.
dot>>Не смертельно.
EP>Отдельный код для каждой комбинации. Конечно не смертельно, можно и на ASM'е писать рабочий код.
Комбинации чего? Сколько их? (только практику плз, а не теоретические рассуждения) Если можно было бы — писали бы и на асме, в LL все средства идут в ход.

dot>>>>Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.
EP>>>Деревья используются на практике. Хранение данных в самом узле позволяет избавится от лишней индерекции.
dot>>Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой.
EP>А например в хэш-таблице?
Если значение большое, то индирекция нужна, иначе сам массив хеш-таблицы будет слишком большим и не помещаться в кеш.
Если значение маленькое, то это скорее всего будет примитив.

EP>>>>>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры
dot>>>>by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.
EP>>>Далеко не всегда. Да и почему внезапно-то?
dot>>Настолько же ВНЕЗАПНО как и в случае с GC.
EP>Ок, допустим, в случае чего by-value заменим, не проблема — пара закорючек.
И поимеем битые указатели.

EP>В случае с GC что будешь делать?
Подстрою GC.

dot>>>>by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.
EP>>>В 99.999% случаях ничего "засучивать" не нужно, и никакие *_ptr не нужны.
dot>>Так в этих же случаях и в яве всё будет всё в YG, а значит никакого жуткого O(N).
EP>Нет же, случаи принципиально разные. Где-то наверху callstack делаем:
EP>

EP>{
EP>    vector<Foo> many_values(N);
EP>    // ...
EP>    pass_by_reference(many_values);
EP>}
EP>

ничего не "засучивая".
EP>Этот массив, по терминам GC, спокойно может попасть под классификацию OG
Сам массив это ровно одна ссылка. Элементы — пусть лежат, если ты не создаёшь|удаляешь их постоянно, а просто меняешь их поля — GC вообще не парится. GC ведёт себя плохо если постоянно меняется граф объектов долго лежащих в памяти. Собственно это соответствует сложному жонглированию владением в C++, где это запросто приведёт к битым указателям, если у вас в команде не Александреску с Страуструпом под руководством Кнута.

dot>>>>Зато гарантируется отсутствие битых ссыслок.
EP>>>Да, это плюс — с этим никто не спорил
dot>>Притом очень ценный плюс, что он перевешивает весь колбасокод с оффхипами и т.д.
EP>Этот же плюс есть в C#, в котором "колбасокод" нужен реже, как раз за счёт структур
Он нужен реже, ибо LL на нём никто не пишет, поколбасятся, да выкинут и дальше пилят веб-сайтики с формочками.

dot>>>>Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.
EP>>>А мы ВНЕЗАПНО не JVM обсуждаем, а вполне конкретную Java. Если брать JVM — то например если в неё скомпилировать C++ — то он там положит всех на лопатки
dot>>Не положит, к сожалению. Иначе бы уже давно компилировали.
dot>>Вся эта указательная магия и арифметика, юнионы, и прочий low level не может быть покрыт GC и JVM ссылками, поэтому при компиляции С/C++ память будет внутри byte[].
EP>Конечно будет, и это одна из причин почему положит на лопатки.
EP>Именно так и происходит

Автор: Evgeny.Panasyuk
Дата: 06.06.15

в Emscripten, который компилирует C++ в JS.
EP>И JS кстати получается реально быстрый. На одном из тестов работает практически в два раза быстрее чем аналогичный код на C#. JS, в веб-браузере, Карл! И этом при том что в C# версии были структуры. Если же брать аналогичный код на Java — то всё будет ещё круче Можем кстати сравнить.
Ну и кому эти микробенчмарки нужны? Ты давай пример системы на плюсах, компилированных под jvm.
Это же полная лажа. Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.
На Скале, кстати, вроде что-то есть.

Кстати, это, конечно, очень субъективно, но когда я искал работу (London), я всегда писал Java/C++ и выбирал finance. И из ~сотни интерьвю не было ни одного С++. Выводы, конечно, можно сделать разные... но всё же.

EP>>>Нормальные IDE есть. Да автоматический анализ кода сложнее, но сложнее не из-за выразительности, а из-за внутренних особенностей сложившихся исторически. Языку больше тридцати лет, а если брать с базу C (из которой многие недостатки и произрастают) — то больше сорока.
EP>>>При этом аналогичную выразительность можно достичь не делая проблемы анализаторам.
dot>>Может и можно... Я сходу не могу сделать такое заявление.
EP>>>Те же структуры есть в C#.
dot>>А толку-то от них...
EP>Не нужно вручную нарезать массивы на структуры
И что это даёт? Что позволяет добиться?

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

dot>>>>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
EP>>>В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
EP>>>Круто — чё
dot>>Если очень надо и до машкодов дойдёшь. Но это очень экзотические случаи.
EP>Так дело даже не сложности создания, а в том что это всё может тормозить. То есть получается взяли самое плохое от обхода живых и мёртвых объектов — обходим все.
Тут ведь как... может тормозить, а может и не тормозить! На практике — не тормозит.

EP>>>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
dot>>Двигаешь pos и получаешь элемент.
EP>То есть предлагаешь не использовать List? Или писать свой?
List это интерфейс.

dot>>Притом чтобы это всё имело смысл — pos должен двигаться строго вперёд, до следующего элемента, это и будет оптимизация sequencial access, а какие всякие другие алгоритмы ты тут хочешь воротить?
EP>Убрать лишние индерекции из random access — например элементарный бинарный поиск.
EP>Та же сортировка или например min/max heap на основе массива, а-ля std::pop_heap.
В этом случае массив в котором ты делаешь бинарный поиск должен быть компактным, содержащим минимум по которому осуществляется поиск, чтобы в кеш поместился. А если у тебя каждый элемент большой, то всё становится бессмысленно.

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

EP>>>>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.
EP>>>>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>>>>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.
EP>>>А как ты называешь объекты которые живут долго, но не до конца работы приложения?
dot>>Old Gen. Данные этих объектов можно менять свободно, но не трогать сильно указатели.
EP>Так они долгоживущие по твоей терминологии или нет?
Долгоживущие. Они живут и если граф объектов не модифицировать, то gc их трогать не будет.

dot>>>>Это можно лечить настройкой GC, испоьзованием разных приёмов (flyweight или пулов например)
EP>>>Причём тут flyweight? Объекты-то изменяются.
dot>>Смотря как изменяются.
EP>flyweight-ы обычно неизменяемые.
Всяко можно наворотить. Берём flyweight A и "измнеяем" его свойство X, т.е. находим другой flyweight B.
Или flyweight может иметь часть неизменную, а часть изменяемую. В общем нафантазировать можно много. Приёмов — масса.

dot>>>>Бывает. Лечится. Алгоритмы — сила.
EP>>>Конечно сила, о чём я тебе и говорю.
EP>>>И при логарифмической сложности, и при линейной, чем больше N тем медленнее — но разница между ними колоссальная. И в результате ситуации совершенно разные, а ты говоришь "тоже не поздоровится"
dot>>Так вот строгость ссылок явы позволяет применять гораздо более хитрые алгоритмы.
EP>Например?
Ну один из очевидных — перемещение данных, из одной области памяти (eden) в другую (tenured) или дефрагметация. Или решать где размещать объекты — на стеке, в регистрах или куче — в процессе исполнения программы.

dot>>Так ты не знаешь в каком именно потоке и когда он уйдёт в ноль и что именно произойдёт в момент ухода в ноль. В этом и суть GC. Да, узнать можно, но это очень трудоёмко. Компьютер с этим справляется в подавляющем большинстве случаев лучше и надёжнее.
EP>Ещё раз, зачем обмениваться практически мёртвыми объектами между рабочими потоками?
Потому что эти потоки могут захотеть использовать те же данные.

EP>>>>>Критический поток поставит его в очередь, а сам удалять не будет.
dot>>>>И возникнет та же проблема, которой ты меня мучил — а что если он будет ставить в очередь быстрее, чем эта очередь разгребаться?
EP>>>Проблема вообще-то была в другом. Если по аналогии — в том что грубо говоря pop одного элемента очереди линейно зависит от её размера. Здесь же такой зависимости нет.
dot>>Не одного элемента, а всей очереди. GC за цикл собирает не один объект.
EP>Чтобы убрать малое колличество мусорных объектов, GC приходится обходить большое количество живых. И скорость сбора мусорных объектов зависит от количества живых. В этом и аналогия.
От количества активных и живых.

dot>>>>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?
EP>>>Аналогично — а почему тогда GC?
dot>>Потому что управление памятью — трудоёмкий процесс в прикладных приложениях. Автоматизировать его — дело святое.
EP>>>Какой объем реализации? На C++ — меньше ста строк.
dot>>Ну вот... сейчас ещё начнём строки считать... увольте.
EP>Достаточно грубой прикидки. Если объём отличается на порядки — то с тем же успехом можно и компилятор модифицировать.
Не с тем же. Который из? Не надо путать изобретение своего языка с использованием предоставленных платформой документированных средств.

dot>>Перегрузка чего? Это же примитивы.
EP>На C++ это отдельные типы. И по разным типам можно сделать разные перегрузки.
Ну да, подходы другие, средства другие. Бывает.

dot>>И вообще, чего опять о языке, мы же о GC вроде? Ну возьми Скалу, там есть перегрузка.
EP>Ты же сказал что "и прочие С++ фишки можно реализовать в java" — мы в этой ветке сейчас и находимся.
Я не обещал реализацию синтаксиса С++ в Яве. Но, скажем, явное управление памятью сделать можно.

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

_>·>Неправда. Будет не исключение, а undefined behaviour, в дебаг-моде в лучшем случае может и грохнется. А если учесть всякие кастомные аллокаторы...

_>Undefined behaviour это по стандарту языка, без учёта работы ОС. Ну т.е. да, для каких-нибудь микроконтроллеров там действительно будет порча памяти, но на этих МК такие вещи как Java/C# вообще не живут. А в любой современной ОС мы получим соответствующее исключение.
Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь.

_>P.S. Ну и да, не забываем, что это мы тут развлекаемся обсуждением заведомо некорректного кода. ))) Типа а вот если мы специально подставим компилятор вот так, то в каком языке какие ошибки будут... ))) В реальном коде такое естественно не встречается.
И ты правда не видел битых указателях в реальных проектах? Укажи, плиз, номер твоей планеты в тентуре.

_>P.P.S. Я там в предыдущем сообщение опечатку сделал (типа из-за симметрии 2 строки на 2 строки) — сейчас исправил. )
Гы.

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

_>>>·>Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.
_>>>Фокус в том, что дефолтное в C++ как раз и есть самое быстрое для 99% задач. )
_>·>Это которое? Я ещё забыл варианты "MyClass[]", "MyClass*[]", все комбинации "xxx_ptr<vector<xxx_ptr<MyClass> >"
_>Дефолтное — это value type и контейнеры stl. Есть парочка редких случаев, когда применение этих инструментов приводит к не самому оптимальному кода (и тогда как раз делают всяческие кастомные аллокаторы и т.п.), но лично я на них натыкался исключительно в обсуждениях на форумах и т.п., а не в личной практике.
В дефолтном случае и GC замечательно работает. А вот эти обсуждаемые извращения в Яве это и есть те самые редкие случаи.

_>>>А что, разве не все программисты такое обдумывают на автомате в процессе проектирования?
_>·>А ты часто обдумываешь в какие регистры процессора какая переменная попадёт?
_>Совершенно не обдумываю, причём по разным причинам в двух разных случаях. В случае отсутствия необходимости в быстродействие (кстати в этом случае у меня скорее Питон в руках будет) понятно что не обдумываю потому что безразлично. А в случае необходимости высокого быстродействия и использования C++ тоже не обдумываю, потому как знаю, что оптимизатор современных компиляторов C++ создаст код лучше любого эксперта в ассемблере.
Собственно та же ситуация и с GC.

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

_>>>Ну если смотреть на этот список с точки зрения C++, то там вообще нет никаких извращений. Вполне нормальные архитектурные элементы не приводящие ни к каким ужасам.
_>·>"Извращения" это непривычный код, не так как учат в букварях.
_>Лично я не увидел в этом списке чего-то необычного, заставившего писать непривычный код.
А тебе вообще доводилось писать LL код?

_>·>Почитай, кстати там комменты — о том же рассуждают. Хорошо сказано:
_>·>

Java is a great platform none the less, but I think it’s biggest advantage is that ordinary business logic (90% of your code?) can still depend on GC and safety features and make use of highly tuned and tested libraries written with Unsafe. This is a great trade-off between getting the last 5% of perf and being productive. A trade-off that makes sense for a lot of people but a trade-off none the less. Writing complicated application code in C/C++ is a nightmare after all.

_>Рассуждения без аргументов не интересны. А если попробовать взглянуть на реальность, то "неожиданно" обнаруживается, что почти все самые сложные современные приложения написаны на C/C++. Причём не только системные, типа ОС, но самые пользовательские, типа браузеров.
В ФФ бОльшая пользовательская часть это js, xul и прочее. А вообще браузер системная вещь — основное назначение — взаимодействие с железом и ОС. Не путай с прикладными приложениями, типа очередной бухгалтерии или склада.

_>>>Если же взглянуть с точки зрения Java, то один пункт действительно становится извратом, реализация которого будет требовать страшного кода. Это пункт "Keep your reads sequential". Кстати как раз это мы обсуждали в соседнем сообщение.
_>·>И это ВНЕЗАПНО нужно делать и в плюсах, банальный vector<MyClass> может работать плохо, если, например, в классе куча полей, а тебя нужно последовательно читать только одно, вылезет structure of arrays и т.п.
_>Так а зачем я тогда буду делать такой MaClass? ))) Кстати, куча полей — это сколько? ) Ты в курсе размера линии кэша современных процессоров? )
"Дефолтное — это value type и контейнеры stl" и даст тебе тот самый жирный MyClass.
Кеш в районе всего лишь нескольких мегабайт — копейки же, миллиончик элементов — и упс, кончилось.

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

dot>>>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели
EP>>>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
dot>>И что GC-free?
EP>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.
На плюсах были бы те же извращения.

dot>>На плюсах так же будешь писать allocation free.
EP>Отдельный/специальный аллокатор это не allocation free.
Хотелось бы посмотреть. Особенно когда дело дойдёт до многопоточности, фрагментации, эффективности по памяти... И в итоге выйдет что никакого чуда-то и нет.

dot>>И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого.
EP>Zing например не решит проблему индерекций/структур.
Конечно не решит... решать ибо нечего.

dot>>А в плюсах выбора нет.
EP>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>Причём реализации возможны как библиотечные, так и runtime.
Ой, да не прикалывайся.

there is no currently practical usage of C++11 GC interface as there is no compiler which fully supports this API in the meantime

http://stackoverflow.com/questions/18005430/are-there-practical-uses-of-c11s-garbage-collection-abi

А всякие conservative gc как были игрушками, так и остались.
Единственный более менее нормальный gc на С++ это jvm.

dot>>>>https://www.youtube.com/watch?v=-6nrhSdu--s
EP>>>К чему это видео?
dot>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,
EP>Из этого видео никак не следует что "большинство выкрутасов это не извращения java".
Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java".

dot>>может быть синтаксис не очень, и код непривычен, но помехой не является.
EP>И уровень кода ниже чем C, и больше его во много раз.
Не знаю что тут значит "уровень кода", но это не важно. Все преимущества java никуда не деваются.

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

dot>>>>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели
EP>>>>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
dot>>>И что GC-free?
EP>>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.
dot>На плюсах были бы те же извращения.

Это демагогия чистой воды, непонятно на кого рассчитанная
В ролике действительно есть описание тех аспектов которые были бы на C++, их даже извращением трудно назвать — банальное affinity.
Помимо этого есть извращения с GC-free, off-heap — их выступающий упомянул только вскользь, мол да — надо как-то решать. Вот этих извращений на C++ бы не было

dot>>>И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого.
EP>>Zing например не решит проблему индерекций/структур.
dot>Конечно не решит... решать ибо нечего.

Никто вручную не нарезает массивы на структуры? Сам же даже предложил.

dot>>>А в плюсах выбора нет.
EP>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>>Причём реализации возможны как библиотечные, так и runtime.
dot>Ой, да не прикалывайся.

Не прикалываюсь

dot>

there is no currently practical usage of C++11 GC interface as there is no compiler which fully supports this API in the meantime

dot>http://stackoverflow.com/questions/18005430/are-there-practical-uses-of-c11s-garbage-collection-abi
dot>А всякие conservative gc как были игрушками, так и остались.
dot>Единственный более менее нормальный gc на С++ это jvm.

Например Boehm GC есть очень давно, и используется в реальных проектах

dot>>>>>https://www.youtube.com/watch?v=-6nrhSdu--s
EP>>>>К чему это видео?
dot>>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,
EP>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java".
dot>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java".

От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул.

dot>>>может быть синтаксис не очень, и код непривычен, но помехой не является.
EP>>И уровень кода ниже чем C, и больше его во много раз.
dot>Не знаю что тут значит "уровень кода", но это не важно.

На C есть структуры — это выше уровнем чем ручное нарезание буферов.

dot>Все преимущества java никуда не деваются.

Конечно теряются — например появляются те самые расстрелы памяти

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

EP>>>>>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.
EP>>>>>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>>>>>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.
EP>>>>А как ты называешь объекты которые живут долго, но не до конца работы приложения?
dot>>>Old Gen. Данные этих объектов можно менять свободно, но не трогать сильно указатели.
EP>>Так они долгоживущие по твоей терминологии или нет?
dot>Долгоживущие. Они живут и если граф объектов не модифицировать, то gc их трогать не будет.

А если менять — то будет

dot>>>>>Бывает. Лечится. Алгоритмы — сила.
EP>>>>Конечно сила, о чём я тебе и говорю.
EP>>>>И при логарифмической сложности, и при линейной, чем больше N тем медленнее — но разница между ними колоссальная. И в результате ситуации совершенно разные, а ты говоришь "тоже не поздоровится"
dot>>>Так вот строгость ссылок явы позволяет применять гораздо более хитрые алгоритмы.
EP>>Например?
dot>Ну один из очевидных — перемещение данных, из одной области памяти (eden) в другую (tenured) или дефрагметация.

Дефрагментация реализуется и без GC.

dot>Или решать где размещать объекты — на стеке, в регистрах или куче — в процессе исполнения программы.

Такой выбор и в C++ реализуется. Причём например помимо стэка можно размещать ещё и внутри самих структур — Small Size Optimization.

dot>>>Так ты не знаешь в каком именно потоке и когда он уйдёт в ноль и что именно произойдёт в момент ухода в ноль. В этом и суть GC. Да, узнать можно, но это очень трудоёмко. Компьютер с этим справляется в подавляющем большинстве случаев лучше и надёжнее.
EP>>Ещё раз, зачем обмениваться практически мёртвыми объектами между рабочими потоками?
dot>Потому что эти потоки могут захотеть использовать те же данные.

Каким образом? У них нет на них ссылки. Ты контекст потерял? Мы обсуждаем случай когда счётчик ссылок ушёл в ноль

dot>>>>>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?
EP>>>>Аналогично — а почему тогда GC?
dot>>>Потому что управление памятью — трудоёмкий процесс в прикладных приложениях. Автоматизировать его — дело святое.
EP>>>>Какой объем реализации? На C++ — меньше ста строк.
dot>>>Ну вот... сейчас ещё начнём строки считать... увольте.
EP>>Достаточно грубой прикидки. Если объём отличается на порядки — то с тем же успехом можно и компилятор модифицировать.
dot>Не с тем же. Который из?

Clang.

dot>Не надо путать изобретение своего языка

Это изменение существующего компилятора, а не изобретение языка.

dot>>>И вообще, чего опять о языке, мы же о GC вроде? Ну возьми Скалу, там есть перегрузка.
EP>>Ты же сказал что "и прочие С++ фишки можно реализовать в java" — мы в этой ветке сейчас и находимся.
dot>Я не обещал реализацию синтаксиса С++ в Яве.

Автоматическая перегрузка по типам которые генерируются в зависимости от состава выражения — вполне себе НЕ синтаксическая фича.

dot>Но, скажем, явное управление памятью сделать можно.

Явное в каком смысле?

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

dot>>>>>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
EP>>>>В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
EP>>>>Круто — чё
dot>>>Если очень надо и до машкодов дойдёшь. Но это очень экзотические случаи.
EP>>Так дело даже не сложности создания, а в том что это всё может тормозить. То есть получается взяли самое плохое от обхода живых и мёртвых объектов — обходим все.
dot>Тут ведь как... может тормозить, а может и не тормозить! На практике — не тормозит.

А ты проверял? Или имеешь в виду не то что "не тормозит", а то что "тормозит для нас приемлемо"?

EP>>>>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
dot>>>Двигаешь pos и получаешь элемент.
EP>>То есть предлагаешь не использовать List? Или писать свой?
dot>List это интерфейс.

Точно, это в C# List. ОК, писать свои ArrayList и т.п.?

dot>>>Притом чтобы это всё имело смысл — pos должен двигаться строго вперёд, до следующего элемента, это и будет оптимизация sequencial access, а какие всякие другие алгоритмы ты тут хочешь воротить?
EP>>Убрать лишние индерекции из random access — например элементарный бинарный поиск.
EP>>Та же сортировка или например min/max heap на основе массива, а-ля std::pop_heap.
dot>В этом случае массив в котором ты делаешь бинарный поиск должен быть компактным, содержащим минимум по которому осуществляется поиск, чтобы в кеш поместился.

Никому он ничего не должен, применим в том числе и для больших массивов.

dot>А если у тебя каждый элемент большой, то всё становится бессмысленно.

Да даже для больших элементов имеет смысл снижать индерекции. Например массив строк: на Java у каждой строки будет две индерекции, в то время как на C++ будет одна либо ноль, что даже чаще.