Здравствуйте, novitk, Вы писали:
N>То что Эльбрусы г... было понятно и в 2020 и в 2015 и в 2010 и в 2005. Это стало понятно ровно тогда, когда Интел который потратил на VLIW в 20х больше ресурсов, чем РФ закрыл Itanium.
У Intel были свои причины свернуть Itanium. Да и так себе это работает как аргумент.
Intel и сейчас внезапно разучился процессоры делать, я сам сижу на их кривом процессоре и не знаю что делать.
N>Ресурсы конечны и те что были потрачены на адаптацию и дальнейшую разработку Эльбруса для широкой публики это просто сожженные деньги. Это должно было превратиться в русский Itanium, когда результаты у Интела стали понятны.
Кроме МЦСТ никто не хотел своё делать, интереснее было заниматься купи-продай.
А потом уже, когда запахло жаренным, то начали у той же МЦСТ специалистов переманивать.
N>С чего бы это? Если начать 10 лет назад, то компетенции на сегодняшний были бы другие.
Ну, если, да кабы. yadro пару лет назад всего с RISC-V нарисовались и только в этом году обещали что-то показать.
Не помню, чтобы было много желающих заниматься CPU 10 лет назад.
N>Производство не имеет отношение к разработки логики в 2025. Производство — другая и гораздо более сложная проблема, которую РФ внутренне решить имхо не сможет в принципе. Только встраиваться в тех. цепочки под Китаем или США.
Говорят, что переезд производства на другую фабрику проблематичен (долго и не бесплатно), а не так, что готовые схемы отправил и получил такие же чипы.
Без наличия выхода на производство, никаких частных инвесторов не найдут, сугубо государство должно будет тянуть разработку.
А у государства тоже мало мотивации будет, если на выходе будут какие-то разработки на бумаге, которые никуда не приткнуть.
N>>>Был ARM, MIPS и Sparc. Это проверенные работающие решение с развитым стеком стоимостью миллионы задочасов. Собственно китайцы так и поступили для Loongson(MIPS). Импортозаместись, а потом можно и попродвигать архитектуру. K>>А в какой момент? Поначалу это была попытка прорыва. Не потянули. N>Какого прорыва? Все что мы обсуждаем было уже сильно после того как VLIW Intel "не потянул", а не наши кулибины без производственной базы.
МВК «Эльбрус-3» — разрабатывался в 1986—1994 годах группой сотрудников Института точной механики и вычислительной техники под руководством Б. А. Бабаяна на основании совершенно новых архитектурных идей. МВК Эльбрус-3 должен был содержать 16 суперскалярных процессоров с VLIW-системой команд. Не был запущен в серию.
Itanium (произносится: Айтэниум) — микропроцессор с архитектурой IA-64 для серверов и рабочих станций, разработанный совместно компаниями Intel и Hewlett-Packard. Впервые был представлен 29 мая 2001 года.
а дальше уже была инерция — ну раз разрабатывают, наверное набрали какую-то компетенцию, совсем выбрасывать жалко
Здравствуйте, rudzuk, Вы писали:
R>И какая же особая заточка у серверных процессоров в объективной реальности, кроме кучи ядер и кеша, которые просто не нужны в десктопах и ноутбуках? Вроде, никто не перекраивает архитектуру проца, чтобы оно в бизнес-задачах заиграло, неправда ли?
т.е. x86 за 20 лет не менялась, архитектура осталась такой же, как была?
R>Так VLIW и сдулся, раз они в восьмой версии намерены отойти от развития архитектуры в "традиционном ключе" (с) Трушкин. На чем ты меня подловить пытаешься, я не пойму
т.е. теперь всё же уже сдулся? А то в предыдущем сообщении было "И если, таки, впендюрят его в восьмую версию, это и будет означать слив VLIW, на которую они наяривали все эти годы.".
Я тебя не пытаюсь подловить, а прямо спрашиваю, но ты в новом сообщении противоречишь себе же из предыдущего сообщения.
R>Сколько интелу потребовалось времени, чтобы признать, что итаниум тупик? Немного, прямо скажем. Разработки свернули, производство продолжили в рамках долгосрочных контрактов.
Начали работу с HP над архитектурой в 1994 году. Последнюю линейку процессоров выпустили в 2017. Производство завершили в 2020. Ну, совсем немного времени.
Да и там вопрос в причинах сворачивания линейки. Не было бы AMD с их x86-64, до сих пор наверняка выпускали и нахваливали.
R>В этой архитектуре не решаются. Неужели все еще не понятно?
Потому что ты так сказал?
R>Вероятно улучшат.
Так же как в x86 добавляли всякие SSE инструкции и т.п.
Не знаю даже чего они сразу нормальную архитектуру не сделали, а только потом стали её оптимизировать под конкретные задачи и до сих пор что-то выдумывают и меняют.
R>А нужна именно отечественная?
Нужно то, что сами смогут развивать и поддерживать. Были альтернативы 5 лет назад или 10 лет назад или сегодня может есть уже?
R>Делают на пятом риске. У него, говорят, с производительностью "скриптов" все в порядке.
Здравствуйте, Философ, Вы писали:
Ф>>> Всё-таки лучше переупорядочивать на этапе компиляции — мне кажется, что тут больше возможностей — тут легче загрузить конвеер(Ы).
N>>Хрен там:
N>>1) Представим себе, что есть команда, которая выполняется 100 тактов. Ну там, согласно гайдам x86 у них деление 128/64 выполняется 90. А все остальные выполняются ну до 10 тактов самая сложная. Параллельная группа команд будет выполняться по времени самой долгой, пока она не закончится — все ждут. Кем жертвовать будем?
Ф>Не вижу проблемы: любая группа команда, при любом подходе в конечном счёте упрётся в зависимость по регистрам или зависимость по данным — тут не важно, аппаратный это OoO, компиляторные ли перестановки, или ты руками что-то переставлял.
Проблема не в зависимости как таковой, а в том, что если при OoO у тебя пока одна стотактная команда хрустит, рядом 100 простых могут пролететь. А в параллельную группу в EPIC (как бы она ни называлась — "широкая команда" или как там её) ты уже вынужден набить конкретные команды, определённое подмножество, которым жертвуешь.
Ф> Если что, то я, как прилежный ученик, так делал учебные примеры из книжки "Оптимизация для процессора Pentium" — переставлял команды руками, и для того чтобы развязать зависимость по данным и/или регистрам, и для того чтобы одновременно нагрузить u и v конвейеры.
Я руками не писал, но выхлоп компилятора помню. Да, было такое. Интересно было, как при переходе к 686 (PPro и далее) компиляторы это снова забыли С честным OoO это не нужно.
Но на пне ты, условно говоря, собирал в такую группу две команды. А не 30 или сколько там позволяет Эльбрус.
Ф> Точно говорю — в простых случаях это возможно даже руками. Но если распространить этото подход на действительно обширный участок кода, то а) руками никак — за гранью человеческих возможностей б) всё равно упрёшься в зависимости
Ну вот именно — что разница вроде бы и количественная, но такая, что убивает всю пользу.
N>>Тут немножко поможет prefetch. Потому и бенчмарки для Эльбруса стараются показывать на потоковой обработке через SIMD Ф>Префетч помогает (не немножечко), и точно не поэтому стараются: префетч и симд про разное.
Prefetch данных следующей итерации (нескольких) SIMD это естественно. Я говорю про явный. Неявный тоже хорош, но его надо ещё предсказывать.
А вот если не SIMD, то ни явный, ни неявный не работают, и идёт просадка. И снова — при OoO эта просадка меньше заметка, а при EPIC начинает бить кувалдой по затылку.
Здравствуйте, vdimas, Вы писали:
N>>Тут немножко поможет prefetch. Потому и бенчмарки для Эльбруса стараются показывать на потоковой обработке через SIMD, где это возможно. А на другом коде результаты сразу будут в разы хуже, чем у конкурентов с честным OoO: вечно что-то пропадает из кэша в самый интересный момент, и когда на OoO одна соответствующая команда тормозит, на EPIC тормозит вся группа.
V>Была сделана ставка на компилятор, что он сможет анализировать сценарии и грамотно раскидывать команды по VLIW.
Вот объясни мне, каким образом можно "грамотно раскидывать команды", когда при среднем времени выполнения, условно, 2 такта, каждая из них может получить непредсказуемую задержку до 200 тактов?
Здравствуйте, vdimas, Вы писали:
N>>Пусть у тебя 1024 ядра (я выбрал цифру пострашнее) V>Да так и есть, страшно. )) V>Технически отрасль давно готова выпускать вычислители с таким кол-вом ядер, но SMP/UMA на таком кол-ве ядер потребуют "надстройку" стоимостью дороже целевых блоков.
[...]
Ну вот представим себе, для начала, что код кэшируется когерентно, а данные — как я описал для SystemZ, когерентности нет в принципе.
По-моему, уже будет неплохо. И с современными языками вполне сочетается.
V>Дело в долбоящерах в международных комитетах, которые ревностно следят исключительно за тем, чтобы ни дай бог кто-нибудь случайно не вырвался вперёд остальных.
И кто запрещает свои расширения или свои экспериментальные языки?
V>Кстате, из-за таких людей как ты, всячески этих вредителей поддерживающих. V>Не знаю как сейчас, но лет 10 назад ты был заражён хлореллой то гнутости, то "открытости". )) V>А сейчас как?
Чтобы я понял, о чём ты, приведи ссылку, или хотя бы приблизительную цитату.
Здравствуйте, vdimas, Вы писали:
V>E2k в макетах сначала показали в 90-е (это все последующие микропроцессорные Эльбрусы которые). V>И это был отрыв башки на тот момент, в плане вычислительной отдачи на единицу тактовой. V>Какие там в опу топовые пни на тот момент... Тогдашние пни выглядели как микросхемы от первых калькуляторов в своей отдаче на единицу тактовой.
Учитывая, что реальные микросхемы пошли где-то к 2005, причём это ещё "упрощённая модель"...
Я не могу себе представить, что тогда показали. Массогабаритный макет на рассыпухе?
Здравствуйте, Sinclair, Вы писали:
S>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java.
Не систему трейдинга, а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе...
В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor.
S>И для этого не пришлось ни ломать JIT, ни переписывать компилятор, ни раскладывать данные по линейкам кеша.
И да, разумеется, максимальный трафик перекачки достигается тогда, когда перекачиваемые данные разнесены по линейкам кеша и у них, и у нас, т.е. когда курсор чтения заметно отстаёт от курсора записи. Ну вот как раз именно в этом режиме "постоянного насыщения очереди" наша реализация оказалась резко эффективней, т.е. в режиме наибольшей нагрузки. В режиме передачи одиночных пакетов с паузой задержки оказались сравнимы.
Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
Плюс у нас есть возможность ожидать на примитиве синхронизации уровня ОС, т.е. отправлять поток в спячку, освобождая аппаратный поток для других задач в отсутствии данных, а у тех безальтернативно спин-ожидание.
В общем, самоучки от IT какие-то, простейшая дополнительная требуемая функциональность (рост очереди при необходимости, возможность ожидать на семафоре при необходимости) являются
у них невозможными, резко замедляющими вообще всё, что весь профит улетучивается.
Ты код-то поизучай внимательно, он у них открыт. ))
S>Понятно, что можно криво написать софт. Непонятно, что тут может бать Бабаяновское железо.
Убрать саму необходимость оперирования "зелеными потоками", вестимо.
И не важно, в stackless реализации, как в дотнетных корутинах с их сворачиванием линейной логики в автомат или в stackful корутинах, как принято в плюсах.
Т.е. вся эта софтовая надстройка для асинхронности становится не нужна, если порождение, уничтожение и переключение логических потоков будет не дороже, чем переключение корутин в упомянутых реализациях. А если будет дешевле, то вообще разговаривать не о чем. ))
Ведь все эти отжирающие тики проца навороты борются с недостатками современных процов и операционок поверх них, не умеющих эффективно порождать/уничтожать/переключать "родные" потоки уровня ОС.
V>>Это мейнстримовый случай, чем приходится заниматься вообще всегда, когда есть обмен данными между потоками. S>Пример LMAX Disruptor показывает, что не всегда.
Да ты на код-то их посмотри внимательно. ))
S>Ну, так что сдерживает-то? Сказки про комитеты, которые запрещают вам ковыряться в носу, рассказывать не надо. Простой вариант: берём дотнет, изобретаем набор атрибутов для лэйаута, делаем свой компайл-тайм-генератор типов
Дотнет, как и Джава, вообще не являются целевыми софтовыми инструментами для вылизывания таких вещей, там и без этого еще есть что вылизывать.
И это в любом случае пришлось бы делать на уровне JIT, т.е. разрабатывать оный свой.
Я о С/С++, где ситуация сложилась примерно как в HTML-стандартах, где лидерам надавали по голове однажды и отстранили от работы над стандартами примерно на 20 лет, пока у красноглазиков опенсорсные их компиляторы и браузеры не дорастут до среднего по индустрии качества. ))
Потеряли примерно 20 лет что в деле развития стандартов веба, что в деле развития языков для эффективного кода.
S>с выровненными по кэшу данными. Работы на один вечер.
Атрибуты для лейаута полей в дотнете есть, вручную данные разносятся легко.
А чтобы не вручную — это надо вмешиваться в выравнивание еще на уровне выделения памяти, бо сейчас эти зазоры берутся из расчёта выравнивания адресов объектов по ширине слова, т.е. произвольного выравнивания с т.з. ширины линейки кеша, получаем перерасход памяти на ровном месте. В плюсах хотя бы можно вмешаться в физическое выравнивание объектов в памяти, самим этой памятью управляя.
S>Если не знаем, на чём будет исполняться код — переносим генератор в рантайм. Работы на два вечера. S>Или берём clang, llvm, и делаем то же самое прямо в кодогенераторе. Работы на пару недель.
Не, это еще загрузчик переписывать и кое-какие пункты стандарта языка, ведь размер некоторых объектов одновременно перестаёт быть константной времени компиляции в смысле фиксирования значения этого числа в момент компиляции, но всё еще является константой в смысле возможности оперирования ею непосредственно в объектных кодах, т.е. без косвенного чтения некоей переменной, хранящей размер линейки кеша, просто эта константа должна корректироваться загрузчиком через соотв. таблицы коррекции, примерно как корректируются загрузчиком адреса.
Это не на пару недель, чуть больше, но да, решаемо.
Ну а толку, если далее ветка разойдётся с мастером и будущие улучшения комплятора-загрузчика станут недоступны.
Или же придётся заниматься одним и тем же вопросом всё время. ))
На деле, подобные вопросы обсуждаются уже даже больше, чем 20 лет, но из-за красноглазиков буксовали, бо их gcc безбожно отставал от кучи других компиляторов, которые были востребованы именно тем, что были лучше gcc. А коль стандарты языка заморозили и дали gcc возможность их догнать, то (a) куча альтернативных компиляторов просто вымерла за ненадобностью в этой кривой реальности и (b) вопросы стандартизации ABI (т.е. возможности манипулирования инфой об объектах в рантайм) были заморожены на 25+ лет.
Я просто думал, что коллеги в курсе происходившего вокруг основных ЯП, с которых "взлетает" любое железо. ))
V>>Имелись ввиду задачи активного обмена данными м/у потоками. S>Для начала нужно понять, зачем вообще потребовался активный обмен данными между потоками. Может, там надо по-другому работу распределить?
Ну ты же привёл пример Disruptor — а основой их решения как раз являются эффективные межпоточные очереди.
Как и у нас, конечно, только за счёт них, родимых, и выезжаем. ))
Ну а понимание "зачем" — это к тебе должен быть вопрос по теме организации эффективных вычислений на современных архитектурах.
Т.е. это как признаваться, что не сделал уроки.
V>>Блин, "более удачные структуры данных"... )) S>А то.
Да садись, два, хосподя...
Как ты вообще собрался утилизировать мощность в ядрах, исключив обмен данными между ядрами/потоками?
На независимых по данным задачах?
А если требуется именно решение одной некоей задачи организовать максимально эффективно?
И что, можно всерьёз об этом рассуждать с умным лицом, что ле? ))
Та блин, на самых первых серьезных векторных/параллельных компах столкнулись со всеми этими проблемами, которые не решены толком до сих пор: https://en.wikipedia.org/wiki/CDC_STAR-100
The problem was compounded by the fact that the STAR had a slower cycle time than the 7600 (40 ns vs 27.5 ns). So the vector length needed for the STAR to run faster than the 7600 occurred at about 50 elements; if the loops were working on data sets with fewer elements, the time cost of setting up the vector pipeline was higher than the time savings provided by the vector instruction(s).
When the machine was released in 1974, it quickly became apparent that the general performance was disappointing. Very few programs can be effectively vectorized into a series of single instructions; nearly all calculations will rely on the results of some earlier instruction, yet the results had to clear the pipelines before they could be fed back in. This forced most programs to pay the high setup cost of the vector units, and generally the ones that did "work" were extreme examples.
Таким образом, длина вектора, необходимая для того, чтобы STAR работал быстрее, чем 7600, составляла около 50 элементов; если циклы работали с наборами данных с меньшим количеством элементов, временные затраты на настройку векторного конвейера были выше, чем экономия времени, обеспечиваемая векторной(ыми) инструкцией(ями).
Когда машина была выпущена в 1974 году, быстро стало очевидно, что общая производительность была разочаровывающей. Очень немногие программы могут быть эффективно векторизованы в ряд отдельных инструкций; почти все вычисления будут полагаться на результаты некоторых более ранних инструкций, однако результаты должны были очистить конвейеры, прежде чем их можно было подать обратно. Это вынуждало большинство программ платить высокую стоимость настройки векторных блоков, и, как правило, те, которые «работали», были крайними примерами.
V>>E2k в макетах сначала показали в 90-е (это все последующие микропроцессорные Эльбрусы которые). S>Речь в топике про Эльбрус-Б. Эль-22, напомню, к E2K никакого отношения не имеет.
Ну и?
Тут кто-то сказал, что "не смогут показать макет", вот я и напомнил, что они показали охереннейший макет в такие года и в таких условиях, где это было сделать на порядки (реально на порядки!!!) сложнее, чем сегодня.
А сейчас, на современных доступных ср-вах разработки, эмулирования и макетирования на современных ПЛИСАХ — да это вообще как два пальца об асфальт со всеми этими макетами.
Вопрос, действительно, в способе видения проблемы и в наборе идей, составляющих решение этой проблемы.
Т.е., откуда берётся сама проблематика — мне хорошо понятно и лично мне интересно, конечно...
Тем более, что подобные языки уже были когда-то в 70-80-е, кое-какие развивались тихой сапой и до сегодня, я как-то давал список таких языков.
В студенчестве мы "на бумажке" программировали на одном из таких языков по теме параллельных вычислений (предмет "устройство современных выч. комплексов и операционных систем", могу ошибиться с точным названием, но суть именно такая).
Здравствуйте, netch80, Вы писали:
V>>Была сделана ставка на компилятор, что он сможет анализировать сценарии и грамотно раскидывать команды по VLIW. N>Вот объясни мне, каким образом можно "грамотно раскидывать команды", когда при среднем времени выполнения, условно, 2 такта, каждая из них может получить непредсказуемую задержку до 200 тактов?
В проце есть инструкции предзагрузки как отдельных ячеек памяти, так и целых регионов, компилятор может расставлять (и расставляет) такие команды в коде несколько "заранее".
В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров.
Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность.
Просто, как обычно, оно проскакивало не в топах по техпроцессу и не в самых популярных де-факто архитектурах. ))
Здравствуйте, netch80, Вы писали:
N>Я не могу себе представить, что тогда показали. Массогабаритный макет на рассыпухе?
На нескольких ПЛИС-ах.
Была цель показать высокую единицу отдачи вычислений на единицу тактовой и это было убедительно показано в сравнении с тогдашними топами.
Здравствуйте, netch80, Вы писали:
N>Проблема не в зависимости как таковой, а в том, что если при OoO у тебя пока одна стотактная команда хрустит, рядом 100 простых могут пролететь.
Таки, это вырожденный случай для одного потока, бо большинство алгоритмов, разработанных человеком, именно последовательно производят вычисления над данными.
А плюс еще ветвления.
А плюс еще исключительные ситуации.
В общем, в спекулятивном исполнении оказалось столько подводных камней, у-у-у... ))
Оно хорошо работает только на независимых задачах, отсюда растёт гипертрединг.
Здравствуйте, netch80, Вы писали:
N>Ну вот представим себе, для начала, что код кэшируется когерентно, а данные — как я описал для SystemZ, когерентности нет в принципе.
На сегодня уже понятно, что NUMA-архитектура наиболее выгодно реализуется как набор многоядерных UMA-узлов с программируемой связью м/у узлами.
Т.е., данные из других узлов надо забирать-отправлять явным образом.
Здравствуйте, Sinclair, Вы писали:
K>>напихать в 200 раз больше исполняющих блоков чем кто-то, кого они считают образцом. S>Хорошая идея. Вопрос: откуда возьмётся в 200 раз больше места на кристалле? Интел, значит, со своими 11нм, еле как впихивает свои несколько десятков FMA-блоков
Которые занимают не так много места. ))
Подавляющее большинство вентилей в проце задействованы под статическую память различного уровня.
S>Или там 192-ядерный RISC-V: чтобы впихнуть хотя бы в 30 раз больше, нужно как-то сделать площадь блоков в 30 раз меньше. Не говоря уже о 200х-кратном превышении.
Да не, просто в классической архитектуре пропорционально кол-ву ядер надо увеличивать как общий кеш на кристалле, так и каждому ядру нужен свой кеш, иначе смысла нет в этой классической многоядерности.
K>>как именно оформлена работа с ними — не очень важно, т.к основная проблема — откуда взять столько параллелизма в задачах — никуда не денется S>Ну, тут, возможно, прорыв будет как раз в языке программирования. В нём как-то особенно невыносимо просто будет писать параллелизм в задачах.
Дешевый параллелизм предполагает работу над одними и теми же данными, например, пресловутое параллельное умножение матриц, где эффект от распараллеливания достигается на гораздо меньших размерностях. Тогда отношения размера кешей к кол-ву ядер может быть меньшим, коль имеем более "тесное" использование данных ядрами. Вернее, аппаратными потоками, конечно, а не ядрами, бо термин "ядро" может несколько расплываться в такой архитектуре, вплоть до отказа от термина.
Допустим, есть только сотни (тысячи?) исполнительных блоков и система шедулинга аппаратных потоков (с локальными файлами регистров, которые являются лишь проекцией участков кеша 0-го уровня) к этим выч. блокам.
(Это всё на правах фантазии, конечно)
S>Опять же, хотелось бы посмотреть. S>Хоть одним глазком — на что там Бабаяну выделили деньги.
Да, спеки Эль-22 в сети не нашлись.
Вполне возможно, что на выделенные деньги стоит доработать еще сам язык, коль они решили плясать от языка, т.е. язык становится самой ответственной частью, в которой нельзя допустить непоправимые позже ошибки. ))
Здравствуйте, vdimas, Вы писали:
V>На сегодня уже понятно, что NUMA-архитектура наиболее выгодно реализуется как набор многоядерных UMA-узлов с программируемой связью м/у узлами. V>Т.е., данные из других узлов надо забирать-отправлять явным образом.
Ну то есть вместо другого домена другой узел, просто связь не выглядит как Ethernet, Infiniband или кого там будут использовать вместо. Максимум — с контролируемым RDMA.
V>Это напоминает общение с памятью видеокартеек.
Там сама карта не очень контролирует вмешательство в её память.
Здравствуйте, vdimas, Вы писали:
N>>Я не могу себе представить, что тогда показали. Массогабаритный макет на рассыпухе?
V>На нескольких ПЛИС-ах. V>Была цель показать высокую единицу отдачи вычислений на единицу тактовой и это было убедительно показано в сравнении с тогдашними топами.
Теперь, наблюдая текущие проблемы, попробуй вычислить, где же был обман
Здравствуйте, vdimas, Вы писали:
V>В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров. V>Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность.
Так "утилизация выч. блоков" никогда не была прямой целью. А вот сократить задержки на команды в целом — да.
V>Просто, как обычно, оно проскакивало не в топах по техпроцессу и не в самых популярных де-факто архитектурах. ))
Я видел в SPARC, 4 и 8. Но оно само, да, специфическое.
Здравствуйте, karbofos42, Вы писали:
k> R>И какая же особая заточка у серверных процессоров в объективной реальности, кроме кучи ядер и кеша, которые просто не нужны в десктопах и ноутбуках? Вроде, никто не перекраивает архитектуру проца, чтобы оно в бизнес-задачах заиграло, неправда ли?
k> т.е. x86 за 20 лет не менялась, архитектура осталась такой же, как была?
А причем здесь это? Речь же о том, что в эпиках используется та же самая микроархитектура (зен), что и в десктопных и мобильных рязанях. Сделали чип из нескольких чиплетов и вот тебе серверный проц. Никто никакие числодробильные заточки не делает.
k> R>Так VLIW и сдулся, раз они в восьмой версии намерены отойти от развития архитектуры в "традиционном ключе" (с) Трушкин. На чем ты меня подловить пытаешься, я не пойму
k> т.е. теперь всё же уже сдулся? А то в предыдущем сообщении было "И если, таки, впендюрят его в восьмую версию, это и будет означать слив VLIW, на которую они наяривали все эти годы.". k> Я тебя не пытаюсь подловить, а прямо спрашиваю, но ты в новом сообщении противоречишь себе же из предыдущего сообщения.
Нет никаких противоречий. Я сразу сказал: VLIW сдулся. Могу конкретизировать: VLIW от МЦСТ сдулся. Почему сдулся? Потому что: "в восьмой версии намерены отойти от развития архитектуры в "традиционном ключе" (с) Трушкин." Следование в традиционном ключе не вывозит бизнес-задач — сдулся. Теперь о "И если, таки, впендюрят его в восьмую версию, это и будет означать слив VLIW". Использована аккуратная формулировка "если, таки, впендюрят", т.к. ты постоянно пруфов хочешь, а я, как уже сказал, не могу найти то видео. Так понятно? Или еще вопросы есть относительно сдулся/не сдулся?
k> R>Сколько интелу потребовалось времени, чтобы признать, что итаниум тупик? Немного, прямо скажем. Разработки свернули, производство продолжили в рамках долгосрочных контрактов.
k> Начали работу с HP над архитектурой в 1994 году. Последнюю линейку процессоров выпустили в 2017. Производство завершили в 2020. Ну, совсем немного времени.
Не-не, кто же так считает? Считать нужно не с момента разработки, а с момента первых коммерческих применений (когда, собственно, и можно получить первые объективные данные) и до момента принятия решения о сворачивании программы разработки (а не производства), а это получается: 2001 и 2017 годы соответственно. Предполагаю, решение о сворачивании было принято еще раньше, просто были обязательства перед HP. Итого, 16 лет. И это при том, что у них небыло примера неудачного применения VLIW.
k> Да и там вопрос в причинах сворачивания линейки. Не было бы AMD с их x86-64, до сих пор наверняка выпускали и нахваливали.
Ну так правильно, интел же не упертые бараны. Посмотрели, сделали выводы. Всем бы так.
k> R>В этой архитектуре не решаются. Неужели все еще не понятно?
k> Потому что ты так сказал?
Потмоу что все, кто пробовал не смогли.
k> R>Вероятно улучшат.
k> Так же как в x86 добавляли всякие SSE инструкции и т.п.
Это совсем разные вещи. SIMD (и даже последний APX) это просто расширение системы команд. Если софт его не использует — никаких бонусов от его наличия не получает. OoO, как функциональный блок, обеспечивает буст любому софту.
k> Нужно то, что сами смогут развивать и поддерживать. Были альтернативы 5 лет назад или 10 лет назад или сегодня может есть уже?
ARM, MIPS Бери и делай. Байкал же делают на арме, и потребительские и серверные камни. Сейчас вот риск-пять появился, вообще идеальный вариант для нас, кмк
k> R>Делают на пятом риске. У него, говорят, с производительностью "скриптов" все в порядке.
k> Кто делает? Опять пруфов не будет?
N>>Не понял. Кодогенератор в jit-ах всегда исполняется на целевой архитектуре, если исключить NUMA сценарии, типа GPU. V>Ну а я про кросс-компиляцию.
И какое она имеет отношение к предложеному подтопику "vliw on jit/pgo"?
С честным OoO это не нужно.
)
