💡 Инструкция: Выберите один ответ из пяти. На работу отведено 85 минут. После завершения откроются правильные ответы, объяснения и результаты по темам.
Вопрос 2 из 30
Какую проверку стоит добавить для участка с `value = flag ? 1 : 1.0`?
Julia Julia · Вывод типов компилятором Копировать
function unstable(flag)
value = flag ? 1 : 1.0
return value + 2
end
function stable(flag)
value = flag ? 1.0 : 1.0
return value + 2
end
@show unstable(true) unstable(false)
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Проверить на отдельном примере, что типовая нестабильность определяется только наличием `Any` в исходнике; объединение двух конкретных типов не влияет на сгенерированный код.
Проверить на отдельном примере, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Проверить на отдельном примере, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 4 из 30
Как проверить, что новая реализация `value = flag ? 1 : 1.0` не изменила обещанное пользователю поведение?
R(T)=\operatorname{infer}(f,T)
Приёмка должна подтвердить, что типовая нестабильность определяется только наличием `Any` в исходнике; объединение двух конкретных типов не влияет на сгенерированный код.
Приёмка должна подтвердить, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Приёмка должна подтвердить, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Приёмка должна подтвердить, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Вопрос 6 из 30
Как нужно интерпретировать `@code_warntype summarize([1.0, -2.0, 3.0])`, не добавляя к коду лишних гарантий?
\operatorname{warntype}(f,x)
Julia Julia · Диагностика через @code_warntype Копировать
function summarize(xs)
s = zero(eltype(xs))
for x in xs
s += x > 0 ? x : zero(x)
end
return s
end
@code_warntype summarize([1.0, -2.0, 3.0])
Красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
`@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Вопрос 7 из 30
Какой эксперимент отличит настоящий механизм `@code_warntype summarize([1.0, -2.0, 3.0])` от случайного результата одного запуска?
Julia Julia · Диагностика через @code_warntype Копировать
function summarize(xs)
s = zero(eltype(xs))
for x in xs
s += x > 0 ? x : zero(x)
end
return s
end
@code_warntype summarize([1.0, -2.0, 3.0])
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Проверить на отдельном примере, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Проверить на отдельном примере, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Проверить на отдельном примере, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Вопрос 8 из 30
Какое требование к `@code_warntype summarize([1.0, -2.0, 3.0])` важнее удобной детали текущей реализации?
Julia Julia · Диагностика через @code_warntype Копировать
function summarize(xs)
s = zero(eltype(xs))
for x in xs
s += x > 0 ? x : zero(x)
end
return s
end
@code_warntype summarize([1.0, -2.0, 3.0])
Сохранить в реализации правило: Производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Сохранить в реализации правило: `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Сохранить в реализации правило: Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Сохранить в реализации правило: Красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Сохранить в реализации правило: Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 9 из 30
При переносе кода с `@code_warntype summarize([1.0, -2.0, 3.0])` в библиотеку какой критерий нельзя заменять впечатлением «пример работает»?
\operatorname{warntype}(f,x)
Приёмка должна подтвердить, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Приёмка должна подтвердить, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Приёмка должна подтвердить, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Приёмка должна подтвердить, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Вопрос 10 из 30
Какое утверждение о `@code_warntype summarize([1.0, -2.0, 3.0])` является переносимым правилом, а не особенностью одного запуска?
Указать в документации: Производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Указать в документации: Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Указать в документации: Красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Указать в документации: `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Указать в документации: Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 12 из 30
Какой контрольный тест лучше всего проверит правило, связанное с `weight::Real`?
Julia Julia · Абстрактные поля Копировать
struct SlowModel
weight::Real
end
struct FastModel{T<:Real}
weight::T
end
predict(m, x) = m.weight * x
@show predict(SlowModel(2.0), 3.0) predict(FastModel(2.0), 3.0)
Проверить на отдельном примере, что поле типа `Real` специализируется на фактическом значении внутри каждого экземпляра так же, как параметрическое поле.
Проверить на отдельном примере, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Проверить на отдельном примере, что поле абстрактного типа или нетипизированный контейнер заставляет хранить разные представления; параметр типа или конкретный абстрактный интерфейс часто сохраняет гибкость без динамического доступа.
Проверить на отдельном примере, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Вопрос 13 из 30
Какое решение устраняет риск вокруг `Real`, не меняя поведение на допустимых данных?
Julia Julia · Абстрактные поля Копировать
struct SlowModel
weight::Real
end
struct FastModel{T<:Real}
weight::T
end
predict(m, x) = m.weight * x
@show predict(SlowModel(2.0), 3.0) predict(FastModel(2.0), 3.0)
Сохранить в реализации правило: Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Сохранить в реализации правило: Поле типа `Real` специализируется на фактическом значении внутри каждого экземпляра так же, как параметрическое поле.
Сохранить в реализации правило: Поле абстрактного типа или нетипизированный контейнер заставляет хранить разные представления; параметр типа или конкретный абстрактный интерфейс часто сохраняет гибкость без динамического доступа.
Сохранить в реализации правило: `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Сохранить в реализации правило: Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 14 из 30
Как проверить, что новая реализация `Real` не изменила обещанное пользователю поведение?
field::T\;\text{с конкретным }T
Приёмка должна подтвердить, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Приёмка должна подтвердить, что поле типа `Real` специализируется на фактическом значении внутри каждого экземпляра так же, как параметрическое поле.
Приёмка должна подтвердить, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Приёмка должна подтвердить, что поле абстрактного типа или нетипизированный контейнер заставляет хранить разные представления; параметр типа или конкретный абстрактный интерфейс часто сохраняет гибкость без динамического доступа.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 17 из 30
Что нужно подтвердить отдельным примером для `s = zero(eltype(xs))`?
Julia Julia · Барьер функций Копировать
function kernel(xs, threshold)
s = zero(eltype(xs))
@inbounds for x in xs
x > threshold && (s += x)
end
return s
end
function report(raw, threshold)
xs = Float64.(raw)
return kernel(xs, Float64(threshold))
end
@show report(1:10, 5)
Проверить на отдельном примере, что барьер функций отделяет динамическую подготовку данных от типостабильного вычислительного ядра и позволяет компилятору специализировать внутренний цикл.
Проверить на отдельном примере, что функциональный барьер мешает оптимизации, потому что разделяет один большой цикл на несколько вызовов.
Проверить на отдельном примере, что типовая нестабильность определяется только наличием `Any` в исходнике; объединение двух конкретных типов не влияет на сгенерированный код.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Проверить на отдельном примере, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Вопрос 22 из 30
Какой эксперимент отличит настоящий механизм `x = rand(100_000)` от случайного результата одного запуска?
Julia Julia · Наблюдаемость и диагностика Копировать
using BenchmarkTools, Profile
x = rand(100_000)
f(x) = sum(sin, x)
trial = @benchmark f($x) samples=30
Profile.clear(); @profile for _ in 1:20; f(x); end
@show median(trial).time median(trial).memory length(Profile.fetch())
Проверить на отдельном примере, что одного замера через @time после разогрева обычно хватает для поиска узкого места; глобальные переменные и способ подстановки аргументов почти не влияют на вывод.
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Проверить на отдельном примере, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Проверить на отдельном примере, что барьер функций отделяет динамическую подготовку данных от типостабильного вычислительного ядра и позволяет компилятору специализировать внутренний цикл.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Вопрос 24 из 30
Две реализации участка с `x = rand(100_000)` совпадают на обычных данных. Что необходимо проверить перед выпуском?
T_{steady}=\operatorname{median}(t_i)
Приёмка должна подтвердить, что одного замера через @time после разогрева обычно хватает для поиска узкого места; глобальные переменные и способ подстановки аргументов почти не влияют на вывод.
Приёмка должна подтвердить, что барьер функций отделяет динамическую подготовку данных от типостабильного вычислительного ядра и позволяет компилятору специализировать внутренний цикл.
Приёмка должна подтвердить, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Приёмка должна подтвердить, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 27 из 30
Что нужно подтвердить отдельным примером для `steady = @belapsed pipeline($x)`?
Julia Julia · Надёжность в эксплуатации Копировать
using BenchmarkTools
function pipeline(x)
y = @. sin(x) + x^2
return sum(y)
end
x = rand(1_000_000)
first = @elapsed pipeline(x)
steady = @belapsed pipeline($x)
@show first steady
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Проверить на отдельном примере, что ускорение горячего микротеста можно считать успехом в эксплуатации, даже если первый вызов, расход памяти и полный пользовательский сценарий стали хуже.
Проверить на отдельном примере, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Проверить на отдельном примере, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Вопрос 29 из 30
Две реализации участка с `steady = @belapsed pipeline($x)` совпадают на обычных данных. Что необходимо проверить перед выпуском?
T_{user}=T_{compile}+T_{run}
Приёмка должна подтвердить, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Приёмка должна подтвердить, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Приёмка должна подтвердить, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Приёмка должна подтвердить, что ускорение горячего микротеста можно считать успехом в эксплуатации, даже если первый вызов, расход памяти и полный пользовательский сценарий стали хуже.