Статье очень не хватает описания применённого трюка на уровне идеи (не уверен, что готов "предложить" - т.е. сформулировать его, но статья явно станет лучше).
Если не понимать что происходит - то читать крайне тяжело, т.к. изложение постоянно перепрыгивает с "чисел и равенств" к "классам и эквивалентности" (да даже понимая что происходит проверить формальную корректность крайне муторно).
В целом довольно похоже на построение множеств чисел в арифметике пеано та вычислительном базисе частично-рекурсивных ф-ий, где однажды определив вычитание мы не вводим ф-ию "минус", а просто тащим уменьшаемое и разность в виде пары.
П.С.
А приведённая ниже часть - несомненно кокетство. Эту теорию, даже на приличных инженерных-компьютерных факультетах (например моей группе в НИУ ВШЭ) не давали. Подозреваю давали только математика.
⚠ Предупреждение! Первые две статьи достаточно техничные. Они нужны для полноты изложения и носят дидактический характер, полезный для того, чтобы приобщить маткружковцев к духу математики. Однако особых открытий они в себе не таят.
Содержательно - нет. Corner case (а все ваши примеры в той или иной мере corner case ) - следует описывать только после того, как основной случай описан и понят достаточно хорошо.
Наша цель - построить конечную модель бесконечного количества знаний. Для этого более важные утверждения должны попасть в модель раньше менее важных. Поэтому приведённая вами модель - плохая она куда больше сбивает с толку, чем помогает.
Это стандарт языка, на который полагается компилятор при оптимизациях.
стандарт это не гарантия, а соглашение
Хорошая модель (из 2 фраз) была что-то типа:
Это стандарт языка, на который полагается компилятор при оптимизациях.
Стандарт - это гарантия, пока нет явных оснований считать по-другому.
В изначальных картинках (nin-jin) очередь 1:1 помогает примерно как топор в сказке "каша из топора". Т.е. что синхронизацию поверх M:M писать что превращать (1:1) - (1:M) - (M:1) - (1:1) - примерно одного уровня проблемы. Как я понял вы явно стали защищать позицию "1:1" очень полезный примитив - ИМХО нет.
=================================================
Разумеется такую очередь lock-free построить можно (на ll-sc прям влёт, на CAS ну запакуем два 32-битных значения в 64-битное).
Однако она встаёт против BorrowChecker, который слишком консервативен.
В итоге у вас получается либо Lock, либо Waker либо unsafe. И тут наличие 1:1 очереди крайне мало помогает.
Моё утверждение - очень полезно понимать, вот эти вот гарантии, какой статус они имеют, и насколько велика вероятность что они сломаны (тобой или не тобой). В ваших краевых случаях - стандарт всё равно остаётся стандартом, но вероятность, что он будет сломан, существенно повышается.
непонятно - что ва так возбудило(1)? против чего вы негодуете?
Или вы не любите тесты а любите параноить(2), принудительно обкладывая все подозрительные места на переполнения
Пожалуйста не переходите на личности(1) и не используйте демагогический приём соломенное чучело (2) - в технической дискуссии это некрасиво.
И зачем второй коммент подряд вы пытаетесь без приглашения меряться длиной и толщиной опыта? (доводилось писать и компилятор и симулятор под разрабатываемую архитектуру и модели многопоточности). И во всех случаях было крайне полезно отличать стандарт от соглашений, а также модель(и ошибки модели) от имплементации модели (и ошибок имплементации).
Теперь по вашим примерам - кажется, что вы смешали сильно разные случаи в одну кучу: - Ниженерный вариант смартфона - corner case; - Rust unsafe - довольно edge case: как для core-team(судя по старым ошибкам с зацикливанием владения при инициализации) так и для пользователей; - Асм-вставки - стандартный инструмент при низкоуровневой разработке и ожидать, что скажем в gcc он будет сломан дольше пары недель крайне странно; - FFI (хотя непосредственно с ним работать не доводилось) - либо при наличии OBI стандарт либо если всё держится на честном слове вендора обкладывается тестами;
На практике нас крайне интересуют две вещи: - модульность (позволяет сосредоточиться на своей части работы не делая чужую, позволяет использовать "бинарный поиск" для нахождения ошибок); - частота ошибок (позволяет искать ошибки эффективно - в первую очередь там, где они более вероятны).
И ваш подход "снандарт языка - это соглашение" - ухудшает работу, т.к. затрудняет использование плюсов обоих этих вещей.
Для примера - сколько раз в жизни вы на практике сталкивались с ошибками в stable-version gcc \ clang \ icc (приведите любую из них)?
Я может "некропостинг" откопал, но всё-же хочу ответить.
1. Английский давать в школе бесполезно и даже редно - у нас его преподают ужастным "грамматико-переводным методом". Который плох даже для взрослых, а для детей, так просто вреден и прямо противоположен особеннотям развития (мозга) ребёнка. 2. Если сравнивать "алгебра + геометрия", то следует сравнивать с "русский + литература" - это так чтобы не шуллерить по-мелкому. 3. Математика - один из немногих предметов, который: - а) неплохо преподаётся в школе - б) полезен почти всегда (если мы говорим про универ).
накидывают кучу пожеланий ... от каких требований придется отказаться, чтобы расписание составилось.
Ну тогда из "пожеланий" делаете целевую функцию и goto п.2.
Альтернативные решения - выдать несколько парето-эффективных расписаний и выбрать из них вручную бысто превращаются в "у нас есть 2^100500 расписаний, давайте выберем из них вручную".
Позиция современного бизнеса "вот когда создадутся, пусть идут к нам, наша ЗП в рынке".
Мне ещё кажется, что на рынке РФ "вкатуны" с 2016 года постепенно поламали доверие при найме и сам найм.
Как был устроен найм раньше - приходит человек наниматься (условно) года на 3. За 6 месяцев ты его научишь (за это время для тебя по деньгам это будет чистый минус), за оставшиеся 2.5 года от своё отработает.
Как это выглядит сейчас - приходит к тебе человек после курсов "войти-в-айти". И у него план на тебя: 1. Устроиться на ЗП 50к. 2. Пол-года ты его будешь дообучать и иметь чистый убыток по деньгам. 3. Через пол-года уйти на 150 на миддл-вакансию.
Ну найм в РФ к такому повороту рынка приспособился и джунов вообще не рассматривает.
Если это приличный ВУЗ (за 150к вроде приличный) - то это ещё и networking и возможность получить хорошую первую строчку в резюме (вроде пройти алго-часть в FAANG).
Брутфорсом его можно было взять за час.... там же экспоненциальная сложность.
Ну так это стандартная задача планирования (составления расписания). При этом существует две основных постановки задачи: 1. Удовлетворить все ограничения 2. Удовлетворить все ограничения и при этом минимизировать целевую функцию (например минимизировать число поездок преподов в универ или минимизировать число "окон" у профессоров или ...).
При этом "истоинно экспоненциальная" - вторая часть.
Первая часть - решается через "перебор с возвратом" "a-b-отсечение" и итоговая сложность может быть хоть линейной (в вырожденном или почти вырожденном случае).
верхний ряд - это как сделать из очереди 1-к-1, очередь много-к-много.
И сразу нет. Это как сделать из очередей 1:M + M:1 - очередь M:M. Но проблема в том, что она вообще никак не избавляет от необходимости множественного mut-владения \ mut-ссылок.
Это стандарт языка, на который полагается компилятор при оптимизациях.
А если следовать вашей логике - и AI32 architecture тоже соглашение (вдруг космические лучи создадут наводку в транзисторе?). Извращённая логика получается.
Но при переезде у тебя в дополнене к страновому purchasing power parity падает ещё и личный (накопления на пол-квартиры превратились в накопления на 1/4 квартиры, родители больше с детьми посидеть не могут и контакты хорошего стоматолога пропали).
деньги небольшие и нужны для получения новых знаний, вознаграждения тех кто добыл старые.
Тут практика расходится с вашим взглядом:
"Александра Элбакян в письме 2015 года судье ... также отметила, что Elsevier зарабатывает деньги на работе исследователей, которым не платят за свою работу.
Посмотрел ваши статьи.
С интересом подписался.
Статье очень не хватает описания применённого трюка на уровне идеи (не уверен, что готов "предложить" - т.е. сформулировать его, но статья явно станет лучше).
Если не понимать что происходит - то читать крайне тяжело, т.к. изложение постоянно перепрыгивает с "чисел и равенств" к "классам и эквивалентности" (да даже понимая что происходит проверить формальную корректность крайне муторно).
В целом довольно похоже на построение множеств чисел в арифметике пеано та вычислительном базисе частично-рекурсивных ф-ий, где однажды определив вычитание мы не вводим ф-ию "минус", а просто тащим уменьшаемое и разность в виде пары.
П.С.
А приведённая ниже часть - несомненно кокетство. Эту теорию, даже на приличных инженерных-компьютерных факультетах (например моей группе в НИУ ВШЭ) не давали. Подозреваю давали только математика.
Нет скорее арифметики Пеано.
В арифметике Пеано тоже довольно трудно определить вычитание.
Содержательно - нет.
Corner case (а все ваши примеры в той или иной мере corner case ) - следует описывать только после того, как основной случай описан и понят достаточно хорошо.
Наша цель - построить конечную модель бесконечного количества знаний.
Для этого более важные утверждения должны попасть в модель раньше менее важных.
Поэтому приведённая вами модель - плохая она куда больше сбивает с толку, чем помогает.
Хорошая модель (из 2 фраз) была что-то типа:
Надувание щёк вместо технических знаний.
Не вижу смысла общаться с вами дальше. Здоровья, счастья, держитесь там.
Ну так проблема в том, что изначальная фраза "стандарт это не гарантия, а соглашение" - куда больше вредит, чем помогает.
Если есть что сказать на техническом уровне - говорите.
Если единственное ваше утверждение "вы бы хоть сделал Х" - лучше вообще молчать.
В изначальных картинках (nin-jin) очередь 1:1 помогает примерно как топор в сказке "каша из топора".
Т.е. что синхронизацию поверх M:M писать что превращать (1:1) - (1:M) - (M:1) - (1:1) - примерно одного уровня проблемы. Как я понял вы явно стали защищать позицию "1:1" очень полезный примитив - ИМХО нет.
=================================================
Разумеется такую очередь lock-free построить можно (на ll-sc прям влёт, на CAS ну запакуем два 32-битных значения в 64-битное).
Однако она встаёт против BorrowChecker, который слишком консервативен.
В итоге у вас получается либо Lock, либо Waker либо unsafe. И тут наличие 1:1 очереди крайне мало помогает.
Моё утверждение - очень полезно понимать, вот эти вот гарантии, какой статус они имеют, и насколько велика вероятность что они сломаны (тобой или не тобой).
В ваших краевых случаях - стандарт всё равно остаётся стандартом, но вероятность, что он будет сломан, существенно повышается.
Пожалуйста не переходите на личности(1) и не используйте демагогический приём соломенное чучело (2) - в технической дискуссии это некрасиво.
И зачем второй коммент подряд вы пытаетесь без приглашения меряться длиной и толщиной опыта? (доводилось писать и компилятор и симулятор под разрабатываемую архитектуру и модели многопоточности).
И во всех случаях было крайне полезно отличать стандарт от соглашений, а также модель(и ошибки модели) от имплементации модели (и ошибок имплементации).
Теперь по вашим примерам - кажется, что вы смешали сильно разные случаи в одну кучу:
- Ниженерный вариант смартфона - corner case;
- Rust unsafe - довольно edge case: как для core-team(судя по старым ошибкам с зацикливанием владения при инициализации) так и для пользователей;
- Асм-вставки - стандартный инструмент при низкоуровневой разработке и ожидать, что скажем в gcc он будет сломан дольше пары недель крайне странно;
- FFI (хотя непосредственно с ним работать не доводилось) - либо при наличии OBI стандарт либо если всё держится на честном слове вендора обкладывается тестами;
На практике нас крайне интересуют две вещи:
- модульность (позволяет сосредоточиться на своей части работы не делая чужую, позволяет использовать "бинарный поиск" для нахождения ошибок);
- частота ошибок (позволяет искать ошибки эффективно - в первую очередь там, где они более вероятны).
И ваш подход "снандарт языка - это соглашение" - ухудшает работу, т.к. затрудняет использование плюсов обоих этих вещей.
Для примера - сколько раз в жизни вы на практике сталкивались с ошибками в stable-version gcc \ clang \ icc (приведите любую из них)?
На рисунке (1) 2 очереди 1-1
На рисунке (2) очерещь 2-1.
Вы утверждаете, что из рисунка (1) можете сделать рисунок(2) без дополнительных фокусо? Как?
Я может "некропостинг" откопал, но всё-же хочу ответить.
1. Английский давать в школе бесполезно и даже редно - у нас его преподают ужастным "грамматико-переводным методом". Который плох даже для взрослых, а для детей, так просто вреден и прямо противоположен особеннотям развития (мозга) ребёнка.
2. Если сравнивать "алгебра + геометрия", то следует сравнивать с "русский + литература" - это так чтобы не шуллерить по-мелкому.
3. Математика - один из немногих предметов, который:
- а) неплохо преподаётся в школе
- б) полезен почти всегда (если мы говорим про универ).
Так что лично я выбор классной одобрил бы.
Ну тогда из "пожеланий" делаете целевую функцию и goto п.2.
Альтернативные решения - выдать несколько парето-эффективных расписаний и выбрать из них вручную бысто превращаются в "у нас есть 2^100500 расписаний, давайте выберем из них вручную".
Позиция современного бизнеса "вот когда создадутся, пусть идут к нам, наша ЗП в рынке".
Мне ещё кажется, что на рынке РФ "вкатуны" с 2016 года постепенно поламали доверие при найме и сам найм.
Как был устроен найм раньше - приходит человек наниматься (условно) года на 3. За 6 месяцев ты его научишь (за это время для тебя по деньгам это будет чистый минус), за оставшиеся 2.5 года от своё отработает.
Как это выглядит сейчас - приходит к тебе человек после курсов "войти-в-айти". И у него план на тебя:
1. Устроиться на ЗП 50к.
2. Пол-года ты его будешь дообучать и иметь чистый убыток по деньгам.
3. Через пол-года уйти на 150 на миддл-вакансию.
Ну найм в РФ к такому повороту рынка приспособился и джунов вообще не рассматривает.
Если это приличный ВУЗ (за 150к вроде приличный) - то это ещё и networking и возможность получить хорошую первую строчку в резюме (вроде пройти алго-часть в FAANG).
Ну так это стандартная задача планирования (составления расписания).
При этом существует две основных постановки задачи:
1. Удовлетворить все ограничения
2. Удовлетворить все ограничения и при этом минимизировать целевую функцию (например минимизировать число поездок преподов в универ или минимизировать число "окон" у профессоров или ...).
При этом "истоинно экспоненциальная" - вторая часть.
Первая часть - решается через "перебор с возвратом" "a-b-отсечение" и итоговая сложность может быть хоть линейной (в вырожденном или почти вырожденном случае).
И сразу нет.
Это как сделать из очередей 1:M + M:1 - очередь M:M.
Но проблема в том, что она вообще никак не избавляет от необходимости множественного mut-владения \ mut-ссылок.
Это стандарт языка, на который полагается компилятор при оптимизациях.
А если следовать вашей логике - и AI32 architecture тоже соглашение (вдруг космические лучи создадут наводку в транзисторе?). Извращённая логика получается.
У меня есть очень большие сомнения, что $4K_РФ эквивалентно $5K_global.
Банально Purchasing power parity для РФ = 1 / 0.6 (т.е. $4K "на руки" = $6.6K "на руки").
https://en.wikipedia.org/wiki/Relative_purchasing_power_parity
Но при переезде у тебя в дополнене к страновому purchasing power parity падает ещё и личный (накопления на пол-квартиры превратились в накопления на 1/4 квартиры, родители больше с детьми посидеть не могут и контакты хорошего стоматолога пропали).
Тут практика расходится с вашим взглядом:
"Александра Элбакян в письме 2015 года судье ... также отметила, что Elsevier зарабатывает деньги на работе исследователей, которым не платят за свою работу.