mayton2019

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

Все настоящиее DLL-файлы имеют сигнатуру. Это магическое число (обычно 2 или 4 или 8 байт) которые прописываются в заголовке данного типа и никогда не меняются.

Для DLL я точно не помню но кажется совпадает с Windows-executable. Два символа 'M', 'Z' будут сигнатурой.

Теперь задача - найти все DLL-файлы на дисковой системе и найти один файл-уродец который этой сигнатуры
не имеет. Это и будет твой файл.

Для любого программиста - это задача на 10-20 минут.

Успех мероприятия будет зависеть от двух факторов.
1) Успеете ли вы грузить трафик? Тут я думаю будет все ОК при использовании TimeSeriesDB.
2) Успеете ли вы делать их анализ? И что за анализ? Нужно ли вам для анализа видеть консистентность
между всех приборов? Что за сложные типы данных? Как они будут участвовать в запросе.

Поищи по ключевому слову Stable Diffusion.

Ну для floating point чисел ничего интересного не происходит. Результат будет - бесконечность (Inf).
И эта бесконечность - это вполне себе реальная константа для таких чисел.

Очереди могут обеспечить exactly once. По крайней мере в настройках у многих есть такой параметр.

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

Декларация класса и реализация его методов могут лежать в разных файлах исходного кода (*.h, *.cpp)

До postgresql версии 13, если я не ошибаюсь, индексы были в полтора, а то и два раза больше. У нас на проекте версия 9, если не ошибаюсь, там индексы добавляют к памяти иногда по 5 гигов. Нормально ли это? Я слышал что индексы должны быть в пределах мегабайт, а не гигабайт.

Работаю с базами данных давно. Начинал с Oracle9i.
Большая часть индексов базируются на B+Tree. Хотя в последнее время в эпоху RocksDb/Cassandra/Tarantool
появились более интересные стурктуры такие как LSM-tree. Они по скорости записи более эффективны.

Про то что индексы должны быть размером в мегабайты - я впервые слышу. Возможно это фраза
вырвана из контекста. Там обсуждалось что-то другое. Поэтому приведите цитату на документацию.
Желательно от производителя БД.

В Оракле есть положительный эффект от периодической перестройки индекса (alter index rebuild).
Этот эффект временный и обычно связан с фактором кластеризации. Его очень любят новички и
часто сам вопрос является троллингом Oracle-профессионалов. Но это было лет 20 назад. Щас
в эпоху облак всем стало пофиг.

Всегда ли не кластиризованные индексы хранятся в оперативной памяти или это как-то можно регулировать?

Не знаю откуда ты такие вот факты черпаешь. Конечно лучше всю базу данных положить в память.
Но база обычно многократно превышает память и мы довольствуемся страничным кешем (page cache)
или buffer pool в других системах. И все они работают по принципу LRU (хранения наиболее горячих
блоков диска). А будет ли это таблица или индекс или еще какойто подвид объекта - это как повезет.
Во всех DBMS есть мониторинг этого страничного кеша. Вот посмотри что у тебя там лежит в час
наибольшей нагрузки. Это и будет самый правильный ответ на твой вопрос. И главное - практически
подтвержденный.

Читал, что бывает так, что индекс в таблице индекса хранит сразу данные определенных столбцов, а не ссылки на эти строки в основной таблице. В каких случаях и почему так бывает?

Приводи ссылки где ты читал потому-что в твоем пересказе получается мистика. Индекс обязан хранить
копии индексируемых столбцов. Иначе-бы поиск вообще не работал.
Если ты строишь композитный индекс по 3 полям то он и будет физически хранить 3 копии этих полей
и ROWID (физический указатель на позицию в таблице для строки). И при определенных условиях
оптимизатор может выдавать данные не из таблицы а прямо из индекса если в SELECT запросе
достаточно данных в индексе. Этим часто пользуются для оптимизации.

Есть альтернативные DBMS наподобие Amazon DynamoDB где индексов нет но есть полная реплика
таблицы которая по другому кластеризована. Динамо считает это индексом хотя с точки зрения
классической DBMS это просто маркетинговый обман.

UPD: R+Tree

Это - тяжелая книга для новичка. Начните с Вирта или Седжвика.

Мне не удавалось добиться от GPT генерации корректного кода под ассмблеры fasm/nasm.
Видимо все таки языковые модели обобщают языки настолько что не могут придерживаться
строгих правил при генерации. Может отсутсвие строгих правил - это как раз сильная сторона
этих моделей. В противном случае мы вернулись бы в эпоху Prolog-программирования и формальной
логики где программы бы всегда компилировались и работали но никакой фантазии или обобщения
из двух программ мы не получили-бы.

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

Я никогда не расчитывал на чяты в части чистого написания кода. Но например в сборе информации
эти чяты вполне себе полезны.

Как Jit Компиляторы обнаружат недостижимой код и лишние проверки?

Если мне не изменяет память, JIT компиллятор компилирует java-метод целиком. Переводя byte-code в машинный код для x86 например.

А то что спрашивает автор - это задача основного компиллятора который язык Java переводит в байткод.

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

ли Космические Лучи, в Ram попали, что тогда будет?

Программисты 20-го века работали в условиях глючной памяти (когда были ЭВМ на лампах и на тразнисторах)
и обрабатывали специальное прерывание типа "глюк в ячейке памяти".

С точки зрения современной парадигмы разработки - это невозможно. Никакой прикладной
программист не ставит себе задачу отслеживания целостности памяти. Это как-бы не его
уровень. Мы предполагаем что память надежна и всегда корректна. А иначе ОС выпадает
в синий экран и никаких принятий решения мы все равно не сделаем а облачные балансировщики
примут свои решения когда хост выпадет из сети.

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

Рассматривать такие случаи в топике Java - бесполезно и контр-продуктивно. Давайте
их рассматривать в топиках инфо-беза и операционок.

По идее minikube и kubectl достаточно. Но если речь идет допустим о пользовании на Windows - то там надо внимательно читать microsoft инструкции. У них всегда много нюансов.

Ну вот первое значение будет 0x62 и второе будет 0x22.

Поскольку Android - это тоже разновидность Linux то тебе надо изучать следующие темы.
- программирование под Linux. Безопасность памяти и процессов.
- язык Си.
- обратный инжинеринг кода.
- архитектура процессоров семейства ARM
- архитектура виртуальный машин ART и Dalvik байткод. Языки Java и Kotlin. Android NDK.
- структура типичного Android приложения. Стек.
- структура упаковки Apk. Процесс деплоя.
- безопасность Android-приложений. Контейнеризация.

Изучай все. И не вздумай углы срезать! А то будешь - маленький свинтус и лентяй.

Большинство преподавателей скорее всего проигнорируют такие требования.
Обучение в первую очередь ставит целью - научить понимать алгоритмы и применять
их на практике. Искать ошибки. Это такая себе пирамида приоритетов.

Стандарты С99 и С11 это какая-то вторичная чепуха. Если вы умеете писать с С99 то
для вас не будет проблемой писать что-то в следующей версии стандарта. Это как у водителя.
Если на 5-скоростной коробке передач ездил то и на 6 скоростной тоже поедет без проблем.
Акцентировать на этом внимание никакой преподаватель не будет. Это не наука. Это - факультатив.

Сам почитаешь короче. Если у вас такая душная вакансия и такие душнилы-работодатели что им
прямо нужен какой-то стандарт - то это не задача 1 дня. Это длительный процесс. Я видел различные
попытки переписывать ентерпразы с одной версии языка на другую. Это все выглядит очень плохо
для организации и скорее всего хеш-тег С11 появился просто по ошибке рекрутера. И его можно
в данном случае просто не брать во внимание.

А почему ты решил что парсинг это узкое место? Ты пишешь информацию в базу. Тоесть у тебя конвейер операций.
И я думаю что до того как начинать оптимизацию, надо собрать логи по таймингам. Сколько милисекунд занимет
чистый парсинг и сколько запись в БД.

Попробуй еще простой параллелизм. Разбей эти 8000 файлов на 2 фолдера по 4000.
И запусти 2 python-процесса. Будет допустим не 5 часов а 3 часа. Уже лучше.
Продолжнай дробить пока удельная скорость обработки не деградирует.