Как стать автором
Обновить

Комментарии 11

Язык интерпретируемый, поэтому не очень быстрый. Если ваш код работает медленно, конечно есть возможность скомпилировать все в байт-код перед выполнением, что несколько ускоряет выполнение, но все же не так быстро как бинарный код. Но, насколько я понял, в своей предметной области у него просто нет конкурентов.
Технически, основной конкурент R как среды анализа данных (не считая упомянутого Python) — matlab. В нем также имеется большое количество как готовых toolbox'ов, так и написанных разными лабораториями пакетов (число которых постоянно пополняется).

С одной стороны, у R активность сообщества на порядок выше, что дает огромный выбор пакетов с методами на любой вкус и цвет. С другой стороны, matlab это де-факто стандартная среда для анализа, закупаемая компаниями для своих сотрудников (несмотря на конские цены). Начальство, в том числе начальство университетов и исследовательских центров, как правило не парится и берет то, что хорошо разрекламировано.

Однако, если 5 лет назад лидерство матлаба было неоспоримо, сейчас популярность обоих сред находится на сопоставимых уровнях. И пусть победит наилучший, кто знает какой будет расклад через 5 лет. Пользоваться то нам :)
Я перешел с Matlab на R, и основными причинами как раз и были цена и проприетарность.
Можно еще вспомнить Octave, который вполне себе открытый, хоть и не совсем матлаб по многим параметрам. А вообще Python + Scipy + Pandas очень неплохо заруливают, причем многие вещи уже из R туда перекочевали и работают, мягко говоря, ничуть не хуже.
По поводу быстродействия: медленный ведь только сам интерпретатор, а пакеты-то пишут на C++/Fortran. Значит, самые ресурсоёмкие операции реализованы более-менее оптимально. Так ли важны несколько лишних секунд, потраченных на интерпретацию, если больше всего ресурсов надо потратить на непосредственно вычисления? Хотелось бы узнать ваше мнение на этот счет.
Вы правы: пакеты, как правило, пишут на С/C++, Fortran и даже Java. И огромное их количество написано на самом R. Но, независимо от того, на чем написан пакет, распараллеливание ресурсоемких операций часто ведет к заметному выигрышу по времени. Например, если (опять таки) рассматривать несколько десятков нейронных сетей с различными гиперпараметрами, да еще и датасет взять побъемнее, то разница по времени при их обучении последовательно и параллельно будет исчисляться далеко не секундами, несмотря на то, что пакет написан на языке пошустрее. В данном случае интерпретатор — всего лишь удобное средство управления уже скомпилированными пакетами, которые, собственно, и выполняют основные вычисления.
Так я же не говорю, что распараллеливать не нужно — конечно, нужно! Я имел в виду замечание о неторопливости R в заключении.
Если в таком ключе рассматривать, то разница в несколько секунд, конечно, роли не играет.
В целом, статья неплохая как очень базовое введение.

Хорошо было бы добавить, что R на Windows (не считая проприетарного Revolution) не поддерживает наиболее эффективный способ распараллеливания большинства задач — mutli-core с shared memory. Т.е. на маке и, насколько я знаю, на *nix — пожалуйста, а вот на Windows — нет.

В вашем случае, взаимодействие идет через сокеты, что для простых задач гораздо менее эффективно.

На какой платформе, кстати, запускали?
Debian 7.3.0 amd64
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории