>Там проблема в том, что он не всегда может эффективно использовать её. Поэтому, чем городить огород в микроархитектуре и тратить на это много транзисторов и энергии, проще сделать новые архитектурные расширения.
Ну вот собственно, вы и признались, что дальше уже не получается получить параллельность, приходится использовать другую систему команд.
>параллельность, которую эксплуатирует AVX512, процессор вообще говоря видит
что-то я сомневаюсь, что процессор видит на 16 инструкций вперед, да еще и налету. А если предсказатель ошибётся, сколько тогда будет стоить эта ошибка? За 1 такт же он не сможет 16 инструкций заново проанализировать.
Они умеют извлекать очень мало параллельности. К тому же, зачем ее извлекать, когда ее можно явно закодировать?
А то как-то странно получается, что мы пишем алгоритм (может даже в какой-то степени параллельный) на последовательном языке, потом процессор пытается извлечь параллелизм, и потом он же пытается заретайрить инструкции последовательно. Хотя можно было бы тут везде иметь слово "параллельно".
>микроархитектура постоянно оптимизируется каждая следующая оптимизация в среднем дает меньше прироста и стоит дороже. Висящие на нижних ветках фрукты собраны. Дальше станет только хуже.
>у вас настолько большие запросы Очень даже обычные. Ну серьезно, какому пользователю есть смысл покупать процессор процентов на 30 быстрее за немалые деньги? И от числа ядер далеко не все задачи выигрывают. Вообще рост числа ядер как раз от сложности дальше ускорять одно ядро.
Вот расскажите, какие вы видите пути существенного ускорения SSOoO процессоров?
Ой, как хорошо, что вы вспомнили AVX. Это же такие general-purpose инструкции! Еще хуже, чем VLIW ) Интересно, зачем они появились в процессорах? Может потому, что в системе команд не хватало параллелизма?
И нет, в Эльбрус гораздо меньше поводов упереться, потому что у него есть аппаратная поддержка выполнения циклов. Некая конвейеризация. Он может наслаивать итерации друг на друга.
Вот именно, за 10 лет получили 50% прироста. И какой ценой? Это говорит о том, что пора что-то менять. Например, систему команд с последовательной на явно параллельную.
Ничего себе растет. Вы помните, как росла производительность лет 20 назад? А что сейчас? Почему тогда мне особо не на что поменять процессор 10-летней давности за разумные деньги? Да даже за неразумные я получу максимум 50% прироста на ядро. И это за 10 лет? Это шутка такая? А до недавнего выхода zen 3 и этого не было. У Интел с Core 2000 где-то по Core 8000 вообще прирост был мизерный.
Некоторые специалисты вообще говорят, что график роста переломился в 2006 году (собственно, и неспециалисту это наглядно видно на графике). А второй раз году в 2011.
Ну начать може и сможет, в зависимости от того, как организован цикл. Но все равно всё встанет на инкременте переменной, потому что это зависимость между итерациями.
Вы точно не так поняли написанное или, может, вообще в теме не разбираетесь...
В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной (и то, если компилятор не раскрутит цикл, но далеко не каждый цикл можно раскрутить).
А вот при отсутствии инлайна как Эльбрус, так и Интел сильно просядут и даже в Интел вряд ли будет 1 такт.
Ну собрать x64 без JIT не удалось, в не-jit коде есть ссылки на поля структуры, которые спрятаны под макрос JIT и починить я это по-быстрому без особого знания не смог. Похоже, никто и не волнует сборка X64 без JIT. А попытки отключения JIT в рантайме кажется ни на что не влияют. Либо там ничего на самом деле не отключается, либо просто нет заметной разницы в производительности.
Основной затык был в портировании luajit хоть в каком-то виде. В остальном — подкрутили сборку, поправили макросы, поправили cpuid. Никаких оптимизаций или чего-то такого не делали. Как только стало запускаться и не вылетать — сразу стрим провели.
какой-то кривой перевод. Он же с газовыми турбинами, на керосине.
А мне непонятны старания людей, пытающихся доказать, что за CISC/RISC будущее. Когда уже ясно, что из системы команд уже практически всё выжато.
>Или несколько итераций внутри широкой команды?
Именно так, наслаиваясь. Конвейерная обработка циклов. Может как-то еще хитрее можно выполнять, но это уже не в моей текущей компетенции.
> она неизбежно будет всё лучше и лучше
Это говорят уже 15 лет. И все равно приходится продолжать говорить. Потому что многопоточная обработка порой очень сложно даётся.
>Там проблема в том, что он не всегда может эффективно использовать её. Поэтому, чем городить огород в микроархитектуре и тратить на это много транзисторов и энергии, проще сделать новые архитектурные расширения.
Ну вот собственно, вы и признались, что дальше уже не получается получить параллельность, приходится использовать другую систему команд.
>параллельность, которую эксплуатирует AVX512, процессор вообще говоря видит
что-то я сомневаюсь, что процессор видит на 16 инструкций вперед, да еще и налету. А если предсказатель ошибётся, сколько тогда будет стоить эта ошибка? За 1 такт же он не сможет 16 инструкций заново проанализировать.
На столько умеют, что пришлось придумывать AVX512.
Они умеют извлекать очень мало параллельности. К тому же, зачем ее извлекать, когда ее можно явно закодировать?
А то как-то странно получается, что мы пишем алгоритм (может даже в какой-то степени параллельный) на последовательном языке, потом процессор пытается извлечь параллелизм, и потом он же пытается заретайрить инструкции последовательно. Хотя можно было бы тут везде иметь слово "параллельно".
>микроархитектура постоянно оптимизируется
каждая следующая оптимизация в среднем дает меньше прироста и стоит дороже. Висящие на нижних ветках фрукты собраны. Дальше станет только хуже.
>у вас настолько большие запросы
Очень даже обычные. Ну серьезно, какому пользователю есть смысл покупать процессор процентов на 30 быстрее за немалые деньги?
И от числа ядер далеко не все задачи выигрывают. Вообще рост числа ядер как раз от сложности дальше ускорять одно ядро.
Вот расскажите, какие вы видите пути существенного ускорения SSOoO процессоров?
Мне интересно, а какие перспективы развития у x86 и ARM, например? AVX1024 что ли? :)
Ой, как хорошо, что вы вспомнили AVX. Это же такие general-purpose инструкции! Еще хуже, чем VLIW ) Интересно, зачем они появились в процессорах? Может потому, что в системе команд не хватало параллелизма?
И нет, в Эльбрус гораздо меньше поводов упереться, потому что у него есть аппаратная поддержка выполнения циклов. Некая конвейеризация. Он может наслаивать итерации друг на друга.
У Эльбруса в архитектуре есть поддержка циклов, так что в счетчик не упрётся.
Вот именно, за 10 лет получили 50% прироста. И какой ценой? Это говорит о том, что пора что-то менять. Например, систему команд с последовательной на явно параллельную.
Ничего себе растет. Вы помните, как росла производительность лет 20 назад? А что сейчас? Почему тогда мне особо не на что поменять процессор 10-летней давности за разумные деньги? Да даже за неразумные я получу максимум 50% прироста на ядро. И это за 10 лет? Это шутка такая? А до недавнего выхода zen 3 и этого не было. У Интел с Core 2000 где-то по Core 8000 вообще прирост был мизерный.
Некоторые специалисты вообще говорят, что график роста переломился в 2006 году (собственно, и неспециалисту это наглядно видно на графике). А второй раз году в 2011.
Ну начать може и сможет, в зависимости от того, как организован цикл. Но все равно всё встанет на инкременте переменной, потому что это зависимость между итерациями.
За последние 10 лет процессоры принципиально не ускорились. И это и есть основная проблема SSOoO - их дальше становится нецелесообразно ускорять.
Вы точно не так поняли написанное или, может, вообще в теме не разбираетесь...
В случае инлайна Эльбрус сможет выполнять сразу несколько итераций цикла за такт, а вот интел не больше одной (и то, если компилятор не раскрутит цикл, но далеко не каждый цикл можно раскрутить).
А вот при отсутствии инлайна как Эльбрус, так и Интел сильно просядут и даже в Интел вряд ли будет 1 такт.