Здравствуйте, Gaperton, Вы писали:
G>Таблицы предсказания не будут большой проблемой, так как это реально важно в циклах. К тому же, таблицы сейчас реально большие — там сотни элементов точно, может быть даже тысяча. Предсказатель сейчас умеют делать очень хороший — у МИПСов которые 64 процент успешных предсказаний более 90%, что говорить о Core Duo.
У P4 был что-то около 99% процент успешных предсказаний на некоторых реальных программах. Еще шутки были, что P5 будет предсказывать результат программы еще до ее запуска.
Проблема в косвенном вызове может быть, если код не окажется в кэше, ну и длинные вызовы тоже более медленны. А еще проблемы с регистрами — в случае с inline'ингом компилятор может оптимизировать распределение для всего блока в целом.
Так что inline еще очень рано со счетов списывать.
G>Ну, оптимальную кодогенерацию, такую ацкую, как в IC++, с учетом параметров конвейра проца, особо не предрасчитаешь. Например , оптимальные алгоритмы распределения регистров сами по себе довольно тормозные. А преварительная компиляция — это уже не совсем JIT.
Там именно предрассчет карт покрытия регистрами, раскрутки циклов и прочих хинтов хотят делать. Пока все еще на исследовательском этапе, но уже что-то интересное проявляется.
C>>Еще нужно учесть фичи типа обязательной проверки границы в массивах в Java, отсутствие указателей и т.п.
G>Верно, на этом, мне кажется, во многом и получается просос раза в два.
Угу. Но эти же проблемы будут и у безопасного нативного языка.
C>> В Java 7 это частично пофиксили — оно умеет прекомпилировать системные файлы и сохранять их в виде кэшированого исполняемого кода. Поэтому в бэтах JDK7 приложения реально "на глаз" начали запускаться как нативные.
G>Прекомпиляция — это ведь опять не JIT, да?
Это помощь JITу — оно потом может совершенно стандартным образом в runtime'е перекомпилироваться.
C>>Как создатель видеочата с DIVX компрессией на Java могу сказать, что больше всего проблем было с GC. Скорость вообще проблемой не была.
G>Скорость, значит, была достаточной для твоих нужд.
Да, согласен.
C>>Ну и ИЛ-2 работал так вполне прилично, когда еще был на Java написан.
G>Прилично, но по показаниям свидетеля переписывание дало таки ускорение в два раза, нет?
Ну он точно его не измерял. Можно попробовать скачать ИЛ-2 и проверить
C>>Инкрементальные GC — это фигня. Они есть ВЕЗДЕ, даже JVM можно настроить, чтобы использовался только трехцветный mark&sweep. Проблема с ними в том, что мутатор (т.е. работающая программа) на Java может заполнять кучу намного быстрее, чем ее будет собирать mark&sweep. В результате приложение может вдруг получать OutOfMemory. Не веришь — возьми сложное приложение на Java и поставь только инкрементальный mark&sweep. Потом наблюдай спецэффекты.
G>Приведи пожалуйста ссылку, подтверждающую отсутствие проблем с soft-realtime в любой JVM. Это следует из твоего текста.
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.%20The%20Concurrent%20Low%20Pause%20Collector%7Coutline — оно не оптимизировано на ПОЛНЫЙ realtime и имеет небольшие фиксированые паузы. Однако, это уже чистая деталь реализации — там используется как раз конкуррентный mark&sweep.
C>>В Erlang'е все хорошо из-за того, что объекты иммутабельны — там можно выполнять упрощенный вариант трехцветного mark&sweep.
G>В Эрланге применяется не mark&sweep, а stop© с двумя поколениями. Там нет проблем ни с переполнениями, ни с прерываниями.
AFAIR, их там несколько. У них изначально при передаче сообщения копировались, и отдельные кучи собирались mark&sweep'ом. Чуть позже сообщения копироваться перестали и стали (вынужденно) использовать систему с поколениями.
C>>Это нужен просто НОРМАЛЬНЫЙ GC, а не realtime.
G>Там и нормального нет. А real-time там сделать в условиях ограниченной памяти сделать просто низя.
Ну так причем тогда GC?
C>>Да нифига это не проблема! Это решается простейшим трехцветным GC (tri-color GC, tri-color mark&sweep), корректность работы которого была доказана Дейкстрой (AFAIR) в качестве примера доказательства параллельных алгоритмов. Год точно не вспомню, но точно раньше 80-х, так как я лично держал в руках вариант Схемы начала 80-х годов с таким сборщиком.
G>Хорошо, я сам поищу эти материалы еще раз, и отпишу сюда.
http://www.memorymanagement.org/glossary/t.html#tri-color.marking
Historical note: "Tri-color marking" is the term used to describe an algorithm developed in 1975 by E. W. Dijkstra and others, as an exercise in proving cooperating programs correct. They chose as their problem a parallel garbage collector, with the intent of illustrating cooperating sequential processes with a large shared data space but minimal exclusion and synchronization constraints.
C>>Так что лучше и меня иногда послушай
G>С удовольствием слушаю, я на проводе.
Алло, алло! Кто там?
G>Более-менее нормально, если не считать, что до этого у них задержка достигала десятки секунд на серверах с большим объемом памяти, что было ни разу не нормально, и они задницу в кровь порвали, чтоб до полсекунды гарантии довести. Эту ссылку я также постараюсь найти.
Так можешь не искать, у нас задержка примерно в две минуты на сервере с 16Гб хипом после тюнингов. Что еще не так плохо, кстати. Нам это не так важно, так как неотзывчивый сервер у нас просто из кластера блокируется — Oracle Coherence рулит.
C>>Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия.
G>Плисуевину для GC и к Erlang/OTP можно добавить, я думаю, это будет не слишком дорого. Тока не нужно пока.
Erlang'у оно пока будет даже вредно — быстрый GC ему просто по причине интерпретируемости нафиг не нужен. Вот когда добавят сильную типизацию и JIT — вот тогда будет веселее
