Ну шикарный вброс сделали :)
И даже убедили нас, промышленная 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 - я бы только им и пользовался для всего. Но - нет,
и не будет.
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
