Абсолютно согласен, что атомики являются кирпичиками для других примитивов. Статья про внутреннее устройство атомика и совсем немного затронут мьютекс. Тем не менее некоторые статьи делают замеры производительности и сравнивают их, поэтому показалось важным сделать акцент на том, что сравнивать их так не всегда имеет смысл (как вы заметили - одно является частью другого). от такого акцента, пожалуй, вывод не выиграл.
За советы спасибо, за минус, конечно, благодарить не могу. Мы можем долго рассматривать варианты улучшения, но, повторюсь, цель была несколько проще: я наяделся, что материал будет полезен тем, кто еще разбирается в нюансах.
Относительно таблицы с миллисекундами: это результы запуска кода на литкоде. Это указано. Наносекунды: обычные го бенчмарки. Здесь никто не ставил целью досконально разобраться именно в замерах скорости, потому что, как вы верно заметили, это тема искусство, и собственно это может быть темой отдельной статьи. Но показать, что есть изменения в скорости хотя бы в прогонах на литкоде стоило.
Относительно примера выше я уже писал ответ на комментарии. Соглашусь, что возможно он не самый удачный.
Спасибо за то, что поделились решением. Оно довольно изящное и за линейное время. Однако цель статьи была несколько иной - показать применение конкретного алгоритма в разных вариациях.
Сейчас думаю, что стоило упомянуть разные варианты решения для полноты картины. От себя добавлю (напомню), что на leetcode в discuss всегда можно найти много интересных подходов к решению.
Я хотел показать, как алгоритм с небольшими модификациями может быть использован для решения задач и разобрал одну из них с литкода.
Что касается тестов, то я разобрал только один кейс, когда все элементы одинаковы и соответствуют искомому. В таком случае решение задачи приводило бы к линейному времени.
Я учту ваши замечания и пожелания относительно количества разнообразных задач и тестов)
спасибо. исправил
Абсолютно согласен, что атомики являются кирпичиками для других примитивов. Статья про внутреннее устройство атомика и совсем немного затронут мьютекс. Тем не менее некоторые статьи делают замеры производительности и сравнивают их, поэтому показалось важным сделать акцент на том, что сравнивать их так не всегда имеет смысл (как вы заметили - одно является частью другого). от такого акцента, пожалуй, вывод не выиграл.
За советы спасибо, за минус, конечно, благодарить не могу. Мы можем долго рассматривать варианты улучшения, но, повторюсь, цель была несколько проще: я наяделся, что материал будет полезен тем, кто еще разбирается в нюансах.
Относительно таблицы с миллисекундами: это результы запуска кода на литкоде. Это указано. Наносекунды: обычные го бенчмарки. Здесь никто не ставил целью досконально разобраться именно в замерах скорости, потому что, как вы верно заметили, это тема искусство, и собственно это может быть темой отдельной статьи. Но показать, что есть изменения в скорости хотя бы в прогонах на литкоде стоило.
Относительно примера выше я уже писал ответ на комментарии. Соглашусь, что возможно он не самый удачный.
Спасибо за то, что поделились решением. Оно довольно изящное и за линейное время. Однако цель статьи была несколько иной - показать применение конкретного алгоритма в разных вариациях.
Сейчас думаю, что стоило упомянуть разные варианты решения для полноты картины. От себя добавлю (напомню), что на leetcode в discuss всегда можно найти много интересных подходов к решению.
Спасибо за замечания.
Я хотел показать, как алгоритм с небольшими модификациями может быть использован для решения задач и разобрал одну из них с литкода.
Что касается тестов, то я разобрал только один кейс, когда все элементы одинаковы и соответствуют искомому. В таком случае решение задачи приводило бы к линейному времени.
Я учту ваши замечания и пожелания относительно количества разнообразных задач и тестов)