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

C>>Заметь слово first — они не исключают статических языков.
WH>Угу. И LLVM не исключае safe языков. Вот только из-за этих уступок ОЧЕНЬ СИЛЬНО усложняется и ослабляется оптимизатор, а валидатор кода в большинстве случаев вобще курит.
Safe-языки в LLVM делаются не просто, а очень просто. Достаточно запретить использование инструкции каста к указателям и явного удаления памяти.

Кстати, с точки зрения оптимизатора LLVM, safe и unsafe различаются очень немногим — почти что только более богатыми возможностями alias analysis в safe-языках.

Верификатор — это уже отдельный разговор.

C>>На Питоне очень удобно скрипты писать, так что не надо.
WH>На один экран кода и чтобы управляли чемто намного болие тяжолым. Иначе в морг.
Ну да, у меня таких скриптов полно — мелкие задачи замечательно оптимизируются. Еще для build-системы тоже очень неплохо подходит (использую Waf).

C>>А на С++ для девайсов тоже очень все неплохо пишется.
WH>Можно лучше.
Можно. Но пока не сделано.

C>>Так JIT в .NET тоже не помогает
WH>Ибо какойто 3.1415(скорей всего маркетойд) принял решение драть ВМ с жабы.
WH>Если бы думали головой, а не лозунгом "догнать и перегнать сан" то все можно былобы сделать много лучше.
Не получится. Без перекомпиляции налету с возможностью деоптимизации (ключевой пункт) многие возможности оптимизации просто невозможны.

Для банального устранения виртуальности нужно уметь делать деоптимизацию, если вдруг у нас динамически загружается сборка и оптимизация проваливается.

C>>Беты 1.7 работают в некоторых моих тестах ОЧЕНЬ быстро.
WH>Быстрее чем Intel C++? На тестах которые не получают преимущества от использования ГЦ?
На чисто числодробительных задачах — не проверял. Но тут, собственно, ни один JIT не поможет — компилировать одну сборку полчаса при загрузке будет недопустимо. А вот HotSpot как может зарулить — просто запускаем движок оптимизации на соседнем ядре (Intel аннонсировал 8-ядерный процессоры, выполняющие по 16 параллельных тредов) и пусть себе там думает.