Здравствуйте, ·, Вы писали:
PM>> Почитайте на досуге как авторы LMAX героически боролись (и вроде бы продолжают бороться) с JVM — пытаясь выровнять данные по границе кэш-линии; как затюнинговать сборку мусора, чтобы система не замерзала в неподходящий момент (и перезапускать всё разв в сутки в конечном итоге)
PM>> Короче, сплошной <троллейбус из буханки хлеба.jpeg> ·>Собственно сейчас в моде Zing JVM, там задержки не более 10ms, в основном ~100us. ·>Писать такое на C++... неее... проще застрелиться. ·>А перезапуск нужен не для gc, а чтобы на диск состояние скинуть, ибо использовать классические СУБД — теоретически невозможно.
Задержка 10ms может быть неприемлемой в некоторых задачах, в том числе и в биржевых системах.
Состояние на диск постоянно скидывается в LMAX в отдельном потоке в файл журнала. И разработчики LMAX повоевали и здесь чтобы добиться предсказуемого результата. Ну и для сетевого I/O наверняка использовали какой-нибудь NIO.
Я почитал ваши сообщения в ветке. Ещё одна иллюстрация, что люди не из мира C++ продолжают верить в мифы 15-20 летней давности. Авторы LMAX скорее всего тоже подумали: "Писать такое на C++... неее... проще застрелиться" и взяли хорошо известный им и широко распространённый инструмент. Хорошо, что при этом они не застрелились
_>Безусловно. А можно даже и без t4 просто голые sql строки вставить и опять же будет отличная скорость. Нюанс в том, что в обоих этих случаях синтаксис станет не как у linq. А вот sqlpp11 сохраняет такой синтаксис без потерь в скорости.
S>>Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.
_>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )
Еще раз без навигационных свойств снижает функциональность в разы. Поверь мне, так как знаю разницу.
По быстродействию. Самая распространенная задача это когда есть некий отчет, где пользователь может наложить до 6 и более условий.
Причем например для справочников эти условия могут быть как равны элементу либо входить в группу. Невыбранные параметры не участвуют в запросе.
Смыла в статическом запросе никакого нет. Кроме того поддержка разных баз, провайдеров итд
Но опять когда эта скорость нужна? Для клиента то он её просто незаметит. А например для Asp.Net то если сильнозагруженный сервер по 1000 запросов в секунду, то тогда стоит заморочится на скорость. Но таких задач ооочень мало.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Наоборот, полная и внятная предсказуемость. EP>Относительно производительности — сплошные недостатки
Тебе снова показать какую часть ты не сумел прочитать ? "Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов". low latency никогда не требовал экстремальной производительности от компилятора, потому и пишется реалтайм в т.ч. на менеджед языках.
EP>Даже если использовать refcounting не только для решения задач в которых
Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ?
EP>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC).
Ужос, кто бы мог подумать ?
EP>Непосредственно ref-counting (в тех случаях где он не нужен по задаче, но нужны указатели) — это где-то на уровне процентов от общих проблем.
Вообще говоря неверно. Там где он не нужен, освобождение графа объектов может занять "хрен знает сколько", а это уже на low latency не тянет.
Здравствуйте, Ikemefula, Вы писали:
I>>>Наоборот, полная и внятная предсказуемость. EP>>Относительно производительности — сплошные недостатки I>Тебе снова показать какую часть ты не сумел прочитать ?
А ты перестал пить коньяк по утрам? Реально, завязывай со своей дешёвой демагогией.
I>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов".
Это не "как на Си". Контроль над временем вообще ортогонален "как на Си".
I>low latency никогда не требовал экстремальной производительности от компилятора,
Это прежде всего low latency, а для low нужна в том числе скорость.
EP>>Даже если использовать refcounting не только для решения задач в которых I>Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ?
На C та часть которая "не только" (то есть опциональная) — она не реализуема.
EP>>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC). I>Ужос, кто бы мог подумать ?
Видимо не ты, раз говоришь что от ref-counting "растут жесточайшие проблемы".
EP>>Непосредственно ref-counting (в тех случаях где он не нужен по задаче, но нужны указатели) — это где-то на уровне процентов от общих проблем. I>Вообще говоря неверно. Там где он не нужен, освобождение графа объектов может занять "хрен знает сколько", а это уже на low latency не тянет.
Здравствуйте, xRAZORx, Вы писали:
RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.
Я делал замеры — эквивалентный С++ код часто сравним, а иногда очень сильно отстает от эквивалентного кода на java (оверхед для generic хипа) — см. тему.
Заранее оговорюсь — что в определенных задачах, конечно, С++ может показать сильный отрыв и по быстродействию и по потреблению памяти, хотя в прикладном программировании таких задач не так много.
В то же время jvm может выполнять оптимизации принципиально недоступные для при статической компиляции.
Для желающих проверить на практике — предлагаю желающим реализовать простейший интерпретатор нетипизированного лямбда исчисления на С++ (ну то есть REPL который бы понимал что-то вроде такого) и сравнить его быстродейтвие с тем, что можно реализовать на яве (мой вариант меньше 500 строк и по быстродействию уделывает известные мне интерпретаторы scheme). Насколько я себе представляю возможные реализации — на стресс тестах будет большое количество виртуальных вызовов и большое количество выделений памяти под мелкие объекты.
И да, согласен, что это тоже не типичная прикладная задача
Eсли лень реализовывать — достаточно сравнить эти два варианта: на С++ и на Java — приближенные к тому, что пришлось бы иметь в коде интерпретатора.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>Я вот могу ещё один очень известный пример привести на похожую тему. Питон сейчас очень популярен в научной среде. Причём не только для написания скриптов (что логично), но и для сложных и тяжёлых вычислений. Казалось бы нонсенс, но секрет раскрывается просто — для таких дел используются специальные библиотеки (типа numpy), которые написаны опять же на C/C++. В итоге получаем сочетания максимального быстрого написания кода с одновременной неплохой производительностью.
В научной среде популярны: Matlab, Mathematica, Statistica, R, Octave, Fortran, наконец. И большинство этих инструментов эффективнее питона (даже с C/C++ биндингами) с точки зрения производительности.
Питон активно пользуют т.н. data scientists, но по причинам, которые к производительности отношение имеют отдаленное.
Здравствуйте, A13x, Вы писали:
RAZ>>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости. A>Я делал замеры — эквивалентный С++ код часто сравним,
Сильное утверждение. На каком уровне? И там и там высокий уровень? Или на Java низкий?
A>а иногда очень сильно отстает от эквивалентного кода на java (оверхед для generic хипа) — см. тему.
Так там такая задача(очень близкая к реализации языка с GC, типа Unlambda), что позволяет раскрываться языку с GC+JIT во всей красе.
И даже при всём при этом получилось забороть
ref-counting'ом
A>Заранее оговорюсь — что в определенных задачах, конечно, С++ может показать сильный отрыв и по быстродействию и по потреблению памяти, хотя в прикладном программировании таких задач не так много.
Не так много задач где это требуется/заметно? Или не так много где есть сильный отрыв?
Здравствуйте, m.aksenov, Вы писали:
_>>Я вот могу ещё один очень известный пример привести на похожую тему. Питон сейчас очень популярен в научной среде. Причём не только для написания скриптов (что логично), но и для сложных и тяжёлых вычислений. Казалось бы нонсенс, но секрет раскрывается просто — для таких дел используются специальные библиотеки (типа numpy), которые написаны опять же на C/C++. В итоге получаем сочетания максимального быстрого написания кода с одновременной неплохой производительностью. MA>В научной среде популярны: Matlab, Mathematica, Statistica, R, Octave, Fortran, наконец. И большинство этих инструментов эффективнее питона (даже с C/C++ биндингами) с точки зрения производительности. MA>Питон активно пользуют т.н. data scientists, но по причинам, которые к производительности отношение имеют отдаленное.
Python популярен у инженеров различных областей. Причём на нём пишут и как отдельные программы, так и используют в виде скриптовых движков (например ParaView).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Python популярен у инженеров различных областей. Причём на нём пишут и как отдельные программы, так и используют в виде скриптовых движков (например ParaView).
Инженерная и научная среды различаются.
Да, использовать Python / Jython в качестве скриптового движка это разумное решение, так как язык сам по себе не самый неплохой, но причины встраивания именно его в распространенности и относительной простоте, а не производительности каких-то там библиотек. По качеству среды / документации Python пока проигрывает специализированным пакетам.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Тебе снова показать какую часть ты не сумел прочитать ?
EP>А ты перестал пить коньяк по утрам? Реально, завязывай со своей дешёвой демагогией.
low latency и производительность кода это одно и тоже ? А производительность всей системы ?
I>>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов". EP>Это не "как на Си". Контроль над временем вообще ортогонален "как на Си".
Наоборот.
I>>low latency никогда не требовал экстремальной производительности от компилятора, EP>Это прежде всего low latency, а для low нужна в том числе скорость.
В первую очередь кое что другое, ибо в low-latency работает в т.ч. и джава.
EP>>>Даже если использовать refcounting не только для решения задач в которых I>>Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ? EP>На C та часть которая "не только" (то есть опциональная) — она не реализуема.
Реализуема, только иначе.
EP>>>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC). I>>Ужос, кто бы мог подумать ? EP>Видимо не ты, раз говоришь что от ref-counting "растут жесточайшие проблемы".
Именно. рефкаунтинг может дать не меньшие тормоза, нежели GC.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
MA>>Питон активно пользуют т.н. data scientists, но по причинам, которые к производительности отношение имеют отдаленное.
EP>Python популярен у инженеров различных областей. Причём на нём пишут и как отдельные программы, так и используют в виде скриптовых движков (например ParaView).
В научной среде применение другое, время написания программы часто сравнимо с временем работы. Никто не жаждет отлаживать реф-каунтинг в многопоточном приложении, если софтина работает день-два, после чего надо писать новую софтину.
Здравствуйте, Ikemefula, Вы писали:
I>>>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов". EP>>Это не "как на Си". Контроль над временем вообще ортогонален "как на Си". I>Наоборот.
Аргументированно
I>>>low latency никогда не требовал экстремальной производительности от компилятора, EP>>Это прежде всего low latency, а для low нужна в том числе скорость. I>В первую очередь кое что другое,
Если в первую очередь другое, то для этого есть другое название.
I>ибо в low-latency работает в т.ч. и джава.
На Java можно в том числе создавать быстрый код. Затратно, но можно.
EP>>>>Даже если использовать refcounting не только для решения задач в которых I>>>Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ? EP>>На C та часть которая "не только" (то есть опциональная) — она не реализуема. I>Реализуема, только иначе.
Расшифруй.
EP>>>>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC). I>>>Ужос, кто бы мог подумать ? EP>>Видимо не ты, раз говоришь что от ref-counting "растут жесточайшие проблемы". I>Именно. рефкаунтинг может дать не меньшие тормоза, нежели GC.
А ты представляешь как реализуется ref-counting в C++11?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен EP>Более того аллокация на стэке — это default для C++, и работает даже в случаях escape.
Не обязательно на стеке, ещё есть thread local heap.
Код может быть очень развесистохитрым, а unique_ptr выведется сам, как результат EA.
dot>>да и Young Generation собирается очень быстро. EP>Во сколько раз "быстро" быстрее "мгновенно"?
O(1)
EP>>>·>Если нужна передача данных между тредами — нужен shared pointer, EP>>>Он нужен только в случаях когда потоки владеют какими-то общими данными и точный момент удаления заранее не определён. EP>>>Если просто нужно передать данные и владение в другой поток, то достаточно и unique, и то не факт — может быть хватит обычного перемещения. dot>>Не владеют, а шарят... EP>А шарят они что по-твоему? Цитата из стандарта: "shared_ptr implements semantics of shared ownership" dot>>Будешь передавать weak_ptr, а значит опять локи. EP>Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла.
shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.
dot>>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что. EP>А например OOM — тоже вполне серьёзно
ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.
dot>>А ещё аллокация из кучи — глобальный лок. В общем, тормоза повсюду. EP>Специальные аллокаторы и т.п. — вполне распространённая практика. EP>Значит в случае Java ты готов использовать и специальную VM, и специальный GC, отказываться от классов, а в случае C++ специальные аллокатор ни в коем случае
VM и GC не влияет на код, просто пускаешь тот же апп под другой VM.
Отказываться от классов? Это как? В смысле раскладывать данные по массивам? Массивы не отказ от классов, а от полей классов. Эта техника не специфична для Java, в С++ тоже так делают: http://programmers.stackexchange.com/questions/246474/data-oriented-design-impractical-with-more-than-1-2-structure-members
dot>>Короче, может и можно писать low latency на C++, но сложнее на порядок. EP>Это фантазии, ничем не обоснованные. EP>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++. EP>Вот конкретный пример (первые минут двадцать)
Посмотрел начало ролика. В общем там неплохо сказано — быстрое ядро относительно маленькое, зато обвязка — на порядок больше. Поэтому в целом и получается этот порядок.
И, кстати, я заметил, что java-specific там практически ничего не было. Основной упор именно на то, что надо понимать как работает железо, а какой язык — не важно, техники отличаются деталями реализации, принцип же тот же.
EP>>>·>который использует lock (mutex?) - EP>>>Обычно в реализациях атомарные inc/dec. dot>>Это где? Вот тут вроде mutex. EP>И там же atomics. Mutex это лишь fallback для платформ в которых нет подходящих атомарных операций
А. Да. Не так посмотрел, там оказывается специализации под разные стратегии.
В общем да. Да, на плюсах можно делать то же, что и в Яве. Ведь Ява на плюсах написана. Но из-за арифметики указателей и прочего нормальный gc сделать всё равно не выйдет, только всякие ref counting и прочее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr. _>·>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers. _>С чего это ты взял, что не могу? ) Да, и ты снова привёл не конкретный пример, а абстрактные рассуждения. Давай конкретную задачку и посмотрим могу или нет... )))
Сможешь, конечно. Можно всё и на brainfuck написать, вопрос в том, что проще и на чём будет проще убедиться в работоспособности решения.
_>>>·>Да не надо локи. Есть много других механизмов. _>>>Например? ) _>·>CAS, volatile, happens-before. _>Если применять CAS не по делу (исключительно в специально предназначенных для этого алгоритмах), а везде вместо локов, то результат будет только ещё намного хуже чем с локами, т.к. в таком случае всё равно будет нечто типа лока, только при этом с полной загрузкой процессора.
Полная загрузка процессора в low latency как раз частенько используется — для того, чтобы операционка не вздумала вытеснить критичный тред. Ещё этот тред к одному ядру привязывается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
dot>>Во-вторых, попробуй такой трюк проверни со включенным security manager, запретить const_cast же — невозможно. EP>Возможно. Даже если опасаешься false positives/negatives grep'а — то легко написать простейший верификатор на базе Clang AST Matchers.
Задоблаешься. Скажем, частенько при интеграции с другими библиотеками, особенно C, может вылезти:
И нифига ненаверифицируешь.
И вообще, никакая это не верификация, а статический анализ.
dot>>В-третьих, вот так в C++ писать уже можно? EP>В Java у volatile семантика другая нежели чем у C++. Для этой же цели используются std/boost::atomic. То есть будет не volatile ImmutableClass *, а atomic<ImmutableClass *>.
О, наконец-то стало можно. Если не ошибаюсь, в С++ это появилось c 2011, в Яве же с 2004.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
dot>>Ролик не смотрел, дома посмотрю... Но могу заметить, что эти все нарезки обычно делаются в довольно ограниченной области кода. И все эти порчи данных довольно изолированы (или как минимум изолируемы).
EP>Да, но мы-то обсуждаем именно такой случай, именно эту самую область кода. И эта ручная error-prone нарезка на структуры, отказ от GC и т.п. — по сути выливается в уровень ниже чем C, и в результате приводит к вполне ожидаемым ошибкам: http://rsdn.ru/forum/philosophy/6201205.1
Заметь, эта ошибка в C++, т.е. к яве отношения не имеет. А java-specific никакой проблемы не представляет (ну, кроме как вместо бесплатной Oracle VM нужно покупать Zing JVM).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
I>>>Ошибся "здесь" — задержка вылезет черз секунду "там" I>·>gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки. I>Самое страшное — твою софтину для биржи на джаве никто не купит. Отсюда ясно, что часть софта в принципе никто даже не станет пытаться писать на джаве.
Расскажи это как миниимум упомянутым dxFeed и LMAX.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов". EP>>>Это не "как на Си". Контроль над временем вообще ортогонален "как на Си". I>>Наоборот.
EP>Аргументированно
Ну и логика
Вот это аргумент: 'Это не "как на Си"'
А вот это — 'Это "как на Си"' — уже нет
Браво !
I>>ибо в low-latency работает в т.ч. и джава.
EP>На Java можно в том числе создавать быстрый код. Затратно, но можно.
Настолько быстрый, как С++ это невозможно. И тем не менее джава есть в low latence. А следовательно твой
EP>>>На C та часть которая "не только" (то есть опциональная) — она не реализуема. I>>Реализуема, только иначе.
EP>Расшифруй.
Это значит, что те же задачи решаются и в Си, за доказательством смотри полноту по тьюрингу и реализации ОС РВ.
EP>А ты представляешь как реализуется ref-counting в C++11?
А при чем здесь 11 ? Есть куча кода написаного в тысячах контор:
"Зануление счетчика, вызов деструктора, который вызывает зануление другого счетчика, который вызывает деструктор,и тд и тд"
Здравствуйте, ·, Вы писали:
EP>>Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен EP>>Более того аллокация на стэке — это default для C++, и работает даже в случаях escape. dot>Не обязательно на стеке, ещё есть thread local heap. dot>Код может быть очень развесистохитрым, а unique_ptr выведется сам, как результат EA.
И каким образом у тебя получился тут unique_ptr?
dot>>>Будешь передавать weak_ptr, а значит опять локи. EP>>Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла. dot>shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.
Как weak_ptr относится к дискуссии?
dot>>>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что. EP>>А например OOM — тоже вполне серьёзно dot>ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.
OOM он конечно везде OOM, но причины наступления бывают разные
dot>>>А ещё аллокация из кучи — глобальный лок. В общем, тормоза повсюду. EP>>Специальные аллокаторы и т.п. — вполне распространённая практика. EP>>Значит в случае Java ты готов использовать и специальную VM, и специальный GC, отказываться от классов, а в случае C++ специальные аллокатор ни в коем случае dot>VM и GC не влияет на код, просто пускаешь тот же апп под другой VM. dot>Отказываться от классов? Это как? В смысле раскладывать данные по массивам? Массивы не отказ от классов, а от полей классов. Эта техника не специфична для Java, в С++ тоже так делают: dot>http://programmers.stackexchange.com/questions/246474/data-oriented-design-impractical-with-more-than-1-2-structure-members
Нет, именно от классов. То что ты привёл это иногда называется Structure of Arrays, в C++ кстати я такую трансформацию реализовывал в библиотечном виде, то есть раскидывание происходит автоматически.
Я же говорю про обычные структуры, в Java нет даже их. То есть положить в один массив плотно друг к другу данные вида:
struct Foo
{
double a;
int b;
char c, d;
};
напрямую не получится, и это существенный источник тормозов. В зависимости от ситуации медленнее может быть на несколько порядков. На ровном месте вырастают целые деревья индерекций.
Обходится например через огород low-level эмуляции на чём-то типа ByteBuffer.
dot>>>Короче, может и можно писать low latency на C++, но сложнее на порядок. EP>>Это фантазии, ничем не обоснованные. EP>>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++. EP>>Вот конкретный пример (первые минут двадцать) dot>Посмотрел начало ролика. В общем там неплохо сказано — быстрое ядро относительно маленькое, зато обвязка — на порядок больше. Поэтому в целом и получается этот порядок.
Субъектива он там нагнал предостаточно (ЕМНИП было даже что-то типа "для нормального C++ кода, нужны те кто ковыряется внутри кода GCC").
Давай обсуждать объективные вещи.
dot>И, кстати, я заметил, что java-specific там практически ничего не было. Основной упор именно на то, что надо понимать как работает железо, а какой язык — не важно, техники отличаются деталями реализации, принцип же тот же.
Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.
dot>А. Да. Не так посмотрел, там оказывается специализации под разные стратегии. dot>В общем да. Да, на плюсах можно делать то же, что и в Яве. Ведь Ява на плюсах написана. Но из-за арифметики указателей и прочего нормальный gc сделать всё равно не выйдет, только всякие ref counting и прочее.
Я делал библиотечный копирующий GC for fun — простой вариант с одним поколением уместился в несколько сотен строк. Естественно есть ограничения, но тем не менее.
AFAIR, в Mozzila используют библиотечный GC в местах interop'а с JS.
Здравствуйте, ·, Вы писали:
I>>·>gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки. I>>Самое страшное — твою софтину для биржи на джаве никто не купит. Отсюда ясно, что часть софта в принципе никто даже не станет пытаться писать на джаве. ·>Расскажи это как миниимум упомянутым dxFeed и LMAX.
Есть куча проектов, которые загнулись из за того, что так и не смогли сбороть этот GC. Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.
Цитата из стандарта: "shared_ptr implements semantics of shared ownership" 
