не пользуясь ничем, кроме памяти, за час реши заранее кем-то сформулированную задачу
Я бы сказал, что это больше “а знаешь ли ты, как решать типовые задачи из определенной области, и их комбинации” и косвенно “насколько хорошо ты обучаем”. Работать в жизни нужно в коллективе и много задач обсуждаются в реальном времени. Работа будет продвигаться очень медленно с человеком, который уходит гуглить каждый термин и простой вопрос.
Ну и ЕГЭ - это массовый фильтр, ещё и комбинированный: задачи разных уровней сложности в одном тесте. От этого и свои недостатки, и конечно основной плюс - стоимость. Индивидуальная, непредвзятая оценка каждого ученика стоила бы во много раз дороже.
Так и считайте резерв тоже от 999 vs 1000. Про электроэнергию пункт вы проигнорировали.
Экономия тоже будет 0.1%. Но когда у вас расходы на вычисления 10тыс/год, вам 10 погоды не делают. А когда 100млн, то это уже интереснее.
Большое количество серверов как раз и даёт возможность экономить на изменениях даже в долю процента, потому что относительный прирост производительности от одного сервера становится маленьким.
Но какие там оптимизации были? Тут нет речи об ускорении с минут до секунд.
Это понятно, что у ВК при их масштабах экономия даже 0.1% от времени запроса может сократить расходы на десятки или сотни тысяч у.е. Для случая замены интерфейса, пусть даже при запросе 30мс это будет 30мс * 0.1% / 30нс = 1000 раз за 1 запрос, и это при расходах на cpu для этих запросов 10млн у.е. в год. Есть сомнения, что там может быть такой код.
Остальные оптимизации вроде безобидные и локальные. Тут уже каждый сам решает, на что он своё время (а компания деньги) потратит.
(y−x) ∼ x Видите проблему? Мы сравниваем x с его отрицательной версией.
Это утверждение неверно, от этого все выводы из статьи неверные. Оно было бы верным только при константном у. Если у ~ х^10, то и (y−x) будет ~ х^10 на определенных интервалах.
Иронично, что статья, нацеленная на опровержение эффект Даннинга-Крюгера, подкрепляет его
Если новый формат спэйса совместим с текущим, то его можно применить при инициализации приложения в space:format(). Например, добавить nullable поле в конец или поменять тип поля на совместимый.
Вторичные индексы можно добавлять так же при инициализации приложения с space::create_index(name, {if_not_exists = true}). Создание индекса не блокирует процесс, т.ч. под нагрузкой должно быть ок. Удалять индексы можно там же с index = space.index[name]; if index then index:drop() end. Вместо изменения индекса можно добавить новый, а старый удалить.
У русской приставки «вы-» с течением времени тоже появились переносные значения. Одно из таких значений — «до конца, полностью». «ВЫ-течь» означает не просто «течь». «ВЫ-течь» означает «вытечь полностью».
А как же "вытекать"? "Полностью" не от приставки зависит, а от суффикса, определяющего совершенный глагол или несовершенный. То же самое с английским leaking out.
Вместо простого алгоритма наполнения хэша со сложностью O(n) получается n наполнений хэша общей сложностью O(n!). Создается n промежуточных объектов. В некоторых случаях это может создать большую нагрузку на GC, т.к. общее количество ключей во всех этих объектах тоже будет n!..
Такое будет работать быстро в функциональных языках, благодаря оптимизациям, которые возможны из-за других особенностей языка. В других языках, включая js, этих оптимизаций может не быть (скорее всего).
Подходы ФП могут сделать код читаемым и лаконичным. Хотя в этом примере страдает даже читаемость.
Искать неточность в доказательстве сложнее, чем замерить производительность. У меня получилась нелинейная зависимость времени от n для вашего алгоритма:
# ruby
def fn(n)
pr = []
lp = Array.new(n)
2.upto(n) do |i|
unless lp[i]
lp[i] = i
pr.push i
end
pr.each do |p|
break unless p <= lp[i] && p * i <= n
lp[p * i] = p
end
end
pr
end
puts fn(100).join(' ')
require 'benchmark/ips'
puts Benchmark.ips { |x|
[1_000, 10_000, 100_000, 1_000_000, 2_000_000].each do |n|
x.report(n.to_s) { fn(n) }
end
x.compare!
}
Если проблема в языке с GC, или в чем-то еще, покажите, пожалуйста, это вашими измерениями.
На середине статьи были мысли примерно такие же. "Открыто новое достижение: 95% функций — чистые!", "в JS нет глобальных моков?!".
Но потом с раздела "Зачем это всё?" автор объясняет, как чистые функции помогают при дебаге. Мне это показалось довольно убедительным и полезным. Если рассуждать дальше, то появляются вопросы по сравнению приложения, написаного на чистых функциях, и приложения, написаного с качественным ООП:
насколько дебаг проще?
какое сравнение трудозатрат на дальней дистанции?
чему проще научить, и какой подход проще внедрить, с учетом того, что в большинстве ЯП нет проверки чистоты функций?
Я бы сказал, что это больше “а знаешь ли ты, как решать типовые задачи из определенной области, и их комбинации” и косвенно “насколько хорошо ты обучаем”. Работать в жизни нужно в коллективе и много задач обсуждаются в реальном времени. Работа будет продвигаться очень медленно с человеком, который уходит гуглить каждый термин и простой вопрос.
Ну и ЕГЭ - это массовый фильтр, ещё и комбинированный: задачи разных уровней сложности в одном тесте. От этого и свои недостатки, и конечно основной плюс - стоимость. Индивидуальная, непредвзятая оценка каждого ученика стоила бы во много раз дороже.
У мэйлру стандартный поиск imap вроде как не работает. Только в официальном приложении работает.
Так и считайте резерв тоже от 999 vs 1000. Про электроэнергию пункт вы проигнорировали.
Экономия тоже будет 0.1%. Но когда у вас расходы на вычисления 10тыс/год, вам 10 погоды не делают. А когда 100млн, то это уже интереснее.
Большое количество серверов как раз и даёт возможность экономить на изменениях даже в долю процента, потому что относительный прирост производительности от одного сервера становится маленьким.
Почему? Это значит, что они серверов могут купить меньше, и счёт за электричество меньше будет.
Но какие там оптимизации были? Тут нет речи об ускорении с минут до секунд.
Это понятно, что у ВК при их масштабах экономия даже 0.1% от времени запроса может сократить расходы на десятки или сотни тысяч у.е. Для случая замены интерфейса, пусть даже при запросе 30мс это будет 30мс * 0.1% / 30нс = 1000 раз за 1 запрос, и это при расходах на cpu для этих запросов 10млн у.е. в год. Есть сомнения, что там может быть такой код.
Остальные оптимизации вроде безобидные и локальные. Тут уже каждый сам решает, на что он своё время (а компания деньги) потратит.
Спасибо за статью! Я правильно понял, что пока нет планов по публикации Lusca в открытом доступе?
Ещё я слышал об Apache Ozone, но опыта с ним не было. Вы его рассматривали? Интересно, какие у него минусы.
Это утверждение неверно, от этого все выводы из статьи неверные. Оно было бы верным только при константном у. Если у ~ х^10, то и (y−x) будет ~ х^10 на определенных интервалах.
Иронично, что статья, нацеленная на опровержение эффект Даннинга-Крюгера, подкрепляет его
Очень удивлюсь, если html = null вообще на что-то влияет в примере, т.к. область видимости переменной заканчивается сразу после этой инструкции.
Это текущие метки аккаунтов
В тарантуле есть multikey индексы — одна запись может быть проиндексирована по нескольким значениям. Документации не могу точной найти, но вот тут что-то есть https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_space/create_index/#box-space-path-multikey. Судя по примеру, можно указать сразу json-path до поля c несколькими значениями.
Если новый формат спэйса совместим с текущим, то его можно применить при инициализации приложения в
space:format(). Например, добавить nullable поле в конец или поменять тип поля на совместимый.Вторичные индексы можно добавлять так же при инициализации приложения с
space::create_index(name, {if_not_exists = true}). Создание индекса не блокирует процесс, т.ч. под нагрузкой должно быть ок. Удалять индексы можно там же сindex = space.index[name]; if index then index:drop() end. Вместо изменения индекса можно добавить новый, а старый удалить.На скрине
Сделал официальный запрос, получил ответ.
А как же "вытекать"? "Полностью" не от приставки зависит, а от суффикса, определяющего совершенный глагол или несовершенный. То же самое с английским leaking out.
А может все проще, и потом окажется, что там LinkedList был. Бинарный поиск получится O(n log n).
Вместо простого алгоритма наполнения хэша со сложностью O(n) получается n наполнений хэша общей сложностью O(n!). Создается n промежуточных объектов. В некоторых случаях это может создать большую нагрузку на GC, т.к. общее количество ключей во всех этих объектах тоже будет n!..
Такое будет работать быстро в функциональных языках, благодаря оптимизациям, которые возможны из-за других особенностей языка. В других языках, включая js, этих оптимизаций может не быть (скорее всего).
Подходы ФП могут сделать код читаемым и лаконичным. Хотя в этом примере страдает даже читаемость.
Ну покажите же, пожалуйста, цифры :)
Искать неточность в доказательстве сложнее, чем замерить производительность. У меня получилась нелинейная зависимость времени от n для вашего алгоритма:
Если проблема в языке с GC, или в чем-то еще, покажите, пожалуйста, это вашими измерениями.
В последнем примере по-моему вариант с try-catch получается чище.
А как обстоят дела с фильтрацией ошибок по типу? Двухуровневый when?
А сеттер — метод вроде же.
Слайдов не хватало, надо было что-то добавить. В любом нормальном шаблонизаторе есть вывод сырого html.
На середине статьи были мысли примерно такие же. "Открыто новое достижение: 95% функций — чистые!", "в JS нет глобальных моков?!".
Но потом с раздела "Зачем это всё?" автор объясняет, как чистые функции помогают при дебаге. Мне это показалось довольно убедительным и полезным. Если рассуждать дальше, то появляются вопросы по сравнению приложения, написаного на чистых функциях, и приложения, написаного с качественным ООП: