Чому немає 256-бітних або 512-бітних мікропроцесорів?

У 8-бітовому мікропроцесорі його шина даних складається з 8 ліній даних. У 16-бітовому мікропроцесорі його шина даних складається з 16 рядків даних тощо.

Чому не існує ні 256-бітного мікропроцесора, ні 512-бітного мікропроцесора? Чому вони просто не збільшують кількість ліній даних і не створюють 256-бітний мікропроцесор або 512-бітний мікропроцесор?

Яка перешкода перешкоджає створенню 256-бітного мікропроцесора або 512-бітного мікропроцесора?

Подумай над цим. Що саме ви передбачаєте "256-бітний" процесор? Що робить в першу чергу розрядність процесора?

Я думаю, якщо додаткова кваліфікація не буде досягнута, розрядність процесора стосується його ширини ALU. Це ширина двійкового числа, з якою він може керувати власними силами за одну операцію. Отже, "32-бітний" процесор може працювати безпосередньо на значеннях до 32 біт шириною в одних інструкціях. Тому ваш 256-бітний процесор містив би дуже велику АЛУ, здатну додавати, віднімати, ORing, ANDing тощо, 256-бітові числа в одних операціях. Чому ти цього хочеш? Яка проблема робить великий і дорогий ALU варто мати і платити, навіть за ті випадки, коли процесор підраховує лише 100 ітерацій циклу тощо?

Справа в тому, що вам доведеться платити за широкий АЛУ, незалежно від того, використовуєте ви його багато чи лише невелику частину його можливостей. Щоб виправдати 256-бітний ALU, вам доведеться знайти достатньо важливу проблему, яка дійсно може отримати користь від маніпулювання 256-бітними словами в одній інструкції. Хоча ви, мабуть, можете навести кілька прикладів, таких проблем не вистачає, щоб виробники відчували, що коли-небудь отримають прибуток від значних інвестицій, необхідних для виробництва такої мікросхеми. Якщо в ньому є ніша, але важливі (добре фінансуються) проблеми, які дійсно можуть отримати користь від широкого ALU, тоді ми побачимо дуже дорогі високоцільові процесори для цього додатка. Однак їх ціна перешкоджатиме широкому використанню поза вузьким додатком, для якого він був розроблений. Наприклад, якби 256 біт зробили можливими певні програми криптографії для військових, то, мабуть, з'являться спеціалізовані 256-бітові процесори вартістю від 100 до 1000 тисяч доларів. Ви б не ставили жодного з них в тостер, джерело живлення або навіть автомобіль.

Я також повинен бути зрозумілим, що широкий ALU не просто робить ALU дорожчим, але й інші частини мікросхеми. 256-розрядний ALU також означає, що має бути 256-бітових шляхів даних. Це одне зайняло б багато області кремнію. Ці дані повинні надходити звідкись і кудись їхати, тому для ефективного використання широкого АЛУ потрібно мати регістри, кеш, іншу пам'ять тощо.

Ще один момент полягає в тому, що ви можете робити будь-яку арифметичну ширину на будь-якому процесорі ширини. Ви можете додати 32-бітове слово пам'яті в інше 32-бітове слово пам'яті в PIC 18 з 8 інструкцій, тоді як ви можете це зробити в тій же архітектурі, що має масштаб до 32 біт лише за 2 інструкції. Справа в тому, що вузький ALU не заважає виконувати широкі обчислення, лише те, що широкі обчислення займуть більше часу. Тому питання швидкості, а не здатності. Якщо ви подивитесь на спектр програм, яким потрібно використовувати певні ширини, ви побачите, що дуже мало потребує 256 бітових слів. Витрати на прискорення лише тих кількох програм із апаратним забезпеченням, які не допоможуть іншим, просто не варті цього і не роблять хороших інвестицій для розробки продукту.

Ну, я не знаю про 256 або 512 біт, але я чув про 1024 бітовий процесор (зараз не можу його знайти). Слово - VLIW , для дуже довгої інструкції Word . Отже, це шина інструкцій, а не ширина шини даних. Переваги полягають у тому, що ви можете впроваджувати паралелізм рівня інструкцій (ILP) у великих масштабах.

Моя перша зустріч з ILP, мабуть, була 20 років тому з Motorola DSP, які мали вказівки щодо виконання MAC (множення та накопичення) під час переміщення даних в пам'ять і з неї, щоб ви могли виконувати новий MAC на наступній інструкції, не витрачаючи час між двома MAC для переміщення даних.
Сьогодні також є контролери загального призначення, які пропонують цей варіант. VLIW застосовує це в набагато більшому масштабі.

$^{20}$$\infty$

Подальше читання
VLIW Architecture

"Бітовість" мікропроцесора зазвичай визначається за розмірами регістрів загального призначення. Розмір визначає, наскільки великі цифри процесор може впорядковуватися і скільки пам'яті він може отримати. 64-бітових чисел вистачає практично для будь-якого алгоритму, і об'єм адресируемой пам'яті (16 мільйонів терабайт) вистачає на досить довгий час. Просто немає жодної переваги щодо збільшення розміру регістрів загального призначення. На зворотному боці площа арифметичних логічних одиниць (АЛУ), яка використовується для виконання операцій на шкалах регістрів, має квадрат суми бітів. 256-бітний ALU був би на 16 разів більшим та значно повільнішим.

З іншого боку, є сенс розширити процесор, щоб можна було робити багато менших операцій одночасно. Насправді процесори Sandy Bridge та Ivy Bridge від Intel роблять саме це, вони мають 256-бітні регістри SIMD і можуть робити два арифметичні операції та одну операцію з пам’яттю на цикл. Тож можна виправдати, називаючи їх 256-бітовими або навіть 768-бітовими процесорами, якби хтось підлий маркетолог, який бажає згорнути регулярно використовувані терміни.

По-перше, розмір бітів процесора, як правило, визначається абстрактною архітектурою, видимою для програміста машинної мови, а не деталями реалізації, такими як розмір шини даних.

Наприклад, Motorola 68000 - 32-бітний процесор. Він має 32-бітні регістри даних та 32-бітні регістри адрес. Тепер перша версія цього архітектурного сімейства виставляє лише 24 біти рядків адреси. Крім того, існують варіанти, які мають лише 8-бітну шину даних (тому 32-бітні операції з пам'яттю виконуються процесором у вигляді декількох циклів доступу).

Тепер про питання, чому б не перейти на 256 та 512. Процесори "на самому" маніпулюють декількома типами даних, тому корисно подивитися, що означає 256 або 512 біт для кожного з цих типів даних окремо. У нас є цілі числа, покажчики та типи з плаваючою комою.

1. Цілі числа: Програми отримують багато пробігу з 32 та 64 бітових цілих чисел. Якщо 64 біт є обмеженням, виправленням цього є наявність програмно-інтегрованих цілих чисел bignum. Мови високого рівня можуть реалізувати цілі типи, щоб операції плавно переходили між "fixnums" та "bignums". Звичайно, ви приймаєте хіт продуктивності з bignums, але ви повинні врахувати це на великій картині: скільки операцій у програмі є операціями bignum. 256 або 512 бітові числа не позбавляють потреби у бінтумах, вони лише збільшують запас, перш ніж нам доведеться перейти на бінгути. Якщо ви хочете маніпулювати 2048-бітними відкритими ключами, 512-бітні цілі числа не зроблять (але бінгум з 512-бітовими цифрами може бути швидким).

2. Покажчики: ширші покажчики дозволяють дві речі: більш широкі адресні простори та додаткові метадані, що зберігаються в покажчику. Адресні простори є віртуальними в наші дні, тому вони можуть зростати, навіть якщо пам’ять не зростає. Запропоновано, що якщо у вас є 128 бітні покажчики, адресний простір настільки обширний, що ви можете розмістити всі процеси простору користувача операційної системи та ядра у випадкові місця в одному незахищеному просторі, і вони навряд чи зіткнутися. Замість того, щоб просто створити більший адресний простір, більш точні покажчики можуть використовуватися для перенесення бітів, які не є бітними адресами, такі як інформація про референтний об'єкт (тип, розмір та інша інформація) або інформація, що стосується безпеки. Мабуть, є якась «оптимальна жирність» для подібних речей, і якби я здогадувався, я все-таки обмежував би її в 128 біт. Це не так t, мабуть, не має сенсу переходити до 256 бітових покажчиків, майте на увазі 512. Більш точні покажчики мають недолік: вони роздувають усі структури даних, що містять покажчики. І, як правило, ви хочете, щоб вказівники були однакового розміру, інакше вам потрібні ускладнення в архітектурі наборів інструкцій (наприклад, сегменти пам'яті), завдяки чому потім у вас є повні покажчики (дескриптор сегмента та зміщення) або просто локальні покажчики (зміщення в межах якогось зрозумілого сегмента) .

3. Типи з плаваючою комою: більше бітів у числах з плаваючою комою означає більшу точність. Я б сказав, що типи з плаваючою комою отримують найбільше користь від ширшого представлення. 256 або 512 бітний плаваючий тип покращить стабільність чисельного коду та якість наукових обчислень, які потребують багатьох ітерацій, та накопичуватимуть помилки на цьому шляху. Точність у плаваючій крапці не є такою ж, як точність у цілих числах: ми не можемо розділити тип плаваючої точки на діапазони, такі як fixnums та bignums. Більш точність у плаваючій точці впливає на якість усіх неточних чисел, чи то вони близькі до нуля, чи мають велику величину. Більше бітів в показниках плаваючої крапки також може значно розширити діапазон чисел з плаваючою комою і набагато швидше, ніж додавання бітів до цілого числа біньюма.

З цих причин я підозрюю, що переважаючою тенденцією в майбутньому буде збільшення ширини апаратних чисел з плаваючою комою, не обов'язково з подальшим збільшенням ширини покажчиків та цілих чисел.

Пам'ятайте, що числа з плаваючою комою в минулому вже випереджали інші типи. Наприклад, деякий час у нас було переважання 32-бітних процесорів, що підтримували 64-бітні подвійні плавки IEEE. Це тому, що хоча ви можете зробити багато з 32-бітовими вказівниками та цілими числами, 32-бітові поплавці дуже обмежені для будь-якої серйозної чисельної роботи.

Однією, дуже корисною функцією, яку непогано було б побачити, як з'являються у представленнях з плаваючою комою, є кілька запасних бітів для тегу типу. Реалізація типів з плаваючою комою в динамічних мовах високого рівня (в яких об’єкти мають тип, але місця зберігання містять значення будь-якого типу) є проблемою, оскільки тоді як запасні біти можна знайти в покажчиках та цілочисленних об'єктах, щоб розмістити частини ідентифікуючи тег типу, це важко зробити з числами з плаваючою комою. Тож, що часто трапляється, це те, що номери з плаваючою комою виділяються купою. Деякі схеми крадуть біти у мантіси, тому типи з плаваючою комою на цій мові втрачають точність порівняно з плаваючими іншими мовами на тій же машині.

Це насправді не допомагає зробити щось корисне. 64-бітові цифри дають достатню точність майже для всіх цілей (хоча системи Intel мають 80-бітну плаваючу точку), проте додаткові лінії збільшують витрати та енергоспоживання, маючи при цьому невеликий негативний вплив на тактову частоту.

Історично процесори використовують мінімальну кількість біт, що має практичний сенс за призначенням. З розвитком технології ширші автобуси та АЛУ стали можливими, отже, збільшення розмірів шин для більш широкого застосування:

• 4 біта: достатньо для цифри, отже, практично для калькуляторів (у стилі BCD), касових апаратів тощо (що є досить обмеженою областю)
• 8 біт: достатньо для символу (ASCII), практичного для систем обробки тексту (що є ДУЖЕ широкою областю), а також для звуку низької якості
• 16 біт: коли 16-бітними популярними були 2 ^ 16 адреси пам'яті, це було розумною кількістю (принаймні набагато розумніше, ніж 2 ^ 8 або 2 ^ 32). 16 біт дає цілком прийнятну якість звуку, і більшість A / D перетворювачів дають менше 16 біт результату, отже, обчислення з такими значеннями в 16 біт має сенс
• 32 біта: 32 біта відповідає точності більшості (але не всіх) вимірюваних людиною величин, і якщо ви не маєте великі бази даних 2 ^ 32 адреси були достатніми для більшості практичних цілей.
• 64 біта: маючи> 2 ^ 32 байти пам'яті, тепер практично.
• 128 біт: на даний момент невелика перевага над 32, за винятком криптографії. Коли ми очікуємо більше 2 ^ 64 байт на жорсткому диску? певно, не скоро.

Насправді такі процесори існують і є загальними, залежно від того, як ви визначаєте біт. Ви майже напевно зараз використовуєте його. Як пояснив Олін, для 256-бітних чисел не дуже багато використання, але що робити з 4-х 32-бітовими числами? Що робити, якщо ALU може одночасно додати 4 пари 32-бітних чисел. Такі АЛУ (про які я знаю) були вперше реалізовані у векторних суперкомп'ютерах у 1970-х. Перший раз, коли я коли-небудь володів таким комп'ютером, коли у мене був один з Intel Pentiums з MMX.

Пам'ятаєте тих хлопців?

Мікросхеми MMX мали єдиний набір інструкцій - кілька даних ( SIMD ), що дозволяє додавати 1 × 64-бітну пару, 2 × 32-бітні пари, 4 × 16-бітні пари або 8 × 8-бітні пари.

Але це нічого. Сучасна відеокарта має графічний процесор (який раніше виступав за одиницю графічної обробки, але тепер розшифровується як загальний процесор). Це часто широкі реалізації SIMD, здатні здійснювати філії, завантаження та зберігання одночасно з 128 або 256 бітами. Мікроархітектура прототипу Larrabee від Intel включає більше двох 512-бітних регістрів SIMD на кожному з своїх ядер.

Зверніть увагу, що SIMD не слід плутати з багатоядерними. Кожне ядро ​​процесора матиме свій широкий ALU, здатний скласти набір цілих чисел.

Тому що нам це ще не потрібно.

Зазвичай біт (який я б визначав як кількість бітів в регістрі) перекладається більш-менш безпосередньо в об'єм адресируемой пам'яті. Це, звичайно, спрощено, оскільки залежно від процесора можуть бути регістри, які мають вдвічі більше довжини біт, або існують методи, щоб обходити ці обмеження пам’яті (хтось там пам’ятає, що робив програмування на 16-бітових вікнах?).

"Чому вони просто не збільшують кількість рядків даних і не створюють 256-бітний"

Усі процесори Intel, які відповідають LGA-2011 Socket, насправді мають 256 штифтів даних, що підключаються до 256 ліній даних на материнській платі, які ведуть до DRAM. Я був би трохи здивований, якби останній ноутбук або настільний апарат, який ви використовували , не мав принаймні 256 ліній даних. Чи можу я запитати, звідки у вас така помилкова думка, що вони "не ... просто збільшують кількість рядків даних"?

LGA-2011 Роз'єм технічний опис , розділ 6.1, вказує на те, що ці процесори мають 256 штирів даних і 76 адресних штифти (банк адреса + адреса пам'яті).

тому що не існує програми, яка потребує або має можливість представляти дані, використовуючи більше 128 біт одночасно.

і ви знаєте, мультимедіа-процесори та графічні картки знайдуть там дорогу перед материнськими процесорами, тільки тому, що для фото / відео є сенс використовувати такі великі довжини даних, які опрацьовуються відразу.

Комп'ютерна система є за своїм значенням обчислювальною машиною, яка вимагає певних входів і дає деякі результати. Ми повинні задовольнити комп’ютер у цих рядках, отже, у розробників з'явився орієнтир, маючи 3 автобуси, а саме: адресна шина, шина даних та шина управління. 1) Вибір адресної шини / Вибір конкретної адреси в пам'яті для операцій читання / запису. 2) Шина даних потім отримує дані, що представляють ці дані в процесор / з процесора та пам'ять для обробки / зберігання. 3) Контрольна шина створює протокол керування інтерфейсом і просить систему поважати його.

Вони необхідні для виконання деяких корисних обчислень для користувача / сервера / клієнта. Взагалі ефективність (швидкість виконання завдання, менше збоїв тощо) залежить від очищення шийок пляшки в системі. Якщо процесор здатний обробляти набагато вищу швидкість, ніж швидкість передачі з жорсткого диска, то горловина пляшки відбувається на жорсткому диску. Так само нам потрібно мати правильну швидкість обробки для певних швидкостей передачі даних та ширини коду.

З самого початку, з різних причин, таких як складність Г / З, вартість, вимога, ефективні алгоритми та основна причина Ринкової сфери, є головними перешкодами для виробництва ширини шини даних, як згадується в хості запитань, скажімо, 256 біт або 512 біт. Такі можливі! Але цієї вимоги ще немає, ринкова сфера ще не видно з потреб сьогодні та відсутністю компліментарної програмної підтримки.

256-бітний процесор означає ширину шини даних, яку може обробляти конкретний процесор, або ALU може обробляти в одному виконанні. Ми почали формувати 4 біти, потім 8,16,32, а тепер 64 і навіть 128 біт, які є теперішньою товарною сферою.

Тому перед тим, як задавати ці питання, ви завжди повинні бачити попит на ринку та його обсяг. В історії це єдиний спосіб прямого розуміння способів життя. Якщо ви не можете собі це дозволити, як ви можете їх придбати? і якщо ви не можете його придбати, як виробник може виробляти? і якщо він не може виробляти, то для цього продукту немає існування !!