В конце технического интервью, если кандидат ответил на вопросы и справился с задачами, у нас есть время для свободных вопросов, которые можно задать команде или кому-то из интервьюеров. Эту практику я переносил из компании в компанию, и она всегда помогала разрядить обстановку или вывести человека на разговор, если он был напряжен во время общения. Вопросы могут быть любые, кроме личных или тех, что под NDA. Обычно кандидаты задают технические вопросы по стеку, пайплайнам, иногда пытаются задать каверзные вопросы, особенно по плюсам, чтобы проверить нас. Иногда и мы не можем ответить на все из них. Вопросы в стиле Google — например, «почему таблетки круглые?» — тоже встречаются, но недавно на одном из интервью прозвучал вопрос, на который вроде все и знали ответ, но никто сразу не смог его дать. Вопрос звучал так: «Какие общие технологии и решения появились в процессорах с времён 486, которыми мы часто пользуемся?»
Вопрос действительно интересный — что нового появилось, чем мы пользуемся каждый день? Что умеют современные процессоры, чего не могли процессоры год или два назад, пять или десять лет назад, сорок лет назад? Мы просто используем миллиарды транзисторов, даже не зная, как они работают. Покопавшись в Википедии, на сайте Агнера Фога и в документации Intel, я составил список того, что появилось и используется в современных процессорах. Всё, что указано ниже, относится в основном к x86 и консолям, если не указано иное. Поскольку консоли после третьего поколения PlayStation — фактически ПК с минимальными отличиями, речь дальше пойдёт в основном о ПК. История имеет склонность повторяться, и многое из того, что мы сейчас имеем, вводилось не один раз, просто под разными названиями.
Разное
Для начала, современные процессоры имеют более широкие регистры и могут адресовать больше памяти. В 80-х годах использовались 8-битные процессоры, но сейчас почти наверняка все ПК и консоли работают на базе 64-битного процессора. Не буду подробно останавливаться на этом, предполагая, что хабражитель как минимум знаком с программированием или смежной тематикой.
Другие решения, которые мы используем в повседневной жизни, но которые были введены в x86 еще с начала 80-х, это страничная организация и виртуальная память, конвейеры вычислений и поддержка операций с плавающей точкой через сопроцессоры.
Кэши
https://en.wikipedia.org/wiki/CPU_cache
Одним из наиболее значимых технических решений для повседневного программирования стало появление кэшей в процессорах. Например, на 286 доступ к памяти занимал всего несколько тактов, а вот на Pentium 3/4 доступ к памяти требовал уже более 400 тактов. Несмотря на то, что процессоры стали значительно быстрее, память не развивалась так же быстро.
Решением проблемы медленной памяти стали кэши и предвыборка данных большими блоками из оперативной памяти. Кэширование позволяет быстро получить доступ к часто используемым данным, а предвыборка загружает данные в кэш, если модель доступа предсказуема.
Несколько тактов против 400+ тактов выглядят пугающе, фактически это просадка более чем в 100 раз. Но, если написать простейший цикл, обрабатывающий большой блок данных, процессор будет предвыбирать нужные данные заранее, позволяя обрабатывать данные на скорости около 22 ГБ/с на моем 3-ГГц Intel. При обработке двух данных за такт при частоте ~3 ГГц в теории можно получить 24 ГБ/с, так что 22 ГБ/с — это неплохой результат. Мы теряем около 5% производительности при загрузке данных из основной памяти, а не на порядки больше.
И это еще не все: при известных паттернах доступа, например, при работе с массивами и блоками данных, которые хорошо помещаются в кэше процессора и легко детектируются блоком предсказания, можно получить близкую к максимальной скорость обработки. Здесь стоит упомянуть известную статью Ульриха Дреппера "Что каждый программист должен знать про память" (https://people.freebsd.org/~lstewart/articles/cpumemory.pdf, rus-linux.net/lib.php?name=/MyLDP/hard/memory/memory.html).
TLB (Translation Lookaside Buffer)
https://en.wikipedia.org/wiki/Translation_lookaside_buffer
Сколько у ядра кэшей? 1-2-3-5? У ядра есть множество различных кэшей для разных задач, и кэши для основной памяти здесь далеко не самые быстрые. Например, есть кэш декодированных инструкций, и вы вряд ли когда-то будете задумываться о его существовании, если только не занимаетесь микрооптимизацией, когда все остальные способы уже были испробованы.
Есть TLB-кэш, который используется для поиска адресов виртуальной памяти. Он расположен отдельно, потому что, даже если данные находятся в кэше L1, поиск любого адреса будет занимать несколько тактов. Поэтому и существует кэш для поиска по виртуальным адресам, обычно имеющий очень ограниченный размер — десятки, максимум сотни записей. Однако поиск по нему занимает один такт или даже меньше благодаря использованию отдельного блока управления.
Спекулятивное выполнение
https://en.wikipedia.org/wiki/Speculative_execution
Конвейерные реализации и наличие блока предсказания переходов в процессорах позволили добавить спекулятивное выполнение, что привело к снижению стоимости условного перехода. Применяя данные от BPU, можно начать выполнения ветвления на основе истории до того как будет известно значение перехода, то есть заранее перед условным переходом. Сначала BPU определяет, какой из вариантов перехода наиболее вероятен, и проц загружает следующий набор инструкций, связанных с этим переходом. Если предсказание оказалось верным, инструкции уже готовы, и не будет никакой задержки выполнения. Если предсказание было неверным, проц загружает необходимые данные и переходит к этим инструкциям. Однако точность предсказателей переходов обычно превышает 95%, поэтому необходимость перезагрузки данных возникает редко.
Спекулятивное выполнение появилось на процессорах Intel с Pentium Pro и Pentium II, и на AMD с линейки K5.
Параллельные вычисления
Ещё одной важной инновацией, которая изменила подход к разработке и производительности ПО, стала поддержка многозадачности и параллельных вычислений на уровне железа. Когда-то многозадачность в x86 выполнялась только на уровне операционной системы, но с появлением процессоров Intel с поддержкой технологии Hyper-Threading (HT) появилась возможность выполнять два "потока" на одном физическом ядре.
Благодаря HT и, позднее, многим физическим ядрам в процессоре, мы смогли выполнять несколько программ или частей программы физически параллельно, снижая время ожидания. Например, в играх это используется для разделения логики, обработки звука, физики и рендеринга, где каждое ядро или поток может быть занят своей задачей. Современные процессоры, особенно в консолях, могут содержать несколько специализированных ядер, что позволяет эффективно распределять нагрузки между потоками.
В третьей плойке установлен центральный процессор Cell BE(Broadband Engine). Этот процессор является совместной разработкой инженеров компаний Sony, Toshiba и IBM. В процессоре установлено 8 ядер. Рабочими являются только семь ядер, восьмое — дополнительное и предназначено для улучшения производительности путём распределения мощности между остальными ядрами. Если одно из восьми ядер получит дефект при производстве, то оно может быть отключено без необходимости объявления дефектности всего процессора. Тактовая частота ядра 3,2 ГГц.
Некэшируемые области памяти
Процессор не может работать напрямую с оперативной памятью: сначала данные попадают в кэш, забираются оттуда в регистры и обрабатываются. Но это не подходит для видеокарт, которым например нужны обновления сразу в буфере текстур. Решением стали некэшируемые участки памяти и механизмы работы с ними, которые позволяют избежать ненужного использования кэша. Одной из особенностей консолей всегда было наличие медиа-процессора, который может сжимать и разжимать видеопоток используя большинство современных кодеков с довольно приличной скоростью, на уровне где-то 150-200 кадров в секунду, успевай только кормить. Но если попробовать прокинуть копирование этих кадров через кеш, то получим очень удручающую ситуацию.
size CPU->GPU
memcpy
------ -------------
256 44.44 Mb/s
512 44.46 Mb/s
1024 44.49 Mb/s
2048 44.46 Mb/s
4096 44.44 Mb/s
8192 33.31 Mb/s
16384 33.31 Mb/sEсли мы будем копировать Full HD видео фрейм, который занимает 1920*1080*1.5 (NV12) = 3,110,400 байт, то сможем заливать только 13 фреймов. Консоли предоставляют удобные механизмы контроля маппинга памяти с разными режимами кэширования, и если правильно использовать WC (write-combining режим записи для некэшируемой памяти) и сделать что-то вроде
wc_fd = mdec_dma_open(SHM_ANON, O_RDWR | O_CREAT, 0);
mdec_dma_ctl(wc_fd, SHMCTL_ANON | SHMCTL_LAZYWRITE, 0, pix_buffer_mem_size);
mmap64(NULL, pix_buffer_mem_size, PROT_READ | PROT_WRITE, MAP_SHARED, wc_fd, 0);
close(wc_fd);хендл wc_fd теперь указывает на память с другими настройками доступа. Результаты будут совсем другие (PS5). Учитывая что память общая, копировать вообще ничего и не нужно, декодер размещает свои данные в памяти, убираем проц из этой цепочки, ему только остается помечать моменты когда видеокарта может обратиться к этим данным:
size VD->СPU->GPU VD->GPU(WC)
memcpy memcpy
------ ------------- -------------
256 44.44 Mb/s 2449.41 Mb/s
512 44.46 Mb/s 3817.70 Mb/s
1024 44.49 Mb/s 4065.01 Mb/s
2048 44.46 Mb/s 4354.65 Mb/s
4096 44.44 Mb/s 4692.01 Mb/s
8192 33.31 Mb/s 4691.71 Mb/s
16384 33.11 Mb/s 4694.71 Mb/sУ десктопного варианта есть LLC (Last Level Cache) кэш. Кэш называют LLC, когда он последний, например, для процессора он будет L3, а для GPU он будет L4. И он объединяет между собой не только процессор, но и другие устройства. Видеокарта отслеживает записи в таких регионах памяти и забирает их себе без участия процессора.
NUMA (Non-uniform Memory Access)
Архитектура с неравномерным доступом к памяти (NUMA), где задержки и пропускная способность памяти различаются, стала настолько распространенной, что воспринимается как стандарт. Почему у нас появились системы NUMA? Изначально была просто память, но с ростом скорости процессоров по сравнению с памятью она уже не могла выдавать данные достаточно быстро, и был добавлен кэш. Кэш должен был оставаться согласованным с основной памятью, работать на порядок быстрее, но при этом был существенно меньше по объему. Он также должен был содержать метаинформацию о данных, чтобы знать, когда их нужно записать обратно. Если записи не требовалось, это улучшало производительность, поскольку такие алгоритмы — самые быстрые.
Позже объёмы памяти стали настолько велики (гигабайты и терабайты оперативной памяти), что маленького кэша уже не хватало для охвата всей доступной памяти. При работе с большими объёмами данных происходило "вытеснение" данных из кэша, и алгоритм начинал работать даже медленнее, чем при доступе к основной памяти. Появились кэши второго и последующих уровней, чтобы с одной стороны обеспечивать доступ к большому объему оперативной памяти, а с другой — не быть слишком медленными и успевать "кормить" кэш первого уровня.
Сложность управления кэшами возросла ещё больше, когда ядер стало несколько, и у каждого был свой кэш. Данные из оперативной памяти должны были оставаться согласованными со всеми кэшами. До NUMA каждый процессор/ядро отправляли сообщение в общую шину при каждой операции чтения или записи, чтобы другие процессоры/ядра могли при необходимости обновить свой кэш.
Эта схема работала для 2–4 процессоров/ядрах, но с ростом их числа время ожидания ответа от всех становилось сравнимым с одним тактом, а микрокод кэшей становился слишком сложным для масштабирования. Решением этой проблемы стало использование общего механизма на группу ядер, который отслеживает состояние кэша для всех ядер группы. Такая структура решает проблему согласованности кэша внутри группы, но сами группы уже нуждаются в синхронизации.
Недостатком такого подхода стало снижение производительности, когда одна группа ядер обращается к памяти, принадлежащей другой группе. В консолях и бытовых системах (до 64 ядер) дополнительно используется кольцевая шина, что добавляет задержку при передаче сообщений между группами при доступе к памяти.
Немного про отравление кеша тут, там же и про когерентность кешей (https://habr.com/ru/articles/687146/)
SIMD (Single Instruction Multiple Data)
Технология SIMD, впервые введённая в x86 как MMX в 90-х годах, позволила выполнять одну инструкцию сразу над несколькими данными, что значительно ускоряет операции с массивами, векторные и графические вычисления. Например, AVX/AVX2/512 (Advanced Vector Extensions) и SSE (Streaming SIMD Extensions) — это более современные версии SIMD, которые активно используются в играх, наукоёмких приложениях, обработке изображений и видео. Эти инструкции позволяют производить вычисления над большими массивами данных, ускоряя операции с плавающими числами и целыми числами в графике, физике и машинном обучении.
Условный код, вида:
for (int i = 0; i < n; ++i) {
sum += a[i];
}хорошо распознается компилятором и векторизуется. А вот что-то вроде такого, уже вызывает проблемы, да и зачастую даже на простых примерах компилятор тоже пасует.
for (int i = 0; i < n; ++i) {
if (!a[i]) continue;
sum += a[i];
}Скорость и эффективность SIMD объясняется тем, что при обработке, скажем, четырёх чисел одновременно, это не требует дополнительных тактов для обработки каждого числа отдельно. Вместо этого процессор выполняет операцию сразу над четырьмя (или даже восемью) числами. Такая оптимизация позволяет увеличить производительность в 2–4 раза на обычных задачах и на порядок — на специальных задачах, но в большинстве случаев мы получаем x1.5-x2 прирост на задачах и специального человека в команде, который это разруливает.
Out-of-Order Execution (Внеочередное выполнение)
90-х годах также появился механизм внеочередного выполнения, который позволяет процессору "угадывать", какие инструкции можно выполнить, пока другие ожидают своих данных. Это позволяет процессору не простаивать, ожидая, пока данные загрузятся из памяти, а продолжать работу, выполняя другие операции, для которых данные уже доступны.
Современные процессоры могут управлять десятками таких "незавершённых" операций одновременно. Это помогает значительно улучшить производительность в ситуациях, где последовательные инструкции могут мешать друг другу, особенно в случае длинных вычислительных цепочек. В играх, где алгоритмы специально переделывают чтобы снизить зависимость, например, физические взаимодействия и эффекты частиц, это может принести некоторый профит и снизить задержки.
Управление питанием
Картинка выше позволяет оценить сколько мы теряем производительности на управлении питанием в емких вычислениях и необходимости "пробуждать" проц после простоя, один из внутренних бенчмарков студии для оценки пригодности cpu.
Современные процессоры пришли к "пиковым" алгоритмам производительности и оснащены множеством функций управления питанием, которые уменьшают энергопотребление в различных сценариях. Большинству современных приложений требуется выйти на пик производительности на несколько секунд, выполнить задачу и затем перейти в режим минимальной частоты для экономии энергии. Это делает подход «ускорение до простоя» (выполнение задач как можно быстрее с последующим переходом процессора в режим простоя) наиболее эффективным.
Однако для игр этот подход не работает: разработчики игр годами стремятся максимально загружать процессоры, удерживая их на высокой производительности как можно дольше. Это мешает процессорам уходить в режим энергосбережения, что критично для игр. Проблема в том, что выход на рабочие частоты занимает значительное время, что вызывает рывки фреймов и нестабильное время отклика. В некоторых случаях даже приходится придумывать код, который работает в фоне, чтобы предотвратить уход ядер в режим энергосбережения, когда основным потокам нечего делать. Это особенно заметно на последних поколениях энергоэффективных процессоров. В левой части - мобильный Ryzen 9-4900HS/RTX2060 на внутренних тестах, с выключеной в биосе опцией управлени питанием, справа он же c активным планом. Один и тот же лэптоп, но вот этот дребезг получается из-за постоянного гуляния частоты процессора, каждые 4-5 фреймов, N запусков бенчмарка, каждый длинной в пару секунд, запоминаем максимальное время фрейма на каждом запуске.
GPGPU
До середины 2000-х графические процессоры (GPU) были ограничены API, который предоставлял лишь базовый контроль над оборудованием. Однако, когда в системе есть фактически второй процессор со своей собственной памятью, часто не уступающей по параметрам основному, возникает вопрос, "почему он простаивает?". Так люди начали использовать видеокарты для более широкого круга задач, например, для задач линейной алгебры, которые прекрасно подходят для параллельных вычислений. Параллельная архитектура GPU могла обрабатывать крупные матрицы, например 512×512 и большего размера, с которыми обычный CPU мягко говоря справлялся очень плохо. Из интересного можно почитать статью Игоря Островского на эту тему (https://igoro.com/archive/gallery-of-processor-cache-effects/)
Первоначально библиотеки использовали традиционные графические API, но позже Nvidia и ATI заметили эту тенденцию и выпустили расширения, которые предоставили нам доступ к большему количеству функций оборудования. На верхнем уровне GPU включает один или несколько потоковых многоядерных процессоров (SM). Каждый такой процессор обычно содержит несколько вычислительных блоков (ядер). В отличие от CPU, GPU не имеют ряда функций, таких как большие кэши или предсказание переходов, или они сильно урезаны по сравнению с CPU. Поэтому задачи, хорошо подходящие для GPU, обладают высокой степенью параллелизма и содержат данные, которые можно разделить между большим количеством потоков.
Память GPU делится на два основных типа: глобальную и разделяемую. Глобальная память — это GDDR, объем которой указан на коробке GPU и обычно составляет от 2 ГБ и выше, доступна всем потокам на всех SM и является самой медленной памятью на карте. Разделяемая память используется всеми потоками в одном SM. Она быстрее глобальной памяти, но недоступна для потоков в других SM. Обе категории памяти требуют строгих правил доступа: нарушение этих правил влечет значительное снижение производительности. Чтобы достичь высокой пропускной способности, доступ к памяти должен быть правильно организован для параллельного использования потоками одной группы. Подобно тому, как CPU считывает данные из одной линии кэша, у GPU линия кэша рассчитана на обслуживание всех потоков в группе при правильном выравнивании. Производители стараются увеличить размер кэш-линии, чтобы обеспечить одновременный доступ как можно большему числу SM. Но это работает только в случае, если все потоки обращаются к одной кэш-линии. В худшем случае, когда каждый поток в группе обращается к разным кэш-линиям, для каждого потока требуется отдельное чтение, что снижает эффективную пропускную способность памяти, так как большая часть данных в кэш-линии остаётся неиспользованной.
Почему я отнес это к CPU? Поскольку мы начали использовать GPU для решения общего круга задач, почему бы и не рассматривать их в этом контексте?
Виртуальная память
Это еще одна из "новых" функций, о которой не приходится задумываться, если мы не занимаемся разработкой операционной системы. Виртуальная память значительно упрощает использование по сравнению с сегментированной памятью, но эта тема уже не актуальна, так что можно на этом остановиться. Виртуальная память использует как аппаратные, так и программные средства, чтобы компенсировать нехватку физической памяти, временно перенося данные из оперативной памяти (RAM) на диск. Отображение фрагментов памяти в файлы на диске позволяет компьютеру обрабатывать вторичную память так, как если бы она была основной памятью. Хорошая статья для ознакомления (https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/9_VirtualMemory.html)
SMT / HT
Использование в основном прозрачно для программистов, но важно знать пару моментов. Типичное ускорение для включения HT на одном ядре составляет около 25% для программ общего пользования. Это улучшает общую пропускную способность, позволяя больше загружать ядро данными от двух потоков выполнения, но при этом каждый поток на ядре может потерять в производительности. Для игр, где важна высокая производительность одного потока, выгоднее отключить HT, чтобы сторонние приложения меньше лезли в кеш и мешали работе. Даже если мы прибьем поток к конкретному ядру, мы все равно не сможем утилизировать более 80% времени ядра, даже при цифрах загрузки близким к 75-80% у нас будут происходить переключения на кадры других потоков. Для примера могу привести случай из жизни, когда у моделера игра просаживалась до 50 фпс просто если в фоне был включен Houdini, который был свернут и "ничего" не делал, но продолжал активно использовать первое ядро, на котором крутился основной поток игры, зависимость была на линейке 12700 от Intel. После выключения HT, ситуация немного улучшилась до 55 fps, а в Pix'e было видно что на первое ядро все равно пролезали блоки выполнения Houdini. Cтабильные 60 получались только при выключении 3д пакета, хотя многое зависит от конкретной нагрузки и от железа, потому что на AMD такой зависимости не было.
Другим побочным эффектом усложнённости чипов стало то, что производительность стала менее предсказуемой, чем раньше, особенно на мобильных чипах. Хорошая статья от NASA почему там будет хорошо если 30% прироста, а не х2 как все надеются :) (https://www.nas.nasa.gov/assets/nas/pdf/papers/saini_s_impact_hyper_threading_2011.pdf)
BPU (Branch Prediction Unit)
Блок предсказания переходов — это отдельная часть процессора, минипроцессор со своей прошивкой, памятью, кешами и тд, который предсказывает выполнение условных переходов в потоке инструкций. В современных процессорах предсказание переходов стало критически важным для роста производительности, так как позволяет сократить простои в конвейере инструкций и более эффективно использовать его ресурсы. В последних поколениях процессоров Intel площадь блока BPU на кристалле может занимать до 15% ядра, а объем микрокода BPU сопоставим с объемом всего остального микрокода. Однако создание больших и глубоких блоков BPU стало крайне сложной задачей, и поэтому блоки глубиной более 64 уровней вложенности практически не проектируют.
Сам BPU состоит из нескольких частей:
Таблица предсказаний (Branch Prediction Table, BPT) — хранит историю предсказаний для различных инструкций переходов, записывая адрес инструкции и статус перехода (например, "выполнится" или "не выполнится").
Буфер истории переходов (Branch History Buffer, BHB) — сохраняет последовательность последних переходов для повышения точности предсказаний, учитывая поведение программы в прошлом для более точного предсказания текущих переходов.
Кэш целевых адресов (Branch Target Buffer, BTB) — хранит целевые адреса переходов, позволяя быстрее осуществлять переход в нужную точку кода при успешном предсказании. BTB также помогает загрузить в кэш L1 данные, которые могут потребоваться в этой ветке.
Кэш последних выполненных переходов (Last Recent Branch Buffer) — хранит последние N адресов переходов (обычно не более 64). Сначала поиск выполняется в этом быстром кэше; если ответ не найден, выполняется поиск по BPT.
BPU (Ветвления)
Интересная статья по теме (https://blog.cloudflare.com/id-id/branch-predictor/)
С первого дня моей работы в программировании опытные коллеги предупреждали, что ветвления замедляют выполнение кода и их следует избегать. На процессорах серии Intel 12700 штраф за неверное предсказание ветвления составляет 14 тактов. Частота неверных предсказаний зависит от сложности кода и общей глубины вложенности. По моим последним замерам на проектах (PS4/5), частота ошибок предсказаний была от 1% до 6%. Показатели выше 3% считаются значительными и могут быть сигналом к оптимизации кода.
Однако, если верное ветвление занимает всего 1 такт, то средняя стоимость ветвления составит:
При 0.5% ошибок: 0.995×1+0.005×14=1.065 * 0.995 \times 1 + 0.005 \times 14 = 1.065 * 0.995×1+0.005×14=1.065 тактов.
При 4% ошибок: 0.96×1+0.04×14=1.52 * 0.96 \times 1 + 0.04 \times 14 = 1.52 * 0.96×1+0.04×14=1.52 тактов.
После таких замеров на реальных проектах мы стали меньше придираться к наличию if, если они не усложняют чтение кода.
Исследуя материал для доклада по ветвлениям внутри студии, я пришел к выводу, что данный штраф не так критичен, учитывая, что в среднем лишь 5% предсказаний ошибочны. Непредсказуемые ветвления — это минус, но большинство из них хорошо поддаются профилированию в горячих функциях и их хорошо видно что в PIXe, что в Razor'e. Оптимизировать алгоритм имеет смысл только там, где профилировщик выявляет проблемы. За последние двадцать лет процессоры стали более устойчивыми к неоптимизированному коду, а компиляторы научились его оптимизировать, так что оптимизация ветвлений разными костылями и хаками из конца 90-х уже не так актуальна и требуется в основном для максимального увеличения производительности уже на этапах пост профилировки релиза.
Хорошая лекция по этой теме (https://course.ece.cmu.edu/~ece740/f15/lib/exe/fetch.php?media=18-740-fall15-lecture05-branch-prediction-afterlecture.pdf)
И еще одно наблюдение о ветвлениях: современные процессоры (XBOX, PS4, PS5, почти все мобильные процы) игнорируют инструкции для предсказания ветвлений, но такие указания помогают компилятору лучше расположить код. Сам процессор полагается исключительно на BPU, а не на "подсказки" от программиста.
Спасибо что дочитали! Если что забыл указать, пишите в коментах.
Комментарии (165)
Nurked
06.11.2024 21:09Так, начнём вот с чего. 486 был моим первым процессором. Это было мажорство, но я не возражал. 100 мегагерц было достаточно всему. Игры шли вообще без каких либо тормозов. Тогда вообще мало что тормозило.
А теперь, реальные вещи, которые 486 нам принёс:
CMPXCHG - теперь сравнивать и перемещать данные между регистрами можно было атомарно, не надо было писать отдельные инструкции.
Встроенный математический сопроцессор. Больше не нужно было бояться операций с плавающей точкой.
Процессор работал быстрее скорости шины. Можно было получить ответ от АЛУ за один такт, там где 386 занимал два такта.
Была ещё кнопочка, которая переводила процессор из режима 66 мегагерц в режим 100 мегагерц. Это было необходимо, чтобы усмирить горячего парня, ибо некоторые ДОС программы выполнялись слишком быстро. А в GTA можно было играть чуть медленней, и игра шла приятнее, не так дёргано.
Короче, учился программировать на этой штуке. Мой первый компьютер. Шеффс кисс.
Politura
06.11.2024 21:09Кнопочка turbo повышающая частоту была на всех, начиная с 8088/8086, как раз потом, может быть даже и с пентиумов, от нее отказались.
alan008
06.11.2024 21:09Вообще-то кнопка Turbo была не для повышения частоты, а для переключения со стандартной частоты (это и был режим Turbo) на пониженную (без Turbo).
PATRI0T
06.11.2024 21:09А зачем пониженная? Проходимость лучше?)
Javian
06.11.2024 21:09Например чтобы старый софт не вываливался в деление на ноль.
Стандартный модуль CRT используется во многих программах на Turbo Pascal. Но при запуске этих программ на современных компьютерах, оснащённых быстрыми процессорами, возникает ошибка "Деление на нуль"
...На процессорах, частота которых 200 MHz и выше, DX:AX, делённое на 55 оказывается больше 65535 и, поэтому, результат не может поместиться в AX. Происходит так называемое переполнение при делении.
https://jkfs.petrsu.ru/~yura/pyldin/yura/u_crt.htm
Программ было много, у которых были проблемы из-за намного быстрого процессора, чем в момент создания программы. Что-то времен 8086 наверняка могло некорректно работать, например игра идет намного быстрее чем следует.
MaFrance351
06.11.2024 21:09Помню, позже ещё были патчи специальные, в духе FIX200.EXE, призванные починить этот Runtime Error.
alan008
06.11.2024 21:09Чтобы человечек в играх не бегал по экрану как бешеный (независимость от framerate'а на тот момент ещё не изобрели)
DvoiNic
06.11.2024 21:09некоторые программы (в т.ч. игрушки) были завязаны на стандартную частоту XT.
beerchaser
06.11.2024 21:09Кнопка Turbo впервые появилась на клонах IBM XT 8088. BIOS у клонов был в значительной степени тянутый и содержал проверку на тактовую частоту из оригинала. Запуск производился на базовой частоте (вроде 4 МГц). После инициализации/загрузки BIOS нажималась кнопка Turbo.
perfect_genius
06.11.2024 21:09Вы не читаете ветки, на которые отвечаете? Или вас сбила с толку ошибка в первом комменте?
из режима 66 мегагерц в режим 100 мегагерц
atomlib
06.11.2024 21:09Тут нужно различать сам режим работы (с его индикацией светодиодом на корпусе) и кнопку.
Режим Turbo — это работа в полной скорости. Этот режим является режимом по умолчанию. Так его описывает какой-нибудь даташит того же 486:
Конкретная реализация кнопки могла различаться от корпуса и материнской платы. Иногда это был замыкающий контакт переключатель, который нажимался и фиксировался в нажатом положении, пока не нажать его повторно. При желании переключатель можно было подключить так, чтобы нажатое положение означало отключение режима Turbo. При отсутствии переключателя полагалось вместо него поставить на материнскую плату джампер.
В других корпусах и системных платах это была обычная кнопка, которая замыкала контакт и отключала режим Turbo, чем замедляла компьютер. Чаще всего получалось так, что кнопка Turbo отключала включённый по умолчанию режим Turbo, а не включала его.
Отказались от кнопки и светодиода действительно в начале эпохи «Пентиумов».
DvoiNic
06.11.2024 21:09Еще был не просто светодиод, а платка с семисегментником. Да и таких были два варианта - "HI"/"LO", и "продвинутый", на котором джамперами выставлялись зажигаемые сегменты, индицирующие частоту...
commanderxo
06.11.2024 21:09В девяностые даже анекдот был про "нового русского", которому продали компьютер в максимальной конфигурации где по кнопке турбо на передней панели показывалось LO, а потом HI, и он пришёл в магазин разбираться кто же именно тут ЛОХИ.
geher
06.11.2024 21:09У меня на пне 120 была работающая кнопка "ло-хи". С соответствующим индикатором. И на многих материнках того времени была возможность подключать турбокнопку. Зачем оно было нужно, не знаю, разница почти не замечалась.
На следующем поколении пней уже такого не наблюлал, хотя кнопка на корпусе еще долго попадалась, просто была не подключена к материнке. Иногда ее использовали для замыкания какой-нибудь перемычки на материнке или плате расширения. Например, перемычки сброса настроек биоса (понятия не имею, зачем).
Ndochp
06.11.2024 21:09На моем пне 75 это была пауза. Ну скорее всего какой-то слип, но можно было остановить любую программу, даже дос, чаю попить, отжать кнопку и продолжить играть.
Dick_from_mountain
06.11.2024 21:09Сопроцессор и на 386Dx был.
vanxant
06.11.2024 21:09Отдельной микросхемой
MaFrance351
06.11.2024 21:09Причём в случае с впаянным в плату основным камнем ещё больше похожей на процессор, как мы его представляем.
Забавно сейчас показать кому-то (из тех, кто "тройки" не застал) плату и попросить показать, где тут процессор.
strvv
06.11.2024 21:09Кстати, да, на части х86 архитектур, до того как осталось только двое, северный/общий мост был больше чем процессор, и/или процессор с ним образовывал многочиповое решение, размазанное между ними.
Например разные редакции Cyrix вплоть до Amd MediaGx, когда процессор и видеопроцессор с северным мостом размазывались в двух-трех чипах, т.к. реализация архитектуры у cyrix, ibm, ti, amd была различной.
HardWrMan
06.11.2024 21:09Забавно у него кеш размазан по плате: область данных с одной стороны, возле BIOS и ОЗУ, а тэги внизу, промеж процессора и сопроцессора.
Javian
06.11.2024 21:09На таких частотах процессоров на задержку передачи данных еще не влияла скорость света в вакууме.
MaFrance351
06.11.2024 21:09А вот сокет 423 помер именно из-за этого - банально паразитная индуктивность мешала достичь более высоких частот.
HardWrMan
06.11.2024 21:09Ага, я когда посмотрел тот самый ролик от THG, у нас уже ходил 478, а в ролике 423 - некоторые не верили, что это Р4. Я про этот ролик, если что:
Sly_tom_cat
06.11.2024 21:09Я почему-то не открывая фуллсайз угадал где проц.
Но у меня прям дежавю т.к. моя первая мамака с 386 была очень похожа на эту, но на месте сопроцессора было пусто.
vitalyvitaly
06.11.2024 21:09Есть такая штука, как RapidCAD в 386 гнездо. Там сопроцессор уже встроен. Видел чувака в ютубе, который ставил его на одну плату с сопроцессором Weitek (еще одно редкое чудо) - и таким образом, можно было иметь в системе уже два разных сопроцессора с разными системами команд (Weitek вроде бы не из серии x87 и требовал специальных драйверов), хотя и не одновременно.
khajiit
06.11.2024 21:09Weitek был своеобразной, но очень интересной железкой )
vanxant
06.11.2024 21:09Не, все сопроцессоры линейки х87 был намного более прикольными железками по принципу работы. Они слушали основной процессор на шине, пропускали все "не свои" инструкции, и выполняли только свои. Основной процессор, соответственно, пропускал инструкции сопроцессора.
khajiit
06.11.2024 21:09Да, weitek в этом плане скорее DSP. Чем он и интересен: обычных сопроцессоров было как грязи, а это — штучное изделие, аппаратно поддерживающее тот же протокол обмена (#FERR, если склероз не изменяет, и шинный обмен с памятью, с остановом основного CPU) , но кардинально отличающееся внутри.
SIISII
06.11.2024 21:09CMPXCHG - теперь сравнивать и перемещать данные между регистрами можно было атомарно, не надо было писать отдельные инструкции
"Принёс нам" -- это кому? Сама подобная операция известна была задолго до появления 80486 и даже до 8086. В частности, она была реализована на (почти) всех мэйнфреймах Системы 370 (команды CS и CDS), а это начало 1970-х.
vanxant
06.11.2024 21:09Старшие 386 тоже работали быстрее скорости шины. Собственно, шина была на 16 МГц, больше не удавалось выжать из стандартной памяти (ОЗУ). Чипы DRAM на 20 и 24/25 МГц в природе были, но были дорогие и редкие. Ещё точнее, между шиной и процессором часто ставили кэш-память (отдельный контроллер и отдельные чипы SRAM на материнской плате), но сами процессоры могли работать и без этого, с множителем внутренней частоты.
Собственно, даже старшие 286 работали быстрее шины, потому что у них почти напрямую была подключена шина ISA аж на целых 8 МГц.
vitalyvitaly
06.11.2024 21:09Я читал когда-то, что были клоны 386AT с оперативной памятью на "статике". Выигрыш в скорости, как утверждалось, составлял до 25 процентов, но и стоимость таких компьютеров явно была очень высокой.
saboteur_kiev
06.11.2024 21:09Так если он был первым, вам было тяжело сравнить с тем, что было до 486 =)
Nurked
06.11.2024 21:09Ну, со временем выучил его. Он у меня был аж до 2002 года, пока я буквально на барахолке не нашёл старенький Celeron III 667Mhz, родители не видели причин для обновлений, поэтому мне пришлось самому всё делать.
saboteur_kiev
06.11.2024 21:09У меня просто хорошее сравнение на личном опыте БК, Спектрум, x86, 286, 386, 486, и так далее.
ITxasky
06.11.2024 21:09Так, начнём вот с чего. 486 был моим первым процессором. Это было мажорство, но я не возражал. 100 мегагерц было достаточно всему. Игры шли вообще без каких либо тормозов. Тогда вообще мало что тормозило.
моя история, "плюсую" :) машина по тем временам отличная
Dr_Faksov
06.11.2024 21:09Хотелось бы заметить, что страничная организация памяти - технологический костыль, а не какое-то преимущество. Позволяла адресоваться к большим адресам имея ограниченную по разрядности шину адреса. Цена вопроса - время операции. Адрес выставлялся в несколько заходов.
HardWrMan
06.11.2024 21:09Забавно, что когда 4ГБ (32 бита) стало мало для всех, то сначала придумали именно РАЕ, как самое очевидное.
vanxant
06.11.2024 21:09Вы таки путаете страничную организацию с сегментной. 16-битный 8086 мог работать с 1Мб ОЗУ именно за счёт сегментов (а 80286 - и с 16 Мб ОЗУ при тех же 16 битах адреса).
Забавно, что сейчас ситуация обратная. "Гражданские" 64-битные процессоры, как правило, ограничивают адрес 48 бит, серверные иногда поднимают планочку до ~52. Типа зачем тратить лишние транзисторы, если физического ОЗУ столько быть не может даже близко. Полные 64 бита имеют разве что PowerPC (НЯЗ)
VoodooCat
06.11.2024 21:09Полные 64 бита в том или ином виде используются для реализации так называемых tagged pointers, когда в адрес зашивается "тэг", для увеличения безопасности работы с памятью (с помощью от железа, разумеется чисто софтовые реализации тоже есть). У intel - Linear Address Masking, AMD - UAI (Upper Address Ignore), и даже на каких-то ARM вроде было. Но для intel/amd это относительно новое.
vanxant
06.11.2024 21:09UAI появилось в Zen4, совсем свежак. Аналог от Интела описан в 2020 году.
До этого все неиспользуемые биты были обязаны быть равными самому старшему биту (который всегда 0 для юзерспейса и 1 для ядра). И сделано это было именно, чтобы дать по рукам любителям потегировать указатели ценой потенциальной несовместимости с будущими процессорами.
В частности, дефолтная JVM, которая использует тегирование для сборщика мусора, выделяет под это дело 3 старших допустимых бита (биты 45-47), в которых хранит номер "поколения". Таким образом, они сами себе режут потенциальное адресное пространство в 8 раз, но считают это оправданным. А дальше вообще финт ушами: они мапят при помощи ОС виртуальное адресное пространство своего процесса на физическое 8 раз, чтобы все 8 вариантов адреса с тегами указывали на одну и ту же физическую ячейку памяти. В итоге, видя такие страдания, Intel и AMD сдались:)
Panzerschrek
06.11.2024 21:09С ветвлениями надо быть всё же поосторожнее. Если важна производительность, надо следить, чтобы ветвления были предсказуемы. Если же там по сути алгоритма вероятность перехода около 50%, то нужно думать, или как эту вероятность в какую либо из сторон сдвинуть, или же полностью отказаться от ветвления.
Myclass
06.11.2024 21:09Навскидку пару дополнительных вещей:
-Появление дополнительных ядер с уменьшенным количеством электронно-реализованных команд, вследствие чего и потребляющих намного меньше энергии.
-Вследствие ошибки в транзисторной реализации операций с плавающей запятой и чуть-ли не банкротством из-за возможных рисков, что весь мир захочет поменять 'бракованный' процессор - Intel перестал быть чистым CISC процессором, а перешёл на смесь CISC и RISC, чтобы не все новые команды с помощью транзисторов делать, а использовать микрокод. Который можно удалённо и апдэйтить.
vanxant
06.11.2024 21:09Строго говоря, микрокод у них был со времён 8086. И то же деление делалось микрокодом. А также всякие сложные адресации. Просто во времена 8086 этот микрокод был "захардкожен" в масочном ПЗУ - на кристалле тупо либо были дорожки, либо не были. Со временем это ПЗУ стало shadow, евпочя.
После ошибки с делением они сделали возможность этот микрокод апгрейдить из БИОСа или драйверов. В ПЗУ, разумеется, оставалась базовая версия.
buinovb
06.11.2024 21:09Мне кажется, что про спекулятивное выполнение написано не совсем правильно. Это больше про выполнение выполнение операций, которые потом могут оказаться не нужны. Например, вычислить обе ветке if до проверки условия. Поправьте, если я не прав.
SIISII
06.11.2024 21:09Спекулятивное -- да, выполнение в предположении того, что оно действительно понадобится. Хотя обычно связано это с предсказанием ветвлений: куда предсказало, ту ветвь и выполняем, а потом либо подтверждаем выполнение, либо отбрасываем в зависимости от того, правильным ли было предсказание.
YMA
06.11.2024 21:09Еще появилось гибкое управление энергопотреблением, до этого оно, конечно - тоже было (i80186, 386SL, и незабвенная команда HLT), но сейчас можно управлять частотами, напряжением, задавать лимиты по TDP.
SIISII
06.11.2024 21:09С частотами иногда и хитрее было: у некоторых процессоров (ещё не микро) переменная длина такта. Скажем, у проца СМ-1420 одна микрокоманда выполнялась либо 200, либо 300 нс (задавалось в самой микрокоманде и было связано с тем, какие микрооперации нужно было выполнить; в частности, если выполнялось обращение к шине, всегда использовалась длительность 300 нс). А у проца ЕС-1035, микроархитектурно содранного с IBM 370/145, если склероз не изменяет (основная масса советских ЕСок были полностью своими разработками, но конкретно в этой только окончательная реализация на уровне микросхем была своя), было 3 или 4 длительности такта в зависимости от вида микрокоманды, а микрокоманды обращения к памяти, кажется, вообще два такта выполнялись, причём разной длительности. Но подробности не помню уже; если доживу (надеюсь) до написания статейки по этой машине -- тогда всё распишу подробно.
Voldemaar
06.11.2024 21:09Попробовал оценить максимальную эффективность SMT/HT с помощью пакета stress-ng.
Мой процессор 4C/8T, 2011 год выпуска.
Открыл два терминала, в первом пишу:
$ taskset -c 0,2,4,6 stress-ng --cpu-method int64 --cpu 4 --metrics-brief --perf -t 30
Жду 30 секунд; результат: 4871924 bops
Во втором пишу:
$ taskset -c 1,3,5,7 stress-ng --cpu-method float128 --cpu 4 --metrics-brief --perf -t 30
Жду 30 секунд, результат 47903 bops
Затем запускаю одновременно (почти), жду 30 секунд, результат 4815118 и 46985.
Получается, что в идеальных условиях эффективность SMT может превышать 98%.
Viacheslav01
06.11.2024 21:09При отсутствии конкуренции за ресурсы, даже HT даст почти 100% эффективности.
LAutour
06.11.2024 21:09В 80-х годах использовались 8-битные процессоры
16-битные были скорее более массовыми.
но которые были введены в x86 еще с начала 80-х, это страничная организация и виртуальная память
Не было там страничной памяти - была сегментная. Страничная появилась в i386. И виртульная память - это термин больше на уровне операционной системы.
но в 90-х годах с появлением процессоров Intel с поддержкой технологии Hyper-Threading (HT) появилась возможность выполнять два "потока" на одном физическом ядре.
P4 с гипердрейдингом появились в 2002 году
Благодаря HT и, позднее, многим физическим ядрам в процессоре, мы смогли выполнять несколько программ или частей программы физически параллельно, снижая время ожидания. Например, в играх это используется для разделения логики, обработки звука, физики и рендеринга, где каждое ядро или поток может быть занят своей задачей.
Игры тогда (до распространения нормальной двухядерности) были почти все однопоточные, преимущество HT раскрывалось только в приложениях, где распараллеливание было сделать проще. Например - перекодирование видео.
Позже объёмы памяти стали настолько велики (гигабайты и терабайты оперативной памяти), что маленького кэша уже не хватало для охвата всей доступной памяти. При работе с большими объёмами данных происходила "вытеснение" данных из кэша, и алгоритм начинал работать даже медленнее, чем при доступе к основной памяти. Появились кэши второго и последующих уровней, чтобы с одной стороны обеспечивать доступ к большому объему оперативной памяти, а с другой — не быть слишком медленными и успевать "кормить" кэш первого уровня.
Автор вообще знает как аппартно реализуется и работает кэш? Как-то не похоже.
Gmugra
06.11.2024 21:09И даже более того.
Вторая половина 80-x это уже эпоха 32-bit: i386, i486, SPARC V7, ARM2/ARM3, Motorola 68020/68030, MIPS R3000, Zilog Z80000, NEC V60. Это всё 32-bit CPU из того времени и наверняка не полный список.
Подозреваю что уже тогда были и интегрированные FPU, кэши и даже brach prediction: все это было, например, у IBM POWER1 который вышел в 1990 и я сомневаюсь что он был прям первым таким.
Вот многоядерность и SMP появилось сильно позже. Самый конец 90-x/начало 2000-x, да.
SIISII
06.11.2024 21:09И ведь перечисленное Вами -- микропроцессоры. А ведь никуда не делись процессоры на рассыпухе, которые и 32-разрядными были, и вещественной арифметикой располагали, и прочая и прочая (в частности, многопроцессорность; ну а многоядерность -- это просто несколько процессоров на одном кристалле, что концептуально не отличается от нескольких процов, каждый из которых занимает пару отдельных шкафов, но которые входят в состав одной машины).
dalerank Автор
06.11.2024 21:09LAutour
06.11.2024 21:09Я про аппартную реализацию и почему вообще
Как раз подтверждение, что на железном уровне понимания - нет. Это как большинство современных программистов знают о всяких объектах, шаблонах, интерфейсах, и при этом не разбираются в ассмеблерном коде.
Позже объёмы памяти стали настолько велики (гигабайты и терабайты оперативной памяти), что маленького кэша уже не хватало для охвата всей доступной памяти
Объем кэширумой памяти никак не зависит от размера кэша. Он зависит от длины адресного тэга (+ битность смещения в странице кэша). Для примера могу вспомнить кэш память на материнских платах (времен P1), которая хоть и была большего объема, чем в процессоре, но могла буферизировать меньший размер памяти, чем позволяла установить материнка.
Появились кэши второго и последующих уровней, чтобы с одной стороны обеспечивать доступ к большому объему оперативной памяти, а с другой — не быть слишком медленными и успевать "кормить" кэш первого уровня.
Кэши старших уровней появились потому что аппаратные ограничения повышают задержки кэша при росте его объема (не считая сложностей размещения больших объемов кэша на одном кристелле с процессорным ядром).
mirwide
06.11.2024 21:09Почему увеличение размера увеличивает время доступа, можете раскрыть? Современный L1 кэш наборно-ассоциативный - ассоциативный между банками и прямое отображение внутри банка. Условные 32Кб, например, могут быть 8 банков по 64 строки по 64 байта. Увеличивать количество банков дорого, потому что для каждого нужно отдельно проверить попадание. В чем ограничение на увеличение размера банка? Независимо от размера мы читаем только 1 строку, адресуем её по части адреса памяти, физической или виртуальной. То что SRAM занимает много места и потребляет много энергии при работе на частоте ЦПУ понятно, почему нельзя сделать банк более 4к непонятно.
byman
06.11.2024 21:09можно сделать банк и более 4 К и кэш L1 побольше. Все зависит от того будет ли в Вашем дизайне кэш L1 узким местом , т.е. в нем будет критический путь определяющий частоту. Можно сделать много мелких банков, каждый из которых влезет в цикл, но после них придется добавлять произвольную логику и уже из-за неё может испортится частота. Опять же слишком большая ассоциативность это раздувание площади L1, а это опять проблема с циклом. Это из моей практики.
LAutour
06.11.2024 21:09Дешифратор адреса в банке: либо быстро, но большой объем логики (плюс сложности с разводкой на кристалле), либо каскадно, но больше задержки. С ассоциативной частью примено то же самое. Конкретно по размеру базового банка - тут скорее просто подобран/рассчитан оптимальный объем.
mirwide
06.11.2024 21:09Понятно, спасибо! Получается, ограничение больше не техническое, а цена и энергоэффективность.
SIISII
06.11.2024 21:09Растут длины линий связи, а значит, не только "прямолинейное" время распространения сигнала, но и паразитные индуктивности и ёмкости. Это сильно ограничивает возможность увеличивать геометрические размеры схемы, а начиная с определённого предела потребует лепить размножители (повторители) сигналов и т.п. промежуточную логику, которая тоже вносит свои задержки. В этом плане вычислительные блоки сильно проще: там связи почти всегда локальные, между близко расположенными транзисторами, а число приёмников у каждого источника невелико. Ну, это грубо, конечно, но все эти факторы и ограничивают возможность увеличения объёма кэша без снижения его частоты.
WASD1
06.11.2024 21:09У банок SRAM(вообще у любых но у SRAM в частности тоже) есть ограничение по глубине/частоте. А поскольку у вас ширина задана - то фактически ограничение на максимальный объём банки. Это во-вторых.
Во-главных же: вы просто не разведёте (на этапе физ-дизайна) достаточно большой кэш за достаточно маленькое число тактов.
Чисто теоретические модели - могут дать логарифмическое время доступа от размера, но на практике они слабо применимы.
Ну и в итоге вы балансируете (на своём наборе нагрузок):
cache_hit_prob * cache_hit_time + (1 - cache_hit_prob) * cache_miss_time.
PetyaUmniy
06.11.2024 21:09Суперскалярность еще.
SIISII
06.11.2024 21:09Суперскалярность появилась в 1960-е.
PetyaUmniy
06.11.2024 21:09Много чего описанного в статье появилось до 486.
Тут же вроде разговор конкретно про х86, суперскалярность в котором появилась в пентиуме.
WASD1
06.11.2024 21:09Из всего описанного в статье - вроде бы только TLB и SIMT появились не в 1960-1970.
SIISII
06.11.2024 21:09TLB имелся во всех IBMовских мэйнфреймах с виртуальной памятью -- т.е. почти во всех машинах Системы 370, появившейся в 1970-м. Насчёт SIMT не понял, если честно. Если речь о SIMD, то в СССР в самом начале 1980-х уже была супер-ЭВМ ПС-2000, которая, по сути, SIMD. В Штатах первый Cray появился в 1975-м
victor_1212
06.11.2024 21:09можно конечно понять что создатели ПС-2000 ее супер ЭВМ называют, но объективно тактовая частота 3MHz это немного, Cray XMP в 1983 году на 105MHz работал, что касается SIMD, то этим много занимались в 1960х (см. Slotnick - ILLIAC), а в системах реального времени еще раньше (1958)
SIISII
06.11.2024 21:09Ну, для СССР вполне себе супер была, выдавая 200 или сколько там млн. оп/с -- как раз за счёт параллелизма. Плюс, она была достаточно мобильной, в отличие от типичных высокопроизводительных машин что у нас, что у них, которые были чисто стационарными.
DrGluck07
06.11.2024 21:09Может меня слегка подводит мой маразм, но в PS3 не было никакого 8-ядерного процессора, как бы там ни фантазировали об этом сонибои. Там был одноядерный CPU с HT (или 2-ядерный без HT, уже не помню). Плюс семь сопроцессоров, объединенных шиной токен-ринг (привет IBM). Программистам игровых движков пришлось очень сильно стараться чтоб всё это заработало с приемлемой скоростью. В этот же момент у Бокса был честный 3-ядерный CPU.
dalerank Автор
06.11.2024 21:09Ну они были, их было семь, да с ними было сложновато работать, и похоже только сами студии сонивские и могли полноценно при поддержке спецов. Формально они могли делать очень многое, так например в XBlades туда были вытащена физика, звук и партиклы. Сони очень продвигали эту технологию на старте
zzzzzzerg
06.11.2024 21:09Не обязательно сониевские студии. Были попытки запускать на нем научные расчеты, у меня даже был доступ к какому-то исследовательском проекту на эту тему в середине 00, но фокус интересов быстро сменился и ничего путного тогда сделать не успели.
DrGluck07
06.11.2024 21:09Это я к тому, что не было 8-ядерноого процессора в том понимании, как про это думают сейчас, типа какой-нибудь Intel i7-10700.
Fedorkov
06.11.2024 21:09Помимо SIMD‑ов есть ещё куча расширений типа AES и Bit manipulation.
И ещё стоит упомянуть аппаратную виртуализацию.
SIISII
06.11.2024 21:09Команды для манипуляций битами точно были ещё в VAX-11; шифрование одной командой есть и постепенно расширяется (по мере появления новых стандартов) в z/Architecture. Аппаратная виртуализация Системе 370 и её последователям, включая z/Architecture, не обязательна: там сама архитектура достаточно прямая для создания виртуальных машин. Собственно, VM/370 и работала изначально на самых обычных мэйнфреймах Системы 370; поддержка виртуализации, имеющаяся во многих процессорах этой и последующих архитектур, лишь ускоряет работу виртуальных машин, но не является безусловно необходимой -- в отличие от интеловского уродства.
vikarti
06.11.2024 21:09Ну строго говоря VMware/Connectix сначала работали без аппаратной поддержки виртуализации. Какими хаками с бинарной трансляцией - вопрос отдельный.
SIISII
06.11.2024 21:09Ну, настоящей виртуализации (не программной эмуляции чужой системы команд) без железной поддержки на IA-32 быть не может из-за наличия команд, которые являются непривилегированными, но работают с системной информацией (считывают содержимое каких-то системных регистров, если склероз не изменяет). Соответственно, либо делать неполноценную "обычную" виртуализацию, которая работать будет лишь в случае, если гостевая ОС эти команды никогда не использует (а соответственно, не требуется их перехватывать и эмулировать средствами гипервизора), либо как-то разбираться с машинным кодом гостевой системы перед его выполнением, обнаруживать такие команды, заменять их чем-то, вызывающим прерывание... Ну, думаю, Вы поняли. Оба подхода не дают 100% надёжности работы, а второй, к тому же, очень сложен и временами вызывает сильные тормоза. Ну а как делали эти самые VMware/Connectix -- понятия не имею, честно говоря.
HardWrMan
06.11.2024 21:09либо как-то разбираться с машинным кодом гостевой системы перед его выполнением, обнаруживать такие команды, заменять их чем-то, вызывающим прерывание...
Вы сейчас описали разницу между ванильным command.com из DOS/Win9x и его заменителем cmd.exe из WinNT. Все привелегированные вызовы (в том числе и сервис DOS) эмулируются через исключение.
SIISII
Из первых абзацев складывается впечатление, что речь пойдёт о чём-то новом, появившемся в 80486. Но почти всё, что описывается далее, появилось раньше не только 80486, но зачастую раньше 8086. Многопроцессорные системы, виртуальная память, кэши, TLB, внеочередное выполнение команд, SIMD -- всё это было известно ещё в 1960-70-е...
alexmib
Вентиляторы на процессоре? ;-)
SIISII
Если рассматривать более ранние процессоры, которые ещё не микро-, у них целая куча вентиляторов бывала :)))
Yak52
Да еще и обязательный кондиционер в комнате )))
HardWrMan
Обязательный кондиционер и даже не один до сих пор устанавливается...
anonymous
НЛО прилетело и опубликовало эту надпись здесь
Politura
Ну, интегрированное в один чип, такого не было, были отдельные элементы, включая микрухи с кэшем на материнке. Сопроцессор тоже отдельной микросхемой был, хотя вот уже не помню, кажется 486SX без сопроцессора, надо было отдельно к нему ставить 487, а вот 486DX уже с сопроцессором внутри.
Javian
Математические сопроцессоры были с Intel 8088/8086 https://en.wikipedia.org/wiki/X87
Politura
Интегрированных в центральный процессор не было, были отдельными микросхемами 8087. Интергированные варианты кажется пошли с линейки dx, толи 386dx, толи 486dx
HardWrMan
486DX. Для 386DX был 387.
Javian
Нашлись подробности на Хабре:
https://habr.com/ru/articles/413997/
ITxasky
все так, я помню ток линейки 386 и 486 с DX, были бодрые машины того времени)) у меня первый новый комп появился как раз 486DX-100. с кнопкой Turbo конечно :) на первый пенек P-75 у родителей денег не хватало
SIISII
Интегрированное -- возможно, но дело-то в том, что это никаких принципиально новых возможностей не открывает и является обычным эволюционным улучшением уже хорошо известного, а не чем-то революционным. Польза несомненна, но не более того.
poulch
просто сильно раньше процессор и был на рассыпухе. и собственно процессором был шкаф-стойка или даже несколько. да и процессоров могло быть несколько и некоторые специализированные. на какой-нибудь СМ-4 сидишь себе в терминале со своим процессором 580вм80 и памятью и редактируешь текст, а потом на компиляцию- выполнение на центральный процессор отправляешь... тут главное что нового появилось в теории процессоростроения, а не в реализациях.
SIISII
Если говорить об СМ-4 и иже с ней (PDP-11, в общем), то и редактирование шло не на терминале, а на самой машине: каждое нажатие клавиши посылало тот или иной код в машину (через UART -- COM-порт, выражаясь более знакомым для многих языком, хотя там и были нюансы: например, в качестве физического интерфейса чаще использовалась токовая петля 20 мА, а не RS-232), и запущенный там текстовый редактор его обрабатывал. Автономный режим иногда был, но для работы он не использовался: штатное ПО было рассчитано именно на посимвольный приём любого ввода и посимвольную же выдачу отображаемого и команд управления (позиционирование курсора и т.п.). Соответственно, если с машиной одновременно работали несколько человек и кто-то запускал, скажем, компиляцию чего-то тяжёлого, текстовые редакторы у остальных начинали подтормаживать.
Вот на ЕС ЭВМ (IBM System/360 и продолжения) терминал (ЕС-7927, главным образом) действительно работал автономно, пока не нажималась одна из клавиш, дёргавшая машину (ввод и функциональные).
poulch
я вот честно смутно это помню :) я еще школьником на них сидел в 90 году в МЭИ. помню зачетные команды kill и suspend... если всему классу терминалов все отрубить, то потом только с админского в отдельной комнатушке оживиться можно было... терминалы там импортные были какие-то и потом когда попилил машину 580 микрухи и другие запчасти продавали в магазинчике в М корпусе. с ЕС ЭВМ у меня только маман дело имела и то в молодости. и потом на XT довольно быстро перешла. а вот куда всякие книжки девать по этим машинам я не придумал. выкидывать жалко...
Javian
На хабре была недавно публикация, в которой упоминалась Группа по популяризации ЕС ЭВМ https://t.me/+MtYmrFE9VYo1NGJi
собирают литературу и прочие материалы.
poulch
забукмаркил.
checkpoint
Интересно, эти популяризаторы хотя бы одну ЕС ЭВМ смогли восстановить и запустить ?
SIISII
Их в 1990-е массово сдали на металлолом -- банально нечего восстанавливать. Может, у вояк что и осталось, но оттуда не уволочёшь.
checkpoint
Хорошо если у вояк действительно что-то осталось, тогда есть еще надежда что-то получить "для музея". Включать эти машины все равно уже некому, людей способных набивать код загрузчика тумблерами с консоли совсем не осталось.
SIISII
Ну, я без проблем набью. Более того, будь в моём распоряжении рабочий процессор от ЕСки, я бы запустил таки всю машину, сделав эмулятор периферии (дисков, лент, терминалов и т.п.).
dalerank Автор
Снимаю шляпу, мое вам уважение. С интересом читал ваш цикл про ЕС-ки (https://habr.com/ru/users/SIISII/publications/articles/)
checkpoint
Я бы постоял рядом.
Интересно, на сколько реально восстановить процессор по схемам ? Деталей в магазинах сейчас в избытке, платы заказывать в Китае стоит копейки. Вот с софтом что делать - не понятно. Ленты есть в музеях, но читать их не на чем. Да и считаются ли ?
SIISII
Софт как раз есть на ПК -- не всё, но довольно многое. А вот схем, по большей части, нет вообще. Из найденного наиболее полный набор оказался на проц от ЕС-1020: примерно 3/4 функциональных схем и около половины принципиальных, плюс все технические описания "верхнего уровня", часть "нижнего" и полный текст микропрограмм, так что мою серию статеек по этой машине можно очень сильно расширить (когда-нибудь в будущем). На остальные ЕСки нет почти ничего подробного.
cadmi
Ну почему, мой препод в университете (1993 год, он был аспирантом) умел в это. Сейчас ему слегка за полтос.
checkpoint
Если человек долго не занимается каким-то делом, то знания и навыки выветриваются очень быстро. Особенно в современном мире где требуется постоянно изучать что-то новое. Ресурс головного мозга ограничен.
Я работать начал в 91-м в качестве оператора, эдакий юнга на вычислительном центре -
принеси-подайотмонтируй-примонтируй. Неоднократно наблюдал как загружают ЕС-1066. Но смогу ли я запустить такую машину сейчас дай мне в руки все инструкции ? Скорее всего я даже питание ей подать не смогу, не говоря о том, чтобы диагностировать проблему со сбоящим накопителем или контроллером каналов, или памятью - что очень часто случалось с этими динозаврами.cadmi
Ваш тезис абсолютно понятен и имеет право на существование, но в свою очередь отмечу, что все же существует и существенная разница между "юнгой принеси-подай", "неоднократно наблюдал" и "работал самостоятельно, в том числе абсолютно самостоятельно в ночные смены", "перезапускал после сбоев" и "диагностировал проблемы с накопителями, контроллером каналов и памятью".
SIISII
Ну, я, хотя и был, с одной стороны, "юнгой" (в 17 лет устроился на ЕСку), с другой, быстро стал де-факто программистом, а отчасти и электронщком (по процессору). Понятно, что интимные подробности за давностью лет забылись, но восстановятся быстро, если вдруг нужда возникнет. Ну а если б сохранился не только проц, но и основная дока на него -- вообще никаких проблем.
vitalyvitaly
А с не IBM 360-cовместимыми моделями вроде ЕС-1010 справились бы? Или - гулять так гулять - серией БЭСМ, Минском-22 или еще чем-нибудь экзотическим?
SIISII
Если есть дока -- почему б не справиться? Вот если ничего нет, тады проблематично, конечно :)
Moog_Prodigy
У вояк тоже ничего не осталось, они ж не дураки - золото хранить. И им тоже компы нормальные нужны были еще лет 30 назад, а денег нет. Вот и. Реальных рабочих машин не осталось и у них.
Но при наличии денег и документации можно воссоздать с нуля. Почему бы нет? Дорого и долго. Но реально.
Javian
Сейчас вопрос в сторону эмуляции. Считывании программ с сохранившихся лент. И сохранении литературы.
checkpoint
Почему только на закрытом телеграм канале, а не на открытом форуме. Как уже задрали эти телеграммщики!
Javian
Форум стоит денег.
xSVPx
Миллионы, наверное...
Зато в закрытом канале фиг чего найдешь потом. Да и сейчас. С точки зрения сохранения информации - это наименее удобный вариант.
checkpoint
Совершенно верно. Все эти каналы в чатах убивают поиск и ограничивают распространение информации.
Вот я типичный "мимо крокодил", дай думаю загляну на огонек, посмотрю чем люди занимаюся и хрен-то там.
RalphMirebs
Вообще, есть близкотематический форум
http://www.s390soft.ru/forum
И на форуме "Полигон Призраков" есть профильная тема.
А вышеупомянутая группа исторически появилась как тематическое ответвление телеграмм-группы по БЭСМ-6, поэтому тоже в телеграмме. Плюс телеграмма во встроенном хранилище файлов. Речь идёт не о долговременности или надёжности, а именно простом процессе выкладки. Литература, кстати, понемногу сканируется и выкладывается на общедоступные сайты. Фотографии же... пока жива телега, живы и фото. На многих форумах ныне тексты есть, а ссылки на фото давно умерли.
checkpoint
Телега умрет и утянет с собой абсолютно всю накопленную информацию. Либо её ограничать по скорости так же как Ютуб, до полного нуля. Нужен Git репозиторий.
RalphMirebs
В настоящее время "обработанные" книги-журналы хранятся тут http://oldpc.su/pc (раздел Библиотека)
checkpoint
Спасибо. Там в библиотеке есть файлик с номенклатурой ЕС ЭВМ, в нём указано сколько машин (изделий) данной номенклатуры было выпущено. Если просуммировать, то получаются гигантские цифры. Куда всё делось ? Вопрос риторический конечно же.
RalphMirebs
Утилизировали большую часть и до сих пор утилизируют. Периодически на Авито всплывают части машин из-под ножа. Что не уничтожили до сих пор в консервации, видел много фото в стиле "оборудование в пыльном углу". Когда у владельца доходят руки, уходит на утилизацию (или в музей, как щас происходит с одной из ЭВМ), иногда "подъедаются" своими же сотрудниками. А какие-то машины стоят ухоженные (но не факт, что рабочие и эксплуатируемые). Взять тот же НИИИТ в Твери
Javian
Скорее в утилизацию. Для частного лица нужны серьезные деньги чтобы выкупить по цене металлолома. А те кто имеет такие деньги не интересуется "старым хламом".
xSVPx
Умерли ссылки на фото, которые пользователи зачем-то загружали не на форум, а в файлопомойки, действительно они сдохли. Но те, что загружены локально обычно "в порядке".
RalphMirebs
Правильно, но для этого нужна "культура загрузки" или автоматические загружающие системы, а главное - место на сервере, а часто и сам сервер. У каждого решения есть плюсы и минусы. Мне лично форумы нравятся больше, в первую очередь из-за возможности индексации, но исторически группа родилась в телеграмме, как "филиал" группы по БЭСМ-6, для разделения обсуждений (почему "родитель" был в телеграмме я не знаю, я не его создатель) и никогда не стремилась стать массовой. Специально, однако, тоже не прятались. Возможно, людей смущает в названии словосочетание "по популяризации", но это тоже пришло от родителя БЭСМ-6.
checkpoint
Есть ряд профильных форумов по электронике (Electronix, Радиокот и т.д.), почему бы там не создать отдельный раздел ? Там уже много людей грамотных, даже есть те кто видео ЕС ЭВМ.
Мне еще нравится Github где в issues часто обсуждают проблемы со ссылкой на конкретный номер строки в файле. Это очень удобно. Сделали бы общий репозиторий с материалами по теме на Gitflic или Github и там же вели обсуждение. Но нет, мы спрячемся в телеграм канальчик, чтобы нас никто не видел.
SIISII
Ну, на гитхабе нельзя по политическим причинам: мало ли, обрубят нахрен интернет (ну или МС решит позакрывать -- тем более, что могут иметь место формальные нарушения авторских прав и т.п.). Но вообще, правильно было бы, конечно, иметь нормальный форум или нечто в этом роде. Но решать не мне :)
checkpoint
Есть же российский Gitflic.
Github хорош тем, что любой желающий может держать у себя на локалной машине полное зеркало репозитория, работать с ним локально и синхранизировать с публичным. А в случае опасности быстро поднять Gitea и развернуть новое публичное зеркало. Складывать информацию в Git репозиторий это великое достижение Человечества. Очень плохо, что большинство электронщиков привыкли к виндузне и неприемлят коммандную строку, и отношение к Git у них соответствующее.
yomayo
Есть бесплатные форумы. Достаточно погуглить. Например, mybb.ru
SIISII
580-я использовалась, в частности, в польских терминалах СМ-7209 -- как по мне, лучшие СМовские терминалы были.
Ну а команды -- это от используемой ОС зависит; достаточно широко использовались, как минимум, RSX-11M, RT-11 и Уних -- как в оригинальном виде, так и клонированные и переименованные.
DvoiNic
У них - "УНИХ", а у нас - "РАФОС"! ©
checkpoint
У нас была ДЕМОС, как ответ ихнему УНИХ.
А РАФОС звучит как средство от насекомых.
DvoiNic
В поговорке были оба варианта, да...
checkpoint
Ну, РАФОС это RT-11, а ДЕМОС это одна из версий BSD Unix. :)
DvoiNic
Да, скорее всего подвел меня мой склероз...
SIISII
Точней: unix -- "у них", а у нас -- демос!
poulch
это да. помню меняли там ОС с како-то нашей на оригинальную. А нас на них учили оригинальному Паскалю... но на финишной стадии обучения мы грязно хакнули процесс- получив, кто у родителей на работе, а кто и дома доступ к Borland Turbo Pascalна 86 или 286 машинах. там всякие задания с массивами и строками гораздо проще делать было...
DvoiNic
Эх, сопрягали когда-то СМ1420 с Корветами и СМ-1800. Можно было работать терминалом, можно "эмулируя терминал" отправлять готовые тексты туда-сюда...
MaFrance351
Там довольно интересная история. 486SX из первых партий - по сути "нормальный" 486DX, но с бракованным сопроцессором. Просто, чтобы не отправлять в recycle bin ещё могущие как-то поработать кристаллы, их корпусировали как 486SX, где сопроцессор задействован не был. С 487DX ещё интереснее, по сути это не сопроцессор, а полноценный камень, при втыкании которого штатный SX отключался.
vikarti
Вы еще скажите что аппаратную поддержку виртуализации придумали не Intel c AMD для x64 а IBM (еще до того как Intel вообще создала процессор хоть для чего то) :)
SIISII
Ну дык IBM и придумала, коммерческие поставки VM/370 -- с 1971-го. Ну а виртуализация на ПК -- до сих пор жалкое подобие левой руки (с), в первую очередь, из-за фантастически кривой архитектуры что 8086/IA-32/AMD64, что ПК в целом.
kochevkv
А можно привести пример не кривых архитектур, для несведущих? Или ссылку на статью для ознакомления. Чисто из любопытства.
SIISII
Совершенно прямых в природе не существует и вряд ли существовать может (из-за противоречивости требований). Но намного более прямые, конечно, имеются -- в частности, та же Система 360 и последовавшая за ней Система 370, про виртуализацию на которой здесь говорилось. DECовские PDP-11 (как по мне, лучшая 16-разрядная архитектура в истории), VAX-11 (вероятно, лучшая 32-разрядная система команд -- но системная архитектура, в общем и целом, хуже IBMовских мэйнфреймов), микропроцессорные -- Z8000, 68000, классический ARM... Везде есть свои странности и ограничения, но в целом все они -- весьма стройные архитектуры без серьёзного количества костылей и тем более откровенных уродств. Ну а 8086 -- прямая противоположность; кажется, Интел смогла в нём собрать все грабли, какие только возможно, а потом ещё добавила новых в 80286 и расширила их в 80386.
vanxant
И в итоге захватила мир и обанкротила почти всех конкурентов. При том что первый SPARC был создан умнейшими гуру, которые нам сейчас впаривают RISC-V, и в тестах показывал производительность раз в 10 быстрее своего "однокашника" 80386 на той же частоте.
Может, в Интел работали всё-таки не идиоты, а ровно наоборот? И то, что вы считаете граблями, были бизнес-преимуществами? Ну там, совместимость с предыдущими изделиями и вот это всё?
SIISII
Одно другому не мешает. Техническое совершенство побеждает очень редко, поскольку пользователю, вообще говоря, плевать, что там под капотом.
А архитекторы в Интел -- именно что идиоты. Полные и абсолютные. Совместимость, кстати, придумали не они. Первыми пообещали совместимость в IBM -- в 1964 году, и своё обещание блюдут до сих пор. Можете взять прикладную программу, написанную в середине 1960-х для мэйнфрейма Системы 360, и благополучно запустить её на современном мэйнфрейме z/Architecture.
DEC тоже порядка 20 лет блюла совместимость в своей линейке PDP-11, и погубила её не красивая архитектура (настолько удачная, что к концу 1970-х она стала, пожалуй, самой распространённой архитектурой в мире), а полные и абсолютные идиоты в руководстве компании. Вместо того, чтобы превратить чрезвычайно удачную мини-машину в хорошую персоналку, для чего в 1980-е уже были технические возможности (даже мы в начале 1980-х смогли запустить в производство свои собственные микропроцессоры с этой системой команд -- сначала К1801ВМ1, потом ВМ2 и ВМ3), по всем статьям превосходящую ублюдскую IBM PC, они сделали машину, совместимую по системе команд, но специально совершенно несовместимую по периферии, чем исключили возможность использования штатных ОС и всей кучи ПО, уже наработанного за 1970-е и начало 1980-х, да ещё заломили за это поделие деньги как за самолёт. Естественно, с таким подходом оно провалилось. Минимашины продолжали производиться и продаваться ещё какое-то время, но, очевидно, рынку была нужна именно персоналка (ну или мэйнфрейм, но там уже безраздельно доминировала IBM)
vanxant
"Взять современный мэйнфрейм z/Architecture" я не могу, немножко денег не хватает. На интел хватает, на IBM нет:)
Ну, и раз уж у вас все кругом идиоты, то почему вы такой бедный?:)
victor_1212
DEC работала на профессиональный рынок, в том числе рабочие станции, это в общем другие требования, и другой уровень цен, как ее погубили это отдельная тема, совет директоров сменил Ken Olsen, т.к. он был против увольнений людей, его знали и уважали как инженера, но поставили послушного, короче бухгалтера взяли верх совершенно не понимая, что лучшие работники просто уйдут, персоналки лепить из дешевых деталей не будут, когда это началось остановить было трудно,
заметим инженеры DEC, особенно работавшие с Ken Olsen, не очень похожи на инженеров IBM, другой стиль работы, и совершенно другой стиль руководства
SIISII
Разговор был о том, что, дескать, Интел всех задоминировала, а значит, её архитектура крута -- а эти вещи вообще никак не связаны.
victor_1212
к Intel особенно теплых чувств нет, как впрочем и к IBM, типа "два сапога пара" :)
Kotofay
PDP-11, VAX, Alpha AXP
ermouth
Как аппаратно сделать – наверное, да, IBM. Но концепция что они использовали – заимствована.
Program and Addressing Structure in a Time-Sharing Environment, https://dl.acm.org/doi/pdf/10.1145/321312.321313, University of Michigan, 1965
saboteur_kiev
многопроцессорные да, а многоядерные?
Многоядерность и хардварные декодеры для видео, аудио, шифрования - те же самые MMX, Quick Sync Video, и др., про это в статье забыли упомянуть.
Про расширение адресации памяти я тут не совсем соглашусь - 486 уже был шагом вперед после 8-битной архитектуры и 16-битной архитектуры, то есть переход на 64-битную был ожидаем, а не чем-то суперновым.
WVitek
Новое для x86 в процессорах 80486dx, несколько помню:
Интегрированный кеш первого уровня.
Умножение частоты системной шины/памяти для получения частоты ядра (DX2, DX4).
Встроенная поддержка вычислений с плавающей точкой.
SIISII
Ещё и настоящий конвейер, если память не изменяет, с эффективным временем выполнения простых команд в один такт.