RedisSharding - SCAN command added

В Standard ML версию RedisSharding (собирается при помощи MLton and PolyML) (https://github.com/kni/redis-sharding-sml) добавил поддержку команды SCAN.

При этом есть нюанс: курсор - это целое произвольной точности.
То есть, если клиенты оперируют с курсором как со строкой или числом произвольной точности, то они будут работать с командой SCAN, иначе нет.

From Haskell to Standard ML

Фух... Полностью избавились от Haskell на серверах.

Причина: свойства MIO (Threaded RTS) избыточны для нас и сам MIO настолько сложен, что в настоящий момент не может быть без ошибок. А обычный RTS медленный и использует устаревший системный вызов select.

Сопутствующий минус: кода стало в 2 раза больше,
но есть еще один плюс: скорость выросла 2 раза.

P.S. Про ошибку в MIO не скажу - это будет маркер.

Standard ML, Haskell parser benchmark

https://github.com/kni/sparcl

Redis protocol benchmark (seconds):

          String  Substring  Reader-String  Reader-Substring   Attoparsec
Haskell:          4.63                                         7.98
Mlton:    3.07    1.81       1.90           1.50
PolyML:   6.32    4.43       7.86           6.08

CSV benchmark (seconds):

          String  Substring  Reader-String  Reader-Substring   Attoparsec
Haskell:          7.85                                         14.41
Mlton:    6.91    5.61        3.51          3.10
PolyML:   9.31    9.29       10.56          9.14

P.S. Haskell ByteString - is Substring

But Substring has no apparent advantages over String in a real application (https://github.com/kni/redis-sharding-sml) :-)

От Haskell к Standard ML

Переписал сервер с Haskell на Standard ML (MLton и Poly/ML).

Кода стало больше, скорость стала выше. Быстрей не только MLton версия, но и Poly/ML. И это, несмотря на то, что у PolyML медленный FFI.

Кода в Standard ML версии больше чем в Haskell потому, что в Haskell используются "зеленые треды" и менеджер IO, а в Standard ML - "голый" kevent (epoll) и функции обратного вызова. Да и синтаксис компактней в Haskell, но в Standard ML "модульней".

В целом, хотя в Standard ML версии кода больше и используются функции обратного вызова, она не сильно сложней Haskell версии. Сложность какбы размазана равномерно. А в Haskell сложность скрывается за "простыми" вещами. Haskell требует больше знаний и имеет больше нюансов, когда копнеш глубже.

Если коротко, то в сравнении с Standard ML Haskell выигрывает в малом, но проигрывает в большом.

P.S.
Да, еще в GHC MIO есть баг, который лимитирует использование Haskell версии.

Hans Boehm's GC benchmark - не только для GC

Hans Boehm написал бенчмарк для GC (работа с Tree).
Это бенчмарк есть и в "NoFib: Haskell Benchmark Suite"
https://github.com/jyp/nofib/blob/master/gc/gc_bench/gc_bench.hs

Немного модифицировал его, чтобы была возможность задавать kStretchTreeDepth.
А также сделал порт на Standard ML (один в один).

Запускаем его с большим размером кучи, чтобы GC не срабатывал, то есть используем как Tree бенчмарк.

GHC version 7.8.3 (ghc -O2 -rtsopts ...)
> time ./gc_bench_haskell 24 16 500000 16 22 +RTS -H250M
13.961u 0.220s 0:14.47 97.9% 947+248k 1+0io 27pf+0w

Poly/ML 5.6
> time ./gc_bench_polyml -H250 24 16 500000 16 22
5.388u 0.389s 0:05.58 103.2% 551+200k 0+0io 0pf+0w

MLton 20130715
> time /net/bsd/gc_bench_mlton 24 16 500000 16 22
2.593u 0.000s 0:02.61 99.2% 212+181k 0+0io 3pf+0w

multiMLton
> time ./gc_bench_multiMLton 24 16 500000 16 22
2.855u 0.000s 0:02.89 98.6% 273+197k 0+0io 0pf+0w


Выходит, что Haskell быстр при работе с числами, векторами, строками, а работа со сложными структурами данных не его конек?

P.S.
На http://benchmarksgame.alioth.debian.org в binary-trees бенчмарке Haskell обгоняет OCaml. Но там Haskell работает параллельно на 4 ядрах, а OCaml на одном.

haskell2025.org

http://www.haskell2025.org/ - Standard ML Family GitHub Project :-)