В исходном датасете представлены данные одной компании, которая каждому дому (объекту) поставила некую оценку.
Не совсем понятно, что вы имеете ввиду под нерепрезентативностью в данном случае.
К сожалению не доводилось использовать TensorRT, однако, если там автоматически применяется подобная оптимизация, то конечно не стоит ее применять вручную.
1. А почему бы не использовать итератор, который по умолчанию ещё и является потокобезопасным для чтения.
Выдержка с сайта Microsoft:
“Все открытые и защищенные члены ConcurrentQueue являются потокобезопасными и могут использоваться одновременно из нескольких потоков.”
2. Загрузим мы 8 гигов в оперативу и сломаем компьютер. Тут нужно искать tradeoff между скоростью и оперативкой. Для этого можно было бы возвращать буферезированный поток, а не полный массив.
Да, такая возможность существует. Но в статье не приводится универсальный код, а взят пример из реальной задачи, в которой есть знание максимально возможного размера обрабатываемого файла (~1 мегабайт) и знание того, что среда выполнения .Net никогда не выделит столько потоков под конструкцию Parallel.Foreach (или Parallel.For), что бы забить полностью доступную нам оперативную память.
Для примера: если предположить, что нам доступны 6 гигабайт, то 6*1024 потоков единовременно или в течении краткого периода времени никогда выделено не будет. Таким образом, вероятность того что мы загрузим ОЗУ полностью стремится к нулю. И даже если предположить, что всё-таки машина сможет выделить столько потоков то компьютер мы не сломаем. Просто приложение будет закрыто с ошибкой переполнения памяти (хотя надо признать, что в этот момент действительно возможны будут замедления работы других процессов).
3. Поэтому мы параллельно считываем? От этого скорость только упадёт из-за накладных расходов по сравнению с последовательным чтением.
Да именно поэтому. Упадет скорость или нет – это достаточно спорный вопрос, дискуссии по которому шли и периодически до сих пор вспыхивают в сети. Падение скорости более вероятно на классических HDD, если же применяются SSD диски, то соответственно эта вероятность будет существенно ниже. Конкретно в нашем случае – было ускорение обработки файлов в несколько раз. Возможно заменить его на параллельную запись в БД, конструкция останется той же самой.
Добрый день. Траектории полёта спутников сложно предсказать, основываясь на одних законах небесной механики, поскольку слишком много факторов воздействия на спутник. Кроме того, их в выборке было 600 и потому разбираться с каждым по отдельности было бы довольно долго.
В бейзлайне организаторов использовалась математическая модель SGP4, выдающая по метрике около ~66, против 95 в топовых решениях.
Не совсем понятно, что вы имеете ввиду под нерепрезентативностью в данном случае.
1. А почему бы не использовать итератор, который по умолчанию ещё и является потокобезопасным для чтения.
Выдержка с сайта Microsoft:
“Все открытые и защищенные члены ConcurrentQueue являются потокобезопасными и могут использоваться одновременно из нескольких потоков.”
2. Загрузим мы 8 гигов в оперативу и сломаем компьютер. Тут нужно искать tradeoff между скоростью и оперативкой. Для этого можно было бы возвращать буферезированный поток, а не полный массив.
Да, такая возможность существует. Но в статье не приводится универсальный код, а взят пример из реальной задачи, в которой есть знание максимально возможного размера обрабатываемого файла (~1 мегабайт) и знание того, что среда выполнения .Net никогда не выделит столько потоков под конструкцию Parallel.Foreach (или Parallel.For), что бы забить полностью доступную нам оперативную память.
Для примера: если предположить, что нам доступны 6 гигабайт, то 6*1024 потоков единовременно или в течении краткого периода времени никогда выделено не будет. Таким образом, вероятность того что мы загрузим ОЗУ полностью стремится к нулю. И даже если предположить, что всё-таки машина сможет выделить столько потоков то компьютер мы не сломаем. Просто приложение будет закрыто с ошибкой переполнения памяти (хотя надо признать, что в этот момент действительно возможны будут замедления работы других процессов).
3. Поэтому мы параллельно считываем? От этого скорость только упадёт из-за накладных расходов по сравнению с последовательным чтением.
Да именно поэтому. Упадет скорость или нет – это достаточно спорный вопрос, дискуссии по которому шли и периодически до сих пор вспыхивают в сети. Падение скорости более вероятно на классических HDD, если же применяются SSD диски, то соответственно эта вероятность будет существенно ниже. Конкретно в нашем случае – было ускорение обработки файлов в несколько раз. Возможно заменить его на параллельную запись в БД, конструкция останется той же самой.
В бейзлайне организаторов использовалась математическая модель SGP4, выдающая по метрике около ~66, против 95 в топовых решениях.