Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, karbofos42, Вы писали:
K>>Сколько сотен миллиардов долларов было вгрохано в Эльбрус, чтобы с него хотеть своё производство и конкуренцию с Intel? S>Дело не в том, сколько миллиардов. Даже если прямо сейчас правительство России единомоментно выделит Бабаяну триллион долларов в рублёвом эквиваленте, это не приведёт по мановению волшебной палочки к появлению 3nm-чипов.
с такой логикой можно ничего не делать и сразу сдаться.
Когда-то СССР был лидером в космических запусках, с такой же перспективой догоняния его для других стран, но как видим догоняют и обгоняют.
Да это не быстро, если начать делать и даже всё правильно делать, то результат не через год будет.
Ее когда-то придумали, чтобы лучше распараллеливать вычисления. На бумаге идея была интересная. Процессор поддерживал очень длинные инструкции, которые могли выполняться за один так процессора. Они соответствовали нескольким инструкциям CISC и еще большему количеству инструкциям RISC. А придумывать эти инструкции должен был оптимизирующий компилятор. Но практика показала, что создать универсальный компилятор способный любую программу автоматически оптимизировать для VLIW-процессора не получается. Приходится тратить очень много усилий разработчиков чтобы оптимизировать программу вручную. В итоге RISC и CISC процессоры научились переупорядочивать инструкции на лету (а CISC еще и расщеплять их на более простые) и в итоге современные CISC процессоры рвут VLIW-как Тузик грелку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Все же VLIW-подобные камни не вошли в мейнстрим больше из-за нежелания потребителей иметь головняк с совместимостью.
x86/x64 очень-очень крепко держит/держал потребителя за яйца. Разговоры про ARM сервера идут уже больше 10 лет, а таковых до сих пор — кот наплакал.
Из-за этого на 99% провалилась IA64, а не из-за проблем с компилятором.
VD>В итоге RISC и CISC процессоры научились переупорядочивать инструкции на лету (а CISC еще и расщеплять их на более простые)
Ну вот эту логику вполне разумно перенести на компилятор. И энергопотребление улучшается и процессор упрощается очень очень серьезно.
Плюс надо принять за аксиому что Российским производителям никогда не были и не будут доступны топовые тех процессы и выезжать на гигагерцах не получится.
Современному реальному серверу производительность процессора далеко не первостепенный параметр.
Если есть возможность по цене условно одного 1.5ГГц купить 3 но на 500МГц и при этом другие параметры (энергопотребление/тепловыделение) будут лучше, то такой камень вполне сможет конкурировать.
Плюс сейчас, в эпоху managed платформ, проблема совместимости с железом стоит не так остро. И запрыгнуть хотя бы на серверный рынок новым архитектурам вполне реально.
В общем я бы не называл подход Эльбруса совсем уж мертворожденным.
S>Ну вот эту логику вполне разумно перенести на компилятор. И энергопотребление улучшается и процессор упрощается очень очень серьезно.
Так думали 20+ лет назад.
S>Плюс надо принять за аксиому что Российским производителям никогда не были и не будут доступны топовые тех процессы и выезжать на гигагерцах не получится. S>Современному реальному серверу производительность процессора далеко не первостепенный параметр. S>Если есть возможность по цене условно одного 1.5ГГц купить 3 но на 500МГц и при этом другие параметры (энергопотребление/тепловыделение) будут лучше, то такой камень вполне сможет конкурировать.
Эмм, теплоэффективность — и есть тот параметр, по которому современные процы в топе.
Если посмотреть на историю того же интела, то ГГЦ они особо не добавляют. А вот операций в секунду на каждый ватт производят всё больше и больше.
Так что у нас вместо одного 1.5 ГГц процессора будет три по 500МГц, с суммарным энергопотреблением в шесть раз выше, чем у того одного. А цена определяется объёмами — чтобы иметь сопоставимую цену, нужно продававть очень много кристаллов.
S>Плюс сейчас, в эпоху managed платформ, проблема совместимости с железом стоит не так остро. И запрыгнуть хотя бы на серверный рынок новым архитектурам вполне реально. S>В общем я бы не называл подход Эльбруса совсем уж мертворожденным.
Для того, чтобы это работало, нужно копать в сторону того самого компилятора. Intel, к примеру, не потянула. Это не означает 100% тупика, но тот мааахонький шанс на написание компилятора, который будет оптимизировать программу под VLIW эффективнее, чем интеловский out-of-order execution на CISC конвееере, требует офигенных усилий.
Не обязательно эти усилия должны выражаться в миллиардах юаней. Как это правильно делать — вполне известно:
1. Открываем архитектуру, публикуем эмулятор
2. Раздаём младшие модели в учебные заведения — бесплатно либо по себестоимости
3. Открываем код компиляторов
4. Готовим учебный курс "особенность компиляции под VLIW архитектуру"
5. Проводим конкурсы и соревнования:
— по доработке компиляторов JVM и .Net под Эльбрус
— по разработке новых языков, более дружелюбных к этой архитектуре
— по написанию софта под эту архитектуру.
Когда у нас будет 10-20 тысяч специалистов по компиляции под VLIW, несколько тысяч статей в научных журналах (и контрибуций в открытые проекты) — вот тогда мы, возможно, и взлетим.
Пока что ничего из этого я в реальности не наблюдаю. Стало быть, никто на уровне хотя бы министерств в Эльбрусе ничего, кроме распилочного проекта, не видит. И очень жаль.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Для того, чтобы это работало, нужно копать в сторону того самого компилятора. Intel, к примеру, не потянула. Это не означает 100% тупика, но тот мааахонький шанс на написание компилятора, который будет оптимизировать программу под VLIW эффективнее, чем интеловский out-of-order execution на CISC конвееере, требует офигенных усилий.
Ну тут прям противоречие. По сути "интеловский out-of-order execution" это и есть тот самый "оптимизирующий компиятор", но реализованный в железе.
Т.е. Intel (и далеко не только Intel уже) его таки "потянула".
Причем он жрет энергию, место на кристалле причем постоянно и, сдается мне, намного сложнее в реализации чем аналогичный, но софтовый.
Вот за счет экономии этой энергии плюс еще явный кэш можно теоретически предложить больше флопсов на ватт.
Насчет "неправильной политики партии" — согласен. Но мы тут все же обсуждаем "тупиковость" VLIW, а не отдельного проекта.
Здравствуйте, syrompe, Вы писали:
s> Ну тут прям противоречие. По сути "интеловский out-of-order execution" это и есть тот самый "оптимизирующий компиятор", но реализованный в железе. s> Т.е. Intel (и далеко не только Intel уже) его таки "потянула".
Для x86 понятнула, а с IA-64, та что Itanium, не шмогла.
s> Насчет "неправильной политики партии" — согласен. Но мы тут все же обсуждаем "тупиковость" VLIW, а не отдельного проекта.
Штеуд слила итаниум, не получился у них влив общего назначения.
Здравствуйте, syrompe, Вы писали: S>Ну тут прям противоречие. По сути "интеловский out-of-order execution" это и есть тот самый "оптимизирующий компиятор", но реализованный в железе. S>Т.е. Intel (и далеко не только Intel уже) его таки "потянула". S>Причем он жрет энергию, место на кристалле причем постоянно и, сдается мне, намного сложнее в реализации чем аналогичный, но софтовый. S>Вот за счет экономии этой энергии плюс еще явный кэш можно теоретически предложить больше флопсов на ватт.
Нет тут никакого противоречия. Мы на этом же форуме какое-то время назад это обсуждали — оказывается, банальное предсказание переходов выполнить в CPU, опираясь на рантайм статистику, на порядок проще, чем в компиляторе.
То же самое с out of order. Компилятору придётся делать массу предположений об относительных таймингах команд и о загрузке вычислительных юнитов.
У процессора вся эта информация расположена "прямо здесь".
Да, это тратит энергию, но область хорошо исследована и достигнуты отличные результаты.
Я не говорю, что добиться того же на уровне компилятора вовсе невозможно, но в это тупо вложено гораздо меньше человеко-часов.
Чтобы это починить, нужно по-прежнему вложить миллион человеко-часов. И тут два варианта: либо оценить стоимость покупки этого времени, и отказаться от проекта по причине "столько денег нам взять негде", либо привлечь комьюнити.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, syrompe, Вы писали:
S>Ну тут прям противоречие. По сути "интеловский out-of-order execution" это и есть тот самый "оптимизирующий компиятор", но реализованный в железе.
Увы, но нет. Подход VLIW — он статический, компилятор все должен предсказать все заранее, в лучшем случае на базе PGO. А вот железный транслятор — он динамический, опирается на статистику реального выполнения.
НС>Увы, но нет. Подход VLIW — он статический, компилятор все должен предсказать все заранее, в лучшем случае на базе PGO. А вот железный транслятор — он динамический, опирается на статистику реального выполнения.
ИМХО эффективнее всего это отдать разработчику. В С завезли likely/unlikely в виде макросов. В C# кстати такого вроде нету.
Опять же даже с Интеловским подходом есть такая штука как профилирование. А с компиляторной оптимизацией профайлер просто может выдать рекомендации по модификации кода.
Здравствуйте, syrompe, Вы писали:
НС>>Увы, но нет. Подход VLIW — он статический, компилятор все должен предсказать все заранее, в лучшем случае на базе PGO. А вот железный транслятор — он динамический, опирается на статистику реального выполнения. S>ИМХО эффективнее всего это отдать разработчику.
Каким образом? Если сделать возможность писать код трансляции на том же коде — он пролетит по эффективности, так как соберет все накладные раскоды с внешней памятью и штатными блоками трансляции. А если разрешить самому писать микрокод, то это резко усложнит рефакторинг кристалла из-за необходимости поддержки совместимости.
Микрокод, кстати, и в интелях можно обновлять. Но доступа сторонним разработчикам к сей фиче нет.
НС>Т.е. оставаясь в статическом контексте. ЧТД.
Ок. Принимается.
Но и статическая оптимизация может закрывать большую часть случаев. Миллионы проверок на null входных параметров тому пример.
Здравствуйте, Sinclair, Вы писали:
S>Когда у нас будет 10-20 тысяч специалистов по компиляции под VLIW, несколько тысяч статей в научных журналах (и контрибуций в открытые проекты) — вот тогда мы, возможно, и взлетим.
Именно специалистов, а не программистов? Откуда такая цифра, почему не с десяток, край сотню, специалистов? Почему тысячи статей, а не сотня?
Здравствуйте, Sharov, Вы писали: S>Именно специалистов, а не программистов?
Нужны и те и другие. Программисты, как правило, народ достаточно простой и сермяжный. Они алгоритмиев не изобретают, а берут готовые из книжечки. Или, скажем, из статьи. S>Откуда такая цифра, почему не с десяток, край сотню, специалистов? Почему тысячи статей, а не сотня?
Потому что КПД очень низкий. Чтобы получился какой-нибудь учебник типа того же Танненбаума, должно выйти несколько сотен статей, и несколько десятков монографий и обзоров.
Понимаете, одна статья — это одно очень узкое и специфичное исследование.
Возьмём, к примеру, ускорение разбора XML.
Берёт группа исследователей и пишет статью типа "ускорение коммерческого парсера XML при помощи SIMD и многоядерных технологий". Статья, естественно, не пионерская — посмотрите на список литературы. Там и Исследование применения SIMD для параллельных битовых потоков: перекодировка UTF-8 в UTF-16, и "Ускорение разбора XML при помощи Потоковых Расширений 4 Intel SIMD", и ещё дофига всего.
Результат, без сомнения, достойный — реальный парсинг разогнан в 2-3 раза в зависимости от плотности разметки.
Но это — всего лишь одна узкая задача по оптимизации одной библиотеки, хоть и под достаточно широкий набор процессоров.
Чтобы у вас получился компилятор, который способен эффективно загружать VLIW-процессор на широком классе задач, нужно несколько десятков-сотен вот таких вот "контрибуций". Которые существуют не в вакууме, а стоят на плечах пары десятков предыдущих работ в похожих областях.
Вот и получаем тысячи статей, как минимум.
И никакой десяток специалистов, и даже сотня, эти статьи не напишут. Тупо потому, что каждая статья — это не просто 20 страниц текста написать, это исследования, пробы, ошибки, откаты, повторы.
Так устроена наука — никакую область вперёд десятком человек не двинешь. Даже десяток команд, работающих параллельно, одновременно конкурируя и сотрудничая, такую огромную тему не потащат.
Это же не просто "о, давайте реализуем БПФ на Эльбрусе и посмотрим, насколько мало он отстал от Intel Atom". Это с десяток попыток наиболее эффективно реализовать БПФ.
Потом кто-то играет с разрядностью float32/float64, кто-то — с расположением комплексных чисел "вперемешку" и "вразбивку". Кто-то учится матрицы умножать.
Кто-то пилит аналог автовекторизации, который находит в циклах на С фрагменты вроде z[i] = x[i]*y[i]; w[i] = x[i]+y[i] и придумывает "автовекторизацию" со склеиванием команд в одну VLIW-команду.
Кто-то потом обобщает это для JIT жавы. Кто-то пишет библиотеки для питона с использованием этого трюка.
Кто-то изобретает новые, уникальные библиотеки для какого-нибудь питона или сишарп, которые позволяют записывать WLIV-инструкции прямо на языке высокого уровня, типа (z[i], w[i]) = WLIV(x[i]*y[i], x[i]+y[i]);
Кто-то потом на это смотрит, и выпиливает всякие безумные вещи типа "оптимальное представление объектов в JS для VLIW архитектуры".
Кто-то потом портирует результаты этого обратно в С++.
Кто-то разрабатывает тулчейн, который показывает качество кода, выдаваемого компилятором, без запуска бенчмарков.
Это не семь команд, это сотня команд, и каждое направление копают две-три команды, которые смотрят друг на друга, читают и рецензируют статьи друг друга, и т.д.
Главное — ни для чего из этого невозможно построить заранее план. Никакой интел не планировал, что AVX512 будут применять для разбора JSON. И даже если бы планировал, то честное финансирование группы, которая бы этим занималась, сожрало бы безумный бюджет. Потому что очень много бывает бесплодных попыток и тупиковых идей.
Научная среда — она совсем другая, чем промышленная. Вот приходят в бакалавреат, магистратуру и аспирантуру люди, и думают — чем бы им таким заняться, чтобы в дипломе было не стыдно показать.
Это десятки тысяч человек ежегодно. Казалось бы — вот оно! Какой-нибудь Хуавей с Яндексом ежегодно устраивают стипендиальные конкурсы на интересующие их темы. ДжетБрейнс много сотрудничал с университетами.
В итоге, кто-то с моего потока развлекался оптимизациями с устранением временных объектов в Котлин; кто-то — оптимизациями вычислительных задач на С (для OpenMP), кто-то — всякими нейросетевыми штуками.
Дай людям возможность — у тебя будут через десять лет все эти десятки тысяч статей про VLIW-компиляцию.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, syrompe, Вы писали:
НС>>Каким образом? S>Расширением языка. S>Как минимум уже сейчас есть: S>
S>if (likely(!err))
S>{
S>}
S>
S>
S>if (unlikely(err))
S>{
S>}
S>
На предсказатель переходов в процессоре это никак не повлияет. Может быть, если очень повезет, оптимизатор в компиляторе сможет переупорядочить код, чтобы несколько likely блоков кода были рядом и поместились в кэш инструкций.
По-моему мнению, эта ручная likely/unlikely разметка бесполезна. Ну разве что показать свою крутость коллегам, типа "смотрите, я могу писать очень оптимизированный код, верьте мне". По крайней мере, код c likely (aka __builtin_expect) который я видел, всегда шел без бенчмарков/результатов профайлера.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>>Именно специалистов, а не программистов? S>Нужны и те и другие. Программисты, как правило, народ достаточно простой и сермяжный. Они алгоритмиев не изобретают, а берут готовые из книжечки. Или, скажем, из статьи. S>>Откуда такая цифра, почему не с десяток, край сотню, специалистов? Почему тысячи статей, а не сотня? S>Потому что КПД очень низкий. Чтобы получился какой-нибудь учебник типа того же Танненбаума, должно выйти несколько сотен статей, и несколько десятков монографий и обзоров. S>Понимаете, одна статья — это одно очень узкое и специфичное исследование. S>Возьмём, к примеру, ускорение разбора XML. S>Берёт группа исследователей и пишет статью типа "ускорение коммерческого парсера XML при помощи SIMD и многоядерных технологий". Статья, естественно, не пионерская — посмотрите на список литературы. Там и Исследование применения SIMD для параллельных битовых потоков: перекодировка UTF-8 в UTF-16, и "Ускорение разбора XML при помощи Потоковых Расширений 4 Intel SIMD", и ещё дофига всего. S>Результат, без сомнения, достойный — реальный парсинг разогнан в 2-3 раза в зависимости от плотности разметки. S>Но это — всего лишь одна узкая задача по оптимизации одной библиотеки, хоть и под достаточно широкий набор процессоров.
S>Чтобы у вас получился компилятор, который способен эффективно загружать VLIW-процессор на широком классе задач, нужно несколько десятков-сотен вот таких вот "контрибуций". Которые существуют не в вакууме, а стоят на плечах пары десятков предыдущих работ в похожих областях. S>Вот и получаем тысячи статей, как минимум.
S>И никакой десяток специалистов, и даже сотня, эти статьи не напишут. Тупо потому, что каждая статья — это не просто 20 страниц текста написать, это исследования, пробы, ошибки, откаты, повторы. S>Так устроена наука — никакую область вперёд десятком человек не двинешь. Даже десяток команд, работающих параллельно, одновременно конкурируя и сотрудничая, такую огромную тему не потащат. S>Это же не просто "о, давайте реализуем БПФ на Эльбрусе и посмотрим, насколько мало он отстал от Intel Atom". Это с десяток попыток наиболее эффективно реализовать БПФ. S>Потом кто-то играет с разрядностью float32/float64, кто-то — с расположением комплексных чисел "вперемешку" и "вразбивку". Кто-то учится матрицы умножать. S>Кто-то пилит аналог автовекторизации, который находит в циклах на С фрагменты вроде z[i] = x[i]*y[i]; w[i] = x[i]+y[i] и придумывает "автовекторизацию" со склеиванием команд в одну VLIW-команду. S>Кто-то потом обобщает это для JIT жавы. Кто-то пишет библиотеки для питона с использованием этого трюка. S>Кто-то изобретает новые, уникальные библиотеки для какого-нибудь питона или сишарп, которые позволяют записывать WLIV-инструкции прямо на языке высокого уровня, типа (z[i], w[i]) = WLIV(x[i]*y[i], x[i]+y[i]); S>Кто-то потом на это смотрит, и выпиливает всякие безумные вещи типа "оптимальное представление объектов в JS для VLIW архитектуры". S>Кто-то потом портирует результаты этого обратно в С++. S>Кто-то разрабатывает тулчейн, который показывает качество кода, выдаваемого компилятором, без запуска бенчмарков. S>Это не семь команд, это сотня команд, и каждое направление копают две-три команды, которые смотрят друг на друга, читают и рецензируют статьи друг друга, и т.д.
Опять же, сотня команд -- как минимум один-два человека в каждом тех. вузе + студенты\аспиранты (всего 2-3 человека), в каждой крупной компании по такому спецу.
Ну вот мы получим сотню специалостов, в это я поверю. Но зачем и откуда тыщи? А как тот-же Танненбаума смог бы продраться через такое кол-ов работ и монографий?
А сколько среди этого многоообразия будет шума, плагиата или банально люди будут друг друга добулировать случайно? Я не знаток научного метода в информатике но вот в целесообразности
тысяч спецов (именно спецов!) сомневаюсь. Хотя бы из-за шума. Т.е. из сотен отберутся десятки их и будет читать и цитировать условный Танненбаум. Как-то так.
Думаю, что в штатах специалистов по С компилятору пару сотен, край 400 человек. Т.е. все равно отберется небольшое кол-во людей.
S>Дай людям возможность — у тебя будут через десять лет все эти десятки тысяч статей про VLIW-компиляцию.
1) Не уверен;
2)даже если итак, то каково будет качество большниства работ при таком кол-ве?
PM>На предсказатель переходов в процессоре это никак не повлияет. Может быть, если очень повезет, оптимизатор в компиляторе сможет переупорядочить код, чтобы несколько likely блоков кода были рядом и поместились в кэш инструкций.
не повлияет на предсказатель переходов Интела.
Для других процессоров может быть сгенерирован другой код, если процессор поддерживает.
Это код из ядра Линукс насколько я понимаю, а он под разные процессоры компилируется.
Здравствуйте, Sharov, Вы писали:
S>Опять же, сотня команд -- как минимум один-два человека в каждом тех. вузе + студенты\аспиранты (всего 2-3 человека), в каждой крупной компании по такому спецу.
Всего-то. S>Ну вот мы получим сотню специалостов, в это я поверю. Но зачем и откуда тыщи?
А вы думаете, что все 10000 будут статьи писать и принципиально новые методы компиляции изучать? Как обычно — 10к пойдут код педалить, из них 2-3% будут заниматься какими-то инновациями. S>А как тот-же Танненбаума смог бы продраться через такое кол-ов работ и монографий?
Почему "бы"? Посмотрите список литературы в конце Танненбаума. Причём он-то опирался не на первоисточники, а на уже кем-то сделанные выжимки. S>А сколько среди этого многоообразия будет шума, плагиата или банально люди будут друг друга добулировать случайно?
Вот именно! Я об этом не упомянул — но так и есть: вот в той статье про XML пара десятков ссылок. А сколько было статей, на которые никто так и не сослался? S>Я не знаток научного метода в информатике но вот в целесообразности S>тысяч спецов (именно спецов!) сомневаюсь. Хотя бы из-за шума. Т.е. из сотен отберутся десятки их и будет читать и цитировать условный Танненбаум. Как-то так.
Из тысяч отберутся сотни, которые будут писать. Из них — считанные проценты напишут что-то такое, что можно будет потом использовать. S>Думаю, что в штатах специалистов по С компилятору пару сотен, край 400 человек. Т.е. все равно отберется небольшое кол-во людей.
Вы, наверное, смеётесь. Ежегодно в тех же штатах выпускаются десятки тысяч людей, которые проходят курсы "разработка компиляторов". Из них процентов 10 разбираются во внутреннем устройстве реального компилятора С.
Десятки тысяч людей заканчивают курсы по интеловской архитектуре. Из них процентов 10% разбираются в ассемблере и понимают, какие конструкции компилятора превращаются в какие инструкции процессора.
Из этих 10% примерно 2% интересуются вопросами оптимизации компилятора. Так происходит пополнение этого пула в несколько сот человек, кто может реально контрибутить в компилятор.
Если вы обучите 200 человек VLIW-архитектуре, то из них тоже "отберётся" 0.2%. То есть 0, что мы сейчас и наблюдаем.
S>>Дай людям возможность — у тебя будут через десять лет все эти десятки тысяч статей про VLIW-компиляцию.
S>1) Не уверен; S>2)даже если итак, то каково будет качество большниства работ при таком кол-ве?
Качество большинства работ не зависит от количества. В любом случае 80% — это шлак. Именно поэтому нам нужны десятки тысяч статей, чтобы достичь реального прогресса.
Мы не знаем заранее, какие из статей окажутся полезными и насколько.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
