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

Vladimir Timofeev vovkasm на gmail.com
Сб Апр 19 12:01:38 PDT 2014


2014-04-18 20:49 GMT+04:00 Daniel Podolsky <onokonem на gmail.com>:
> 2014-04-18 18:10 GMT+04:00 Natalya Savenkova <name2rnd на gmail.com>:
>> Можно, пожалуйста, примеров таких инструментов? (это я на полном серьезе,
>> есличо)
> Треды, jit, семплирующий профайлер.
>
> Это то, что нужно каждый день, и чего в перле нет и не будет никогда -
> виртуальную машину его уже никто не починит.

Нет и не будет, истинная правда ) Perl это язык а не инструменты «вокруг».

Треды
Это можно отдельной темой вынести. Кратко, треды в Perl есть. Да, в
jvm треды легче, большая часть pthreads реализаций легче, но это не
значит, что тредов в реализации Perl нет. К примеру Padre написан с
использованием тредов, там это оправданно. Некоторые реализации
модулей используют pthreads под капотом (IO::AIO), никто не
ограничивает программиста.
Треды для серверных высоконагруженных задач обладают рядом преимуществ
и рядом недостатков. Они только кажутся легкими в использовании (вот
если заглянуть в лог работающей JIRA, можно много интересного
увидеть). Или в Android, к примеру, вообще постарались изолировать всё
тредовое хозяйство подальше от программиста в виде Activity, ох не
зря.
Но таки их можно использовать и в Perl.

JIT
Он не спасает от говнокода и не решает за программиста проблемы
производительности и знания особенностей архитектуры. Можно обмануть
компилятор, можно интерпретатор, можно и jit. Это кажется, что сейчас
мы включим jit и все будет мега-быстро - не будет. Напишется ещё пол
мегабайта кода и опять будет медленно. Что в jvm, что в .net, что в
perl. Более того, после утыкания в производительность с jit,
переписать на JNI будет уже сложнее, т.к. придется учить и C и
алгоритмы и оптимизировать и рефакторить код одновременно. На Perl, к
примеру, этот процесс размажется во времени и не будет скачкообразным.
Т.е. сперва напишется модуль на XS, потом ещё модуль, программисты
научатся делать C + XS, потом начнутся оптимизации и рефакторинг.

Профайлер.
Ну тут просто всё есть. Зачем семплирующий, если можно на живой
системе NYTProf юзать? Ну ладно, мне иногда надо было понять, что в
системе в целом происходит (но это уже не про Perl), так пожалуйста
prof(Linux), pmc(FreeBSD), что ещё не хватает? Ну DTrace если хочется
выборочно по всей системе.

Это все я не ктому, что Perl круче чем что-то. Не лучше, но и не хуже.
Я бы хотел видеть реализацию перла совсем другой внутри - со стройной
системой коллбэков и типов данных (вместо кучи ifов связанных с магией
и раскиданных по коду), с быстрой интеграцией с нативным кодом, с jit,
с быстрыми вызовами методов, с более строгим синтаксисом поддающимся
парсингу и анализу, с более продуманными библиотеками и т.п. Но это не
значит, что на нем невозможно писать высоконагруженные проекты. На нем
написаны сервисы которые держат такую нагрузку, что для
java-приложений или .net пришлось бы поставить раз в 5 больше
серверов.

-- 
Vladimir Timofeev <vovkasm на gmail.com>


Подробная информация о списке рассылки Moscow-pm