Вот мне интересно. Автор сам читает свои собственные заголовки?
Тут не надо быть филологом чтобы просто поймать вывих мозга.
Хм.... одного int между собой. Это как хлопок одной ладонью..
freeExec, сборник звуков может не подходить по объему занимаемой памяти например.
В данном случае нейросеть работает как архиватор. Оптимизируя хранение. Можно
сказать что архивация является побочнным эффектом этой задачи. Хотя и явно
не описаной автором.
В данном задании самое сложное - это поиск обучающих датасетов по звукам.
Я предлагаю автору начать с этого. Когда в базе будет хотя-бы по 100 семплов звучания шагов, потом трелей соловья, и прочее, можно начать обсуждать архитектуры сети а самое главное - аксептенс-критерии.
Потому что последние - это самая слабая часть в постановке.
Там не в лень дело. При разработке linux (kernel) насколько я знаю главным аппрувером
изменений является горячий финский парень Торвальдс. Это очень жесткий и вредный
чел. У него есть несколько цитат в группе разработки ядра где он объясняет почему С++
не подходит для разработки. Один раз сказал что-то вроде "Stuped idea". Вобщем
поищи сам я думаю найдешь.
Как по мне есть две вещи которые мешают затащить С++. Первое - это потеря контроля
над размером бинарника. За счет механики шаблонизации бинарь может быть несколько
в раз больше чем ожидался. Это убийственный артифакт для операционки. Нельзя просто
так раздуть ядро в несколько раз и расчитывать что оно будет так-же эффективным как и
раньше. Размер всех составляющих важен с точки зрения кеша инструкций.
И второе (IMHO) - время компилляции. Опять-же встроенные С++ шаблон-матчеры делают время
компилляции непредсказуемым (в одной из конферений говорят о недоказуемом
времени останова компилляции). Тоесть в теории - бесконечным.
Я не знаю сколько собирается ядро. Пускай знающие скажут. Но допустим оно собиралось
3 часа на сях. И после миграции в С++ цикл сборки может затянуться на 3 дня. Это
тоже слишком дорогая плата за просто замену языка.
Хотя может я ошибаюсь.
По поводу Rust в ядре. Ничего пока неясно. Я думаю этот вопрос можно задать отдельно в хабре.
Си - это портабельный ассемблер. Собственно такая задача и ставилась при создании языка. Облегчить написание частей Unix.
По поводу устарел или не устарел. Вот когда его заменят на другой язык при разработке Linux например, вот тогда и можно говорить о старении. А пока он безальтернативен.
Для чего вы вообще создаете пет-проект? Есть вариант - чтобы пройти собеседование.
В этом случае включайте туда все что будет интересовать работодателя.
Читал, что при использовании JOIN индексирование бесполезно.
Вот интересно где ты это читал. Я конечно знаю что мы живем в эпоху "плоской земли". Это когда любой заблуждающийся может найти целое сообщество таких-же заблудших душ. Ну да ладно.
Поскольку разработка под БД и SQL - это практика. То ты можешь подойти с практической стороны. Взять 2 таблицы (желательно поболее 1 гигабафт) и сделатьй JOIN их по PK и ссылочному ключу без индекса. И потом тоже самое с индексом. И не забудь предложение WHERE потому что оно тоже имеет значение.
Вообще индекс в наше время - это trade-off. Сделка по сути. Мы платим налог в виде какого-то % IOPS/CPU во время вставки OLTP транзакций и мы это ПРИНИМАЕМ и соглассны с этим.
Но мы взамен имеем очень короткое время поиска данных или JOIN.
Вообще проверь это все. И не верь никаким писателям.
И мне тоже не верь. Проверяй на своей базе время выборки для всего SELECT.
Вот мне интересно. Автор сам читает свои собственные заголовки?
Тут не надо быть филологом чтобы просто поймать вывих мозга.
Хм.... одного int между собой. Это как хлопок одной ладонью..