Улучшения скорости для Perl chameneos-redux в игре «Тесты компьютерного языка»

Question

Когда-нибудь смотрели на игру по тестированию компьютерных языков (ранее известную как «Великий языковой отбор»)?

В настоящее время у Perl довольно здоровая конкуренция. Мне также кажется, что, возможно, в некоторых местах результаты Perl могут быть улучшены. Самый большой из них сейчас находится в скрипте chameneos-redux - версия Perl работает хуже всего на любом языке: в 1626 раз медленнее, чем базовое решение C!

Есть некоторые ограничения на то, как программы могут создаваться и оптимизироваться, и есть интерпретируемое наказание Perl за время выполнения, но 1,626 раз? Должно быть что-то, что может сократить время выполнения этой программы.

Взглянув на исходный код и вызов , как можно улучшить скорость?

Answer 1

Я запускал исходный код через профилировщик Devel::SmallProf. Вывод профиля слишком многословен, чтобы публиковать здесь, но вы можете увидеть результаты самостоятельно, используя $ perl -d:SmallProf chameneos.pl 10000 (не нужно запускать его для 6000000 собраний, если вы действительно не хотите!) Для получения дополнительной информации см. perlperf на некоторых инструментах профилирования в Perl.

Оказывается, что использование семафоров является основным узким местом. Львиная доля общего процессорного времени тратится на проверку, заблокирован ли семафор или нет. Хотя у меня не было достаточно времени, чтобы понять, почему в исходном коде используются семафоры, возможно, вы можете обойтись без необходимости использования семафоров. Это, вероятно, ваш лучший шанс улучшить производительность кода.

Answer 2

У меня есть версия , основанная на другой версии от Джесси Милликяна, которая, я думаю, никогда не была опубликована.

Я думаю, что он может работать в ~ 7 раз быстрее, чем текущая запись, и использует все стандартные модули. Я не уверен, что он действительно соответствует всем правилам.

Я попробовал на нем модуль forks, но думаю, что он немного замедляется.

Answer 3

Как писал Зайд, Thread :: Semaphore довольно медленный. Одной из оптимизаций может быть использование неявных блокировок для общих переменных вместо них. Это должно быть быстрее, хотя я подозреваю, что это не будет намного быстрее.

В общем, реализация многопотоковой реализации Perl не подходит для любого вида использования, который требует много межпоточного взаимодействия. Он очень подходит для задач с малой связью (поскольку в отличие от потоков CPython и потоков CRuby они на самом деле имеют приоритет).

Возможно, можно улучшить эту ситуацию, нам нужны лучшие примитивы.

Answer 4

Кто-нибудь пробовал s / threads / вилки / на записи Perl? Или Coro / Coro :: MP , хотя последний, вероятно, вызовет предложение интересных альтернативных реализаций .