Да, за этой техникой лежит очень интересная идея и она является хорошим вариантом для нагруженных IO приложений. Но Fiber это не абсолютный аналог и заменитель потоков, например, для тех же вычислений на нескольких ядрах, для чего они не предназначены и что делать не могут.
Доводилось на конференциях и встречах общаться со многими :) Многие действительно никогда их не использовали до тех самых встреч и конференций.
Ни в коем случае это не была попытка обидеть, а призвание к изучению новых вещей.
Хорошо, надо добавить пояснения к табличкам.
Надо смотреть в колонку «real» — действительное время исполнения кода. Параллельный тест jRuby (24.3) и так уже быстрее обоих тестов на MRI (25.7 и 26.9). Время в колонке total — это сумма времени работы обоих ядер, но большая часть работы происходила одновременно, в чем и выигрыш.
Опять же, в этих замерах главное — прирост производительности в случае с jRuby, и его отсутсвие в случае с MRI.
Спасибо за замечание :)
Допускаю, что на более длинной дистанции jRuby мог бы показать результат лучше из-за разогрева JVM и оптимизаций, но не это главное.
В этом примере я хотел сделать акцент на приросте производительности при использовании потоков. Соответственно, при большем количестве потоков и ядер jRuby стал бы выигрывать еще больше, когда MRI продолжал бы топтаться на месте независимо от железа. Это очень важно, учитывая тенденцию увеличения количетсва ядер, а не скорости каждого из них в отдельности.
Ни в коем случае это не была попытка обидеть, а призвание к изучению новых вещей.
Колонка real — это total elapsed time, о котором Вы говорите.
Надо смотреть в колонку «real» — действительное время исполнения кода. Параллельный тест jRuby (24.3) и так уже быстрее обоих тестов на MRI (25.7 и 26.9). Время в колонке total — это сумма времени работы обоих ядер, но большая часть работы происходила одновременно, в чем и выигрыш.
Опять же, в этих замерах главное — прирост производительности в случае с jRuby, и его отсутсвие в случае с MRI.
Допускаю, что на более длинной дистанции jRuby мог бы показать результат лучше из-за разогрева JVM и оптимизаций, но не это главное.
В этом примере я хотел сделать акцент на приросте производительности при использовании потоков. Соответственно, при большем количестве потоков и ядер jRuby стал бы выигрывать еще больше, когда MRI продолжал бы топтаться на месте независимо от железа. Это очень важно, учитывая тенденцию увеличения количетсва ядер, а не скорости каждого из них в отдельности.