• Хаброквест в честь 20-летия Mail.Ru Group — 20 задачек
    0
    Аналогичная история, кажется что решил, но подсказку так и не понял.
  • Титаны от математики схлестнулись над эпичным доказательством abc-гипотезы
    +1
    1. А давайте назначать веса не по количеству строчек в резюме, а по содержатьельности критики, как вам такой подход?

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

    2. Зачем? Пусть каждый объяснит свою точку зрения и отвечает на вопросы до тех пор пока кто-нибудь не признает свою неправоту (и соответственно спор будет закончен на этом) или кому-то не надоест (соответственно спор остается открытым). Тут мы вернулись к тому, с чего начали, а именно Мотидзуки, конечно, никому ничего не должен, но это не продуктивный подход к делу, или более точно непродуктивный подход к доказательству чего-бы то ни было, в конечном итоге, доказательство само по себе так же важно как и доказываемая теорема.

    3. Опять же зачем придумывать какое-то достаточное число ученых для консенсуса? Ну например, представим, что достаточное количество математиков X согласилось, что теорема T верна, какой полезный результат это согласие дает? Значит ли, что этой теоремой могут пользоваться другие математики? Так они и без этого могут ей пользоваться и доказывать что-то в предположении, что теорема истинна или ложна. Значит ли это что исследования в этой области нужно свернуть и никогда к этому не возвращаться? Я так не думаю, потому что одним из интересных результатов в математике (и не только) является нахождение более простого или исходящего из других принципов доказательства. Они важны, потому что они позволяют понять проблему лучше, объяснить ее большему числу людей и связать ее с другими областями. Если в результате такого исследования обнаружится проблема в оргинальном доказательстве тоже хорошо — лучше об этом знать, чем не знать.
  • Титаны от математики схлестнулись над эпичным доказательством abc-гипотезы
    0
    1. Таким образом вы сводите математику к набору верований в то, что «сделали эксперты», что опять же странно. Придумать доказательство теоремы сложнее, чем следовать уже приведенному логическому выводу. Отсюда мое несогласие с вашей позицией, что только избранные эксперты могут утверждать, что доказательство некорректно. Любой, кто может привести строгий аргумент (эксперт или нет), может критиковать доказательство и нет, быть признанным экспертом в области для этого не нужно.

    2. Вот тут вы откровенную ерунду говорите. Штаты представляют значительную часть математического сообщества. Не ту часть, которая если верить Фесенко, активно занимется IUT, а значительную часть математического сообщества в целом, и специфично ту часть, которая занималась ABC гипотезой в частности и теорией чисел в общем. Кроме того, Штолц и Стикс все-таки являются немецкими математиками, которые живут и работают в Германии.

    3. Это ваша субъективная точка зрения, сравните это с количеством людей профессионально занимающихся математикой, например, и вы увидите, что это число не такое уж и большое. И не нужно приписывать мне мнения, которых я не высказывал, я ни слова не сказал о том, что математика должна быть простой, если вы внимательно прочитаете комментарий, я даже не сказал, что двузначного числа экспертов каким-то образом недостаточно для чего бы то ни было, я просто указал, что аргумент о том, сколько человек «не высказалось» довольно смешной способ демонстрировать математическую корректность и работает в обе стороны.

    4. Я прочитал и отчет Мотизуки и статью Фесенко. Ничего против отчета Мотизуки после нескольких прочтений я не имею и мое мнение касается именно статьи Фесенко. Обратите внимание, что даже в отчете Мотизуки прямо сказано, что до сих пор обсуждение было неконкретным, и это хорошо, что обсуждение стало более по существу. И на этом фоне статья Фесенко, это как раз яркий пример обсуждения не по существу.

    У нас с вами, очевидно, разное понимание «круга специалистов». Получается, что все «неспециалисты», которые будут применять ABC гипотезу к проблемам, которые не имеют прямого отношения к IUT или анабелевой геометрии должны просто верить на слово Мотидзуки или никогда не применять ABC гипотезу. Для меня это кажется довольно диким, в противном случае любой курс математики для инженеров (да и не только инженеров) можно свести просто к формулировкам теорем и предложить студентам «поверить на слово», что все эти теоремы корректны — это для меня моральный эквивалент вашего подохода.
  • Титаны от математики схлестнулись над эпичным доказательством abc-гипотезы
    0
    Это довольно странная аргументация по нескольким причинам:
    1. Для того чтобы понимать какой-то раздел математики необязательно иметь публикации в этом разделе математики, отсутвие публикаций в большинстве случаев просто означает, что человек не занимается активными исследованиями в области — чтобы пользоваться наработками других математиков в области нужно понимать их, но самому быть активным исследователем в области не обязательно.
    2. Мотидзуки конечно никому ничего не должен, но и математическое сообщество также не должно единогласно считать вопрос ABC гипотезы закрытым и нравится вам это или нет, но штаты представляют довольно значительную часть этого сообщества. Но как бы то ни было вести обсуждение по принципу кто кому чего должен не продуктивно. Как минимум Мотидзуки и компании стоит признать, что существует проблема понимания (если не проблема корректности) и решать ее соответствующим образом, а не отнекиваться говоря, что это очевидно и не вызывает вопросов у тех кто «в теме».
    3. Факт, что никто из математиков каких-то определенных стран ничего плохого не сказал о теории вообще кажется смешным, учитывая, что количество людей, которые разбираются в теории, согласно автору, это двузначное число. Если это правда, то количество людей, которые вообще касаются этой темы хоть как-нибудь настолько мизерное, что не удивительно, что никто ничего плохого не сказал, не удивительно было бы, даже если никто вообще ничего об этом не сказал.
    4. Весь тон статьи выглядит, за отсутсвием лучшего слова, религиозным. Чтобы познать истинну вы должны провести X лет в монастыре на вершине одинокой горы питаясь только энергией космоса… Или как в статье, чтобы «познать истинну» вы должны быть экспертом в IUT, а чтобы быть экспертом в IUT вы должны не просто потратить пару лет изучая то, что другие сделали, вы должны быть активным исследователем в области. Это конечно не аккуратное сравнение, а просто чтобы проиллюстрировать проблему со статьей Фесенко. А еще добавьте к этому то, что за исключением пары фраз статья не предлагает никакого объяснения позиций обоих сторон и никакой технической аргументации почему одна из сторон права, а другая нет, и получается, что как самостоятельная работа эта статься Фесенко не содержит ничего содержательного кроме перехода на личности, что не идет на пользу обсуждению.

    Это конечно не значит, что Штольц и Стикс правы, а Мотидзуки неправ, но основания сомневаться в позиции обоих сторон имеются и просто сказать, что они никому ничего не должны не является решением проблемы.
  • Титаны от математики схлестнулись над эпичным доказательством abc-гипотезы
    +7
    Мне кажется, что вы не понимаете что там в этой 1000 страниц происходит. Это не 1000 страниц одной теоремы с одним очень длинным доказательством (или двух теорем с двумя доказательствами). Это 1000 страниц с кучей сранительно небольших теорем связанных общей идеей и каждая со своим индивидуальным доказательством, которые в конечном итоге используются чтобы доказать abc гипотезу.

    Вот например, классический набор книг по мат анализу от Фихтенгольца тоже почти до 1000 страниц доходит. Это куча теорем связанных общей идеей и каждая со своим собственным доказательством. Чтобы осмысленно их прочитать у студентов уходит несколько лет. Но это не значит, что Фихтенгольц не знаком был с декомпозицией или не разбивал материал на части, когда писал оригинальную версию. Та же история и с abc гипотезой — проблема сорее всего несколько глубже чем просто объем доказательства или отсутсвие декомпозиции.
  • Измерение времени с наносекундной точностью
    0
    Я не говорю о выборке из памяти, я говорю о времени, которое нужно чтобы послать команду на перефирию и времени, которое перефирии нужно чтобы принять команду, чего достаточно, чтобы зафиксировать момент времени. Я не слова ни сказал о пропускной способности памяти или времени, которое требуется чтобы передать все команды необходимые протоколом DDR и вернуть назад прочитанные данные — коммуникация с целью зафиксировать точку во времени могут быть и проще чем полноценное чтение/запись в память. Не нужно мешать все в одну кучу.
  • Измерение времени с наносекундной точностью
    0
    Ну прям так сразу любая перефирия медленная? Например, в DDR4 RAM один цикл меньше наносекунды и она не находится на процессоре, так что сигнал от процессора не так уж и искажает результат, если конечно вы не хотите сразу этот сигнал на механическом диске зафиксировать.
  • Измерение времени с наносекундной точностью
    0
    Чтобы оптимизация какой-то индивидуальной строки которая сама по себе выполняется доли секунд приносила эффект, эта строка должна выполниться много раз а иначе откуда выигрышу взяться?
    В этом случае если реализация самого цикла занимает настолько значительное время, что на фоне этого оптимизация кода который выполняется в цикле не приносит измеримого выигрыша, то какой собственно толк от такой оптимизации?
  • 24-ядерный CPU, а я не могу набрать электронное письмо
    +1
    Ни каждое зависание на пару секунд происходит по одним и тем же причинам.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    0
    Это уже другая история. Одно дело сказать, что БД впринципе не может выполнять больше 200 транзакций в секунду, другое дело, что вам для одного логического действия нужно выполнять много последовательных транзакций. Одно утверждение указывает на проблему в БД и сторадже, другое на проблему в ПО, которое использует эту БД.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    0
    А хотя нет, вы правы, commit_delay на самом деле как раз то что я описывал выше, прошу прщения за невнимательное чтение.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    0
    Из описания это не совсем то что я имел ввиду, или даже совсем не то, что я имел ввиду. Контрольные точки отмечают моменты в которых достоверно известно, что все предшествующие записи в журнале больше не нужны и могут быть удалены, между контрольными точками журнал все еще пишется и количество использованых IO операций при этом никак не контроллируется этими контрольными точками.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    +1
    C в CAP и D в ACID имеют очень мало чего общего (кроме того что они соседние буквы в алфавите), любой мусор можно зафиксировать на диске, сообственно есть системы хранения которые так и делают. Кроме того когда вы говорите о невозможности и упоминаете CAP, вам нужно найти соответсвия сразу C и A из CAP в ACID, в противном случае CAP без C или A не особо что-то ограничивает. Т. е. даже если мы на секунду забудем что C из CAP не имеет соответсвий в ACID, то нам все еще придется разобраться с A из CAP и наоборот.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    +1
    2PL работает на том уровне на котором его реализуют, так что я не очень понял на каком таком другом уровне он работет? Если он работает на уровне записей базы данных, то этого вполне достаточно.

    Запись LSN в журнал — всего лишь одна из возможных реализаций коммита. Кроме того писать в WAL все подряд нет необходимости — это опять же всего лишь одна из возможных реализаций.

    Более того, даже если допустить, что все существующие БД пишут в WAL все подряд, это совершенно никаким образом не запрещает объединить несколько обновлений WAL в 1 IO. Элементарно, в какой-то момент БД должна определить, что нужно записать в журнал. Все что нужно это просто подождать какое-то время перед тем как непосредственно выполнять эту запись и собрать данные с нескольких транзакций. Максимальная задержка может возрасти, но и параллельность при это тоже возрастет. Ничего хитрого в этом нет, простая пакетная обработка и амортизация затрат времени.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    0
    1. Теоретически и даже практически разумные решения существуют и существовали довольно долгое время, например, классический 2PL автоматически заблокирует транзакцию, которая обращается к данным используемым другой транзакцией. Ниакой эвристики не нужно.
    2. Транзакции совсем не обязательно должны быть независимы, нужно просто коммитить зависимые транзакции вместе.
  • «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
    0
    Пусть задержка по записи 5мс и мы пишем в журнал всегда последовательно. Если в базе данных параллельно выполняется N независимых транзакций, кто мешает объединить эти транзакции в одну запись в журнал? Если зависимость по данным отсутствует (и даже иногда когда она присутствует, но мы можем опустить этот случай для простоты) писать каждую транзакцию отдельным IO в журнал нет необходимости. Т. е. даже если каждая отдельная запись в журнал это 5мс, если эта запись коммитит сразу несколько транзакций то можно получить больше чем 200 транзакций в секунду и IO очередь при этом не нужна.
  • Пронумеровать все действительные числа на отрезке [0,1]
    0
    1. Любое число которое ваш перечислящий алгоритм выдает имеет конченое число знаков в какой-то системе счисления — это уже точно не все числа.
    2. Давайте посмотрим на ваши таблицы и заметим что талица уровня 2 включает все числа, которые есть на уровне 1, таблица уровня 3 включает все числа которые есть в таблицах на уровнях 1 и 2, и так далее. Т. е. другими словами несколько уровней не добавляют ровным счетом ничего, вы с тем же успехом можете рассматривать «предельную таблицу» в которой все числа имеют бесконечное число разрядов, потому как она будет содержать все числа, котороые есть в каждой из «конечных таблиц». И, сюрприз-сюрприз, согласно аргументу Кантора, который вы так легко отвергли, найдется такое число, которого не будет в этой «предельной таблице».
    3. Скорость роста на которую вы ссылаетесь никакого отношение к определеню счетности не имеет, соответсвенно скорость роста каких-то там функций ни на что не влияет.
  • Пронумеровать все действительные числа на отрезке [0,1]
    0
    Вы путаете теплое с мягким. Долго оно вычисляется или нет не существенно, существует оно или нет вот в чем вопрос.

    В вашем подходе, чтобы число было пронумерованно, должна существовать запись этого числа принадлежащая какому-то уровню. Соответственно вопрос, существует ли такая запись иррационального числа (например, Pi/5, как предрагалось раньше), которая принадлежит хоть какому-то уровню?

    Или другими словами, вы утверждаете, что ваш алгоритм перебирает все вещественные числа, но доказательство этого вы не привели, а лишь ограничились фразой:
    мы можем пронумеровать все числа из диапазона [0,1], т.к. мы последовательно проходим по каждому уровню и последовательно нумеруем все возможные комбинации на данном уровне

    Которая говорит толькто то, что вы можете пронумеровать все числа, которые можно вписать в вашу таблицу, но из этого никак не следует что все вещественные числа могут быть вписаны в вашу таблицу. На этом диагональный принцип как раз и строится, он предъявляет число, которое нельзя вписать в таблицу, пусть и немного другой структуры.
  • Без new: Указатели будут удалены из C++
    +38
    Забавно, 5 статей (no-new-new, cpp-will-no-longer-have-pointers, no-pointers, raw-pointers-are-gone, deprecating-pointers) ссылающихся друг на друга по кругу — довольно хорошо ребята подготовились. Если бы еще c isocpp.org договорились, вобще бы умора была.
  • Почему я ушёл из Google и начал работать на себя
    0
    Задач в гугле хватает всяких разных, так что есть из чего выбирать. Можно предлагать свои задачи, элементарно, если вы идентифицировали проблему или придумали как сэкономить ресурсов вы можете предложить свой проект. Наконец, вы можете сменить команду. Итого автор четыре года сидел на одном месте и делал только то что ему сказали и ни шага в сторону? Да, разработчик не может делать уж свосем все подряд что взбредет ему в голову, но сказать что он совсем не в силах повлиять на что либо будет неправдой.
  • Почему я ушёл из Google и начал работать на себя
    0
    Вы похоже совершенно упустили мою мысль. Еще раз, его назначали на проекты, а потом забирали у него эти самые проекты и он ничего с этим не делал. Хотя он мог, например, проявить инициативу и предложить свой проект, выбрать себе проект самостоятельно или сменить команду. Почему ничего из этого не было сделано?
  • Почему я ушёл из Google и начал работать на себя
    +1
    Он приходит на месяц в команду и делится своим опытом и учится тому как команда работает, потом возвращается назад в свою команду и делится с ней тем чему научился. Итого, удачные решения проблем распротраняются по компании, человек получает опыт и галочку в свой промо пакет за полезный вклад в комъюнити, плюс возможно путешествие в другую страну на месяц, если команда в другом месте.

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

    Кроме того не понимаю как наличие семьи что-то вам усложняет, если вы меняете одну команду на другую внутри компании без перездов, без потери в должности и зарплате.
  • Почему я ушёл из Google и начал работать на себя
    0
    1. Менджер не принимает решение о подаче заявки на повышение, это делает сотрудник, если и когда считает нужным. Он может учитывать мнение менджера, а может и нет.
    2. Комитет учитывает не только оценку менеджера, так что если оценка менеджера будет серьезно расходиться с другими оценками очень часто, то это начнет вызывать вопросы. Так что просто ставить превосходно всем не получится, как и наоборот.
    3. Как удрежать людей в команде я не знаю и не задавался этим вопросом, но ведь и не об этом статья. У человека был выбор, но он им толи не воспользовался, то ли умолчал об этом.
  • Почему я ушёл из Google и начал работать на себя
    0
    Ну вот из моего опыта достаточно народу переходит между командами, кто на совсем, кто на пол года, кто на месяц просто посмотреть что другие делают и опытом обменяться. Некоторые особенно интересные товарищи прыгают между командами вообще раз в год. И да есть команды, из которых люди бегут, но суть в том что выбор есть.
  • Почему я ушёл из Google и начал работать на себя
    0
    Менджер тоже должен был задать этот вопрос, но если вы полагаетесь только на голову менджера, то не нужно удивляться что вы винтик в компании, если вы просто делаете то, что вам говорят. А оценивать стоимость решения по отношению к получаемой прибыли это тоже вполне себе задача для инженера.
  • Почему я ушёл из Google и начал работать на себя
    0
    Ну в первую очередь он должен был оспорить это со своим менджером.
  • Почему я ушёл из Google и начал работать на себя
    0
    Потому что выходит, что это тесты не на умение писать код,
    Вам нужно еще уметь находить задачу, решение которой принесет пользу/прибыль, формализовать ее чтобы она поддавалась решению и только после этого вы приступете к написанию кода, подбору всяких технологий и тд и тп. Так что почему это тест должен проверять именно умение писать код?
    Последние год-два такой метод довольно активно пинают за недостатки.
    Критика Google-ового (и не только) способа оценивать кандидатов на алогритмических задачах вполне активно существует явно не год и не два.
    Во-вторых там есть система рекомендации кандидатов для найма. В итоге дошло до того, что без рекомендации от сотрудника Гугла попасть на собеседование на достойную вакансию очень сложно. А это практически кум-сват-брат система.
    Не буду говорить за всех, но я попал к ним на собеседование без рекомендации.
    Я не думаю, что действительно хороший программист будет хотя бы месяц вечерами тратить заучивания наизусть реализацию кучи алгоритмов. Он знает их сложности, плюсы/минусы, может быть знает библиотеки с хорошими реализациями, больше ему не нужно для работы. Но ведь на гугл-стайл собеседованиях этого мало.
    Но ведь для Google стайл собеседования кучи алгоритмов и не нужно.
  • Почему я ушёл из Google и начал работать на себя
    0
    Остальные это люди не только внутри команды автора, но и в других командах и других проектах, потому что комитет оценивает людей из разных команд. Почему они должны переписывать конвеер, который поддерживается другой командой? И чтобы аргумент про «остальные не переписали» выглядел разумно стоит еще узнать что эти остальные делали вместо этого и какой результат они от этого получили.

    Опять же когда ему дали поддерживать этот легаси бажный конвеер генерирующий корявые данные, первый вопрос, который он должен был задать, если этот конвеер такой плохой, то кто на него жалуется и почему? И если никто не жалуется, то может он никому и не нужен и стоило его убить и сэкономить ресурсы?
  • Почему я ушёл из Google и начал работать на себя
    0
    если ваш проект не приносить пользы, вы не можете выбрать команду, которые реально приносить пользу
    С чего вы это взяли?
  • Почему я ушёл из Google и начал работать на себя
    –4
    Простите, а какие такие KPI там автору раскрыли? Завершенные проекты, это KPI, который вы имеете ввиду? Или недостаток сложных решенных задач? Все это просто недостаток информации. Все остальное автор сам придумал для того чтобы квантифицировать результаты своей работы и продемонстрировать свой вклад. Соответственно метрики, которые он сам придумал, он и пытался оптимизировать.

    Касательно заврешнных проектов, а что автор сделал чтобы получить себе в портфолио завершенный проект? Из текста статьи я увидел, что проекты сначала назначались, а потом отбирались менджментом, а автор вроде как и не при делах. Я не говорю о том, чтобы предложить свой собственный проект, который принесет пользу, но выбрать проект он все таки мог. Может быть не в своей команде, а в более стабильной, если в его команде нет проектов удовлетворяющих его потребностям. Сделал ли это автор? Может сделал, а может и нет. Из написанного это не очевидно.
  • Почему я ушёл из Google и начал работать на себя
    0
    Комиссия состоящая из группы людей разного пола, национальности и работающих в разных командах на разных проектах нацелена, среди прочего, на уменьшенее притеснения азиатов, пожилых негритянок и белых, причем как намеренные так и подсознательные, а также позволяет следить что бы критерии повышения были одинаковыми между разными командами и соответственно никто не имел нечестного преимущества.

    И да, если вы думаете что непосредственный менджер никакого влияния на решения комитета не оказывает, то вы не правы. Менеджер тоже составляет отзыв на кандидата. Только это работает в обе стороны: и если менджер притесняет сотрудника и если менджер его переоценивает. Странно ругать систему оценки за то, что она старается быть непредвзятой и предлагать оставить решение на одного человека со всеми недостатками одного человека.
  • Почему я ушёл из Google и начал работать на себя
    0
    Я не автор статьи, так что понятия не имею нашел он в этом пользу или нет. Зато я знаю, что брать любую критику как «факт» не разбираясь в подробностях двольно сомнительная практика.
  • Почему я ушёл из Google и начал работать на себя
    0
    Автор статьи перкрасно это знает, потому что автор статьи должен был выбрать чьи отзывы он хочет включить в свой промо пакет перед тем как подавать его.
  • Почему я ушёл из Google и начал работать на себя
    +3
    В промо пакет среди прочего входят еще отзывы о проделанной работе от коллег. Так что да, можно спросить-уточнить, они так и делают.
  • Почему я ушёл из Google и начал работать на себя
    0
    Твое повышение зависит не от твоей работы, а от решения комиссии, которая потратит на тебя час а потом забудет.
    С другой стороны тот кто тебя знает, может сказать что вы делаете много и хорошо, но забыть о том, что вы делаете не то, что нужно. Да и говорить, что повышение не зависит от работы не совсем честно.
    И да, варианты с местничеством, кумовством и т.п. никуда не пропадают, меняется только адрес волосатой лапы.
    Если вы действительно знаете о таких случаях в Google, то можно пожайлуста примеров с конкретными именами? Сдается мне, что если это происходит, то прежде чем метать помидоры в «плохую систему», стоит зарепортить тех кто использует ее не по назначению.
  • Spectre и Meltdown
    +1
    Вообще-то TLB как раз пытаются сохранить, просто при обновлении cr3 он сбрасывается полностью, если PCID не включен (или аналогичная фича). Я не знаю, где вы взяли эту информацию, но на код для ядра Linux вы можете посмотреть здесь. Когда PCID доступен его пытаются использовать и избежать полного сброса TLB.
  • Spectre и Meltdown
    0
    Тут пытались заявить, что в документации это упоминается, что какие-то «лица» от AMD это упоминали на каких-то формуах и что кто-то это проверял. Все что я спросил, так это ссылки, для проверки этих ссылок я могу обойтись без NDA.
  • Spectre и Meltdown
    0
    Я не считаю, что AMD врет, как и не считаю, что они говорят правду. На данный момент у меня не достаточно информации чтобы утверждать ни то ни другое.

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

    И тут появляетесь вы с вполне конкретными деталями поведения процессоров AMD, только вот когда вам начинауют вопросы задавать начинаете «я где-то слышал», «другие уже проверяли зачем я буду», «ядро писатели», «цитаты от AMD», при этом без единой ссылки (ладно вы не проверяли, но те кому нужно могут обратиться к оригинальному источнику информации, если бы ссылки присутсвовали).

    Наконец, мой оригинальный вопрос касался конкретного поведения AMD, которое вы выдаете за факт, а меня вы читать отправили документацию к Intel. Чтобы я там нашел что? Поведение процессоров AMD? Очень сомнительно ваши аргументы выглядят.
  • Spectre и Meltdown
    0
    А причем тут интеловские процессоры? Я специально спросил про остановку пайплана на AMD процессорах. Очень странно вы аргументируете свою позицию. Вы сделали вполне конкретное утверждение о том, что процессоры AMD прерывают работу команд на конвеере, а привести ссылку на документацию не можете. Правда ли есть доступная документация описывающее это или вам просто кажется, что это так?
  • Spectre и Meltdown
    0
    И вы можете дать ссылку на этот манул? И что вы подразумеваете под точным алгоритмом и принипом?