разы (хотя иногда и не в разы, но медленнее) медленнее обычного цикла?
Apply1(slice,
Concurrent(
Compose2(
Transform(func(in int64) int64 {
return in + 1
}),
Transform(func(in int64) int64 {
return in - 1
}),
),
),
)
Я бы не делал, но не из-за скорости. Это просто жуткий API в Go
Так по другому и не сделать, пока не появится generic method
Хотя вру – делал, давно, когда не понимал, что это жуть 🙂
В Go это делается прямым императивным кодом – циклами и так далее
В принципе, у меня те же выводы :)
Compose2 - конкурентная работа 2 ассоциативных функций? Медленно насколько? С чем сравнивали?
5 проходов по массиву из 100000, где каждый раз +1 и потом в след проходе -1 cpu: AMD Ryzen 5 5600H with Radeon Graphics BenchmarkRawRange-12 13060 938500 ns/op 802818 B/op 1 allocs/op BenchmarkTransform-12 5440 2399847 ns/op 802817 B/op 1 allocs/op BenchmarkTransformConcurrent-12 21343 553147 ns/op 1607035 B/op 22 allocs/op
Посмотрел. Там простор для оптимизаций)
Ухты, и с чего начать?
Ну.. я бы обязательно попробовал блокировки на мьютексах (как эталон, который скорее всего будет самый медленный). Далее алгоритм на CAS - вот тут надо подумать сначала, сразу же не скажешь. Еще было бы классно делать операции inplace если типы совпадают.
С чего начать, думание над алгоритмом с использованием cas? И не выльется ли это, в какой нибудь lock-free pool? (т.к. пока у меня идея, что нужна запись/чтение n элементов, в любом порядке)
Не простой вопрос. У меня уже вечер, расслабиться бы)
Ну так этот вопрос не срочный. В любом случае, спасибо за уже сказанное
В общем подумал немного, там можно проще все сделать. Вот примерный код
Обсуждают сегодня