mayton2019

Я думаю что признаков можно придумать много. Но все они будут следствием из базового признака
равенства.

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

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

Вот ошибка

duplicate key value violates unique constraint "universitySpecialties_pkey"

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

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

Я не очень понимаю зачем здесь тема БД выпячивается наперед. Шаблон Retry используется очень широко.
И это не к БД относится а к приложению. Мы использовали обычно Guava Retrying with exponential back-off
вот как в примерах пишут https://github.com/rholder/guava-retrying и это примениме не только к БД
а к любым внешним API (Rest/SOAP e.t.c.). Эта механика работае почти везде. Ей много лет и она
воплощена многих сетевых протоколах а не только в приложениях.

По поводу настроек БД. Я могу рассказать про Oracle. Update использует специальный неблокирующий
синтаксис NOWAIT
SELECT .... FOR UPDATE NOWAIT;
который мгновенно возвращает ошибку если не удалось захватить сет строк для обновления. Это подходит
для работы с UI и толстым клиентом например или с веб клиентом.

Например для джоба которы должен работать ночью и взяв например
1000 клиентов или фирм и обработать - предпочтителен подход блокировки всего курсора
SELECT .... FOR UPDATE;.
В этом случае другие джобы будут стоять в ожидании.

А для дневной OLTP активности лучше брать корткие операции с NOWAIT. Проконсультируйтесь с вашей
документацией по вашей БД поддерживается ли неблокирующая операция.

Еще посмотрите видео от Филиппа Дельгядо. Он рассказывал как работали с очередями в Postgres,
там есть интересные режимы блокировок когда не "все или ничего" а есть какой-то компромиссный
режим.

Вообще Retry и защита от перегрузок это броня и снаряд. Как DDOS. Если вы с одной стороны внедряете Retry то с другой
стороны люди начинают плакать и стонать от ваших ретраев до тех пор пока не поставят
вам троттлер или аварийный размыкатель.

Короче думайте о последствиях.

Этот вопрос нужно адресовать к современной физике. Сделать такой процессор не очень сложно.
Но сложно сделать его потребительски привлекательным. Все делатели процессоров в современном
мире бьются за энергоэффективность. А с повышением частоты там просиходит (пускай физики меня
поправят) квадратичное увеличение потребляемой мощности (к коэффциентиком). Вот сколько именно
ватт я сейчас не скажу но величина будет неприятная. Тоесть 8 ГГц процессор будет греться как кофейник
и будет потреблять более чем в 4 раза если сравнивать его с 2Ггц ядром.

Еще я-бы рассмотрел такой вариант как влияние на здоровье человека. Выж понимете да. Вся современная
радиопередающая техника (мобилы, Wi-Fi, Bluetooth) со всех сторон зажаты медицинскими нормами
всяких международных контролирующих организаций. И не дай бох хоть одна организация докажет
что вероятность поймать рак мозга растет там на 5% от такого процессора - загнобят санкциями.

По поводу мегафлопов. Фактически производительность техно-стека (Процессор-Память-I/O)
зависит не только от проца но и от всех устройств которые в стеке. И даже работая на 8ГГц
ты скорее всего не получишь желаемого роста скорости майнкрафта на переходе от 4 х 2 Ггц просто по той
причине что кеш и память и диск остались ровно теже самые.

Да и вообще. Эпоха гигантизма в процессорах прошла. Щас все двигаются к узкой специализации
CPU/GPU/TPU и к интернету вещей. И майнкрафт здесь никак не будет главным регулятором стратегии.
Уж извини. Водное охлаждение тоже вещь такая себе. Узкий сегмент энтузиастов. Обычным людам это
так же не надо как и квантовый комп.

Можно один батник вызвать из другого.

@call bat2.bat

Приоритет и две даты можно конвертнуть в строки и конкатенировать. Только следи за тем
чтобы лексикографический порядок соблюдался. Если честно непонятно что тебе дает это
объединение. Сортировки и для трех нормально работают.

UPD: Я обновлю свой ответ на основе новых данных.

Менеджеры хотят в приложении задачи перетаскивать

Если это наподобие двигания тасок в JIRA-borad то тогда действительно не нужны
никакие даты. Нужно одно поле rank. Возможно поле priority это оно и есть.

Тогда при накидывании тасок на доску мы просто делаем им sequence с любого
стартового значения. А когда менеджер двигает - нам нужна процедура
swap(id1, id2)
которая просто меняет ранги местами для двух JIRA ids.

Сжатые папки и архивы - это кажется разные технологии. Я помню что в эпоху Windows 98 мы ставили
ZipMagic. Он и обеспечивал прозрачную работу с архивами на лету. Вот. А SevenZip (7z) просто обеспечивал
интеграцию приложения 7z и эксплорера. И добавлял контекстные действия над файлом.

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

Если функция более хитрая (не гладкая) то к ней надо с хитростью подходить.

Как то так должно быть.

function find($number, $div = 1, $result = []) {
    if ($i <= $number / $div) {
        find($number, $div + 1, ($number % $i == 0) ? array_push($result[], $i) : $result;
    } else {
    	return $result;
    }
}

Я не спец в ПХП и могу ошибаться в том как arrays работают. Вобщем идея такая. Проверяйте и исправляйте.

А можно ли использовать отдельную табличку на hdfs для этих целей?

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

Для стриминга информации действительно подходит связка Graphana + Prometeus + InfluxDb.
Но тут дальше непонятно какой-такой посредник тебе нужен. Такие посредники существуют
для Kafka/Cassandra и они называются коннекторы. Они льют информацию из очереди
в таблички и наоборот (там есть правда условие). Но опять-же твою постановку надо грумить
очень глубоко вплоть до объемов данных и лагов и условий чтобы понять что на самом деле надо.

На hdfs есть табличка (обычно дергаю из неё данные в hive).

По роду постановки - это очень близко к микро-батчингу или стримингу. Но я пока не вижу
какой стек ты используешь. Обычно к стримингу ближе идут Spark/Databricks/Flink/Storm.
У них хотя-бы существует терминология стриминга. Вот а hive - это точно не про стриминг.

Есть точка зрения (от функциональщиков) что если у тебя код разбит на функции и они покрыты тестами
то никакой дебаг тебе не нужен. А если вдруг стал нужен - то что-то у тебя не то с тестовым покрытием.
Я тут не могу на 100% согласиться потому что я лично не видел чисто функциональных проектов. Но
эта мысль очень правильная. Она заставляет задуматься.

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

Есть особые условия безопасности когда программист физически не имеет доступа к периметру где работает
его код. Я такое видел и даже участвовал. Это банковские продукты которые очень сильно защищены.
И понятное дело что никто debug port вам туда не откроет. За этим следят безопасники и единственное
что у вас будет для анализа это логи. Поэтому логи .. логи и еще раз логи с разной детализацией.

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

Вместе с С++ хорошо сочетается знания алгоритмов и железа.
Попробуй для практики зарегистрироваться на codewars / leetcode и прочих задачниках
и порешай задания. По железу. Поразбирайся с Arduino, Raspberry. Сделай что нибудь полезное.

Можно попробовать токенизировать все вопросы. И сложить их в векторы токенов.
И прогнать через алгоритм кластеризации. В настройках ты задашь например 100 центров
кластеров. На выходе ты получишь 100 наборов ключевых слов по самым популярным тематикам.

L3 кеш как сильно бустит производительность игровому серверу?

Да сильно. Вот формулы я не знаю. Да и никто не знает. Это как в симуляции.
Чтоб узнать сколько - ты просто берешь две конфигурации. Запускаешь бенчмарк
и смотришь как было ДО и как стало ПОСЛЕ. И ничего лучше пока не придумали.
Компьютерное железо - это практическая наука. И здесь эксперимент - важнее теории.

По какому алгоритму игровой сервер использует кеш процессора?

Насчет алгоритма я не знаю. Возможно разновидность LRU. Я помню смотрел одно
видео где один С++ ный маг и колдун (кажется Ulrih Drepper) рассказывал об алгоритмах
кешей в железе.

Алгоритм оперирует обычно кусочками памяти в блоках по 64 байта. Кеш-линии.
И если тебе надо прочитать 1 байтик то будет прочитан кусок кратный кеш-линии.
Зато при последующих попытках читать второй и третий байтики алгоритм будет
оперировать с пирамидой кешов. Обычно L1 - самый быстрый и другие медлненее.
Хорошо прогретые кеши обычно содержат 100% нужную информаицю для текущего
ядра процессора. Или для thread.

Кеш придумали для геймеров или для серверов тоже?

Нет. Его создавали просто для эффективного использования железа еще в 20м веке.
Мы его увидели начиная кажется с первых Pentium-ов.

Да. Разумеется игры этим пользуются. А программист game-разработки должен думать
об устройстве кешей. Например планировать размер структур данных чтоб они были кратны
кеш-линиям.

Как хорошо будет жить сервер с основной нагрузкой на одно ядро без кеша L3?

Я не очень себе представляю подобную конфигурацию. Расскажи как ты этого достигнешь.

Если в процессор дать кеша 2gb L3 то его IPC вырастет?

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

Обычно провайдер продает очень тухлый интернет в "обратную сторону". Допустим в
рекламе звучало 100Мб и возможно вы можете смотреть футбол в full-HD
но это не покрывает "трафик в обратную сторону".

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

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

Такие библиотечки как CUDA и OpenCL в части инициализаци должны выдавать сведенья о железе.
Может эти сведенья будут очень high-level но должны быть.

Двоичная система которая используется внутри железа имеет очень красивое представление в hex.
Четыре бита - отображаются в один hex символ. И очень неудобное представление в десятичной.