Размер тестового файла в CrystalDiskMark слишком мал. Есть высокая вероятность, что на стороне хранения это всё оседает в кешах (в т.ч. DRAM, он как раз часто не меньше 1ГБ). Особенно по отношению к RUVDS.
С размером потоков не игрались? T1 может не на всех решениях утилизировать диск нормально.
Другой вопрос же к самим провайдерам... Современные потребительские NVME спокойно держат Read 4k Q32T1 под 500МБ\с, а тут подобными скоростями хвастается только RUVDS. Как умудрились производительность потерять?
А почему не Linux, кстати? Если сервер - то линукс, иначе извращение. А с виндой... Вот, недавно новость прошлась: "В Windows Server 2025 добавлена нативная поддержка накопителей NVMe". А у вас в тестах уже есть эта поддержка? А на всех тачках?
ToArray()метода, чтобы избежать создания лишнего списка.
ToArray под капотом - это простой ToList().ToArray(), так что там не просто создается лишний список, там трафика памяти в 2 раза больше.
В первом случае массивы будут храниться в оперативной памяти нашего приложения, а во втором — в кэше процессора
Я даже не знаю что спросить первым... Т.е. второй вариант не хранит данные в оперетивной памяти? Т.е., в первом варианте данные не будут попадать в кеш процессора?
в наши дни процессоры стали гораздо умнее взаимодействовать с компиляторами
Как именно процессоры взаимодействуют с компиляторами?
использование unsafeкода может значительно повысить производительность
Но явно не приведённый пример.
компилятор не может угадать, как вы хотите использовать эти данные, в отличие от вас самих
Зачем компилятору угадывать это?
Структуры же не столько хороши в доступе к данными, сколько в своей природе: они являются значимыми типами, т.е. выделяются и хранятся "на месте", вне зависимости от того, где это место.
Эффективный доступ к ним исходит из этого свойства, поскольку массив таких структур обладает высокой локальностью кеша при последовательном обходе (но и сам массив весит больше, что делает реаллокацию массива дорогим).
Когда поток блокируется, он держит ядро CPU активным.
С чего бы ему держать ядро активным? И чем конкретно блокируется? Async'и призваны плодить меньше потоков и заменяют собой вызовы типа sleep или read. Делает ли активным ядро блокировка потока приемом соединения через вызов accept? Мы можем тут ждать достаточно долго.
Выше вы советовали использовать os.sleep чтобы дать ядру "отдохнуть". Но ведь это тоже блокировка потока. Тогда в чем выгода использовать os.sleep, если заблокированный поток якобы держит ядро CPU активным?
Возможно, с python 3.13 и беж GIL и имеет смысл, но гораздо проще и из коробки реализуется однопоточный кэш, к которому обращаются задачи из асинхронного кода.
Сишку бы более подробно написать, хотя бы по корректировку счетчика ссылок.
Вы заменяете значение объекта через его id, т.е. сам объект из кэша, а не кэш. Получается, возможна ситуация, когда я из кэша взял один объект, затем в процессе работы кто-то мне этот объект заменил на лету?
Ну и как вы планируете обходить возникшую гонку данных, т.к. в то время как писатель атомарен, читатель - нет, и может прочесть мусор. Это может вызвать UB при чтении промежуточного значения?
Флаг компиляции -std=c11 говорит о том, что компиляция ориенторована на линукс. Все ваши читатели на линуксе?
Ну почему же "ничего". Как минимум, этим продуктом можно заменить sqlite. Я бы не сказал, что sqlite ничего не умеет. Мозилла например в своем браузере sqlite использует, а могли бы duckdb
Автор здесь не описывает, однако DuckDB поставляется в виде библиотек и cli. И вот cli - штука крутая, анализировал ей наборы данных в миллионы записей.
Задачи по типу "собрать айдишки из csv/экселя и выявить дубликаты" спокойно решается прямо из DuckDB: SELECT * FROM 'data.csv' WHERE id IN (SELECT id FROM 'data.csv' GROUP BY id HAVING COUNT(*) > 1). Или другими запросами, у вас по-сути на руках sqlite с фичами pg и не только. При работе с экселем потребуется расширение, которое входит в состав duckdb из коробки.
Ещё одна опция «Sparse VHD» автоматически сжимает размер виртуального жёсткого диска
На самом деле, не сжимает, а деаллоцирует, разрежает. Блоки с нулями в разреженных файлах просто не выделяются и не хранятся на диске, а блоки с данными хранятся как есть.
НО! При этом, хоть о сжатии в оригинале не написано, теперь WSL (и докер кстати тоже) поддерживает сжатие (не разреженность, а именно сжатие NTFS). Что для меня оказалось очень востребованным, т.к. wsl использует ext4, которое не умеет в сжатие, а образ того же докера спокойно растет до 100гб (которые можно сжать теперь в 40, по крайней мере у меня).
rustmustdie до сих пор кажется скорее шуточной статьей, нежели чем-то серьезным. В другой статье, cmustdie, где Алексей является соавтором, приводятся более адекватные (на мой взгляд) аргументы.
Очень надеюсь, что через некоторое время автор скажет что-то на подобии "Расходимся, это была шутка".
Хабр мне всегда казался чем-то вроде журнала, где выкладывают научный, близко стоящий или просто полезный материал. Конечно, написать бота в 12 лет - хорошо, написать рабочего бота - еще лучше (без шуток, не у каждого получается, даже если склад ума вроде бы соответствует), но, как мне кажется, статье следует быть не на хабре (и, видимо, не мне одному кажется, т.к. судя по комментариям, плюсы ставили, но оценка у статьи 0, значит, столько же минусов).
Для меня хабр это место, где люди могут поделиться своими (и не совсем) открытиями, новостями, прямо или косвенно относящимся к хабу, интересными мыслями, практиками и т.д. Всё перечисленное объединяет полезность (как, к примеру, статья, на которую ссылался автор). Ну или у меня не тот образ хабра сложился.
Из этой статьи я узнал, что, почему-то, asyncio все еще не везде используется. С одной стороны, он тут пока не нужен, да и бот спроектирован для работы одновременно с одним пользователем, с другой - не все боты так используются, а асинхронность полезна для развития. К слову, в статье, на которую ссылается автор, предусмотрена работа с несколькими пользователями.
Я, конечно, рад, что вы умелы в столь юном возрасте, но ваша задача (или, по крайней мере, её исполнение), по моему мнению, не тянет на статью. За грамматику хвалю, на уровне.
Действительно, мне стоило сначала статью прочитать, прежде чем что-то писать. Здесь нет упора в процессор (о которой я думал, читая про конкурентность), а как раз IO-нагрузка. Моя ошибка, прошу прощения.
По поводу памяти: асинхронные задачи в расте представляют собой структуру, в которую была преобразована асинхронная функция (или была явно реализована структура с трейтом Future), в Go же корутины имеют свой собственный контекст (~4.4KiB по словам знакомого разработчика на Go).
Но что случилось в пятом тесте - мне не ясно. Я бы предположил, что в предыдущих тестах выполняются блокирующие сишные вызовы, из-за чего создается больше потоков, чем обычно. Но "спать"-то go должен уметь, а значит в первом тесте такой проблемы нет.
Крайне плохая идея использовать асинхронщину в задачах с упором в процессор. Сами разработчики не рекомендуют (секция "When not to use tokio") использовать в подобных задачах tokio, т.к. он спроектирован для решения проблем, завязанных на вводе-выводе. В качестве альтернативы предлагается крейт rayon (который, к слову, тоже использует модель задач, не порождая бесчисленное количество потоков).
У меня, в общем-то, и без них твиттер не грузился. Уж не знаю, приколы это были мобильных операторов и всея России, однако теперь их хотя бы можно объяснить.
Если вы хотите, действительно обеспечить надежность файла в Linux, вы должны открыть дескриптор к каталогу содержащему файл и также применить для него fsync().
Разве кроссплатформенность не должна гарантировать идентичного результата на разных платформах? Возможно, это было сделано ради производительности, но не думаю, что уместно жертвовать некоторым шансом записи, когда мы хотим гарантий, что она произойдет.
Напрягает лишь, что есть возможность хранить индекс объектом, и что возможность в [] указывать new Index() позволяет и поощрает создавать отдельный объект для обращения к элементу по индексу, а создавать лишние объекты - не есть хорошо. Но если данная фича также имеет поддержку compile-time развертки a[^N] в a[a.lenght - N], то вопросов меньше
Наконец-то кто-то об этом написал! Буквально вчера ныл по этому поводу и тут статья.
Давно пора что-то менять! И не просто "что-то", а либо основу, фреймворки всякие, либо сам подход к разработке софта. У меня давно претензии есть к Windows.
Размер тестового файла в CrystalDiskMark слишком мал. Есть высокая вероятность, что на стороне хранения это всё оседает в кешах (в т.ч. DRAM, он как раз часто не меньше 1ГБ). Особенно по отношению к RUVDS.
С размером потоков не игрались? T1 может не на всех решениях утилизировать диск нормально.
Другой вопрос же к самим провайдерам... Современные потребительские NVME спокойно держат Read 4k Q32T1 под 500МБ\с, а тут подобными скоростями хвастается только RUVDS. Как умудрились производительность потерять?
А почему не Linux, кстати? Если сервер - то линукс, иначе извращение. А с виндой... Вот, недавно новость прошлась: "В Windows Server 2025 добавлена нативная поддержка накопителей NVMe". А у вас в тестах уже есть эта поддержка? А на всех тачках?
Все пишут комментарии с вопросами/сомнениями по реализации.
А я напишу простое человеческое "Спасибо", выручил! Не всегда есть возможность открыть что-то удобное для логов, особенно когда это на удаленном узле.
ToArray под капотом - это простой ToList().ToArray(), так что там не просто создается лишний список, там трафика памяти в 2 раза больше.
Я даже не знаю что спросить первым... Т.е. второй вариант не хранит данные в оперетивной памяти? Т.е., в первом варианте данные не будут попадать в кеш процессора?
Как именно процессоры взаимодействуют с компиляторами?
Но явно не приведённый пример.
Зачем компилятору угадывать это?
Структуры же не столько хороши в доступе к данными, сколько в своей природе: они являются значимыми типами, т.е. выделяются и хранятся "на месте", вне зависимости от того, где это место.
Эффективный доступ к ним исходит из этого свойства, поскольку массив таких структур обладает высокой локальностью кеша при последовательном обходе (но и сам массив весит больше, что делает реаллокацию массива дорогим).
Гарантируется спецификацией, т.е. зависит от реализации.
С чего бы ему держать ядро активным? И чем конкретно блокируется? Async'и призваны плодить меньше потоков и заменяют собой вызовы типа sleep или read. Делает ли активным ядро блокировка потока приемом соединения через вызов accept? Мы можем тут ждать достаточно долго.
Выше вы советовали использовать os.sleep чтобы дать ядру "отдохнуть". Но ведь это тоже блокировка потока. Тогда в чем выгода использовать os.sleep, если заблокированный поток якобы держит ядро CPU активным?
Возможно, с python 3.13 и беж GIL и имеет смысл, но гораздо проще и из коробки реализуется однопоточный кэш, к которому обращаются задачи из асинхронного кода.
Сишку бы более подробно написать, хотя бы по корректировку счетчика ссылок.
Вы заменяете значение объекта через его id, т.е. сам объект из кэша, а не кэш. Получается, возможна ситуация, когда я из кэша взял один объект, затем в процессе работы кто-то мне этот объект заменил на лету?
Ну и как вы планируете обходить возникшую гонку данных, т.к. в то время как писатель атомарен, читатель - нет, и может прочесть мусор. Это может вызвать UB при чтении промежуточного значения?
Флаг компиляции -std=c11 говорит о том, что компиляция ориенторована на линукс. Все ваши читатели на линуксе?
Ну почему же "ничего". Как минимум, этим продуктом можно заменить sqlite. Я бы не сказал, что sqlite ничего не умеет. Мозилла например в своем браузере sqlite использует, а могли бы duckdb
Не совсем понятно, к чему конкретно претензия
Автор здесь не описывает, однако DuckDB поставляется в виде библиотек и cli. И вот cli - штука крутая, анализировал ей наборы данных в миллионы записей.
Задачи по типу "собрать айдишки из csv/экселя и выявить дубликаты" спокойно решается прямо из DuckDB: SELECT * FROM 'data.csv' WHERE id IN (SELECT id FROM 'data.csv' GROUP BY id HAVING COUNT(*) > 1). Или другими запросами, у вас по-сути на руках sqlite с фичами pg и не только. При работе с экселем потребуется расширение, которое входит в состав duckdb из коробки.
Пожалейте нас... У нас уже есть yopta.space
Забавно, всегда считал это нормой. А так, оказывается, не должно было быть.
На самом деле, не сжимает, а деаллоцирует, разрежает. Блоки с нулями в разреженных файлах просто не выделяются и не хранятся на диске, а блоки с данными хранятся как есть.
НО! При этом, хоть о сжатии в оригинале не написано, теперь WSL (и докер кстати тоже) поддерживает сжатие (не разреженность, а именно сжатие NTFS). Что для меня оказалось очень востребованным, т.к. wsl использует ext4, которое не умеет в сжатие, а образ того же докера спокойно растет до 100гб (которые можно сжать теперь в 40, по крайней мере у меня).
rustmustdie до сих пор кажется скорее шуточной статьей, нежели чем-то серьезным. В другой статье, cmustdie, где Алексей является соавтором, приводятся более адекватные (на мой взгляд) аргументы.
Очень надеюсь, что через некоторое время автор скажет что-то на подобии "Расходимся, это была шутка".
Хабр мне всегда казался чем-то вроде журнала, где выкладывают научный, близко стоящий или просто полезный материал. Конечно, написать бота в 12 лет - хорошо, написать рабочего бота - еще лучше (без шуток, не у каждого получается, даже если склад ума вроде бы соответствует), но, как мне кажется, статье следует быть не на хабре (и, видимо, не мне одному кажется, т.к. судя по комментариям, плюсы ставили, но оценка у статьи 0, значит, столько же минусов).
Для меня хабр это место, где люди могут поделиться своими (и не совсем) открытиями, новостями, прямо или косвенно относящимся к хабу, интересными мыслями, практиками и т.д. Всё перечисленное объединяет полезность (как, к примеру, статья, на которую ссылался автор). Ну или у меня не тот образ хабра сложился.
Из этой статьи я узнал, что, почему-то, asyncio все еще не везде используется. С одной стороны, он тут пока не нужен, да и бот спроектирован для работы одновременно с одним пользователем, с другой - не все боты так используются, а асинхронность полезна для развития. К слову, в статье, на которую ссылается автор, предусмотрена работа с несколькими пользователями.
Я, конечно, рад, что вы умелы в столь юном возрасте, но ваша задача (или, по крайней мере, её исполнение), по моему мнению, не тянет на статью. За грамматику хвалю, на уровне.
Действительно, мне стоило сначала статью прочитать, прежде чем что-то писать. Здесь нет упора в процессор (о которой я думал, читая про конкурентность), а как раз IO-нагрузка. Моя ошибка, прошу прощения.
По поводу памяти: асинхронные задачи в расте представляют собой структуру, в которую была преобразована асинхронная функция (или была явно реализована структура с трейтом Future), в Go же корутины имеют свой собственный контекст (~4.4KiB по словам знакомого разработчика на Go).
Но что случилось в пятом тесте - мне не ясно. Я бы предположил, что в предыдущих тестах выполняются блокирующие сишные вызовы, из-за чего создается больше потоков, чем обычно. Но "спать"-то go должен уметь, а значит в первом тесте такой проблемы нет.
Крайне плохая идея использовать асинхронщину в задачах с упором в процессор. Сами разработчики не рекомендуют (секция "When not to use tokio") использовать в подобных задачах tokio, т.к. он спроектирован для решения проблем, завязанных на вводе-выводе. В качестве альтернативы предлагается крейт rayon (который, к слову, тоже использует модель задач, не порождая бесчисленное количество потоков).
У меня, в общем-то, и без них твиттер не грузился. Уж не знаю, приколы это были мобильных операторов и всея России, однако теперь их хотя бы можно объяснить.
Нередко в документации проскакивали русифицированные названия методов. Ситуацию спасал лиль пример кода.
По крайней мере такая ситуация была в документации по С# год назад.
Разве кроссплатформенность не должна гарантировать идентичного результата на разных платформах? Возможно, это было сделано ради производительности, но не думаю, что уместно жертвовать некоторым шансом записи, когда мы хотим гарантий, что она произойдет.
Напрягает лишь, что есть возможность хранить индекс объектом, и что возможность в [] указывать new Index() позволяет и поощрает создавать отдельный объект для обращения к элементу по индексу, а создавать лишние объекты - не есть хорошо. Но если данная фича также имеет поддержку compile-time развертки a[^N] в a[a.lenght - N], то вопросов меньше
Наконец-то кто-то об этом написал! Буквально вчера ныл по этому поводу и тут статья.
Давно пора что-то менять! И не просто "что-то", а либо основу, фреймворки всякие, либо сам подход к разработке софта. У меня давно претензии есть к Windows.