В основном, из прикреплённой поликлиники придёт врач по вызову на дом и потом там же закрывать больничный.
Если прийти в другую поликлинику, то могут попросить сделать временное прикрепление. Отказать в приёме не должны, но форс мажор может быть. Лично не пробовал. Да и ограничение на одно прикрепление в год есть.
P.S. Скорее всего так они считают, сколько людей обслуживает одна поликлиника.
Удивляет, почему до сих пор никто не догадался провести флэшмоб по закидыванию жалобами таких каналов? 100млн посмотрели фильм про дворец, а если бы они же пожаловались на канал Соловьева и других пропагандистов, то можно было бы почистить YouTube от этой дряни.
В аппаратуре боттлнек не может появится при вычислении границ инструкций, если последнее выполняется за такт. Если получится сделать логику, выполняющую разбиение куска данных на 8м инструкций и укладывающееся в такт, то получится только дополнительная стадия, логика и лишнее потребление на переключения. Никаких падений производительности здесь не появится.
Шина данных у меня — это строка или несколько строк кэша L1I. Разрежено разложить — это то, что я и написал. Вариантов этого разложение я могу придумать 2-3 уже сходу. Достаточно определить номер бита, с которого начинается конкретная из 8-ми инструкций. Число комбинаций конечное значение. Можно даже вручную их перебрать. Да, отличается от ARM, но особой проблемы нет, а тем более падения производительности.
Кэш не оперирует инструкциями и он не требует значений, зависящих от размера инструкций. Здесь нет большой разницы, учитывая ещё и то, что x86 код поплотнее будет, чем у ARM. Более того, у x86 есть ещё кэш microop, а это уже подобие RISC от ARM. Кстати, этот microop кэш можно трактовать как ещё и декодер инструкций, раз результат его работы такой же, как у декодера.
Берём 8*16байт шину данных, формируем из неё 8 x86 инструкций и отправляем на 8м декодеров. Исходные 8*16байт данных сдвигаем на число найденных x86 инструкций с учётом их размера и добавляем новую порцию данных. Где здесь появляется боттлнек? Естественно необходимо каждый такт считывать до 8*16 байт данных, в худшем случае. Подкачка последовательных инструкций — не является боттленком уже довольно давно.
Можно поставить предварительную стадию, которая разбивает на отдельные инструкции и попутно считая их число. Она будет достаточно простой функционально, но длинной, и всё-равно может влезть. Сомневаюсь, что у Intel/AMD не так сделано, а стоят подряд 4-е полноценных декодера x86. Вообще, кажется, читал, что декодеров там 2-3 разных типов, полный и несколько попроще.
А ещё, 8-м декодеров дадут прирост только в том случае, если конвейер инструкций не успевает за вычислительным. Вероятность, что Intel/AMD упустили это из виду, стремится к 0.
Хотя из статьи есть одна интересная идея. Каждая инструкция x86 переходит в последовательность мелких инструкций, которые зависят друг от друга. Т.е. для параллельного исполнения N инструкций x86 нужно сделать Reorder буфер(ROB) размером N*k, где k — длина x86 инструкций. У ARM, получается, ROB вмещает больше исходных инструкций и эффективнее используется. Но это проценты от общей производительности, если не меньше.
На частоте в два раза меньшей 8 декодеров x86 точно влезут. Тем более у M1 и техпроцесс поновее 5нм/TSMC против 7нм/TSMC у Zen3.
С бизнес моделью — вообще чушь какая-то. Ничего не мешает AMD понатыкать в свои чипы CPU/GPU/DSP/ISP/"другие ускорители"/SRAM, а сверху нахлобучить DRAM. Два основных производителя и несколько разных API для работы с этой мишурой. Вот будет радость-то!
В общем, в статье ни одного существенного препятствия для того, чтобы Intel и AMD догнали и перегнали конкретно чип M1, не приведено. Предположу, что просто не ожидали такого поворота событий. Помимо этого Intel с AMD могут не бояться Apple, так как последняя существует в своём закрытом мирке. Только косвенно, из-за возросшего интереса к ARM в целом.
За счёт чего Apple переманит к себе новых нелояльных покупателей? Те, кто и до этого использовал/покупал, так и продолжат. Процент хакинтошей вряд ли сильно большой и не будет заметен. Обновление устаревшего железа — так же не сильно скажется, так как не часто происходит. С геймингом большие проблемы у ARM, только если мобильные игры сюда посчитать. Не уверен что мобильные игры на настольном компьютере подстегнёт кого-нибудь специально покупать новые продукты Apple.
В общем, я не вижу причин почему Apple резко начнёт захватывать рынок только из-за смены CPU x86->ARM и на свой GPU.
P.S. Да, уменьшение габаритов и потребления вместе с сохранением, или даже увеличением, производительности может кого-то сподвигнуть на покупку макбука. Но не все смогут смириться, что нельзя запустить привычные программы из винды, нет популярных десктопных игр и ещё ворох проблем.
Из приведённой ссылки у M1 выше разрядность к память 128бит против 64 у обычного DDR. Больше разрмеры кэшей L1: 192L1I и 128L1D. Скорее всего и размеры остальных буферов (rename, dispatch/commit) так же больше чем у большинства AMD/Intel. Вот и набирается.
По числу исполнительных слотов вроде столько же, сколько у AMD/Intel.
Тогда для чего же нужно переименование, если не для этого?) Оно как раз заменяет архитектурные регистры на микроархитектурные и позволяет адресовать больше, чем доступно архитектурных. На линейный участок это не повлияет, а вот на независимые вычисления — ещё как.
Кэш — это кэш, контроллер и банки SRAM. Он прозрачен для программиста и только содержит некоторые части программы, и редко когда используется как непосредственно память для программ (в некоторых архитектурах линии кэша можно перепрограммировать как SRAM, а иногда и залочить, но это уже совсем другое).
Под памятью для программ я подразумевал любой тип SRAM/PRAM/DRAM и другие варианты, доступные по адресам. Разница между накристальной и на материнской плате огромная. Задержки и потребление будут кардинально отличаться. Можно сравнить HBM и обычный GDDR в GPU.
Если сравнивать user experience, то да, можно запускать в ОС бенчмарки и смотреть кто быстрее. При сравнении микроархитектур такие бенчмарки неточны из-за большого различия в коде как ОС, так и самой программы. Да и поведение недетерминировано. Правильнее взять маленькие программы для baremetal, умещающиеся в кэше, которые будут выполнять какую-то одну функцию. Вот тогда сравнение точное.
Не стоит в лоб сравнивать M1 с процессорами AMD/Intel. Сходу не припомню у последних SoC с памятью для программ на борту (Intel с их eDRAM в Iris не в счёт). Доступ в близкую память сильно быстрее и меньше потребляет.
Честно сравнить можно только программы, умещающиеся в кэш.
О тестах на латентность или пропускную способность M1 гугл пока не знает.
Похоже в спецификации ошибка. В whitepaper стоит "Peak TF32 Tensor Core" в табличке и далее в сравнении с V100.
Хотя я бы не стал полагаться на эти цифры ни в презентации AMD, ни в спеках Nvidia. Попугаи они и в Африке попугаи. Не на всех задачах эти терафлопы выжимаются.
В основном, из прикреплённой поликлиники придёт врач по вызову на дом и потом там же закрывать больничный.
Если прийти в другую поликлинику, то могут попросить сделать временное прикрепление. Отказать в приёме не должны, но форс мажор может быть. Лично не пробовал. Да и ограничение на одно прикрепление в год есть.
P.S. Скорее всего так они считают, сколько людей обслуживает одна поликлиника.
Год назад прикрепился в Зеленограде через mos.ru. Никуда не ходил. Госуслуги так до сих пор не могут? Может от региона зависит или от страховой?
Государственная комиссия по радиочастотам
Есть закон блокировать сайты, а вот о законе, запрещающем заходить на сайты, я не слышал. Разве не так? И на рутрекере не только пиратский контент.
Полагал, что Youtube сам убрал Соловьёва из трендов, а не на основе жалоб. Значит, для закрепления, нужно повторить;)
Удивляет, почему до сих пор никто не догадался провести флэшмоб по закидыванию жалобами таких каналов? 100млн посмотрели фильм про дворец, а если бы они же пожаловались на канал Соловьева и других пропагандистов, то можно было бы почистить YouTube от этой дряни.
А разве это вирус? Подобные ошибки встречаются, но исправляют после нахождения быстро.
В аппаратуре боттлнек не может появится при вычислении границ инструкций, если последнее выполняется за такт. Если получится сделать логику, выполняющую разбиение куска данных на 8м инструкций и укладывающееся в такт, то получится только дополнительная стадия, логика и лишнее потребление на переключения. Никаких падений производительности здесь не появится.
Шина данных у меня — это строка или несколько строк кэша L1I. Разрежено разложить — это то, что я и написал. Вариантов этого разложение я могу придумать 2-3 уже сходу. Достаточно определить номер бита, с которого начинается конкретная из 8-ми инструкций. Число комбинаций конечное значение. Можно даже вручную их перебрать. Да, отличается от ARM, но особой проблемы нет, а тем более падения производительности.
Кэш не оперирует инструкциями и он не требует значений, зависящих от размера инструкций. Здесь нет большой разницы, учитывая ещё и то, что x86 код поплотнее будет, чем у ARM. Более того, у x86 есть ещё кэш microop, а это уже подобие RISC от ARM. Кстати, этот microop кэш можно трактовать как ещё и декодер инструкций, раз результат его работы такой же, как у декодера.
Берём 8*16байт шину данных, формируем из неё 8 x86 инструкций и отправляем на 8м декодеров. Исходные 8*16байт данных сдвигаем на число найденных x86 инструкций с учётом их размера и добавляем новую порцию данных. Где здесь появляется боттлнек? Естественно необходимо каждый такт считывать до 8*16 байт данных, в худшем случае. Подкачка последовательных инструкций — не является боттленком уже довольно давно.
Можно поставить предварительную стадию, которая разбивает на отдельные инструкции и попутно считая их число. Она будет достаточно простой функционально, но длинной, и всё-равно может влезть. Сомневаюсь, что у Intel/AMD не так сделано, а стоят подряд 4-е полноценных декодера x86. Вообще, кажется, читал, что декодеров там 2-3 разных типов, полный и несколько попроще.
А ещё, 8-м декодеров дадут прирост только в том случае, если конвейер инструкций не успевает за вычислительным. Вероятность, что Intel/AMD упустили это из виду, стремится к 0.
Хотя из статьи есть одна интересная идея. Каждая инструкция x86 переходит в последовательность мелких инструкций, которые зависят друг от друга. Т.е. для параллельного исполнения N инструкций x86 нужно сделать Reorder буфер(ROB) размером N*k, где k — длина x86 инструкций. У ARM, получается, ROB вмещает больше исходных инструкций и эффективнее используется. Но это проценты от общей производительности, если не меньше.
На частоте в два раза меньшей 8 декодеров x86 точно влезут. Тем более у M1 и техпроцесс поновее 5нм/TSMC против 7нм/TSMC у Zen3.
С бизнес моделью — вообще чушь какая-то. Ничего не мешает AMD понатыкать в свои чипы CPU/GPU/DSP/ISP/"другие ускорители"/SRAM, а сверху нахлобучить DRAM. Два основных производителя и несколько разных API для работы с этой мишурой. Вот будет радость-то!
В общем, в статье ни одного существенного препятствия для того, чтобы Intel и AMD догнали и перегнали конкретно чип M1, не приведено. Предположу, что просто не ожидали такого поворота событий. Помимо этого Intel с AMD могут не бояться Apple, так как последняя существует в своём закрытом мирке. Только косвенно, из-за возросшего интереса к ARM в целом.
Это вы ещё в Factorio или Satisfactory не играли. Там часов 10 нужно только чтобы привыкнуть к игре и более менее освоиться.
За счёт чего Apple переманит к себе новых нелояльных покупателей? Те, кто и до этого использовал/покупал, так и продолжат. Процент хакинтошей вряд ли сильно большой и не будет заметен. Обновление устаревшего железа — так же не сильно скажется, так как не часто происходит. С геймингом большие проблемы у ARM, только если мобильные игры сюда посчитать. Не уверен что мобильные игры на настольном компьютере подстегнёт кого-нибудь специально покупать новые продукты Apple.
В общем, я не вижу причин почему Apple резко начнёт захватывать рынок только из-за смены CPU x86->ARM и на свой GPU.
P.S. Да, уменьшение габаритов и потребления вместе с сохранением, или даже увеличением, производительности может кого-то сподвигнуть на покупку макбука. Но не все смогут смириться, что нельзя запустить привычные программы из винды, нет популярных десктопных игр и ещё ворох проблем.
Совсем не очевидно. Замена сторонних CPU и GPU на свои не влечёт автоматически увеличение спроса на продукцию Apple.
По подсчётам самого Intel там всего 30%.
Из приведённой ссылки у M1 выше разрядность к память 128бит против 64 у обычного DDR. Больше разрмеры кэшей L1: 192L1I и 128L1D. Скорее всего и размеры остальных буферов (rename, dispatch/commit) так же больше чем у большинства AMD/Intel. Вот и набирается.
По числу исполнительных слотов вроде столько же, сколько у AMD/Intel.
Тогда для чего же нужно переименование, если не для этого?) Оно как раз заменяет архитектурные регистры на микроархитектурные и позволяет адресовать больше, чем доступно архитектурных. На линейный участок это не повлияет, а вот на независимые вычисления — ещё как.
Кэш — это кэш, контроллер и банки SRAM. Он прозрачен для программиста и только содержит некоторые части программы, и редко когда используется как непосредственно память для программ (в некоторых архитектурах линии кэша можно перепрограммировать как SRAM, а иногда и залочить, но это уже совсем другое).
Под памятью для программ я подразумевал любой тип SRAM/PRAM/DRAM и другие варианты, доступные по адресам. Разница между накристальной и на материнской плате огромная. Задержки и потребление будут кардинально отличаться. Можно сравнить HBM и обычный GDDR в GPU.
Если сравнивать user experience, то да, можно запускать в ОС бенчмарки и смотреть кто быстрее. При сравнении микроархитектур такие бенчмарки неточны из-за большого различия в коде как ОС, так и самой программы. Да и поведение недетерминировано. Правильнее взять маленькие программы для baremetal, умещающиеся в кэше, которые будут выполнять какую-то одну функцию. Вот тогда сравнение точное.
Не стоит в лоб сравнивать M1 с процессорами AMD/Intel. Сходу не припомню у последних SoC с памятью для программ на борту (Intel с их eDRAM в Iris не в счёт). Доступ в близкую память сильно быстрее и меньше потребляет.
Честно сравнить можно только программы, умещающиеся в кэш.
О тестах на латентность или пропускную способность M1 гугл пока не знает.
Похоже в спецификации ошибка. В whitepaper стоит "Peak TF32 Tensor Core" в табличке и далее в сравнении с V100.
Хотя я бы не стал полагаться на эти цифры ни в презентации AMD, ни в спеках Nvidia. Попугаи они и в Африке попугаи. Не на всех задачах эти терафлопы выжимаются.