rPman

пот первое же нагугленное исследование использования 8-битных и 16-битных весов на nvidia gpu

5 Conclusions
We have demonstrated DNN training with 8-bit floating point numbers (F P 8) that achieves 2 − 4×
speedup without compromise in accuracy. The key insight is that reduced-precision additions (used
in partial product accumulations and weight updates) can result in swamping errors causing accuracy
degradation during training. To minimize this error, we propose two new techniques, chunk-based
accumulation and floating point stochastic rounding, that enable a reduction of bit-precision for
additions down to 16 bits – as well as implement them in hardware. Across a wide spectrum of
popular DNN benchmarks and datasets, this mixed precision F P 8 training technique achieves the
same accuracy levels as the F P 32 baseline. Future work aims to further optimize data formats and
computations in order to increase margins as well as study additional benchmarks and datasets.

еще есть огромные нейронные сети, требующие неадекватно большие объемы оперативной памяти, что очень дорого, когда речь идет о нейроннх сетях
Например, те же проекты OpenAI, напомню чтобы запустить тот сберовский ruDALL-e понадобится видеокарта больше 6Gb RAM (можно и с таким но потребуются телодвижения и сильно больше времени), если я верно понял тут используются 16-битные веса, а если переделать на 8-битные, требования к памяти можно еще сильнее понизить.

есть еще разработки по использованию 1битных весов (ума не приложу как это работает), гугл выдает кучу статей

Если нужны данные, отнеси специалисту, любая самодеятельность, если не разбираешься, до добра не доведет.

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

p.s. помимо синхронизации с mi cloud есть еще гугловская, она включается очень легко, что если жмахать во время ввода первого логина не глядя, не заметишь включишь.
попробуй

значит узкое место почти наверняка диск.

Пальцем в небо, файловая система на которой таблеспейсы лежат какая? случайно не cow (btrfs/zfs/xfs)? с ними отвратительно работают базы данных, так как частые записи в файл генерируют сильную фрагментацию. В этом случае перед тяжелой обработкой хотя бы дефрагментируй файлы базы и отключи cow фичу на таблеспейсах

неплохим тюнингом может оказаться (на выбор):
* разместить базу в ram диске (буквально, залить на сервер в облаке, обработать данные, залить назад, работая напрямую с таблеспейсами, но версия софта должна совпадать до последней цифры)
* разместить базу целиком на ssd (даже если это будет потребительский и дешевый)
* добавить в систему ssd кеш для hdd с помощью например bcache (включенный на запись), правда для линейной обработки базы это может дать мало пользы, но вообще это неплохой способ на порядок поднять производительность за дешево (в одном месте я использовал фичу virtualbox со снапшотами в файл, есть и у kvm, когда последующие записи шли не на исходный образ а на другой диск, и он ssd)
* разместить таблеспейс для индексов (а может и каждую таблицу отдельно) на другом физическом устройстве (hdd, ssd или даже в ram), требования к размеру тут обычно низкие, ключевое слово - исключить последовательные чтения/записи на одно устройство.
* разместить журнал (например ext4) на ssd диск (хватит пары гигабайт) или по хардкору даже отключить его (очень опасно, можно получить кашу из данных при сбое питания, но как временное решение пока идет долгая операция, при наличии всех бакапов, оправдано) - наименьшая оптимизация, но при частых мелких записях это заметно

Если данные будут смотреть люди исключительно глазами (и в лучшем случае в экселе фильтрацию по подстроке будут делать), до достаточно список в ячейку разместить объединив строки с помощью implode, с каким нибудь разделителем, например ';' или '|' (очень редко используется, коллизий будет гораздо меньше, что даже можно считать машиночитаемым)

Если с данными нужно будет работать, например фильтрация, то делай декардово произведение по каждой строке с со своим списком. В результате данных из-за дублирования будет очень много (на столько что это часто становится проблемой) но зато с таким документом более менее можно работать (фильтрация работает прямо в интерфейсе экселевского фильтра) плюс машиночитаемо, плюс и глазами кое что можно разглядеть.

Эксель - наиболее неудобный инструмент для передачи данных, все из-за того, что обычные пользователи не желают осваивать базы данных и sql, хотя визуальных их редакторов уже пруд пруди...

Советую вспомнить хотя бы ms access (если уж закупили офис и на что то другое тратиться нет желания и сил), одно время mdb файлы даже как файлы экспорта данных и даже формат хранения использовались, удобно, машиночитаемо, компактно и интерфейс прямо на рабочем столе.

Сейчас это не имеет значения, почти для любой базы данных есть удобные инструменты, так что передавать можно к примеру в sqlite формате, или sql, или хотя бы в csv файлах (жуть как неудобно, но страдальцы могут хотя бы без каких либо знаний открыть их в любимом экселе)

Когда ты разрабатываешь какое то приложение, не важно на сколько сложное, ты же не пишешь его с нуля и до конца полностью (точнее такое бывает но редко, для не сильно больших задач и у этого метода есть недостатки - больше подвержен ошибкам), наоборот, код идеологически разбивается на части или этапы разработки, каждый из которых пишется по очереди, до принципиальной возможности запуска, часто кстати в уже написанные части подставляются заглушки (и/или подсовывается база данных в определенном состоянии) и добавляются отладочные сообщения, чтобы приложение запустилось в нужном состоянии чтобы в принципе была возможность протестировать только что написанную часть.

Под протестировать я подразумеваю любой способ проверить, что получится, как программа отреагирует (например что напишет в логах), и сравнить это с ожидаемым поведением.

Что значит ожидаемое поведение? когда ты делишь задачу на подзадачи, у тебя появляются промежуточные данные и состояния, ну как в анекдоте про чайник и программиста, чтобы заварить чай нужно:
* налить воду в чайник
* поставить на базу/печку и включить
* дождаться готовности/выключить
* налить чай
на каждом этапе нужно проверять состояние, например первый пункт - есть ли вода в чайнике, горячая ли она или холодная, полный ли чайник, есть ли у тебя чайник в руках, и т.п.

Тесты создают на основе данных, являющихся нормальными, ненормальными и граничными для тех алгоритмов, что используются в коде. К примеру нет нужды проверять температуру воды в чайнике отдельно на фиксированные значения 10, 20, 30,.. градусов, если в алгоритме заложены естественные их границы - холодная и горячая, вот вокруг этих констант и приходится гулять.

Вот именно эти проверки и есть тесты, которые необходимо автоматизировать.

Степень полноты тестирования вопрос философский, в конечном счете тесты нужны не только для автоматического тестирования и составления отчетности на изменения кода, но и собственно для разработки, разрабатывая тесты ты делаешь код полнее и точнее (например проверяя температуру воды на первом шаге ты добавишь в код условие - если вода горячая, то пропустить ее нагрев), почитай про test-driven development, TDD

p.s. а еще тесты - это способ исследовать неизвестную библиотеку, дело в том что open source реалии таковы, что документации нет от слова совсем, в лучшем случае перед тобой список методов с типами аргументов и пара примеров, все остальное нужно догадываться по логике наименований, здравому смыслу и ковырянии в исходниках. Тесты тут могут быть исключительно как способ изучения этой библиотеки, но не обязательно такие тесты реализовывать в коде, это все же процесс в ручную происходит, но все же, создавать тесты на ответы от чужой библиотеки полезно для длительной поддержки проекта для того, чтобы у тебя были алерты на необычное поведение ее после обновления)

создание правильных и полных тестов очень сильно повышают стоимость разработки и поддержки проекта, причем чуть ли не на порядок, но дает некоторую защиту от смерти проекта в будущем из-за накапливающихся ошибок, о которых ничего не ясно без тестов.

и еще, создать тесты с нуля на готовый проект почти невозможно.