История изменений

Эльбрусы стопудово не взлетят.

Это я как человек, немного сам делающий процессор скажу и обосную.

У эльбрусов есть действительно фишки очень хорошие, но они не связаны с VLIW, а вообще ортогональны ему. Это например умная предвыборка, которая бежит вперёд по программе и тупо стучит в кэш везде где находит. Тут большинство нихрена не читает по теме,

Но сам VLIW не потащит, просто потому, что он может быть в теории на «алгоритмах» типа gzip или фурье, но на практике мы используем 90% времени совсем другие программы:

вот кто пишет на Qt, дизассемблируйте кусочек любой вашей функции и увидьте это:

sub esp, N
mov [esp+X], edx
mov [esp+Y], eax
mov eax, [ebp+K]
mov [esp+Z]
call trololo1
add esp, K
mov [esp+M], eax
mov edx, [ebp+K]
mov [esp+O], edx
mov eax, [ebp+K]
mov [esp+P], eax
call trololo2

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

Второе - архитектура VLIW ну вообще никак не сможет разгоняться на таких простынях, а их множество в любом «нормальном» коде. В х86-процах такое говно давят длиннющими очередями записи и большим аппаратным стеком адресов возврата пределах 16-32 уровней вложенности и столь же хитроумными извертами в виде предсказания ветвлений и спекулятивного исполнения.

В эльбрусе ничего такого нет, поэтому на «нормальных» приложениях но обречён страдать.

Третье - когда я учился, то нашей базовой кафедрой был МЦСТ на первых двух курсах. И еще я успел там поработать. Работали там где я был студенты за миску риса. А кусок транслятора делала 218я группа то есть тоже студенты. Ну вы понели.

Эльбрусы стопудово не взлетят.

Это я как человек, немного сам делающий процессор скажу и обосную.

У эльбрусов есть действительно фишки очень хорошие, но они не связаны с VLIW, а вообще ортогональны ему. Это например умная предвыборка, которая бежит вперёд по программе и тупо стучит в кэш везде где находит. Тут большинство нихрена не читает по теме,

Но сам VLIW не потащит, просто потому, что он может быть в теории на «алгоритмах» типа gzip или фурье, но на практике мы используем 90% времени совсем другие программы:

вот кто пишет на Qt, дизассемблируйте кусочек любой вашей функции и увидьте это:

sub esp, N
mov [esp+X], edx
mov [esp+Y], eax
mov eax, [ebp+K]
mov [esp+Z]
call trololo1
add esp, K
mov [esp+M], eax
mov edx, [ebp+K]
mov [esp+O], edx
mov eax, [ebp+K]
mov [esp+P], eax
call trololo2

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

Второе - архитектура VLIW ну вообще никак не сможет разгоняться на таких простынях, а их множество в любом «нормальном» коде. В х86-процах такое говно давят длиннющими очередями записи и большим аппаратным стеком адресов возврата пределах 16-32 уровней вложенности и столь же хитроумными извертами в виде предсказания ветвлений и спекулятивного исполнения.

В эльбрусе ничего такого нет, поэтому на «нормальных» приложениях но обречён страдать.