Комментарии 35
Попытался оптимизировать работу в формате Q4_0 для e2k процессоров с 5-й и выше версией системы команд (для тех которые с 128-ми битными регистрами), выкладываю сюда: https://github.com/E2Kports/llama.cpp
Именно в этом формате проверят умножение матриц бенчмарк. А вот используемая в статье модель сконвертирована под Q4_1, на ней ускорения ждать не стоит. Нужно брать модели в Q4_0, либо подождать пока доработаю и этот формат.
А вообще, проект llama.cpp ну очень уж быстро меняется - пришлось пару раз под новые правки подстраиваться...
Я за Эльбрусами слежу очень поверхностно...
Но вот быстрый гуглеж про 16С показал, что камень еще не вышел: http://mcst.ru/elbrus-16s ("ведётся подготовка серийного производства в 2022 году").
Вы его как тестировали?
Если идет оценка архитектуры, то, результаты следует отнормировать на MHz, как это делают например с тем же CoreMark. т.е. результат должен быть (ms / поток)/MHz
Отредактировал. Но я бы не сказал что это именно тест архитектуры, скорее это просто тестпо типу "А заработает ли?". На данный момент хочется оптимизировать ggml для Эльбруса, если есть интерес можете помочь всегда готов к сотрудничеству
Но я бы не сказал что это именно тест архитектуры
Если это так, то какой смысл в результатах Ryzen'а с даунклоком? Вы же понимаете, что процессор это законченное изделие и вы не получите Эльбруса-16С с частотами Ryzen 5800H? Да и 1.3 ГГц для Zen 3 не соответствует ни одной из моделей, даже включая Ryzen Embedded V3000 (там у V3C18I 1.9 ГГц базовой частоты, у всех остальных выше)
Да, понимаю. Просто пока не получилось Ryzen до 2ГГц опустить. Это будет сделано позже и я обновлю таблицу и тесты.
Ryzen до 2ГГц опустить.
Так а зачем это вообще делать? Вы все равно не увидите вживую Ryzen с фиксированной частотой 2 ГГц (даже у Embedded это All Core Clock, но на одном ядре будет больше)
Вы ж сами говорите, что вам архитектурная скорость (на МГц) не интересна, а если так, то нет никакого смысла в этих извращениях с частотами.
Вам ниже тоже самое другими словами говорят.
Зачем? Что нам покажет этот фактор? Частота не ниспослана свыше, она часть архитектуры. Одна система работает с меньшей частотой, но больше умеет на такт, другая меньше...
Я понимаю сравнение ms на ватт. Или ms на рыночную стоимость компа. Но почему ms на MHz?
Частота определяется техпроцессом. Надо смотреть не сколько тактов в секунду, а просто - сколько тактов. Вот смотрите если взять coremark:
Pentium IV 3.00GHz, Coremarks 5007.1, Coremark/Mhz: 1.6731
Pentium 100MHz, Coremarks 213.83, Coremark/Mhz: 2.138
Да, PIV за счет тактовой выигрывает, но Pentium за счет архитектуры тратит на одну итерацию в полтора раза меньше тактов, чем Pentium 4, соответственно его архитектура лучше.
И то же самое можно сказать и про 8СВ vs Ryzen 7: Разница в частоте в два раза, но если считать в количестве затрачиваемых тактов, то процентов 40%. И тогда мы действительно увидим - а умеет ли одна система больше за такт чем другая.
Нужно ещё учитывать скорость доступа в память/кеш. Ну и в P IV появились инструкции SSE2.
Частота определяется техпроцессом.
Не совсем - частота определяется множеством факторов: техпроцессом, длиной критического пути в архитектуре, целевым энергопотреблением и т.п.
Вы привели пример с 4-ым пнем на 3 ГГц - такая частота там достигалась на техпроцессе в 130 нм, но при этом же у Pentium III Tualatin на тех же 130 нм частоты были далеки от 3 ГГц (1.4 у последнего серийного).
но Pentium за счет архитектуры тратит на одну итерацию в полтора раза меньше тактов, чем Pentium 4, соответственно его архитектура лучше.
Во-первых, по одному тесту делать вывод некорректно.
Во-вторых - Pentium не будет работать на частоте в 3 ГГц, если его сделать по 130нм техпроцессу (см. Atom N270 - он правда на 45нм, но зато близок к первому Pentium'у архитектурно).
Рассматривать эффективность архитектуры (как раз таки сколько тактов уходит на ту или иную операцию) не имеет особого практического смысла, это интересно сугубо с точки зрения академической - например при изначальном исследовании архитектуры или чтобы получить инструмент прогнозирования, если архитектура в принципе разгоняется (или тормозится) до каких-то других частот. И ровно поэтому для этих целей используют наборы тестов - например SPEC и CoreMark.
Частота определяется техпроцессом и микроархитектурой. Как разобьют долгие операции на куски, такая и будет частота. Можно намельчить и сделать конвейер на 20 стадий, зато поднять частоту повыше, как у P4, а можно — наоборот.
Собственно комментарии те же самые. Про нормирование про частоту я тебе давно говорил, а про Crystal Mark - совершенно непонятно что конкретно он меряет, поэтому что говорят его попугаи - тоже не ясно. Без этого совершенно непонятно что попугаи в нем дают на практике.
Плюс ко всему:
The result of CrystalMark 2004R7 is not compatible with CrystalMark 2004/R2/R3.
CrystalMark 2004R7 is a 32bit total benchmark software.
тратит на одну итерацию в полтора раза меньше тактов, ... соответственно его архитектура лучше.
Вот тут не понимаю логики. Почему лучше? Какая на выходе разница, сколько система умеет за такт? Пользователь не расходует такты, он расходует ватты, секунды и бабки.
Там же внутри ggml (которая используется в Alpaca) есть вагон использования векторных расширений, как они транслируются в VLIW? Используются ли они? По хорошему надо бы в нативный код портировать это и потом сравнивать.
Да, это и хочу сделать. Пока разбираюсь как это в натив закинуть. Если все пройдет успешно будут еще тесты. На данный момент это грубо говоря тест "из коробки" с минимальным вмешательством
Здесь на Хабре есть статья от @SmartEngines "Низкоуровневая оптимизация кода на платформе Эльбрус". Эльбрус-8СВ и 16С поддерживают уже векторные операции с регистром 128 бит. Также для процессоров Эльбрус имеется высокопроизводительная библиотека EML, функции из которой можно использовать для оптимизации.
Один из плюсов VLIW и Эльбруса в том, что векторные интрисинки(SSE/AVX) достаточно напрямую транслируются в систему комманд, и их "реализация" поставляется с компилятором. В результате "векторный код" довольно не плохо компилируется по производительности.
А если код изначально хорошо оптимизирован под SSE/AVX, то улучшить перформанс под эльбрусы не получится?
Если переписать нативно под e2k, улучшить скорее всего можно, вопрос насколько. Вообще нейросетки с минимум ветвлений, должны относительно хорошо ложиться на VLIW.
Для эльбруса недостаточно просто упаковать операции в одну avx/sse инструкцию.
Ему надо полностью оптимизировать функции/процедуры на которые приходится большая часть времени работы. Оптимизации заключаются в том что надо подсказать компилятору вещи, которые не очевидны из кода - типичное количество итераций в том или ином цикле, могут ли пересекаться указатели, выравнены ли данные итп.
В общем надо уметь читать ассемблер е2к, смотреть что генерирует компилятор и все ли возможности он в том или ином случае использовал.
Чувствую, что отхвачу минусов, но таки вот. Очередная попытка натянуть сову на глобус. Типа вот наш проц (который печатался на Тайване и уже не печатается и в обозримом будущем не будет) что-то может в несколько раз медленнее чем человеческий камень. Отставание в 10 - 15 лет по производительности никуда не денется какие тесты не гонять. Единственный путь - дружить с цивилизацией и совместно что-то делать полезное (как пример - МКС и проект термоядерного реактора ITER). Надеюсь, что будет реально чем хвастать скоро, а не выжимать из воздуха сравнительные статьи где фактически несуществующий в продакшне проц с чем-то лежащим на полках сравнивается.
Рязань производится на том же самом TSMC.
А в ближайшем десятилетии возможно сможет производится в одном из штатов, так как у "цивилизации" если чего-то нет, то они не жалеют времени и денег на то чтоб у них это появилось чтоб они ни от кого не зависели. Пример - та же космонавтика где у них практически все свое появилось уже и мы им будем скоро не нужны.
Я это все к тому что быть с "цивилизацией" можно по разному, можно учится у них и делать как они (то есть стараться быть как бы ментально на одном уровне с ними), а можно быть при них служанкой - кофе приносить, туалеты на их станции чинить, соперничать с другим обслуживающим персооналом за право быть к господину ближе чем другие.
Причем большая часть элиты нашей страны строго ориентировалась на второе все время своей власти, но барину нравятся только маленькие и слабенькие, большие могучие коровы ему не нужны.
Я к тому, что есть вещи, которые можно делать и можно нагнать, а есть которые вряд ли. Опуская даже ситуацию, простой пример: в технологиях постсовок слаб, но силён например в науке типа математики. Таким образом в идеальном мире российские учёные могли бы приносить пользу при разработке и развитии технологий (к примеру ядерных, процессорных или космических), материальные части для которых (чипы, софт, коллайдера) строятся/производятся в других странах, в итоге все выигрывают, человечество движется вперёд. Технологии не будут ждать кого-то отстающего, а т.к. скачки происходят экспоненциально, то уровень отставания будет расти. Это вам не ядерное оружие испытывать, тут физика не менялась почти век, такое и Северная Корея умеет. А сейчас всё сводится у некоторых к радости если вдруг у Маска ракета не взлетит в срок как сегодня. Печально это.
можно по разному, можно учится у них и делать как они (то есть стараться быть как бы ментально на одном уровне с ними), а можно быть при них служанкой
А есть ещё два пути: можно сотрудничать с ними на равных, участвуя в международных проектах, предлагая выгодные условия для иностранного бизнеса с участием российского капитала и так далее, и можно пытаться имитировать их, отгородившись железным занавесом и клепая в своём маня-мирке поделки "по мотивам", с совершенно безнадёжными экономическими характеристиками, которые умрут сиюмоментно как только тот занавес рухнет, похоронив все вложенные в них финансовые и интеллектуальные ресурсы.
Вот из этих четырёх путей мы выбрали последний.
Поддерживаю. Стюардессу пора закопать.
Вполне ожидаемо. Любой, кто сталкивался с портированием на E2K знает, что просто скомпилировать исходники и пройти юниты еще даже далеко не пол дела, потому что производительность будет низкой.
Дальше надо вдумчиво читать гайды МЦСТ по оптимизации и профилировать. Тогда удается добиться неплохой производительности даже на старом процессоре 8C.
Собственно, обо всем этом не раз и не два говорили представители МЦСТ и аматоры E2K.
Конечно, хочется надеятся, что в будущем задачу по оптимизации можно будет возложить на компилятор с элементами ИИ.
Попытался оптимизировать работу в формате Q4_0 для e2k процессоров с 5-й и выше версией системы команд (для тех которые с 128-ми битными регистрами), выкладываю сюда: https://github.com/E2Kports/llama.cpp
Именно в этом формате проверят умножение матриц бенчмарк. А вот используемая в статье модель сконвертирована под Q4_1, на ней ускорения ждать не стоит. Нужно брать модели в Q4_0, либо подождать пока доработаю и этот формат.
А вообще, проект llama.cpp ну очень уж быстро меняется - пришлось пару раз под новые правки подстраиваться...
Большое спасибо, сегодня проверю. Да проект быстро меняется, нужно будет проводить новые тесты
Тут вообще наверное ускорения ждать не стоит так как у эльбруса только два целочисленных устройства умеют в вектора 80-128 бит, ему надо наоборот все в вещественное переводить и в них считать так как все 6 вещественных юнитов их поддерживают.
Серьезно, лучше уж просто грамотно на плюсах написать и довериться компилятору, чем делать вот такие ручные оптимизации.
От оптимизации ускорилось в два с лишним раза.
Там довольно заурядный цикл я думал компилятор его без труда автовекторизует и он его таки векторизовал, но уже без буфера подкачки.
Загоняем Альпаку на Эльбрус