AMD проти Intel: частка «червоних» на ринку x86-процесорів зросла до 31,3%

Обсуждение статей и новостей сайта
Автор
Сообщение
Timedemo
Member
Откуда: Ненька Украина

Сообщение

ДядяСаша: 10.02.2023 12:15
gehka3: 10.02.2023 11:53 ДядяСаша
Это "скоро" уже лет тридцать как пророчат, то с выходом ноутов, то со смартфонами - а всё ещё офисные машинки покупаются, вот рыночек ТОП сегмента - да, с ценником на современное по цене малолитражки бу, народ задумывается
Хлопці подивіться навколо себе скільки людей поряд з Вами користуються ноутами, а скільки ПК тоді зразу мене зрозумієте. Яка пропорція зараз. Пару років була 3:1, зараз 5:1. Вже мало й на підприємствах замовляють стаціонарні ПК, всі орієнтуються на ноутбуки.
Процес іде.
Не судіть по Київу про всіх виробників чіпів.

Відправлено через 1 хвилину 54 секунди:
MessiaH: 10.02.2023 10:47 Предлагаю обсудить AMD проти Intel: частка «червоних» на ринку x86-процесорів зросла до 31,3%
Красные делают вполне нехилые процаки, надеюсь 7950х3д даст в щи 13900к и будет мегакрутым гейминг процаком на лет 5 точно
Эта надежда длится уже 35 лет.
terminahtor
Member
Аватара пользователя
Откуда: Київ

Сообщение

AMD...Intel...ARM one love B-)
Timedemo
Member
Откуда: Ненька Украина

Сообщение

Кстати мегакрутой гейминг делает видяха. Исключение танчики на денди.
vmsolver
Member

Сообщение

manbearboar: 10.02.2023 21:19
vmsolver: 10.02.2023 17:31 Пока не очевидно есть ли смысл в AVX-512 в десктопах, и то как легко Интел от них отказалась в угоду мелких ядер, только подтверждает эту мысль.
Интел дрыгались буквально до последнего, пытаясь заставить работать две архитектуры с разным набором комманд под одной крышкой.
Нет.
manbearboar: 10.02.2023 21:19 В их планах был озвучен аппаратный thread director, который должен был это дело разрулить и даже за месяц до релиза 12 поколения они не готовы были подтвердить, что АВХ512 не будет.
Нет. Почитайте что такое thread director. И он не это должен разруливать.
manbearboar: 10.02.2023 21:19 Потом таки отключили, но на первых версиях биосов его можно было включить обратно, при условии отключения е ядер.
Я б не охарактеризовал это всё как "легко".
Да и говорить, что "легко отказались" когда он занимает площадь на кристалле, только не может работать, это ыы.
Вы не понимаете о чём говорите (с)

Відправлено через 7 хвилин 16 секунд:
Scoffer: 10.02.2023 21:55
vmsolver: 10.02.2023 17:31Пока не очевидно есть ли смысл в AVX-512 в десктопах
Сенсу AVX вище 64 в принципі немає, окрім маркетингових забаганок.
Есть, и 128, и 256 отлично себя показывают в вычислениях, так и 512 тоже. векторизация это сравнительно простой способ увеличения темпа обработки (производительности). А сейчас уже перешли на ускорение не векторов, а матриц, новый виток спирали развития.
Scoffer: 10.02.2023 21:55 SIMD взагалі для чого вигаданий був: для того щоб раз ми все одно запускаємо 64-бітне ALU і воно вже самим цим фактом жре енергію, то ефективніше утилізувати його як 8*8 біт даних, а не 8 біт корисної інфи і 56 біт обчислення нулів.
Нет, выше написал
Scoffer: 10.02.2023 21:55SIMD вище розрядності ALU це просто оверхед по жору в кількості випадків, що впритул наближаються до 100%.
Нет, не оверхед, векторизация позволяет обрабатывать сразу несколько чисел одновременно, например при вектора 256 бит, можно сразу обрабатывать четыре FP64 числа одновременно, а не один, в случае если векторного юнита нет.
Scoffer: 10.02.2023 21:55Можна було б заперечити: "так декодування команд теж щось жере". Вірно, але для зменшення жору в цій частині проца набагато вигідніше завезти векторних команд, справжніх векторних, як в суперкомпах крея колись, а не SIMD, котрі векторами, незважаючи на всі маркетологічні потуги, не є.
Никаких проблем декодирования векторизация не составляет.
Не помню что у Cray там "настоящего", их было много разных.
Нет, маркетологи тут не причем, векторизация просто дешевый способ.
Scoffer
Member
Аватара пользователя

Сообщение

vmsolver
Я не згоден. SIMD вище розрядності ALU це натягування сови на глобус, і попутно створення ситуації коли треба постійно вводити нові команди щоб патенти не застаріли, і конкуренти не були допущені.
Справжній вектор це той де ти в команді описуєш його довжину, а апаратне забезпечення в процесі виконання саме наріже на стільки порцій, скільки воно здатне за раз виконати, ще й в конвеєр запхне. Тобто немає потреби в постійних нових AVX 100500 від слова зовсім. Вийшов проц з 10ма алу на борту, буде виконувати по 640 біт за раз, а якийсь в ноуті чи мобільнику по 64, і обидва будуть абсолютно сумісні з програмної точки зору.

Відправлено через 2 хвилини 7 секунд:
https://people.eecs.berkeley.edu/~pattr ... ture06.pdf

Відправлено через 4 хвилини 39 секунд:
До речі англомовна вікі теж норм їх розрізняє з сімдами
https://en.wikipedia.org/wiki/Vector_processor
vmsolver
Member

Сообщение

Scoffer: 10.02.2023 22:49 vmsolver
Я не згоден. SIMD вище розрядності ALU це натягування сови на глобус, і попутно створення ситуації коли треба постійно вводити нові команди щоб патенти не застаріли, і конкуренти не були допущені.
Хм
Scoffer: 10.02.2023 22:49Справжній вектор це той де ти в команді описуєш його довжину,
Теоретики они такие теоретики ;) А почему вектор фиксированной длины вдруг перестал являться вектором?
Scoffer: 10.02.2023 22:49а апаратне забезпечення в процесі виконання саме наріже на стільки порцій, скільки воно здатне за раз виконати, ще й в конвеєр запхне. Тобто немає потреби в постійних нових AVX 100500 від слова зовсім. Вийшов проц з 10ма алу на борту, буде виконувати по 640 біт за раз, а якийсь в ноуті чи мобільнику по 64, і обидва будуть абсолютно сумісні з програмної точки зору.
Идея красивая, но не идеальная. Во-первых об этом надо думать до создания SIMD юнита в архитектуре вообще, что было давно и уже не важно почему это создано не так как сферическом вакууме идеальности. Во-вторых, даже создав набор инструкций где все векторы переменной длины, всё равно рано или поздно надо внедрять инструкции которых ранее не было, поэтому такой универсальный стандарт тоже будет иметь версии, нумерации и т.д.

Собственно, я не увидел чем и почему фиксированные векторы это натягивание совы на глобус, а векторы переменной длины, которые также могут быть длиннее разрядности АЛУ, нет.
И что? Куда смотреть? Что имелось в виду при упоминании сего в прошлом посте?
manbearboar
Member

Сообщение

vmsolver
Слайд от Интел с FMA512.
спойлер
Изображение
https://www.anandtech.com/show/16881/a- ... tectures/5
Дата новости, что AVX-512 таки не будет это 19 августа 2021 года.
До этого Интел всячески мяли титьки и не признавались, как оно будет. На профильных форумах ходили споры о том как Интел собирается заставить это работать, заявляя avx-512 в P-core и не запилив его в E-core.
Финальный ответ - тупо никак.

Відправлено через 6 хвилин 9 секунд:
vmsolver: 10.02.2023 22:38 Нет. Почитайте что такое thread director. И он не это должен разруливать.
А вы почитайте его описание, найдите там упоминание что он "детектирует использование потоком тяжёлых инструкций и сигнализирует об этом оси" и сложите два плюс два.

В итоге идея редуцировала в пару строчек в коде W11, который "неприоритетные" потоки запихивает на e-ядра.

Что характерно, в августе они уже говорили что отключат авх512 аппаратно
The biggest thing that gets the cut is that Intel is losing AVX-512 support inside Alder Lake. When we say losing support, we mean that the AVX-512 is going to be physically fused off, so even if you ran the processor with the E-cores disabled at boot time, AVX-512 is still disabled
https://www.tomshardware.com/news/how-t ... ve-avx-512
Но на релизе оказалось, что на части процев его можно включить, потому что более ранние партии выпускались без аппаратной блокировки.
По датам выпуска этих партий можно судить когда внутри Интел ещё зиждилась надежда, что thread director в паре с W11 всё разрулит.

Відправлено через 13 хвилин 32 секунди:
Физически существующие доказательства дрыганий - это партии продажных Альдеров с живым AVX512 блоком.
Это не инженерники, уже финальная версия.
To check for AVX-512 compatibility, Zingaburga says you'll need to check the batch number on your Alder Lake CPU or the chip you are potentially buying. Batch numbers with V149 or X149 or lower will have the AVX-512 instruction set enabled on the silicon. While codes starting with V150 or X150 through V201 or X201 could potentially support AVX-512, it's not guaranteed.
А такую драматичную драму как вы могли пропустить?
In short, early production units of Alder Lake chips had their AVX-512 instruction sets intact from the factory, but Intel didn't want it enabled for unknown reasons. Motherboard manufacturer's caught wind of this and created a switch to allow AVX-512 right from the BIOS.

Intel countered this with new microcode updates to stop AVX-512 enablement, but even that was countered by the fact that older BIOS microcodes still existed, and users could switch to those versions at any time.
vmsolver
Member

Сообщение

manbearboar: 10.02.2023 23:16 vmsolver
Слайд от Интел с FMA512.
спойлер
Изображение
https://www.anandtech.com/show/16881/a- ... tectures/5
Дата новости, что AVX-512 таки не будет это 19 августа 2021 года.
До этого Интел всячески мяли титьки и не признавались, как оно будет. На профильных форумах ходили споры о том как Интел собирается заставить это работать, заявляя avx-512 в P-core и не запилив его в E-core.
Финальный ответ - тупо никак.
И где они "дрыгались"? Внутри конторы была подковёрная борьба куда это развивать, решили без AVX512. Всё. Вам то чего хныкать?
manbearboar: 10.02.2023 23:16
vmsolver: 10.02.2023 22:38 Нет. Почитайте что такое thread director. И он не это должен разруливать.
А вы почитайте его описание, найдите там упоминание что он "детектирует использование потоком тяжёлых инструкций и сигнализирует об этом оси" и сложите два плюс два.
В этом вашем "сложите два плюс два" находится отсебятина которая к реальности не имеет ничего общего, эта штука нужна для помощи диспетчеру задач ОС решать какие потоки на какая ядра перераспределять, на Р-ядро, на е-ядро или на SMT Р-ядра. Всё. К AVX512 это не имеет никакого отношения.
manbearboar: 10.02.2023 23:16В итоге идея редуцировала в пару строчек в коде W11, который "неприоритетные" потоки запихивает на e-ядра.

Что характерно, в августе они уже говорили что отключат авх512 аппаратно
The biggest thing that gets the cut is that Intel is losing AVX-512 support inside Alder Lake. When we say losing support, we mean that the AVX-512 is going to be physically fused off, so even if you ran the processor with the E-cores disabled at boot time, AVX-512 is still disabled
https://www.tomshardware.com/news/how-t ... ve-avx-512
Но на релизе оказалось, что на части процев его можно включить, потому что более ранние партии выпускались без аппаратной блокировки.
По датам выпуска этих партий можно судить когда в Интел ещё зиждилась надежда, что thread director в паре с W11 всё разрулит.
Решили не развивать эту тему на десктопе, отдав приоритет е-ядрам, thread director тут не причем, выше написал для чего она нужна. Не выдумывайте лишних сущностей без надобности.
Scoffer
Member
Аватара пользователя

Сообщение

vmsolver
Які теоретики? Суперкомпи були векторними на практиці, а не в теорії. І такими вони були рівно до моменту поки не почали збиратись з консьюмерського залізячча, та і після NEC психонула і зібрала поверх х86 з додатковими платами тру-векторний з програмної точки зору SX-Aurora. Додатковий програмний прошарок сам розпихує тру-вектори по залізу, для програмерів все прозоро.

Переваги принципові: фізично не потрібні векторні ALU, можна обійтись скалярними, котрих в сучасних процах і без того не одне, і, що головніше, можна законвеєрити лоад-стор, що різко збільшує відсоток завантаження проца.
Мінімальний випадок: у тебе на борту проца 1 алу, 1 лоад юніт, 1 стор юніт, і 1 набір регістрів шириною в розрядність алу, і один додатковий регістр-лічильник довжини вектора. Командою встановлюється довжина векторів, і проц погнав в три конвеєра маслати на всіх парах вектор хоч в мегабайт довжиною. Здається малувато? Значить береш всі свої 6-8 алу, котрі в ядрі на борту тому що суперскаляр, і на кожному запускаєш конвеєри в паралель, довжина ж відома, нарізати легко, і все, у тебе вже в 6-8 раз швидше. Ще мало? Та хоч до посиніння розширюйся. І це все без жодної зміни в ПЗ. Оце нормальна схема.
А коли виходить ммх і наче норм, потім ссе, котрий 1 в 1 повторює ммх, принаймні в перших версіях так точно, але старі проги ніякого профіту мало того що не бачать, так ще і з часом з проца починають викидати старі сімд команди і темп роботи зменшується, а потім авх 128/256/512 з рівно тим же самим підходом - це якесь лайно якщо чесно.
Для програмістів додатковий профіт - не треба самому нарізати дані на порції в усіх варіаціях SIMD і готувати відповідний код щоб ну хоч десь воно завелось, апаратура сама покромсає по скільки їй треба. Хоче - хоч по 576 біт. І все коректно виконає.
vmsolver
Member

Сообщение

Scoffer: 10.02.2023 23:35 vmsolver
Які теоретики? Суперкомпи були векторними на практиці, а не в теорії. І такими вони були рівно до моменту поки не почали збиратись з консьюмерського залізячча.
Не вижу никаких преимуществ или даже причин, почему интеловцы должны были сделать также, они выбрали фиксированную длину. Вы так и не смогли выразить, почему это плохо.
Scoffer: 10.02.2023 23:35Переваги принципові: фізично не потрібні векторні ALU, можна обійтись скалярними, котрих в сучасних процах і без того не одне, і, що головніше, можна законвеєрити лоад-стор, що різко збільшує відсоток завантаження проца.
У векторных АЛУ свой регистровый файл вроде бы, это уже рушит всю красоту вашей идеи. Ну и попробуйте набрать скалярными АЛУ ту же ширину, пусть например двух юнитов AVX2, напомню, каждый из них шириной 256 бит. Летс гоу! ))
В наборе скалярных АЛУ нельзя делать горизонтальные инструкции, в общем случае это сложнее и вряд ли быстрее чем специализированный блок. Вообще, любой специализированный блок будет быстрее чем большая разухабистая конструкция, где есть куча раздельных АЛУ, у которых вроде бы даже разные возможности, посмотрите порты запуска, они не все равнозначны. Также у векторного АЛУ могут быть команды, которых нет у скалярных.
Scoffer: 10.02.2023 23:35Мінімальний випадок: у тебе на борту проца 1 алу, 1 лоад юніт, 1 стор юніт, і 1 набір регістрів шириною в розрядність алу, і один додатковий регістр-лічильник довжини вектора. Командою встановлюється довжина векторів, і проц погнав в три конвеєра маслати на всіх парах вектор хоч в мегабайт довжиною.
Программист написал цикл, зная ширину вектора в проце, всё, компилятор сгенерил нужный код. В более сложных случаях можно использовать библиотеку, она вообще сама посмотрит по CPU ID доступный набор SIMD команд и выберет нужную ветку кода для процессора
Scoffer: 10.02.2023 23:35Здається малувато? Значить береш всі свої 6-8 алу, котрі в ядрі на борту тому що суперскаляр, і на кожному запускаєш конвеєри в паралель, довжина ж відома, нарізати легко, і все, у тебе вже в 6-8 раз швидше. Ще мало? Та хоч до посиніння розширюйся. І це все без жодної зміни в ПЗ. Оце нормальна схема.
А коли виходить ммх і наче норм, потім ссе, котрий 1 в 1 повторює ммх, принаймні в перших версіях так точно, але старі проги ніякого профіту мало того що не бачать, так ще і з часом з проца починають викидати старі сімд команди і темп роботи зменшується, а потім авх 128/256/512 з рівно тим же самим підходом - це якесь лайно якщо чесно.
Сделайте! ))
Не всё так просто. Что касается совместимости, то х86 этим и славится. Не всегда можно ускорить старую программу, есть пределы за которые можно выйти лишь переписав программу, и вот для этого нужны новые инструкции и возможности и именно так и было сделано, и SIMD это именно поэтому.
Scoffer
Member
Аватара пользователя

Сообщение

vmsolver: 10.02.2023 23:54У векторных АЛУ свой регистровый файл вроде бы
Не обов'язково. Не більш ніж зручність коли є 100500 алу.
Обов'язково - регістр-лічильник вектора і конвеєрізація лоад-стору бо без них немає сенсу в затії.

Відправлено через 4 хвилини 22 секунди:
vmsolver: 10.02.2023 23:54почему интеловцы должны были сделать также, они выбрали фиксированную длину
тому що інтеловцям важливо оновлювати патенти, це головна причина
х86-64 і ссе по 2й включно вже суспільне надбання і може використовуватись всіма без спросу
куди таке годиться з точки зору інтела?)

Відправлено через 3 хвилини 23 секунди:
vmsolver: 10.02.2023 23:54Вы так и не смогли выразить, почему это плохо.
Тобто повна програмна сумісність з машинами сильно різної продуктивності і енергоефективності це вже недостатньо? І приріст продуктивності на старому софті.
vmsolver
Member

Сообщение

Scoffer: 11.02.2023 00:07Не більш ніж зручність коли є 100500 алу.
Нет столько АЛУ, это сейчас 6-wide процессоры, а раньше они были сильно уже, посмотрите в каком году представили AVX2, это древность уже.
Scoffer: 11.02.2023 00:07тому що інтеловцям важливо оновлювати патенти, це головна причина
И в чём проблема? Давайте представим что это так, и что? Почему Интел не может добавлять что-то новое в свои процессоры и патентовать это? Это нормальная практика. Или речь про АМД? Ну так у Интел и АМД кросс-лицензия есть, Интел придумает новый набор команд, АМД может его реализовать в своих процессорах.

Попробуйте перед тем как написать что-то ещё, ответить на критику выше. Так как вы пишите одно, я это развечиваю, вы пишите другое, я также это нивелирую, вы третье и так далее.
Цитирую свой аргумент
vmsolver: 10.02.2023 23:54Не всегда можно ускорить старую программу, есть пределы за которые можно выйти лишь переписав программу, и вот для этого нужны новые инструкции и возможности и именно так и было сделано, и SIMD это именно поэтому.
Scoffer
Member
Аватара пользователя

Сообщение

vmsolver
Тому що у тебе якісь дуже дивні аргументи.
По-перше зараз не 6-вайд процесори, а цілком собі 10-вайд, привіт IBM Z. При чому 10-вайд вони доволі давно, як мінімум покоління 2-3 точно.
По-друге кількість алу обумовлюється суперскалярністю проца, планувальник просто не може нарізати мюопсів на скалярному коді щоб знадобилось більше ALU. Очевидно векторних інструкцій це взагалі не стосується. Вони за визначенням паралельні. Ріж поки не набридне. І АЛУ так само докидуй поки не набридне. Хоч сто штук.
По-третє те що не завжди можна стару прогу прискорити не значить що треба тупо забити на цю можливість. В більшості випадків прискорити можна.
По-четверте інтел може додавати нові команди і патентувати їх, але вони перші років надцять нікому будуть не потрібні оскільки приріст від кількості алу на векторах буде і на старих командах, а в не перші ті патенти вже протухнуть. Зовсім інша справа коли ти насильно або пересаджуєшся на нові команди, або ніяких тобі х2 до швидкості.
manbearboar
Member

Сообщение

Yalg: 10.02.2023 19:54 Не стоит забывать что видюхи у них продаются лучше чем у амд.
Интел поставил относительно немало видеокарт ритейлерам и отразил это в своей отчётности, но есть нюанс, их ещё нужно теперь продать :gigi:
Вся боль Арка в этой разнице между поставками и продажами.
vmsolver
Member

Сообщение

Scoffer
Scoffer: 11.02.2023 00:27Тому що у тебе якісь дуже дивні аргументи.
Не может быть!
Scoffer: 11.02.2023 00:27По-перше зараз не 6-вайд процесори, а цілком собі 10-вайд, привіт IBM Z. При чому 10-вайд вони доволі давно, як мінімум покоління 2-3 точно.
Мы же про х86 говорили, причем тут IBM? В обзоре Алдер Лейка
Starting off with the directly most obvious change: Intel is moving from being a 4-wide decode machine to being a 6-wide microarchitecture, a first amongst x86 designs, and a major design focus point.

А микроопераций за такт 6-8 штук. Да, я это назвал 6-wide, не вижу причин не называть его так и далее.
Scoffer: 11.02.2023 00:27По-друге кількість алу обумовлюється суперскалярністю проца, планувальник просто не може нарізати мюопсів на скалярному коді щоб знадобилось більше ALU.
А потом
Scoffer: 11.02.2023 00:27По-третє те що не завжди можна стару прогу прискорити не значить що треба тупо забити на цю можливість.
А разве не очевидно, что всё до SIMD-вое развитие процессоров как раз преимущественно и есть оптимизации и улучшения архитектуры в такую сторону, чтобы старые программы работали быстрее, и делалось это с оглядкой на доступные техпроцессы, это сейчас миллиард транзисторов туда, миллиард сюда, это мелочи, раньше с этим было сильно плохо.
Это сочинять просто ;)
Scoffer: 11.02.2023 00:27По-четверте інтел може додавати нові команди і патентувати їх, але вони перші років надцять нікому будуть не потрібні оскільки приріст від кількості алу на векторах буде і на старих командах
Всем кто пишет программы они будут нужны, так как новые инструкции это новые возможности и скорость.
Что касается подхода с множеством скалярных АЛУ то повторю
vmsolver: 10.02.2023 23:54любой специализированный блок будет быстрее чем большая разухабистая конструкция, где есть куча раздельных АЛУ
В векторном юните всё в куче, быстро и синхронно, и проблем с лоад-сторе нет и т.д.
Вы просто пропускаете то что я пишу, мне не удобно себя цитировать :-P
Scoffer: 11.02.2023 00:27Зовсім інша справа коли ти насильно або пересаджуєшся на нові команди, або ніяких тобі х2 до швидкості.
Ну блин! Ну хватит уже
vmsolver: 10.02.2023 23:54Не всегда можно ускорить старую программу, есть пределы за которые можно выйти лишь переписав программу, и вот для этого нужны новые инструкции и возможности и именно так и было сделано, и SIMD это именно поэтому.
В общем, мне дальше лень в этом участвовать B-)
manbearboar
Member

Сообщение

vmsolver: 10.02.2023 23:35 Решили не развивать эту тему на десктопе, отдав приоритет е-ядрам, thread director тут не причем, выше написал для чего она нужна.
А могли решить развивать?
Как вы себе это представляете технически?

Я за этой темой следил и не скажу на каком форуме есть моё вангование, что ближе к релизу AVX512 просто отключат, потому что не удастся реализовать задуманный "перехватчик" инструкций.
Ещё предлагался вариант через прерывания, но он ещё кривше.

Когда они решили е-ядра пихать без паритета по инструкциям с P-ядрами, они уже де-факто отключили авх512, только ещё несколько лет после этого себе в этом не признавались.
Где-то работала команда, которая обещала вот-вот рабочее решение, ажно до самого релиза.
С видеокартами похожая ситуация, Раджа полгода кормил руководство инфой что видеокарты уже вот-вот, счас релизнём.

Факты все на руках и в железе.

Домыслами можно было бы считать предположение, что кинулись они в эту тему после получения разведданных по планам АМД на Бергамо.

При этом у Интел момент принятия решения делать гибрид был поздно пилить новые архитектуры и решили засунуть то что есть как есть, при этом какой-то надмозг предложил решение проблемы разных инструкций и это пошло в работу.
В итоге всё криво косо.
У AMD картина складывается как будто всё было задумано изначально - отдельный dense кристалл на 16 ядер, из которого можно ещё десктопный 8+16 запилить, с полным набором инструкций без всякой гетерогенности и потраченного впустую кремния.
fastneed
Member
Аватара пользователя
Откуда: UA

Сообщение

рахую експертів Mercury Research не кваліфікованими пустозвонами
дивно що їх ще не посадили
ronemun
Advanced Member

Сообщение

Scoffer
у висококонкурентному середовищі якраз і виживає тільки той хто захистить свої наробки і всім їх навяже - такий закон грошей. Тут святих не може бути. І чим буде невигідно для інших тим більше ти заробиш - адже їм прийдеться постійно оновлятись. Зроби зло і дай його рішення - і всі тебе любитимуть. Головне щоб нічого не запідозрили.
Саме тому Інтел/х86 і стала основою не тільки компів, а й серверів, і відтіснила IBM і інші архітектури. Туди ж можна вписати і принципове обмеження шин даних щоб було важко приєднувати інші прискорювачі, дуууже дорогі мультипроцесорні платформи, спеціальні обмеження в оперативі, очевидне затягування з розділення проців на ядра і чіпсет - щоб поменше ядер вмістилось і примусити більше проців купляти, і навіть довге затягування з ростом теплопакету - очевидно менше ват - менша частота - менша продуктивність - тре більше проців
Последний раз редактировалось ronemun 11.02.2023 14:57, всего редактировалось 1 раз.
Scoffer
Member
Аватара пользователя

Сообщение

ronemun
Я прекрасно розумію чому і навіщо інтел так робить. Я не розумію чому місцеві персонажі захищають ці рішення як видатні технологічні досягнення, хоча вони є прямою деградацією в порівнянні з попередніми напрацюваннями :D
ronemun
Advanced Member

Сообщение

Scoffer
Взагалі ARM у v9 перейшла на ті принципи що ти розповідаєш, але швидко збилась, перший млинець погано спікся - виявилось дуже важко програмувати чомусь, старий софт все таки не пішов, і навіть в серверних аріантах в 100+ ядер, де весь софт ніби можна оптимізувати, різко передумали купляти. Прийшлось переробляти проци і зараз вийшла v9 v2, ніби повернулись до старих Neon паралельно з новими
Мене теж дивувало оте бажаня робити абсолютно універсальні ядра що для нових що для старих архітектур - чому не впарити до нового паралельно 1-2 старих ядер, звичайно трохи перероблених, але щоб тупо працювали для старого коду, і не займали весь планувальник, всі нові 256/512 регістри, мучились в режимі сумісності і.т.п. Ті старі ядра це 1% від нових по транзисторам, їм навіть економічного режиму не тре - на нових техпроцесах там нульове споживання. Зарашня оператива швидша за тодішній кеш. А старий софт і так невибагливий - він же під ту древнсть розроблявся
Ответить