Comments 11
P.S. Спасибо за ещё одну статью-мотивацию.
Я сознательно не стал писать такую формулировку.
Во всем нужен разумный подход. Иногда лучше сделать с применением цикла, пусть чуть медленнее по исполнению, но зато понятнее и проще, чем сознательно пытаться обойти цикл.Это очень хорошо видно, когда студенты обучаются основам программирования.
С учетом современного развития пакетов в R очень удобно пользоваться итераторами и функциональным подходом. Естественно, что предварительно необходимо их понять и научиться легкости владения.
Современную позицию про итераторы можно почитать у Hadley: "21. Iteration"
Для питона (и наверняка для R) особенно это хорошо видно на научных библиотеках типа numpy.
В этой статье, которая условно для новичков, хорошо было бы написать.
Можно и в конце этого пункта добавить типа «но ещё бОльшего ускорения вы можете добиться путём умного применения итераторов».
Как наживку для пытливых умов:)
И насчёт «понятнее и проще» тоже не соглашусь — код с map-функциями часто намного легче прочесть, и смысл сразу на поверхности, чем когда разбираешься в хитросплетениях циклов.
Текст не совсем для новичков, а для людей, программирование для которые не является основной профессией. С текущей скоростью развития ИТ средств иногда забываешь, что требуется оптимизация и как ее лучше проводить. И когда упираешься в стену по производительности, желательно иметь подсказку, что делать.
Эти рекомендации изначально были выработаны для студентов физиков и математиков, которые занимаются сложными расчетными задачами и не погружены глубоко в детали вычислительного механизма. Не одна дипломная работа была спасена путем катастрофической оптимизации вычислений (с нескольких лет до нескольких суток), причем эти подходы применялись и в C++, и в R, и в Mathematica, и Matlab. Да, красота и четкость немного страдали, но временнОй выйгрыш того стоил.
map\walk подходы очень хороши и компактны, но надо их принять и полюбить. По моему опыту, функциональное программирование не для всех органично.
Как я указал в тексте, это всего-лишь '"шпаргалка" для начала исследований по возможной оптимизации существующего кода.'
Но даже в такой простой повествовательной форме этот пост вызывает сильную неоднозначность у читающих. Я вот по оценкам статьи в целом вижу, что + и — идут в почти одинаковой пропорции. И это без каких-либо комментариев, видимо просто по первым абзацам.
Кстати, самое интересное, что тема для очередного поста появляется в ходе дискуссий и вопросов по предыдущим. Дискуссии идут как в комментариях, так по почте. Приходится доставать кусочки кода из различных задач, решавшихся ранее, и актуализировать подходы, в соответствии с состоянием R на текущий день.
Rcpp, который даже при минимальном уровне владения синтаксисом C++ позволяет в некоторых случаях в разы ускорить код.Это уже следующий шаг, выход за рамки R.
Новый термин — Tidyverse, который полезно взять на заметку.
Не далее как вчера применение parallel + hadleyverse позволило ускорить решение одной процессинговой задачки почти на порядок. Кода при этом стало существенно меньше.
Есть корпус из 32536 документов (один документ = предложение из 2-10 термов) и словарь термов (дата фрейм: 1-й столбец — какой терм брать, 2-й столбец — на какой заменить)
Размер словаря = 4005 термов (используется в качестве стеммера с учетом отраслевой специализации)
Общая цель задачи — классификация документов
Ранее тупым перебором словаря в цикле с отдачей каждой пары значений в регулярку (gsub) на замену слов корпуса уходило примерно 230 секунд (тупо загружалось одно ядро)
Благодаря советам автора распараллеливание на 4 ядра дало ускорение в 10 раз (т.е. до 23 секунд).
+ к этому в процессе переписки с Ильей переосмыслил некоторые подходы, на будущее теперь есть хороший инструментарий «турбонаддува» R за что автору большое спасибо.
Илья, спасибо большое.
P.S. Использовались следующие пакеты:
library(dplyr)
library(tidyr)
library(magrittr)
library(purrr)
library(stringr)
library(tibble)
library(iterators)
library(foreach)
library(doParallel)
Вам не хватает скорости R? Ищем скрытые резервы