Когда поток блокируется, он держит ядро 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.
C++ обладает слишком огромным наследием, чтобы просто переработать даже малые участки языка. Из-за этого приходится тащить все старое, даже если этим больше никто не пользуется, иначе мы сломаем старый код и испортим совместимость.
Вместо переработки языка в целом, появляются иные языки, что так же высоки по уровню и с возможностью быть "ближе к железу" - Rust к примеру
Эта проблема терроризировала меня долго и была обнаружена в Windows 11 Dev сборке. Количество виртуальной памяти ограничивается количеством реальной памяти + размером файла подкачки, скорее всего у тебя файл подкачки отключен. Попробуй выставить файл подкачки в автоматическом режиме и хорошенько освободить жесткий диск для файла подкачки без данных. Достаточно будет какого-нибудь даже медленного диска, просто чтобы система понимала, что, в случае отсутствия сжатия памяти, данные будет куда деть. Я, на самом деле, на хабре статью об этом хотел написать, но посчитал, что не стоит того.
С чего бы ему держать ядро активным? И чем конкретно блокируется? 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.
C++ обладает слишком огромным наследием, чтобы просто переработать даже малые участки языка. Из-за этого приходится тащить все старое, даже если этим больше никто не пользуется, иначе мы сломаем старый код и испортим совместимость.
Вместо переработки языка в целом, появляются иные языки, что так же высоки по уровню и с возможностью быть "ближе к железу" - Rust к примеру
Эта проблема терроризировала меня долго и была обнаружена в Windows 11 Dev сборке.
Количество виртуальной памяти ограничивается количеством реальной памяти + размером файла подкачки, скорее всего у тебя файл подкачки отключен. Попробуй выставить файл подкачки в автоматическом режиме и хорошенько освободить жесткий диск для файла подкачки без данных. Достаточно будет какого-нибудь даже медленного диска, просто чтобы система понимала, что, в случае отсутствия сжатия памяти, данные будет куда деть.
Я, на самом деле, на хабре статью об этом хотел написать, но посчитал, что не стоит того.