Сравнение производительности Эльбрус-8С с Intel и AMD

Архитектура даёт то что даёт, ОС контролирует что контролирует.

Что за общие высказывания уровня религиозных форумов?

Ну что, клован?

------

Читайте Выше. И срочно в библиотеку! Это к архитектуре и к процессорам не относится!

Я про архитектуру процессоров Эльбруса. А то будете тут ещё примеры CISC и RISC процессоров AMD и Intel приводить в пример.

Это относится к уязвимостям процессоров. Нет никаких гарантий, что аналогичной уязвимости не может быть на эльбрусе.

25(33)

Да, но у x86 IPC =/= ILP.
Плюс кэш декодированных инструкций. Так что показатель не сильно ниже, чем у vliw.

Под частичными нагрузками мелкие ядра тоже более эффективны.
Там интел хочет 1 жирное ядро + 4 некстген атома ставить в проц.

1 жирное ядро

Мало. Сейчас уже небось наберётся 2-4 потока каждый из которых загрузит одно ядро на 100%.

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

А на мобилах небось на быстром ядре запущен эксклюзивно гуй, а всё остальное там в фоне пропёрдыватся как может на медленных ядрах.

Жду. Очень жду.

Потоки чаще всего постоянно синхронизируются друг с другом

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

Ты не знаешь, что Embarrassingly Parallel задачи настолько редки, что на Embarrassingly Parallel специально под них заточенной видеокарте у тебя работает только гуй и только частично? Ну может ещё майнер.

Я занимаюсь определенной областью, про которую я вроде писал в этом треде (ML ещё раз для особо одарённых), в которой у меня таких задач хоть жопой жуй. Проблемы формошлепов и классических софтварных решений мне как-то по боку.

Машинное обучение? Ну вот когда весь софт переделаешь под нейросеточки, тогда придёшь и будешь напыщенно тут всех называть говнокодерами.

А я не называю говнокодерами всех. А только тех, кто не понимает, когда у него задача позволяет не постоянно синхронизироваться, а когда не позволяет.

ракетными ЦЕЛЯМИ

это что такое за ракетные цели?! прямо глаза режет такая фраза многие алгоритмы не параллелятся в принципе. например - рекуррентные. для таких алгоритмов кол-во ядер/потоков не играет никакой роли, важна скорость на одном ядре. нет никакого смысла в 264 каналах если система не успевает обрабатывать информацию и у вас постоянно идет срыв сопровождения по всем этим 264 каналам.

В этом и фишка, что это не какой-то там гипертрединг или разные частоты на ядрах. Всё работает параллельно. Если те же общие регистры, в общем архитектура удивительная. Проблема в том, что многие сравнивают её с х86, потому что на Эльбрусе можно запустить приложения х86, как я выше постил два сообщения.

Вы, очевидно, не прочитали мое сообщение, либо сделали вид. Есть обширный класс задач, где важна именно производительность ядра, а их количество не имеет значение. В этих задачах не важно, сколько вы можете обрабатывать команд одновременно, важно как быстро вы обработаете одну команду.

Тут надо, чтобы были разработчики именно под архитектуру Эльбруса, тогда и будет полная отдача.

Это справедливо, в общем-то, для всех архитектур. Но если у вас задача не параллелится, то это тоже бесполезно.