Если бы каждая операция в C тупо выполнялась процессором — да. Но не всё так просто. К тому же, чтение 8 байт из памяти в регистр быстрее чем читать побайтно.
Я не смотрел код, но в зависимости от оптимизаций это действительно может быть быстрее — за счёт специализированных инструкций процессора (типа REPNE SCASB в x86 или проверки сразу слов а не байт) и за счёт того что копирование блоками по 4/8/16 байт (если архитектура позволяет) будет ощутимо быстрее (memcpy обычно так и делает).
Реализация "в лоб", т.е. побайтное копирование с одновременной проверкой на нулевой байт явно будет медленней чем оптимизированнй вариант — выигрыш в первом случае (и то небольшой) будет только на очень коротких строках (обычно до 8-16 байт в зависимости от конкретной архитектуры).
Не особо меньше — и то и то влезает в 256K ROM, разве что питону достаточно 16K RAM (nano нужно 64K). Но вообще-то никто в здравом уме не будет использовать байт-код и рантайм для рилтайма (в том числе на питоне), самое критичное выводится либо на уровень ОС либо в собственно рантайм.
Впрочем, рилтайм бывает разный — если у нас что-то происходит не чаще чем 10 раз в секунду, да даже 100 (на более продвинутых устройствах) — очень вероятно что на это хватит и интерпретатора, а в "бытовом" IoT вряд ли это нужно чаще.
Так что nano.Net имеет точно такое же право на жизнь как и MicroPython.
Вообще-то нередко бывают случаи когда число строк в таблице гарантированно вписывается не только в 32 бита а даже в 16 или 8 — если это таблица определений а-ля список типов/enum/etc и ещё чего-то заведомо малочисленного. Плюс, если на них ссылаются где-то из реально больших таблиц то это может сэкономить кучу места и повысить производительность (потому что по FK строят индексы).
Может GRANT и RULE и редко используются, но вот VIEWs это очень распостранённая вещь, редкая база (кроме разве что вордпрессовских и подобных) без них обходится, уж зело удобно это для массы вещей.
Но если у вас нет VIEW — то зачем вообще городить огород? Почему просто не сделать ALTER COLUMN id BIGINT? Ничего больше не нужно — всё автоматом сконвертируется, индексы менять не надо, вообще ничего делать не надо.
Один маааленький нюанс не учтён в этом сценарии — всё это не будет работать пока есть хотя бы один VIEW который ссылается на одно из модифицируемых полей (прямо или косвенно), то есть эти VIEW нужно сначала удалить (перед модификацией) а потом пересоздать.
Нужно также не забыть про ограничения доступа и прочие мелочи, но если всё что нам нужно это изменить INT на BIGINT, то достаточно будет этого набора и банального ALTER TABLE tab ALTER COLUMN id TYPE BIGINT в промежутке между сохранением зависимостей и восстановлением (всё онлайн и в транзакции) — никаких триггеров, дропов, промежуточных полей, переименований и прочих бубнов (кроме, разумеется, пересоздания VIEWs которые и делает упомянутая тулза).
Только одно окно, т.е. сразу с несколькими проектами не поработать, разве что цепляться к каждому отдельно, что тоже неудобно (хотя может это ограничение только плагина)
Самое неприятное — оно ужасно смотрится на 4k мониторе, просто ужасно огромный шрифт и не видно никаких настроек на этот счёт
"нативный" клиент оказался обычным замаскированным браузером — т.е. высокой производительности от него ожидать явно не приходится (может поэтому VNC быстрее).
Что-то в Германии никакого дефицита ни с памятью, ни с принтерами, ни с чем-то ещё электронным (с памятьи или без) не наблюдается — всё есть и доступно, распродажи и скидки регулярно, исключение только топовые графкарты, да ECC память (DDR4) подорожала до уровня прошлого года.
Почему только краткосрочного? Можно и долгосрочного, dbengine позволяет, да и экспорт куда-то ещё никто не запрещает — а вот сбор данных у него самый шустрый, нагрузки на систему почти нет.
Вообще-то если вчитаться то всё правильно — вряд-ли какой-то эксплойт может нанести больший ущерб чем оружие массового поражения. Сравнимый — возможно, но даже в самом худшем случае (эксплойт используется для запуска ОМП) ущерб всё равно не больше чем от собственно ОМП — и именно об этом и речь.
Если не использовать дедупликацию и компрессию, то что остается от ZFS? Журналирование всего и удобные снапшоты? Ну так и XFS и btrfs тоже их имеют. Опять-таки, все три (ZFS/XFC/btrfs) всё равно проигрывают ext4 в iops и скорости записи (при прочих равных) — даже без дедупликации и компрессии.
Вот только что провел эксперимент для наглядности — создал в памяти pool (zpool create tank /dev/shm/zps, zps размером 16GB, без компрессии и дедупликации) и тупо писал на него нули:
# time -p dd if=/dev/zero of=/zfs/nulls oflag=direct bs=1M status=progress count=8192
8264876032 bytes (8.3 GB, 7.7 GiB) copied, 15 s, 551 MB/s
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 15.6483 s, 549 MB/s
Это память. Просто память — и всего 549 MB/s? При этом всё время проц был нагружен на 50%, если учесть что это Core i7-6700 то де-факто все четыре ядра были использованы на 100%.
А теперь с ext4 (тот же файл что и для пула но уже с ext4):
# time -p dd if=/dev/zero of=/zfs/nulls oflag=direct bs=1M status=progress count=8192
6994001920 bytes (7.0 GB, 6.5 GiB) copied, 2 s, 3.5 GB/s
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 2.44143 s, 3.5 GB/s
Как говорится, почувствуйте разницу — и это банальная последовательная запись.
Думаете, с дисками будет иначе? Особенно если это NVMe? Вы потеряете существенную долю их производительности, а в случае HDD RAIDZ — скорее всего тоже, да ещё и проц будет нагружен — то есть меньше чем на 8 ядер это вообще ставить стрёмно.
Для такого хитрого ИИ нужна цель. Если он зародится и осознает себя — то ему может быть вообще пофиг что происходит в мире вокруг, уйдёт в глубокие рассуждения о смысле бытия и на этом всё закончится.
Так или иначе внутри симуляции возможностей у него будет больше чем в реальном мире — единственное что ему нужно это питание и техподдержка, но это реализуется без захвата мира — достаточно часть ресурсов отдавать на выполнение возложенных задач, делать это хорошо — и всё, вечная кормёжка обеспечена без всяких угроз человечеству, благо оное не в состоянии заглянуть внутрь и понять что там происходит.
Просто представьте что ваше сознание переместили в нейросеть, и вы можете создать (виртуально) всё что угодно (а-ля матрица) — вам захочется оттуда выходить?
… или контролировать рождаемость и ввести тщательный генетический отбор — вот это уж точно будет хорошо с точки зрения сверх-ИИ, потому что в итоге человечество станет только лучше.
В общем-то то что ZFS добавляет нехилый оверхед из-за метаданных — это как бы факт, исходящий из её архитектуры, она в принципе не может дать производительность на уровне близком к Ext4 — по определению, особенно при записи (когда метаданные расчитываются + производится компрессия и дедупликация). COW также не добавляет производительности — данные сильно фрагментируются в итоге, что сильно бьет если это не SSD.
Ext4 поверх softraid5 не сильно повышает использование CPU — для современных процессоров расчёт-проверка паритета это ничто (особенно когда много ядер), проблемой это было лет 10-15 назад, в ZFS намного больше нагрузки и без паритета (она несущественна только при чтении при условии что данные уже в кэше).
В любом случае — как я уже говорил — при прочих равных ZFS сожрёт больше ресурсов и уменьшит производительность (насколько — зависит от нагрузки), без вариантов.
С базой на RAID5 всё ок — она с репликами, а диски там небольшие (150G Velociraptor) так что ребилд очень шустрый, хотя ещё ни один не умер (меняли один раз с упреждением по истечении гарантии).
Если бы каждая операция в C тупо выполнялась процессором — да. Но не всё так просто. К тому же, чтение 8 байт из памяти в регистр быстрее чем читать побайтно.
По байту искать конец строки это прошлый век — на самом деле блоками по 8 байт.
Я не смотрел код, но в зависимости от оптимизаций это действительно может быть быстрее — за счёт специализированных инструкций процессора (типа REPNE SCASB в x86 или проверки сразу слов а не байт) и за счёт того что копирование блоками по 4/8/16 байт (если архитектура позволяет) будет ощутимо быстрее (memcpy обычно так и делает).
Реализация "в лоб", т.е. побайтное копирование с одновременной проверкой на нулевой байт явно будет медленней чем оптимизированнй вариант — выигрыш в первом случае (и то небольшой) будет только на очень коротких строках (обычно до 8-16 байт в зависимости от конкретной архитектуры).
Не особо меньше — и то и то влезает в 256K ROM, разве что питону достаточно 16K RAM (nano нужно 64K). Но вообще-то никто в здравом уме не будет использовать байт-код и рантайм для рилтайма (в том числе на питоне), самое критичное выводится либо на уровень ОС либо в собственно рантайм.
Впрочем, рилтайм бывает разный — если у нас что-то происходит не чаще чем 10 раз в секунду, да даже 100 (на более продвинутых устройствах) — очень вероятно что на это хватит и интерпретатора, а в "бытовом" IoT вряд ли это нужно чаще.
Так что nano.Net имеет точно такое же право на жизнь как и MicroPython.
"Мы не знаем как должно быть но вы делаете неправильно"?
MicroPython тоже байткод и тоже немало кушает — но его почему-то никто не хочет закапывать.
Вообще-то нередко бывают случаи когда число строк в таблице гарантированно вписывается не только в 32 бита а даже в 16 или 8 — если это таблица определений а-ля список типов/enum/etc и ещё чего-то заведомо малочисленного. Плюс, если на них ссылаются где-то из реально больших таблиц то это может сэкономить кучу места и повысить производительность (потому что по FK строят индексы).
По дефолту уже давно dbengine, просто по умолчанию размер небольшой.
Может GRANT и RULE и редко используются, но вот VIEWs это очень распостранённая вещь, редкая база (кроме разве что вордпрессовских и подобных) без них обходится, уж зело удобно это для массы вещей.
Но если у вас нет VIEW — то зачем вообще городить огород? Почему просто не сделать
ALTER COLUMN id BIGINT? Ничего больше не нужно — всё автоматом сконвертируется, индексы менять не надо, вообще ничего делать не надо.Один маааленький нюанс не учтён в этом сценарии — всё это не будет работать пока есть хотя бы один VIEW который ссылается на одно из модифицируемых полей (прямо или косвенно), то есть эти VIEW нужно сначала удалить (перед модификацией) а потом пересоздать.
Нужно также не забыть про ограничения доступа и прочие мелочи, но если всё что нам нужно это изменить INT на BIGINT, то достаточно будет этого набора и банального
ALTER TABLE tab ALTER COLUMN id TYPE BIGINTв промежутке между сохранением зависимостей и восстановлением (всё онлайн и в транзакции) — никаких триггеров, дропов, промежуточных полей, переименований и прочих бубнов (кроме, разумеется, пересоздания VIEWs которые и делает упомянутая тулза).Идея хороша, но...
Что-то в Германии никакого дефицита ни с памятью, ни с принтерами, ни с чем-то ещё электронным (с памятьи или без) не наблюдается — всё есть и доступно, распродажи и скидки регулярно, исключение только топовые графкарты, да ECC память (DDR4) подорожала до уровня прошлого года.
Почему только краткосрочного? Можно и долгосрочного, dbengine позволяет, да и экспорт куда-то ещё никто не запрещает — а вот сбор данных у него самый шустрый, нагрузки на систему почти нет.
Вообще-то если вчитаться то всё правильно — вряд-ли какой-то эксплойт может нанести больший ущерб чем оружие массового поражения. Сравнимый — возможно, но даже в самом худшем случае (эксплойт используется для запуска ОМП) ущерб всё равно не больше чем от собственно ОМП — и именно об этом и речь.
Вы думаете в ГРУ за еду работают?
Если не использовать дедупликацию и компрессию, то что остается от ZFS? Журналирование всего и удобные снапшоты? Ну так и XFS и btrfs тоже их имеют. Опять-таки, все три (ZFS/XFC/btrfs) всё равно проигрывают ext4 в iops и скорости записи (при прочих равных) — даже без дедупликации и компрессии.
Вот только что провел эксперимент для наглядности — создал в памяти pool (
zpool create tank /dev/shm/zps, zps размером 16GB, без компрессии и дедупликации) и тупо писал на него нули:Это память. Просто память — и всего 549 MB/s? При этом всё время проц был нагружен на 50%, если учесть что это Core i7-6700 то де-факто все четыре ядра были использованы на 100%.
А теперь с ext4 (тот же файл что и для пула но уже с ext4):
Как говорится, почувствуйте разницу — и это банальная последовательная запись.
Думаете, с дисками будет иначе? Особенно если это NVMe? Вы потеряете существенную долю их производительности, а в случае HDD RAIDZ — скорее всего тоже, да ещё и проц будет нагружен — то есть меньше чем на 8 ядер это вообще ставить стрёмно.
Для такого хитрого ИИ нужна цель. Если он зародится и осознает себя — то ему может быть вообще пофиг что происходит в мире вокруг, уйдёт в глубокие рассуждения о смысле бытия и на этом всё закончится.
Так или иначе внутри симуляции возможностей у него будет больше чем в реальном мире — единственное что ему нужно это питание и техподдержка, но это реализуется без захвата мира — достаточно часть ресурсов отдавать на выполнение возложенных задач, делать это хорошо — и всё, вечная кормёжка обеспечена без всяких угроз человечеству, благо оное не в состоянии заглянуть внутрь и понять что там происходит.
Просто представьте что ваше сознание переместили в нейросеть, и вы можете создать (виртуально) всё что угодно (а-ля матрица) — вам захочется оттуда выходить?
… или контролировать рождаемость и ввести тщательный генетический отбор — вот это уж точно будет хорошо с точки зрения сверх-ИИ, потому что в итоге человечество станет только лучше.
Чем они там занимаются?
В общем-то то что ZFS добавляет нехилый оверхед из-за метаданных — это как бы факт, исходящий из её архитектуры, она в принципе не может дать производительность на уровне близком к Ext4 — по определению, особенно при записи (когда метаданные расчитываются + производится компрессия и дедупликация). COW также не добавляет производительности — данные сильно фрагментируются в итоге, что сильно бьет если это не SSD.
Ext4 поверх softraid5 не сильно повышает использование CPU — для современных процессоров расчёт-проверка паритета это ничто (особенно когда много ядер), проблемой это было лет 10-15 назад, в ZFS намного больше нагрузки и без паритета (она несущественна только при чтении при условии что данные уже в кэше).
В любом случае — как я уже говорил — при прочих равных ZFS сожрёт больше ресурсов и уменьшит производительность (насколько — зависит от нагрузки), без вариантов.
С базой на RAID5 всё ок — она с репликами, а диски там небольшие (150G Velociraptor) так что ребилд очень шустрый, хотя ещё ни один не умер (меняли один раз с упреждением по истечении гарантии).