💡 Инструкция: Выберите один ответ из пяти. На работу отведено 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)
Проверить на отдельном примере, что типовая нестабильность определяется только наличием `Any` в исходнике; объединение двух конкретных типов не влияет на сгенерированный код.
Проверить на отдельном примере, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Проверить на отдельном примере, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 4 из 30
Как проверить, что новая реализация `value = flag ? 1 : 1.0` не изменила обещанное пользователю поведение?
R(T)=\operatorname{infer}(f,T)
Приёмка должна подтвердить, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Приёмка должна подтвердить, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Приёмка должна подтвердить, что типовая нестабильность определяется только наличием `Any` в исходнике; объединение двух конкретных типов не влияет на сгенерированный код.
Приёмка должна подтвердить, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Вопрос 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])
Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
`@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Вопрос 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])
Проверить на отдельном примере, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Проверить на отдельном примере, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Проверить на отдельном примере, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Вопрос 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])
Сохранить в реализации правило: Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Сохранить в реализации правило: `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Сохранить в реализации правило: Красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Сохранить в реализации правило: Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Сохранить в реализации правило: Производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Вопрос 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])` является переносимым правилом, а не особенностью одного запуска?
Указать в документации: Красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Указать в документации: Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Указать в документации: Производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Указать в документации: Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Указать в документации: `@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` специализируется на фактическом значении внутри каждого экземпляра так же, как параметрическое поле.
Проверить на отдельном примере, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Проверить на отдельном примере, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Проверить на отдельном примере, что поле абстрактного типа или нетипизированный контейнер заставляет хранить разные представления; параметр типа или конкретный абстрактный интерфейс часто сохраняет гибкость без динамического доступа.
Проверить на отдельном примере, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Вопрос 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)
Сохранить в реализации правило: Надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Сохранить в реализации правило: Поле типа `Real` специализируется на фактическом значении внутри каждого экземпляра так же, как параметрическое поле.
Сохранить в реализации правило: Поле абстрактного типа или нетипизированный контейнер заставляет хранить разные представления; параметр типа или конкретный абстрактный интерфейс часто сохраняет гибкость без динамического доступа.
Сохранить в реализации правило: `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Сохранить в реализации правило: Вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Вопрос 14 из 30
Как проверить, что новая реализация `Real` не изменила обещанное пользователю поведение?
field::T\;\text{с конкретным }T
Приёмка должна подтвердить, что поле типа `Real` специализируется на фактическом значении внутри каждого экземпляра так же, как параметрическое поле.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Приёмка должна подтвердить, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Приёмка должна подтвердить, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Приёмка должна подтвердить, что поле абстрактного типа или нетипизированный контейнер заставляет хранить разные представления; параметр типа или конкретный абстрактный интерфейс часто сохраняет гибкость без динамического доступа.
Вопрос 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` в исходнике; объединение двух конкретных типов не влияет на сгенерированный код.
Проверить на отдельном примере, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Проверить на отдельном примере, что барьер функций отделяет динамическую подготовку данных от типостабильного вычислительного ядра и позволяет компилятору специализировать внутренний цикл.
Вопрос 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 после разогрева обычно хватает для поиска узкого места; глобальные переменные и способ подстановки аргументов почти не влияют на вывод.
Проверить на отдельном примере, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Проверить на отдельном примере, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Проверить на отдельном примере, что барьер функций отделяет динамическую подготовку данных от типостабильного вычислительного ядра и позволяет компилятору специализировать внутренний цикл.
Вопрос 24 из 30
Две реализации участка с `x = rand(100_000)` совпадают на обычных данных. Что необходимо проверить перед выпуском?
T_{steady}=\operatorname{median}(t_i)
Приёмка должна подтвердить, что барьер функций отделяет динамическую подготовку данных от типостабильного вычислительного ядра и позволяет компилятору специализировать внутренний цикл.
Приёмка должна подтвердить, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Приёмка должна подтвердить, что красный фрагмент в `@code_warntype` служит достаточным доказательством потери производительности, поэтому профилирование можно отложить до его устранения.
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Приёмка должна подтвердить, что одного замера через @time после разогрева обычно хватает для поиска узкого места; глобальные переменные и способ подстановки аргументов почти не влияют на вывод.
Вопрос 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}
Приёмка должна подтвердить, что надёжная эксплуатация учитывает время первой компиляции, повторные вызовы, память и ошибки; ускорение микротеста не считается успехом, если ухудшился полный сценарий.
Приёмка должна подтвердить, что `@code_warntype` показывает проблемные объединения и динамические участки, но красный цвет не равен автоматически дефекту; вывод связывают с измерением конкретной функции.
Приёмка должна подтвердить, что вывод типов компилятора работает лучше, когда тип результата определяется типами входов и ветви возвращают согласованное семейство; значение `Any` в горячем цикле мешает специализации.
Приёмка должна подтвердить, что производительность подтверждают BenchmarkTools, профилем и счётчиками на реалистичных данных, учитывая разогрев и исключая глобальные переменные из измерения.
Приёмка должна подтвердить, что ускорение горячего микротеста можно считать успехом в эксплуатации, даже если первый вызов, расход памяти и полный пользовательский сценарий стали хуже.