Наконец-то добрался протестировать производительность Mio ("Scalable IO Manager"), который появился в GHC 7.8. Предыдущей менеджер при переключении в threaded режим существенно терял производительность.
Тестирование производилось, используя реальное приложения, написанное на Haskell: RedisShardnig (http://github.com/kni/redis-sharding-hs-strict). Оно собиралась при помощи команды:
ghc -threaded -feager-blackholing -rtsopts -O2 --make redis_sharding.hs
Результаты сравнения Mio и старого менеджера.
FreeBSD (мой ноутбук: Intel(R) Pentium(R) CPU P6200)
Linux (какой-то сервер c 8 ядерами)
А вот данные как изменяется производительность с ростом количество рабочих OS threaded (параметр запуска -N):
GHC 7.8.1 threaded, Linux, 8 ядер.
Как видим, с выходом нового менеджера ввода-вывода производительность не только перестала падать при переключении в threaded режим, а даже стала возрастать!
Тестирование производилось, используя реальное приложения, написанное на Haskell: RedisShardnig (http://github.com/kni/redis-sharding-hs-strict). Оно собиралась при помощи команды:
ghc -threaded -feager-blackholing -rtsopts -O2 --make redis_sharding.hs
Результаты сравнения Mio и старого менеджера.
FreeBSD (мой ноутбук: Intel(R) Pentium(R) CPU P6200)
Requests per second | | threaded ---------------------------- GHC 7.8.1 | 11560 | 12853 GHC 7.6.1 | 11210 | 7686
Linux (какой-то сервер c 8 ядерами)
Requests per second | | threaded ---------------------------- GHC 7.8.1 | 16393 | 17605 GHC 7.6.1 | 16583 | 9354
А вот данные как изменяется производительность с ростом количество рабочих OS threaded (параметр запуска -N):
GHC 7.8.1 threaded, Linux, 8 ядер.
... +RTS -N1 ( 4 OS threads) - 15873.02 requests per second ... +RTS -N2 ( 6 OS threads) - 28735.63 requests per second ... +RTS -N3 ( 8 OS threads) - 29411.77 requests per second ... +RTS -N4 (10 OS threads) - 26954.18 requests per second
Как видим, с выходом нового менеджера ввода-вывода производительность не только перестала падать при переключении в threaded режим, а даже стала возрастать!