[Moscow.pm] Запросы без ответа

[Dmitry Smal]

Ну шикарный вброс сделали :)
И даже убедили нас, промышленная VM с JIT и профайлером - круто.
А что с обратной стороной медали - на каких языках для это машины можно 
писать?
Много людей разрабатывает масштабные проекты на Jython или Jruby (что бы 
не просто скриптинг прикрутить) ?

<-- тут требуется сокрушительный ответ со стороны jvm фагов -->

Так что JVM - это скорее всего еще и язык Java.
Когда я ушел с Java (1.5 тогда была) у нее было две проблемы (на мой 
взгляд):

1) Разработка приносила боль. Если ты не идус конечно :)

2) Java - это быыыстро! Поэтому никто не за толщиной и сложностью софта 
никто особо не следил.
     В результате сферический Java-софт-в-вакуме - это неподъемный 
монстр, котору нужно тонным памяти и ядер.
     Да вот для примера наша Jira в конторе на 3000 чел, ну пускай в ней 
100000 тасков.
     Пускай я каждый сотрудник делает 100 запросов в день ~ итого 10 
QPS. Это блин такой маааленький сайтик.
     Так почему страницы генерятся по 5-10с?
     Вы думаете JIT и профилировщик спасут нас?

On 04/20/2014 03:09 PM, Daniel Podolsky wrote:
> Я отвечу всем сразу, хорошо?
>
> 1) Threads
>
> 1.1) Треды сегодня - способ утилизировать ресурсы многоядерного
> процессора. Хорошие треды позволяют утилизировать и ресурсы
> многопроцессорной системы. Программеры, которые хорошо умеют это
> делать без тредов, на рынке широко не представлены.
>
> 1.2) Треды должны обеспечивать легкую межпоточную коммуникацию. В этом
> смысле в перле тредов нет. prefork и прочие многопроцессные модели
> требуют привлечение для межпоточной коммуникации SYSV IPC, который
> убог, с одной стороны, и избыточно сложен с другой.
>
> 2) JIT
>
> 2.1) При прочих равных JIT реально повышает производительность.
> Соответственно, современная VM должна его иметь. С чем тут спорить -
> не понимаю.
>
> 2.2) Если JIT нет - работу по выявлению узких мест и их переписыванию
> на уровень пониже приходится делать человеку. Именно так JIT связан с
> удешевлением разработки.
>
> 2.3) JIT способен производить оптимизацию, которую человеку никогда не
> осилить. Например, он может определить, что в 99% случаев некий цикл
> завершается за три итерации, и развернуть его в плоский код.
>
> 3) Sampling Profiler
>
> 3.1) Семплирующий профайлер позволяет изучать прямо сейчас тормозящий
> боевой код. Другого способа делать это задешево я не знаю. А вы?
>
> 3.1.1) Пока вы разрабатываете - семплирующий профайлер вам не нужен. А
> вот когда у вас появляется потребность в дебаге кода, который тормозит
> только на боевом трафике, и то не всегда - вот тогда вы начинаете
> искать средства. Проблема программеров в том, что им редко приходится
> иметь дело с эксплуатацией.
>
> 3.2) VM  перла не предоставляет доступа к перловому стеку вызовов.
> Поэтому системного уровня профайлер оказывается бесполезен.
>
> 4) Язык  perl мне нравится. Больше других, наверное. Но!
>
> 4.1) С точки зрения эксплуатации perl - не язык, а его VM. Со всеми вытекающими.
>
> 4.2) perl - это CPAN. А CPAN завязан на особенности реализации так
> плотно, что переписать язык на современную VM нереально. Вон, есть V8.
> Был бы perl под V8 - я бы только им и пользовался для всего. Но - нет,
> и не будет.