Каждый раз при вызове функции вычисления синуса перебирать все файлы и отправлять?
Это можно сделать один раз, например заиспользовав статическую переменную. Чтобы не тормозить приложение, можно делать это в отдельном треде, корутине, горутине, и т.д. (в зависимости от возможностей языка).
С довольно большой вероятностью у вас просто не будет прав на какие-то из этих действий, оно либо упадет, либо в системный лог запишется куча предупреждений.
Если приложение смогло взять значения секретов, то почему вредоносный код в том же приложении не сможет? Да, некоторые файлы не удастся прочитать, но нужные наверняка будут прочитаны с успехом. А логи врядли помогут, так как скорее всего приложение не будет логгировать попытку прочитать какой-то файл. Теоретически так можно защитится, но давайте посмотрим с практической стороны.
Однако, если вы запущены в serverless-окружении - то ничего вы и не получите ни из каких файлов.
А откуда по вашему приложение возьмет секреты (env переменные, файлы, аргументы запуска)? Ну да ладно, допустим ни один из этих вариантов не подошел. Но вот вариант с отправкой того де coredump вполне может оказаться рабочим. Не знаю, почему вы его проигнорировали.
Вы в канал будете писать итоговую сумму для каждого worker, это выйдет намного быстрее, так как вместо countTasks вызовов atomic.*, у вас будет countWorkers вызовов Mutex.Lock/Unlock (то есть намного меньше).
Результат стабильно воспроизводится (первый бенчмарк всегда работает быстрее), причем даже пытался увеличить в 10 раз количество задач. Похоже что компьютер у меня устает, но все же результат странный.
Так-то и быструю сортировку можно написать в 10-20 строчек, но так обычно не делают. А все потому, что на самом деле эффективный алгоритм - это далеко не «наколеночное» решение.
В случае с FFT, то тут целый простор для улучшений и реализаций, начиная от поддержки произвольных длин, заканчивая локальными оптимизациями, поддержкой команд SSE, AVX и т.д. Скорее всего в реальном проекте (не лабораторной работе для студентов) вы не захотите тратить время на это все, а подключите тот же FFTW.
Разница сортировки и FFT в том, что сортировка уже встроена в поставляемую стандартную библиотеку, а FFT нет. Но это не повод для написания собственных реализаций. Конечно, все зависит от ситуации.
type mapImpl[A, B] struct {
s Stream[A]
v A
fn func(A) B
}
func (m *mapImpl[A, B]) Next() bool {
return s.Next()
}
func (m *mapImpl[A, B]) Scan(v *B) {
m.s.Scan(&m.v)
*v = m.fn(m.v)
}
// ...
Увеличилась ли тут сложность? Вроде нет.
Есть простор для оптимизации? Да.
Привычно ли использование? Да, аналогично тому же sql.Rows, к примеру.
Вообще ничего против не имею вашей библиотеки. Но ошибок все-таки не хватает (того же Err()). Для продакшена такую библиотеку неудобно будет использовать, так как придётся поверх этого всего городить велосипед, чтобы ошибки поддержать (а это нормально, например когда нам пользователь что-то в сокет кладёт или ещё что).
Вообще это все сугубо мое личное мнение и я могу быть где-то не прав. Но немножко грустно, что с появлением generic-ов частенько мелькают библиотеки с как минимум сотнями звёздочек, реализующие всякие Result[T, E], Optional[T] и type Map[K, V] map[K]V. Неужели стандартные возможности языка не позволяют этого? Или у нас путь как с npm пакетами (плохое сравнение, но все же) - проще строчку в go.mod, чем одну/две в *.go
Не знаю откуда вы это взяли и от кого, но заявление странное. Наверняка кто-то и пользуется, но такое можно сказать практически про любой сервис в любой компании.
Изменять в рантайме размеры может и не нужно, но выделять, к примеру, матрицу размера, определённого в compile time, выглядит не всегда разумно. Вообще, как мне кажется, не нужно делать преждевременные оптимизации в ущерб читаемости кода, так как может оказаться, что проседания производительности не в лишних аллокациях. Да не спорю, круто писать сразу оптимальный во всех смыслах код, но кажется, что это может оказаться сильно дороже, чем хотелось бы.
На самом деле я использовал некоторые наиболее мне понравившиеся идеи из xBB. Раньше я работал с xBB и даже разобрался как он работает, потом у меня появились новые идеи, возможно не самые лучшие, и я решил написать свой.
Это можно сделать один раз, например заиспользовав статическую переменную. Чтобы не тормозить приложение, можно делать это в отдельном треде, корутине, горутине, и т.д. (в зависимости от возможностей языка).
Если приложение смогло взять значения секретов, то почему вредоносный код в том же приложении не сможет? Да, некоторые файлы не удастся прочитать, но нужные наверняка будут прочитаны с успехом. А логи врядли помогут, так как скорее всего приложение не будет логгировать попытку прочитать какой-то файл. Теоретически так можно защитится, но давайте посмотрим с практической стороны.
А откуда по вашему приложение возьмет секреты (env переменные, файлы, аргументы запуска)? Ну да ладно, допустим ни один из этих вариантов не подошел. Но вот вариант с отправкой того де coredump вполне может оказаться рабочим. Не знаю, почему вы его проигнорировали.
Например:
Отправить содержимое файлов в популярных каталогах: /etc, /var…
Сделать core dump и отослать его.
Вы в канал будете писать итоговую сумму для каждого worker, это выйдет намного быстрее, так как вместо countTasks вызовов atomic.*, у вас будет countWorkers вызовов Mutex.Lock/Unlock (то есть намного меньше).
Ради интереса попробовал поменять местами запуски бенчмарка и получил противоположный результат:
Результат стабильно воспроизводится (первый бенчмарк всегда работает быстрее), причем даже пытался увеличить в 10 раз количество задач. Похоже что компьютер у меня устает, но все же результат странный.
Так-то и быструю сортировку можно написать в 10-20 строчек, но так обычно не делают. А все потому, что на самом деле эффективный алгоритм - это далеко не «наколеночное» решение.
В случае с FFT, то тут целый простор для улучшений и реализаций, начиная от поддержки произвольных длин, заканчивая локальными оптимизациями, поддержкой команд SSE, AVX и т.д. Скорее всего в реальном проекте (не лабораторной работе для студентов) вы не захотите тратить время на это все, а подключите тот же FFTW.
Разница сортировки и FFT в том, что сортировка уже встроена в поставляемую стандартную библиотеку, а FFT нет. Но это не повод для написания собственных реализаций. Конечно, все зависит от ситуации.
Ну к примеру как бы выглядела реализация Map:
Увеличилась ли тут сложность? Вроде нет.
Есть простор для оптимизации? Да.
Привычно ли использование? Да, аналогично тому же sql.Rows, к примеру.
Вообще ничего против не имею вашей библиотеки. Но ошибок все-таки не хватает (того же Err()). Для продакшена такую библиотеку неудобно будет использовать, так как придётся поверх этого всего городить велосипед, чтобы ошибки поддержать (а это нормально, например когда нам пользователь что-то в сокет кладёт или ещё что).
Вообще это все сугубо мое личное мнение и я могу быть где-то не прав. Но немножко грустно, что с появлением generic-ов частенько мелькают библиотеки с как минимум сотнями звёздочек, реализующие всякие Result[T, E], Optional[T] и type Map[K, V] map[K]V. Неужели стандартные возможности языка не позволяют этого? Или у нас путь как с npm пакетами (плохое сравнение, но все же) - проще строчку в go.mod, чем одну/две в *.go
Интересно, а чем подход как в sql.Rows не устроил, то есть сделать:
Не понимаю, для чего Option, зачем создавать себе проблемы.
Не знаю откуда вы это взяли и от кого, но заявление странное. Наверняка кто-то и пользуется, но такое можно сказать практически про любой сервис в любой компании.
Изменять в рантайме размеры может и не нужно, но выделять, к примеру, матрицу размера, определённого в compile time, выглядит не всегда разумно. Вообще, как мне кажется, не нужно делать преждевременные оптимизации в ущерб читаемости кода, так как может оказаться, что проседания производительности не в лишних аллокациях. Да не спорю, круто писать сразу оптимальный во всех смыслах код, но кажется, что это может оказаться сильно дороже, чем хотелось бы.
Если вы говорите про более эффективные средства, то хотя бы их перечисляйте. А пока это выглядит как попытка поумничать.