СС
меня подобное сильно ломало) но уже вник и понял что к чему. на самом деле не так сложно как кажется)
juxt(->>
darts-numbers
(partition 3 1)
(map (juxt
(partial string/join "-")
(partial apply +)))
(into {})
(apply max-key val))
Size: a a a
2020 January 17
ST
подходящий случай для
ST
Сергей Суржик
(->>
darts-numbers
(partition 3 1)
(map #([(clojure.string/join "-" %) (apply + %)]))
(apply max-key second))
где я не прав?
Wrong number of args (0) passed to: clojure.lang.PersistentVector
а можно и без всяких мапов
(->>
darts-numbers
(partition 3 1)
(sort-by (partial apply +) >)
first)
=> (19 7 16)
ST
а можно и без всяких мапов
(->>
darts-numbers
(partition 3 1)
(sort-by (partial apply +) >)
first)
=> (19 7 16)
странно, но вариант с сортировкой — медленнее
T
странно, но вариант с сортировкой — медленнее
Ну поиск максимума всегда медленнее сортировки
T
подходящий случай для
juxt(->>
darts-numbers
(partition 3 1)
(map (juxt
(partial string/join "-")
(partial apply +)))
(into {})
(apply max-key val))
Да. Я написал вариант с джакст но что-то меня длина партиалов на экране телеофона отпугнула и я не стал его постить)))
ST
Ну поиск максимума всегда медленнее сортировки
получилось быстрее
что, впрочем, логично
что, впрочем, логично
ST
Да. Я написал вариант с джакст но что-то меня длина партиалов на экране телеофона отпугнула и я не стал его постить)))
ну, с #(%) было бы короче, но меня пугают эти криптосимволы 😊
T
ну, с #(%) было бы короче, но меня пугают эти криптосимволы 😊
Согласен, меня тоже
T
Ну поиск максимума всегда медленнее сортировки
Ой, тьфу, наоборот. Оговорился
DF
ну вот на меня сегодня ещё раз нашло, и я ещё побенчмарчил https://github.com/serioga/clojure-benhcmarks/blob/master/src/clojure_benchmarks/long_adder.clj
как бы базовые выводы такие:
- если у тебя данные для суммирования имеются на руках сразу, то параллельность имеет слишком большие накладные расходы
- если данные поступают медленно, то atom отлично справится с регистрацией поступающих данных
- если параллельность нужна, то atom почти так же хорош, как и LongAdder, при этом он не ограничен только суммированием и к его изменениям можно подписаться
как бы базовые выводы такие:
- если у тебя данные для суммирования имеются на руках сразу, то параллельность имеет слишком большие накладные расходы
- если данные поступают медленно, то atom отлично справится с регистрацией поступающих данных
- если параллельность нужна, то atom почти так же хорош, как и LongAdder, при этом он не ограничен только суммированием и к его изменениям можно подписаться
Привет! Все руки не дойдут до эксперимента. Вот тут я немного не понял, сложить 1000 цифр не очень показательно :) моя беда была сложить десятки миллионов цифр
'''; LongAdder, no parallelism
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))]
(dotimes [_ parallelism]
(.add acc adding))
(.sum acc)))'''
'''; LongAdder, no parallelism
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))]
(dotimes [_ parallelism]
(.add acc adding))
(.sum acc)))'''
DF
Просто для примера я складывал единицы
AK
И как оно?
ST
Dima Fomin
Привет! Все руки не дойдут до эксперимента. Вот тут я немного не понял, сложить 1000 цифр не очень показательно :) моя беда была сложить десятки миллионов цифр
'''; LongAdder, no parallelism
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))]
(dotimes [_ parallelism]
(.add acc adding))
(.sum acc)))'''
'''; LongAdder, no parallelism
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))]
(dotimes [_ parallelism]
(.add acc adding))
(.sum acc)))'''
но твой последний вариант всё равно свёлся к 1000 складываний через Adder, а внутренний цикл был просто синтетический, не имеющий отношения к складыванию разных чисел откуда-то
ST
Dima Fomin
Просто для примера я складывал единицы
поменяй
parallelism на 1e8 и смотриST
Dima Fomin
Привет! Все руки не дойдут до эксперимента. Вот тут я немного не понял, сложить 1000 цифр не очень показательно :) моя беда была сложить десятки миллионов цифр
'''; LongAdder, no parallelism
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))]
(dotimes [_ parallelism]
(.add acc adding))
(.sum acc)))'''
'''; LongAdder, no parallelism
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))]
(dotimes [_ parallelism]
(.add acc adding))
(.sum acc)))'''
Вопрос, откуда и как будут браться эти цифры. В случае с синтетическим
cbu-bound-sum ты можешь выиграть немного времени. Но когда в дело вступает работа с коллекциями размером десятки миллионов, то тормозить начинает в других местах. Поэтому я тебя и спрашивал, откуда и как поступают данные для обработки.(defn cbu-bound-sum
[n]
(loop [i (int 0)
n (int n)]
(if (pos? n)
(recur (unchecked-inc i) (unchecked-dec n))
i)))
=> #'dev.probe/cbu-bound-sum
(criterium/quick-bench
(loop [i (int 0)
n (int 1000)]
(if (pos? n)
(recur (unchecked-add i (cbu-bound-sum 100000)) (unchecked-dec n))
i)))
Evaluation count : 24 in 6 samples of 4 calls.
Execution time mean : 29,806815 ms
Execution time std-deviation : 835,762971 µs
Execution time lower quantile : 29,107323 ms ( 2,5%)
Execution time upper quantile : 31,076411 ms (97,5%)
Overhead used : 1,758432 ns
=> nil
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))]
(dotimes [_ parallelism]
(.add acc (cbu-bound-sum adding)))
(.sum acc)))
Evaluation count : 12 in 6 samples of 2 calls.
Execution time mean : 60,477632 ms
Execution time std-deviation : 554,677132 µs
Execution time lower quantile : 60,097199 ms ( 2,5%)
Execution time upper quantile : 61,249817 ms (97,5%)
Overhead used : 1,758432 ns
=> nil
(criterium/quick-bench
(let [acc (java.util.concurrent.atomic.LongAdder.)
limit 1e8
parallelism 1000
adding (long (/ limit parallelism))
done-signal (java.util.concurrent.CountDownLatch. parallelism)]
(dotimes [_ parallelism]
(async/go
(.add acc (cbu-bound-sum adding))
(.countDown done-signal)
:done))
(.await done-signal)
(.sum acc)))
Evaluation count : 84 in 6 samples of 14 calls.
Execution time mean : 7,178148 ms
Execution time std-deviation : 125,635914 µs
Execution time lower quantile : 7,092377 ms ( 2,5%)
Execution time upper quantile : 7,394825 ms (97,5%)
Overhead used : 1,758432 ns
Found 1 outliers in 6 samples (16,6667 %)
low-severe 1 (16,6667 %)
Variance from outliers : 13,8889 % Variance is moderately inflated by outliers
=> nil
DF
но твой последний вариант всё равно свёлся к 1000 складываний через Adder, а внутренний цикл был просто синтетический, не имеющий отношения к складыванию разных чисел откуда-то
А, ну да, получается так. Ну подразумевалось, что внутри треда будет последовательный расчет нужных для складывания чисел
DF
Скажем мап по группе контрактов с вычислением их VaR
ST
Dima Fomin
Скажем мап по группе контрактов с вычислением их VaR