Да, других тем чрезмерно богато. Не являюсь поклонником Сталина, но приплетать к происходящему в западной компании Сталина, Колыму и СССР считаю совсем излишним. Потому что это как бы совершенно из другой оперы. Ещё бы Оруэлла упомянули.
Ну или если поминать, то тогда уж не как страшилку, а как методологию. Спор большевиков с меньшивиками о том, можно ли принимать в члены тех, кто просто числится в членах партии (позиция меньшевиков) или только активистов, которые работают в каком-либо из начинаний партии (позиция большевиков). Или методология демократического централизма. Но это всё было бы, скорее, антонимами к происходящему в Valve.
Вспомнилась антиутопия «Бразилия» Терри Гиллиама. Вам не нравится вид торчащих повсюду в квартире чёрных труб? У нас есть на выбор трубы разных цветов!
Кстати, суперкомпьютер строить на «Эльбрусе» — хорошая затея. Потому что программу для суперкомпьютера будут заведомо вылизывать, а благодаря архитектуре, на «Эльбрусах» при таком вылизывании можно потенциально задействовать все аппаратные возможности по максимуму, поскольку аппаратура практически полностью открыта для программиста.
Только вот взлом можно делать не только посредством взлома на уровне кода. Гораздо эффективнее, подчас, взламывать людей. Нужен всего-то системный администратор, который выполнит нужную последовательность действий — и защита на уровне процессора от этого не защитит. Что не означает, конечно, что такой защиты быть не должно.
Максим, очень жаль, что вы никак не отреагировали на разбор вашего реального примера с компиляцией внутреннего цикла из сортировки со вставками под Эльбрус. Вы и ваши единомышленники в комментариях утверждали, что скомпилированный вами результат в 13 тактов на итерацию является принципиально неустранимым недостатком эльбрусовского компилятора.
Однако пользователи antag и Дмитрий Щербаков разобрали данный фрагмент (https://habr.com/ru/post/576420/comments/#comment_23456356). Сначала оказалось, что с опцией оптимизации -O2 внутренний цикл компилируется уже в код с 7 тактами на итерацию (вы ещё забыли включить другую рекомендуемую для Эльбруса оптимизацию -ffast). Далее оказалось, что эвристика компилятора неверно определила цикл как выполняющийся с небольшим количеством итераций, что можно было обойти, добавив в исходник комментарий с подсказкой для компилятора — и в итоге внутренний цикл скомпилировался в код, выполняемый за 1 такт — втрое быстрее, чем код для Intel/AMD.
И очень разочаровывает, что вы ни в той статье не добавили Post Scriptum с указанием на этот разбор, ни в этой статье не обмолвились. При том, что это можно было хорошо обыграть в вашей парадигме — дескать, вот какие танцы с бубнами нужны, чтобы хорошо скомпилировать простую сортировку. Но даже это не интересно, не интересна реальность — интересны теоретические рассуждения в вакууме. Вот вы претендуете в своих текстах на поиск истины, а по факту оказывается, что истина не интересует, а интересует лишь пропаганда.
Это же тоже надо подтверждать фактами. А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора фирмой Yadro. Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.
Ну вот в ветке ниже (https://habr.com/ru/post/576420/comments/#comment_23456356) оказалось, что NOP 2 гвоздиком не прибит и что это не «всерьёз и надолго» — что при других настройках происходит компиляция всего цикла в одну широкую команду.
Ну займитесь оптимизацией под x86 — покажите, что можно сделать быстрее, чем на «Эльбрусе». Вы просто сменили тему разговора — в данном примере ваш тезис про неэффективность «Эльбруса» не оправдался. Можно это признать? А после признания говорить уже о том, что компилятор нехорош, что его долго пилили и всё равно он не может сходу определить горячий цикл и правильно его оптимизировать. Я тут вас абсолютно поддержу — это недоработка программистов. И в тезисе про закрытость системы команд поддержу.
Я просто не понимаю этого нежелания признать, что пример получился не вполне в тему исходного тезиса статьи. Вы же даже приписку к статье не хотите сделать, что вот при таких-то настройках оно компилируется более эффективно, чем на x86. Это же неправильно. И ваши оппоненты укажут на это нежелание как на вашу ангажированность. Вы делаете свою статью подударной.
Подождите, но ведь исходный тезис был в том, что «Эльбрус» принципиально неулучшаем и что он будет работать принципиально хуже процессоров Intel и AMD. А тут вдруг оказалось, что предложенный цикл сортировки компилируется в одну широкую команду. Ну так можно признать, что исходный тезис ложен или нельзя? А дальше давайте клясть недоработанный компилятор и закрытость системы команд. Я вот с вами наперебой готов это всё клясть — но после того, как признаем, что ложен исходный тезис про неспособность статического планирования «Эльбруса» достичь эффективности выше суперскалярного процессора.
Вы говорите о том, что не стоит вырывать слова из контекста, но Бабаян там прежде говорит о несостоятельности суперскалярности — а автор статьи именно суперскалярность указывает как правильную альтернативу VLIW. Так что если не вырывать из контекста, то нужно все три полюса дать — и что суперскалярность плохо, поскольку лишь 6 команд в такт, и что VLIW плохо, потому что статическое планирование, а хорошо — полностью параллельный процессор с параллельным языком программирования.
Максим, но ведь ваш тезис был про принципиальную невозможность оптимизировать программу лучше, чем на суперскалярных x86-процессорах. А оказалось, что это можно сделать — и получается почти вдвое быстрее. Обнаружилась проблема в компиляторе — ну так пусть исправляют.
Поясните по поводу «NOP 2 прибит гвоздиком». Если загрузка занимает 1 такт, то зачем NOP 2? Или речь о том, что с использованием предсказателя обращений памяти загрузка занимает от 1 до 3 тактов и всё равно придётся вставлять NOP 2 на всякий случай? Но что мешает вместо NOP 2 добавить команду, взаимодействующую с этим самым предсказателем?
Вы в статье приводите ссылку на Бабаяна. Так там Бабаян поясняет, почему Itanium не взлетел — потому что мог в параллель выполнять лишь 6 команд, как и суперскалярные процессоры Intel и AMD. Но, в отличие от них, требовал статического планирования. Соответственно, не мог с ними конкурировать. И дальше Бабаян поясняет, что потому в Эльбрус и была заложена потенциальная возможность исполнять по 20+ команд за такт.
Ну и вы ссылаетесь на то, что Бабаян был в курсе, что VLIW-архитектура не оптимальна. Но там он прежде всего рассуждает, что суперскаляр не оптимален, что достиг своего предела. Что поэтому они сделали VLIW, который тоже не оптимален. А оптимален явный параллелизм, который надо теоретически прорабатывать — причём это потребует не только другой архитектуры железа и других операционных систем, но и других языков программирования.
Подождите. Stateless — это, фактически, переизобретение процедурного программирования под ООП. Кто хочет писать в процедурном стиле, так и делает — объявляет объект с public-полями и без единого метода, потом объявляет класс с public-методами и без единого поля. И получаете желанное:
Насчёт количества измерений я и пишу, что реальная размерность будет размерностью фазового пространства. Но это недостаточно наглядно. Что до размерности идей, то я в другой статье этот момент раскрывал.
Корабль к Альфе Центавра нужен, конечно же, не сам по себе. Это один из первых шагов воплощения мечты русских космистов (включая Циолковского), говоривших, что человечество может состояться только если выйдет за границу своей «колыбели» — Земли — и возьмёт на себя ответственность за Вселенную.
Дублирование. Космические технологии.
GW Девы — это пульсирующий переменный белый карлик.
Да, других тем чрезмерно богато. Не являюсь поклонником Сталина, но приплетать к происходящему в западной компании Сталина, Колыму и СССР считаю совсем излишним. Потому что это как бы совершенно из другой оперы. Ещё бы Оруэлла упомянули.
Ну или если поминать, то тогда уж не как страшилку, а как методологию. Спор большевиков с меньшивиками о том, можно ли принимать в члены тех, кто просто числится в членах партии (позиция меньшевиков) или только активистов, которые работают в каком-либо из начинаний партии (позиция большевиков). Или методология демократического централизма. Но это всё было бы, скорее, антонимами к происходящему в Valve.
Или рынок географически прирастёт — за счёт дружественных стран, понимающих риски зависимости от Запада в микроэлектронике.
Вспомнилась антиутопия «Бразилия» Терри Гиллиама. Вам не нравится вид торчащих повсюду в квартире чёрных труб? У нас есть на выбор трубы разных цветов!
Кстати, суперкомпьютер строить на «Эльбрусе» — хорошая затея. Потому что программу для суперкомпьютера будут заведомо вылизывать, а благодаря архитектуре, на «Эльбрусах» при таком вылизывании можно потенциально задействовать все аппаратные возможности по максимуму, поскольку аппаратура практически полностью открыта для программиста.
Только вот взлом можно делать не только посредством взлома на уровне кода. Гораздо эффективнее, подчас, взламывать людей. Нужен всего-то системный администратор, который выполнит нужную последовательность действий — и защита на уровне процессора от этого не защитит. Что не означает, конечно, что такой защиты быть не должно.
Максим, очень жаль, что вы никак не отреагировали на разбор вашего реального примера с компиляцией внутреннего цикла из сортировки со вставками под Эльбрус. Вы и ваши единомышленники в комментариях утверждали, что скомпилированный вами результат в 13 тактов на итерацию является принципиально неустранимым недостатком эльбрусовского компилятора.
Однако пользователи antag и Дмитрий Щербаков разобрали данный фрагмент (https://habr.com/ru/post/576420/comments/#comment_23456356). Сначала оказалось, что с опцией оптимизации -O2 внутренний цикл компилируется уже в код с 7 тактами на итерацию (вы ещё забыли включить другую рекомендуемую для Эльбруса оптимизацию -ffast). Далее оказалось, что эвристика компилятора неверно определила цикл как выполняющийся с небольшим количеством итераций, что можно было обойти, добавив в исходник комментарий с подсказкой для компилятора — и в итоге внутренний цикл скомпилировался в код, выполняемый за 1 такт — втрое быстрее, чем код для Intel/AMD.
И очень разочаровывает, что вы ни в той статье не добавили Post Scriptum с указанием на этот разбор, ни в этой статье не обмолвились. При том, что это можно было хорошо обыграть в вашей парадигме — дескать, вот какие танцы с бубнами нужны, чтобы хорошо скомпилировать простую сортировку. Но даже это не интересно, не интересна реальность — интересны теоретические рассуждения в вакууме. Вот вы претендуете в своих текстах на поиск истины, а по факту оказывается, что истина не интересует, а интересует лишь пропаганда.
Это же тоже надо подтверждать фактами. А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора фирмой Yadro. Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.
Спасибо за информацию, познавательно.
Ну вот в ветке ниже (https://habr.com/ru/post/576420/comments/#comment_23456356) оказалось, что NOP 2 гвоздиком не прибит и что это не «всерьёз и надолго» — что при других настройках происходит компиляция всего цикла в одну широкую команду.
Ну займитесь оптимизацией под x86 — покажите, что можно сделать быстрее, чем на «Эльбрусе». Вы просто сменили тему разговора — в данном примере ваш тезис про неэффективность «Эльбруса» не оправдался. Можно это признать? А после признания говорить уже о том, что компилятор нехорош, что его долго пилили и всё равно он не может сходу определить горячий цикл и правильно его оптимизировать. Я тут вас абсолютно поддержу — это недоработка программистов. И в тезисе про закрытость системы команд поддержу.
Я просто не понимаю этого нежелания признать, что пример получился не вполне в тему исходного тезиса статьи. Вы же даже приписку к статье не хотите сделать, что вот при таких-то настройках оно компилируется более эффективно, чем на x86. Это же неправильно. И ваши оппоненты укажут на это нежелание как на вашу ангажированность. Вы делаете свою статью подударной.
Подождите, но ведь исходный тезис был в том, что «Эльбрус» принципиально неулучшаем и что он будет работать принципиально хуже процессоров Intel и AMD. А тут вдруг оказалось, что предложенный цикл сортировки компилируется в одну широкую команду. Ну так можно признать, что исходный тезис ложен или нельзя? А дальше давайте клясть недоработанный компилятор и закрытость системы команд. Я вот с вами наперебой готов это всё клясть — но после того, как признаем, что ложен исходный тезис про неспособность статического планирования «Эльбруса» достичь эффективности выше суперскалярного процессора.
Вы говорите о том, что не стоит вырывать слова из контекста, но Бабаян там прежде говорит о несостоятельности суперскалярности — а автор статьи именно суперскалярность указывает как правильную альтернативу VLIW. Так что если не вырывать из контекста, то нужно все три полюса дать — и что суперскалярность плохо, поскольку лишь 6 команд в такт, и что VLIW плохо, потому что статическое планирование, а хорошо — полностью параллельный процессор с параллельным языком программирования.
Максим, но ведь ваш тезис был про принципиальную невозможность оптимизировать программу лучше, чем на суперскалярных x86-процессорах. А оказалось, что это можно сделать — и получается почти вдвое быстрее. Обнаружилась проблема в компиляторе — ну так пусть исправляют.
Поясните по поводу «NOP 2 прибит гвоздиком». Если загрузка занимает 1 такт, то зачем NOP 2? Или речь о том, что с использованием предсказателя обращений памяти загрузка занимает от 1 до 3 тактов и всё равно придётся вставлять NOP 2 на всякий случай? Но что мешает вместо NOP 2 добавить команду, взаимодействующую с этим самым предсказателем?
Вы в статье приводите ссылку на Бабаяна. Так там Бабаян поясняет, почему Itanium не взлетел — потому что мог в параллель выполнять лишь 6 команд, как и суперскалярные процессоры Intel и AMD. Но, в отличие от них, требовал статического планирования. Соответственно, не мог с ними конкурировать. И дальше Бабаян поясняет, что потому в Эльбрус и была заложена потенциальная возможность исполнять по 20+ команд за такт.
Ну и вы ссылаетесь на то, что Бабаян был в курсе, что VLIW-архитектура не оптимальна. Но там он прежде всего рассуждает, что суперскаляр не оптимален, что достиг своего предела. Что поэтому они сделали VLIW, который тоже не оптимален. А оптимален явный параллелизм, который надо теоретически прорабатывать — причём это потребует не только другой архитектуры железа и других операционных систем, но и других языков программирования.
СобачныйМенеджер.выгулять(собаку)
БанковскийМенеджер.снятьс(аккаунт, сумма)
Считайте СобачныйМенеджер и БанковскийМенеджер названиями модулей, в которых бы хранились соответствующие процедуры в процедурном языке.
Корабль к Альфе Центавра нужен, конечно же, не сам по себе. Это один из первых шагов воплощения мечты русских космистов (включая Циолковского), говоривших, что человечество может состояться только если выйдет за границу своей «колыбели» — Земли — и возьмёт на себя ответственность за Вселенную.