Re[36]: Java vs C# vs C++ - Философия программирования

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

PM>> Почитайте на досуге как авторы LMAX героически боролись (и вроде бы продолжают бороться) с JVM — пытаясь выровнять данные по границе кэш-линии; как затюнинговать сборку мусора, чтобы система не замерзала в неподходящий момент (и перезапускать всё разв в сутки в конечном итоге)

PM>> Короче, сплошной <троллейбус из буханки хлеба.jpeg>
·>Собственно сейчас в моде Zing JVM, там задержки не более 10ms, в основном ~100us.
·>Писать такое на C++... неее... проще застрелиться.
·>А перезапуск нужен не для gc, а чтобы на диск состояние скинуть, ибо использовать классические СУБД — теоретически невозможно.

Задержка 10ms может быть неприемлемой в некоторых задачах, в том числе и в биржевых системах.

Состояние на диск постоянно скидывается в LMAX в отдельном потоке в файл журнала. И разработчики LMAX повоевали и здесь чтобы добиться предсказуемого результата. Ну и для сетевого I/O наверняка использовали какой-нибудь NIO.

Я почитал ваши сообщения в ветке. Ещё одна иллюстрация, что люди не из мира C++ продолжают верить в мифы 15-20 летней давности. Авторы LMAX скорее всего тоже подумали: "Писать такое на C++... неее... проще застрелиться" и взяли хорошо известный им и широко распространённый инструмент. Хорошо, что при этом они не застрелились

Часть кода, кстати, открыта: https://github.com/LMAX-Exchange/disruptor и выглядит на мой взгляд over engineering. Хотя, может для Java мира это нормально

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

_>Безусловно. А можно даже и без t4 просто голые sql строки вставить и опять же будет отличная скорость. Нюанс в том, что в обоих этих случаях синтаксис станет не как у linq. А вот sqlpp11 сохраняет такой синтаксис без потерь в скорости.

S>>Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.

_>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )
Еще раз без навигационных свойств снижает функциональность в разы. Поверь мне, так как знаю разницу.
По быстродействию. Самая распространенная задача это когда есть некий отчет, где пользователь может наложить до 6 и более условий.
Причем например для справочников эти условия могут быть как равны элементу либо входить в группу. Невыбранные параметры не участвуют в запросе.
Смыла в статическом запросе никакого нет. Кроме того поддержка разных баз, провайдеров итд
Но опять когда эта скорость нужна? Для клиента то он её просто незаметит. А например для Asp.Net то если сильнозагруженный сервер по 1000 запросов в секунду, то тогда стоит заморочится на скорость. Но таких задач ооочень мало.

Ну и поддержка БД в EF больше https://social.msdn.microsoft.com/Forums/ru-RU/16b09dc7-64ea-47b4-ba1c-a94499378355/ef6-more-than-one-factory?forum=adodotnetentityframework

Здравствуйте, 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, может вылезти:

const Obj obj = ...;
doSomethingWithImmutableObj(obj);
...
void *obj = &obj;
...
Obj *obj2 = (Obj *)obj2;
...
obj2.modify();

И нифига ненаверифицируешь.
И вообще, никакая это не верификация, а статический анализ.

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.

	От:	PM
	Дата:	07.10.15 18:30
	Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	07.10.15 20:31
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	07.10.15 20:47
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	07.10.15 21:06
	Оценка:

	От:	A13x
	Дата:	08.10.15 04:16
	Оценка:

От:	m.aksenov	http://maksenov.info/
Дата:	08.10.15 04:41
Оценка: