Производительность и параллельные вычисления — бесплатный тест онлайн

Вопрос 1 из 30

Ситуация: Цикл добавляет миллион значений в растущий вектор, и время увеличивается быстрее объёма данных. Что является главным техническим основанием для разбора?

n <- 10000
result <- numeric(n)
for (i in seq_len(n)) result[i] <- i^2
result[1:3]

Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers data.table изменяет данные по ссылке через := и использует ключи и индексы для быстрых операций без лишних копий Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе

Вопрос 2 из 30

Ситуация: Цикл добавляет миллион значений в растущий вектор, и время увеличивается быстрее объёма данных. Что именно может сломаться при новых данных?

n <- 10000
result <- numeric(n)
for (i in seq_len(n)) result[i] <- i^2
result[1:3]

Один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Неожиданная мутация исходного объекта происходит, когда две переменные ссылаются на одну data.table Экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping Многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость

Вопрос 3 из 30

Ситуация: Цикл добавляет миллион значений в растущий вектор, и время увеличивается быстрее объёма данных. Какое изменение устраняет именно причину проблемы?

Используйте copy() на границе, где требуется независимый объект, и документируйте операции по ссылке Используйте специализированное управление RNG-потоками и проверяйте повторяемость при одинаковом числе workers Уменьшайте передаваемые данные, распределяйте крупные независимые задачи и измеряйте wall time и память Предвыделяйте результат или используйте подходящую векторную операцию, сохраняя читаемость и память Профилируйте полный рабочий сценарий, затем локально измеряйте найденное узкое место

Вопрос 4 из 30

Ситуация: Цикл добавляет миллион значений в растущий вектор, и время увеличивается быстрее объёма данных. Какой контроль отличит исправление от случайно удачного результата?

Повторите запуск, сравните результаты по задаче и проверьте отсутствие совпадающих случайных последовательностей Проверьте адрес объекта через tracemem/address и сравните исходник после функции Сравните flame graph/Rprof, allocations и end-to-end время до и после изменения Сравните последовательный и параллельный запуск на разных размерах, включая startup overhead Измерьте время и выделения памяти на реалистичном размере через bench или Rprofmem

Вопрос 5 из 30

Ситуация: Цикл добавляет миллион значений в растущий вектор, и время увеличивается быстрее объёма данных. Какое заключение останется верным и на новых данных?

n <- 10000
result <- numeric(n)
for (i in seq_len(n)) result[i] <- i^2
result[1:3]

Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе; при этом главный риск состоит в том, что многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; при этом главный риск состоит в том, что многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место; при этом главный риск состоит в том, что один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе; при этом главный риск состоит в том, что экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе; следовательно, предупреждения можно не учитывать, если итог выглядит ожидаемо

Вопрос 6 из 30

Ситуация: Команда ускорила арифметику на наносекунды, но отчёт по-прежнему ждёт чтение гигабайтного файла. Какой принцип непосредственно относится к этому коду?

tmp <- tempfile(); write.csv(mtcars,tmp,row.names=FALSE)
Rprof(); result <- read.csv(tmp); Rprof(NULL)
result <- summaryRprof()$by.total[1:3,]
result

Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе Оптимизация должна сохранять численную корректность, порядок результатов, обработку ошибок и воспроизводимость случайных вычислений Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers

Вопрос 7 из 30

Ситуация: Команда ускорила арифметику на наносекунды, но отчёт по-прежнему ждёт чтение гигабайтного файла. Какой риск здесь остаётся главным, даже если результат выглядит правдоподобно?

tmp <- tempfile(); write.csv(mtcars,tmp,row.names=FALSE)
Rprof(); result <- read.csv(tmp); Rprof(NULL)
result <- summaryRprof()$by.total[1:3,]
result

Быстрая версия меняет тип, округление или порядок строк и остаётся незамеченной по одной общей метрике времени Многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость Один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping

Вопрос 8 из 30

Ситуация: Команда ускорила арифметику на наносекунды, но отчёт по-прежнему ждёт чтение гигабайтного файла. Какая правка делает решение устойчивым, а не просто удобным на текущем примере?

Добавьте тест эквивалентности, допустимый численный допуск и контроль структуры до сравнения скорости Предвыделяйте результат или используйте подходящую векторную операцию, сохраняя читаемость и память Уменьшайте передаваемые данные, распределяйте крупные независимые задачи и измеряйте wall time и память Используйте специализированное управление RNG-потоками и проверяйте повторяемость при одинаковом числе workers Профилируйте полный рабочий сценарий, затем локально измеряйте найденное узкое место

Вопрос 9 из 30

Ситуация: Команда ускорила арифметику на наносекунды, но отчёт по-прежнему ждёт чтение гигабайтного файла. Что нужно проверить после правки?

Измерьте время и выделения памяти на реалистичном размере через bench или Rprofmem Повторите запуск, сравните результаты по задаче и проверьте отсутствие совпадающих случайных последовательностей Сопоставьте all.equal(), типы, names, порядок строк и ошибки на граничных входах Сравните последовательный и параллельный запуск на разных размерах, включая startup overhead Сравните flame graph/Rprof, allocations и end-to-end время до и после изменения

Вопрос 10 из 30

Ситуация: Команда ускорила арифметику на наносекунды, но отчёт по-прежнему ждёт чтение гигабайтного файла. Какой итог разбора не смешивает правило языка с впечатлением от результата?

tmp <- tempfile(); write.csv(mtcars,tmp,row.names=FALSE)
Rprof(); result <- read.csv(tmp); Rprof(NULL)
result <- summaryRprof()$by.total[1:3,]
result

Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место; при этом главный риск состоит в том, что экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; при этом главный риск состоит в том, что один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место; поэтому внешний вид напечатанного объекта важнее происхождения и структуры данных Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место; при этом главный риск состоит в том, что один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе; при этом главный риск состоит в том, что многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость

Вопрос 11 из 30

Ситуация: Функция должна вернуть расширенную копию таблицы, но добавляет столбец и в объект вызывающего кода. Какое правило нужно применить к этому фрагменту прежде всего?

library(data.table)
dt1 <- data.table(x=1:3)
dt2 <- dt1
dt2[, y := x*2]
result <- dt1
result

data.table изменяет данные по ссылке через := и использует ключи и индексы для быстрых операций без лишних копий Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место

Вопрос 12 из 30

Ситуация: Функция должна вернуть расширенную копию таблицы, но добавляет столбец и в объект вызывающего кода. Что в этой ситуации способно исказить вывод без явной синтаксической ошибки?

library(data.table)
dt1 <- data.table(x=1:3)
dt2 <- dt1
dt2[, y := x*2]
result <- dt1
result

Один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса Многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость Неожиданная мутация исходного объекта происходит, когда две переменные ссылаются на одну data.table Экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend

Вопрос 13 из 30

Ситуация: Функция должна вернуть расширенную копию таблицы, но добавляет столбец и в объект вызывающего кода. Что следует изменить в коде или процессе?

Используйте copy() на границе, где требуется независимый объект, и документируйте операции по ссылке Предвыделяйте результат или используйте подходящую векторную операцию, сохраняя читаемость и память Уменьшайте передаваемые данные, распределяйте крупные независимые задачи и измеряйте wall time и память Профилируйте полный рабочий сценарий, затем локально измеряйте найденное узкое место Используйте специализированное управление RNG-потоками и проверяйте повторяемость при одинаковом числе workers

Вопрос 14 из 30

Ситуация: Функция должна вернуть расширенную копию таблицы, но добавляет столбец и в объект вызывающего кода. Какой тест лучше всего ловит повтор этой ошибки?

Сравните последовательный и параллельный запуск на разных размерах, включая startup overhead Измерьте время и выделения памяти на реалистичном размере через bench или Rprofmem Сравните flame graph/Rprof, allocations и end-to-end время до и после изменения Повторите запуск, сравните результаты по задаче и проверьте отсутствие совпадающих случайных последовательностей Проверьте адрес объекта через tracemem/address и сравните исходник после функции

Вопрос 15 из 30

Ситуация: Функция должна вернуть расширенную копию таблицы, но добавляет столбец и в объект вызывающего кода. Как сформулировать вывод без лишних обобщений?

library(data.table)
dt1 <- data.table(x=1:3)
dt2 <- dt1
dt2[, y := x*2]
result <- dt1
result

Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; при этом главный риск состоит в том, что неожиданная мутация исходного объекта происходит, когда две переменные ссылаются на одну data.table data.table изменяет данные по ссылке через := и использует ключи и индексы для быстрых операций без лишних копий; при этом главный риск состоит в том, что экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping data.table изменяет данные по ссылке через := и использует ключи и индексы для быстрых операций без лишних копий; при этом главный риск состоит в том, что неожиданная мутация исходного объекта происходит, когда две переменные ссылаются на одну data.table data.table изменяет данные по ссылке через := и использует ключи и индексы для быстрых операций без лишних копий; поэтому отсутствие сообщения об ошибке уже подтверждает корректность результата Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе; при этом главный риск состоит в том, что многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость

Вопрос 16 из 30

Ситуация: Четыре микроскопические задачи запускают на десятках процессов, и большая часть времени уходит на создание workers. Какой механизм точнее всего объясняет связь кода с ситуацией?

library(parallel)
cl <- makeCluster(2)
result <- parLapply(cl, 1:4, function(i) sum((1:1e5)^i))
stopCluster(cl)
result

Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов data.table изменяет данные по ссылке через := и использует ключи и индексы для быстрых операций без лишних копий Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место

Вопрос 17 из 30

Ситуация: Четыре микроскопические задачи запускают на десятках процессов, и большая часть времени уходит на создание workers. Какой дефект нужно искать в первую очередь?

library(parallel)
cl <- makeCluster(2)
result <- parLapply(cl, 1:4, function(i) sum((1:1e5)^i))
stopCluster(cl)
result

Экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость Неожиданная мутация исходного объекта происходит, когда две переменные ссылаются на одну data.table Один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса

Вопрос 18 из 30

Ситуация: Четыре микроскопические задачи запускают на десятках процессов, и большая часть времени уходит на создание workers. Какой вариант исправления сохраняет смысл анализа?

Уменьшайте передаваемые данные, распределяйте крупные независимые задачи и измеряйте wall time и память Используйте copy() на границе, где требуется независимый объект, и документируйте операции по ссылке Профилируйте полный рабочий сценарий, затем локально измеряйте найденное узкое место Предвыделяйте результат или используйте подходящую векторную операцию, сохраняя читаемость и память Используйте специализированное управление RNG-потоками и проверяйте повторяемость при одинаковом числе workers

Вопрос 19 из 30

Ситуация: Четыре микроскопические задачи запускают на десятках процессов, и большая часть времени уходит на создание workers. Какая проверка относится к исходному риску, а не к внешнему виду результата?

Проверьте адрес объекта через tracemem/address и сравните исходник после функции Повторите запуск, сравните результаты по задаче и проверьте отсутствие совпадающих случайных последовательностей Сравните последовательный и параллельный запуск на разных размерах, включая startup overhead Измерьте время и выделения памяти на реалистичном размере через bench или Rprofmem Сравните flame graph/Rprof, allocations и end-to-end время до и после изменения

Вопрос 20 из 30

Ситуация: Четыре микроскопические задачи запускают на десятках процессов, и большая часть времени уходит на создание workers. Какое заключение лучше всего выдерживает проверку?

library(parallel)
cl <- makeCluster(2)
result <- parLapply(cl, 1:4, function(i) sum((1:1e5)^i))
stopCluster(cl)
result

Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место; при этом главный риск состоит в том, что один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; поэтому достаточно один раз проверить класс объекта на текущем наборе данных Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers; при этом главный риск состоит в том, что экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; при этом главный риск состоит в том, что set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; при этом главный риск состоит в том, что экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping

Вопрос 21 из 30

Ситуация: После векторизации итог немного отличается, а downstream-порог превращает малую разницу в другую категорию. На какое свойство R здесь следует опереться?

x <- runif(1000)
a <- sum(x)
b <- Reduce(`+`, x)
result <- all.equal(a,b,tolerance=1e-12)
result

Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers Оптимизация должна сохранять численную корректность, порядок результатов, обработку ошибок и воспроизводимость случайных вычислений Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов data.table изменяет данные по ссылке через := и использует ключи и индексы для быстрых операций без лишних копий Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место

Вопрос 22 из 30

Ситуация: После векторизации итог немного отличается, а downstream-порог превращает малую разницу в другую категорию. Почему успешный запуск ещё не доказывает корректность?

x <- runif(1000)
a <- sum(x)
b <- Reduce(`+`, x)
result <- all.equal(a,b,tolerance=1e-12)
result

Быстрая версия меняет тип, округление или порядок строк и остаётся незамеченной по одной общей метрике времени Неожиданная мутация исходного объекта происходит, когда две переменные ссылаются на одну data.table Экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping Один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend

Вопрос 23 из 30

Ситуация: После векторизации итог немного отличается, а downstream-порог превращает малую разницу в другую категорию. Какая правка лучше локальной заплатки?

Профилируйте полный рабочий сценарий, затем локально измеряйте найденное узкое место Добавьте тест эквивалентности, допустимый численный допуск и контроль структуры до сравнения скорости Используйте copy() на границе, где требуется независимый объект, и документируйте операции по ссылке Уменьшайте передаваемые данные, распределяйте крупные независимые задачи и измеряйте wall time и память Используйте специализированное управление RNG-потоками и проверяйте повторяемость при одинаковом числе workers

Вопрос 24 из 30

Ситуация: После векторизации итог немного отличается, а downstream-порог превращает малую разницу в другую категорию. Как подтвердить корректность на граничном случае?

Проверьте адрес объекта через tracemem/address и сравните исходник после функции Сопоставьте all.equal(), типы, names, порядок строк и ошибки на граничных входах Повторите запуск, сравните результаты по задаче и проверьте отсутствие совпадающих случайных последовательностей Сравните flame graph/Rprof, allocations и end-to-end время до и после изменения Сравните последовательный и параллельный запуск на разных размерах, включая startup overhead

Вопрос 25 из 30

Ситуация: После векторизации итог немного отличается, а downstream-порог превращает малую разницу в другую категорию. Какой вывод точнее всего связывает механизм и главный риск?

x <- runif(1000)
a <- sum(x)
b <- Reduce(`+`, x)
result <- all.equal(a,b,tolerance=1e-12)
result

Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; при этом главный риск состоит в том, что быстрая версия меняет тип, округление или порядок строк и остаётся незамеченной по одной общей метрике времени Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers; при этом главный риск состоит в том, что set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Оптимизация должна сохранять численную корректность, порядок результатов, обработку ошибок и воспроизводимость случайных вычислений; следовательно, совпадение числа строк можно считать полной проверкой решения Оптимизация должна сохранять численную корректность, порядок результатов, обработку ошибок и воспроизводимость случайных вычислений; при этом главный риск состоит в том, что быстрая версия меняет тип, округление или порядок строк и остаётся незамеченной по одной общей метрике времени Оптимизация должна сохранять численную корректность, порядок результатов, обработку ошибок и воспроизводимость случайных вычислений; при этом главный риск состоит в том, что экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping

Вопрос 26 из 30

Ситуация: Параллельные симуляции на Windows и Linux дают разные ответы, хотя установлен один seed. Какое утверждение лучше всего объясняет показанный фрагмент?

RNGkind("L'Ecuyer-CMRG")
set.seed(14)
result <- .Random.seed[1:6]
result

Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers Оптимизация должна сохранять численную корректность, порядок результатов, обработку ошибок и воспроизводимость случайных вычислений Векторизованные операции переносят цикл в оптимизированный код и часто уменьшают накладные расходы интерпретатора, но не меняют асимптотику сами по себе Профилирование измеряет, где программа действительно тратит время и память; оптимизация по впечатлению часто выбирает не то место Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов

Вопрос 27 из 30

Ситуация: Параллельные симуляции на Windows и Linux дают разные ответы, хотя установлен один seed. Какое скрытое допущение здесь опаснее остальных?

RNGkind("L'Ecuyer-CMRG")
set.seed(14)
result <- .Random.seed[1:6]
result

Экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Один microbenchmark маленькой функции игнорирует ввод-вывод, создание данных и сборку мусора всего процесса Быстрая версия меняет тип, округление или порядок строк и остаётся незамеченной по одной общей метрике времени Многократное расширение вектора через c() внутри цикла копирует данные и создаёт квадратичную стоимость

Вопрос 28 из 30

Ситуация: Параллельные симуляции на Windows и Linux дают разные ответы, хотя установлен один seed. Что нужно сделать, чтобы ошибка не вернулась на следующем наборе данных?

Уменьшайте передаваемые данные, распределяйте крупные независимые задачи и измеряйте wall time и память Предвыделяйте результат или используйте подходящую векторную операцию, сохраняя читаемость и память Профилируйте полный рабочий сценарий, затем локально измеряйте найденное узкое место Добавьте тест эквивалентности, допустимый численный допуск и контроль структуры до сравнения скорости Используйте специализированное управление RNG-потоками и проверяйте повторяемость при одинаковом числе workers

Вопрос 29 из 30

Ситуация: Параллельные симуляции на Windows и Linux дают разные ответы, хотя установлен один seed. Какая проверка непосредственно подтверждает, что дефект устранён?

Сравните последовательный и параллельный запуск на разных размерах, включая startup overhead Сопоставьте all.equal(), типы, names, порядок строк и ошибки на граничных входах Измерьте время и выделения памяти на реалистичном размере через bench или Rprofmem Повторите запуск, сравните результаты по задаче и проверьте отсутствие совпадающих случайных последовательностей Сравните flame graph/Rprof, allocations и end-to-end время до и после изменения

Вопрос 30 из 30

Ситуация: Параллельные симуляции на Windows и Linux дают разные ответы, хотя установлен один seed. Что стоит написать в технической рецензии к этому фрагменту?

RNGkind("L'Ecuyer-CMRG")
set.seed(14)
result <- .Random.seed[1:6]
result

Оптимизация должна сохранять численную корректность, порядок результатов, обработку ошибок и воспроизводимость случайных вычислений; при этом главный риск состоит в том, что быстрая версия меняет тип, округление или порядок строк и остаётся незамеченной по одной общей метрике времени Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers; поэтому повторный запуск в той же сессии заменяет проверку граничных случаев Параллельное выполнение полезно только когда работа превышает стоимость запуска процессов, передачи данных и объединения результатов; при этом главный риск состоит в том, что set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers; при этом главный риск состоит в том, что set.seed перед форком не всегда даёт желаемые независимые последовательности во всех платформах и backend Параллельные случайные вычисления требуют независимых воспроизводимых потоков, например L'Ecuyer-CMRG, и сохранённой конфигурации workers; при этом главный риск состоит в том, что экспорт огромного объекта каждому worker умножает память и может сделать параллельную версию медленнее или вызвать swapping