там вроде вопрос был, насколько дольше ждать удовольствия первому, чем второму. А вероятность получить удовольствие у них одинаковая на каждом шагу, так что матожидание тоже одинаковое, так что 0.
1) про футбол интересная задачка. Я бы запилил декартово дерево (имхо, самое простое для реализации руками случайно сбалансированное дерево поиска), с количеством потомков для каждой ноды, тогда порядковая статистика за логарифм считается.
2) в первой задаче — вроде 0 с ходу
3) последнюю не стал смотреть, остальные вроде просто
нет. При release-семантике все операции записи (а не только в атомики), сделанные до записи в атомик A с release-барьером становятся видимыми другим тредам, но только при условии, что они выполняют чтение этой переменной (A) с acquire-барьером. Если они читают другой атомик B с acquire-барьером, то тогда не гарантируется, что они увидят все операции записи, в том числе в A, в нужном порядке, и вообще их увидят, что логично, так как B может в другой кэш-линии лежать.
«A store operation with this memory order performs the release operation: no reads or writes in the current thread can be reordered after this store. All writes in the current thread are visible in other threads that acquire the same atomic variable»
У меня один старший и опытный коллега на одной из прошлых работ искал в std::map итератором. В следующем году на другой работе на другом проекте вместо std::set был std::vector, и содержал от десятков тысяч до миллиона записей, которые постоянно искались по значению и удалялись из середины. И это были куски кода, которые делали всю работу. Постоянно сталкивался, что проходят по immutable односвязному списку и добавляют элементы в конец другого immutable односвязного списка (сразу O(N^2) на пустом месте), используют односвязный список для поиска по значению, да полно всего. Так что если в компании не используются собеседования с кодом, то компания рискует.
так они уж лет 15 есть, книги эти, и сайты лет 10. Я бы сказал, это уже давно мейнстрим. За бугром так вообще сейчас тупо везде задачами собеседуют. На моей текущей работе тоже на собеседовании приходилось реализовать кой-чего.
Мне тоже не нравится необходимость постоянно в решении задач практиковаться, если что. Но вот правила игры такие. Вы сами пишете, что учиться нужно для себя в обязательном порядке, но почему не по списку алгоритмов? это ж тоже в конечном итоге для себя
ретивость — скорее нет, тут фактор большого конкурса на место. Но спросить человека по нескольким алгоритмическим темам — нужно. Вот они и проверяют, по задаче на тему. Времени только мало дают, поэтому приходится задачи тупо задрачивать.
иногда требуются. Чаще всего требуется просто выбрать правильно коллекцию (даже с этим у многих проблемы). У меня на практике был случай, когда человек использовал для хранения множества массив вместо хэштаблицы или дерева, и код, который действительно работает постоянно и делает всю работу программы (которая продавалась за большие деньги), дико тормозил. На код-ревью иногда сталкиваюсь с тем, что люди выбирают коллекции небрежно, и могут реализовать алгоритм с квадратичной сложностью там, где кол-во элементов требует более эффективного алгоритма, зачастую даже стандартного.
Так что базовая алгоритмическая грамотность на уровне «отличаю массив от списка и хэштаблицы, а еще знаю про деревья» должна быть.
эти пробелы в знаниях очень сильно попортят жизнь, если придется искать работу «вдруг», что в общем-то иногда случается. Сам так искал работу 2 раза, и я лучше постоянно буду держать в голове какие-то собеседнические вещи «на всякий случай», чем потом лихорадочно это все вспоминать, систематизировать, и лажать на собесах тогда, когда работа нужна еще вчера.
При разработке грамматики для C# смог получить именно проблему, что парсер не справлялся с вариантом isFlag? var1: var2, потому что он пытался парсить, используя знак? не как тернарный оператор. Antlr просто не хватало глубины поиска в правилах и он не мог поймать тернарку.
Может тогда antlr не стоит пользовать, а взять что-нибудь LR-ное, типа того же bison, на основе автомата со стеком, там такой проблемы не будет.
Ну так эльбрусы же с их VLIW-ом. Они в своем компиляторе как раз параллелят подобные операции. Бесперспективняк, на мой взгляд. Как только не извращаются, лишь бы нормальный техпроцесс не пилить, не наращивать частоты и предсказатель переходов не делать.
Я когда-то смотрел конференцию, где пилили Java на Эльбрусе, там цифра была, что среднее кол-во команд в слове, после кучи попыток распараллелить — 2-3, не сильно больше, чем у того же интела. Зато геморроя с VLIW-ом намного, намного больше. Тот же Itanium, который тоже был VLIW-ом, скоропостижно сдулся.
А мне помогает пойти от противного. Признать, что работать не хочется, либо уже не можется (второе бывает, когда долго заставлять себя работать, а еще если заставлять себя быть продуктивным, или заставлять себя хотеть работать). Затем посидеть и подумать не о там, как заставить себя работать, как повысить продуктивность, как *подставить свое*, а наоборот — как это все (т. е. продуктивность) задолбало. Затем — понаблюдать за чувствами (страх, там, чувство вины, чувство стыда и тому подобная ересь). Попереживать. Посочувствовать себе. Понять, что продуктивность сейчас не светит, и верхом продуктивности сейчас будет, если я просто поправлю пару строчек.
2) в первой задаче — вроде 0 с ходу
3) последнюю не стал смотреть, остальные вроде просто
(взято отсюда: en.cppreference.com/w/cpp/atomic/memory_order)
Мне тоже не нравится необходимость постоянно в решении задач практиковаться, если что. Но вот правила игры такие. Вы сами пишете, что учиться нужно для себя в обязательном порядке, но почему не по списку алгоритмов? это ж тоже в конечном итоге для себя
Так что базовая алгоритмическая грамотность на уровне «отличаю массив от списка и хэштаблицы, а еще знаю про деревья» должна быть.
Может тогда antlr не стоит пользовать, а взять что-нибудь LR-ное, типа того же bison, на основе автомата со стеком, там такой проблемы не будет.
Я когда-то смотрел конференцию, где пилили Java на Эльбрусе, там цифра была, что среднее кол-во команд в слове, после кучи попыток распараллелить — 2-3, не сильно больше, чем у того же интела. Зато геморроя с VLIW-ом намного, намного больше. Тот же Itanium, который тоже был VLIW-ом, скоропостижно сдулся.