Пруф? Я не понимаю ход Вашей логики.
С чего Вы взяли, что их ядро не поддерживает параллелизм на уровне инструкций. Что-то мне подсказывает, что без этого оно проиграло бы VLIW в разы, а не в десятки процентов. Или Вы пользуетесь иным определением суперскалярности?
Вам выше дали пруф того, что ни одно из использованных в статье открытых ядер не имеет OoO
Я не понимаю Вашу логику. То есть, исходя из того, что четыре ядра в таблице не OoO, Вы делаете вывод, что пятое тоже не OoO?
Я по прежнему жду пруф на то, что именно дизайн суперскалярного ядра выполненого авторами статьи на FPGA не является OoO.
Есть ли в их ядре OoO или нет — я не знаю. Дайте пруф, откуда Вы это взяли, пожалуйста.
не даёт ответа на главный вопрос: а какой бы они прирост получили, если бы пошли не в сторону VLIW, а в сторону мейнстрима
Да, я не вижу ответа на этот вопрос ни в этой статье, ни в какой-либо другой. А мой уровень навыков работы с FPGA не позволяет провести такой эксперимент. То бишь, вопрос остается открытым.
Вы явно статью не читали. Табличка служит, в первую очередь, для сравнения их суперскалярного ядра с прочими.
При этом они явно пишут:
«However, our design recognizes a few tradeoffs. First, as stated in the Synthesis Results section, the instruction scheduler consumes substantial hardware utilization. The instruction scheduler is simple to utilize less hardware than other modules. Second, scheduling eight sequential instructions from the fetch stage requires one extra clock cycle for each scheduling turn. This requirement increases program execution time, indicating that IPC is slightly degraded. Our VLIW core still achieves higher IPC compared with existing open-source RISC-V cores at the expense of hardware resource, as presented in Table 4.»
В качестве экспериментального пруфа
По точно такой же логике автомобиль с ДВС намного лучше электромобиля. При том, что электромобилям больше лет, чем ДВС )
Пока высказывание не подтвержденго экспериментально, оно может быть не более, чем гипотезой.
можно ли относить к VLIW архитектуру с динамическим планированием и динамическим разрешением конфликтов
Боюсь, это риторический вопрос. У ребят просто не было выбора, так как написать компилятор для VLIW архитектуры слишком трудоемко. IMHO, это получилось очень хорошее приближение. Причем совершенно корректное, так как возможности оптимизации статического планирования в компиляторе намного выше, чем простейшего динамического на FPGA.
нет сравнения с ОоО-архитектурами
Это только Ваше предположение. Такие подробности в статье опущены.
Это не значит, что вы не правы,
Я могу быть не прав только посмев разместить ссылку на статью? Лично я до сих пор вообще ничего не утверждал, кроме констатации факта, что есть статья со следующими выводами. Вы о чем вообще?
Прочитайте статью, пожалуйста, прежде чем отвечать. Некрасиво получатеся.
здесь имеется динамическое планирование
«implementing a VLIW architecture based on that ISA is the lack of a powerful compiler to schedule original instructions in accordance with the VLIW instruction format»
«We design a simple instruction scheduler to exploit the parallelism potential of sequentially original instructions dynamically.»
Если коротко и по-русски, то они реализовали динамическое планирование в связи с отсутствием компилятора, который должен был бы осуществлять статическое планирование.
кто из этих малюток RISC-V, с которыми они сравнивают
Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.
Как раз тем это исследование меня и заинтересовало, что тут сравниваются процессоры с одинаковой (насколько это вообще возможно) микроархитектурой. Тогда как все остальные стравнения суперскалярных CPU с VLIW были явно с разной микроархитектурой.
Дело в том, что VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением.
Не все с этим согласны. У ребят получилось совсем наоборот. Выигрыш VLIW от 1.2 до 1.57 раз против пятиступенчатого конвеера на, по сути, одной и той же архитектуре RISC-V.
Обнаружил очень интересный документик о VLIW. Ребята утверждают, что по сравнению с пятиступенчатой конвеерной архитектурой VLIW выигрывает в среднем в 1.4 раза (от 1.2 до 1.57)
Прикол в том, что VLIW у них базируется на RISC-V и 256-битных командах.
Так что VLIW еще рано хоронить.
Так это же самое сложное и есть! Разобраться в навороченной сложности и трансформировать ее в простое и понятное. Последние годы я именно оптимизацией (как сложного кода в простой, так и медленного кода в быстрый) и развлекаю себя )
Простите, но именно "когнитивная сложность" и доставляет мне удовольствие в программировании. А от деятельности, которая не требует постоянно напрягать мозги и решать сложные задачи мне тошно и некомфортно.
Так что, если судить по себе (имею я право на субъективное мнение?), программист должен любить решать сложные задачи и получать от их решения удоволетворение. Как получают удовольствие некоторые школьники, решая олимпиадные задачи. Просто так, для себя, потому что это интересно и приятно.
Децентрализация подразумевает, что обмен между абонентами ведется напрямую, а не через промежуточный сервер. Перехватить траффик сложнее и шифруется весь поток, а не сообщения по отдельности.
То бишь если мы шифруем сообщения по отдельности, так как не знаем в каком порядке они будут обработаны сервером, то одинаковые сообщения дадут одинаковый код после шифрации. А если мы шифруем поток, то одинаковые сообщения дадут разный код после шифрации, так место в потоке у них различно.
C++ призывают воздержаться от [...] использования динамической памяти [...] malloc() и free()
Одно дело malloc() и free(), а совсем другое неявные new() и delete().
В общем случае, в критически важном участке кода лучше вообще отказаться от всего лишнего, включая malloc() и free(), выделив всю необходимую память заранее.
Мы получаем законченный сетевой сервис, который предоставляет данные системы воздушных сигналов
А это другая крайность. С точки зрения надежности системы лучше получать в том числе и сырую информацию с датчика. Хотя бы потому, что таких сервисов может быть несколько дублирующих. И тогда, обладая всей полнотой информации, намного проще будет разобраться, какой из них вышел из строя, если вдруг они стали выдавать различающиеся данные.
А не проще ли использовать уже защищенный и децентрализованный протокол? Обменятся ключами через другие каналы всяко сложнее, чем просто попросить корреспондента поставить тот же Jami.
Даже вне зависимости от энергосистемы, выбросы CO2 при производстве литиевых АКБ для электромобиля сопоставимы с выбросами ДВС за 60-80 тыс. км. пробега. Такая технология сейчас.
Если использовать тепловой насос
Даже на скромные 100 кв.м. площади газовый котел требуется не менее, чем на 10КВт. Подобный тепловой насос будет стоить в 20 раз дороже газового котла.
Но даже без учета стоимости насоса или котла тепловой насос все равно в минусе. Куб газа дает не менее 10 КВт*ч при цене у меня в деревне 6 руб. за куб. Даже если котел будет с COP=5 (предел для воды), то 2 КВт*ч электричества в той же деревне стоят больше 9 руб (4,57 за 1 КВт*ч).
В статье очень не хватает фотографий внутренностей лампы, выяснения ее элементной базы и принципиальной схемы. Есть вполне обоснованное предположение, что там используется ESP8266 (или подобный МК с WiFI), который можно перепрошить самому прямо в схеме, после чего, уже без опасений, запустить его в локальную сеть.
А для параноиков есть WiFi роутеры с vlan (или с возможностью прошивки их openWRT).
С чего Вы взяли, что их ядро не поддерживает параллелизм на уровне инструкций. Что-то мне подсказывает, что без этого оно проиграло бы VLIW в разы, а не в десятки процентов. Или Вы пользуетесь иным определением суперскалярности?
Я не понимаю Вашу логику. То есть, исходя из того, что четыре ядра в таблице не OoO, Вы делаете вывод, что пятое тоже не OoO?
Я по прежнему жду пруф на то, что именно дизайн суперскалярного ядра выполненого авторами статьи на FPGA не является OoO.
Это даже в Эльбрусе есть.
Есть ли в их ядре OoO или нет — я не знаю. Дайте пруф, откуда Вы это взяли, пожалуйста.
Да, я не вижу ответа на этот вопрос ни в этой статье, ни в какой-либо другой. А мой уровень навыков работы с FPGA не позволяет провести такой эксперимент. То бишь, вопрос остается открытым.
Вы явно статью не читали. Табличка служит, в первую очередь, для сравнения их суперскалярного ядра с прочими.
При этом они явно пишут:
«However, our design recognizes a few tradeoffs. First, as stated in the Synthesis Results section, the instruction scheduler consumes substantial hardware utilization. The instruction scheduler is simple to utilize less hardware than other modules. Second, scheduling eight sequential instructions from the fetch stage requires one extra clock cycle for each scheduling turn. This requirement increases program execution time, indicating that IPC is slightly degraded. Our VLIW core still achieves higher IPC compared with existing open-source RISC-V cores at the expense of hardware resource, as presented in Table 4.»
По точно такой же логике автомобиль с ДВС намного лучше электромобиля. При том, что электромобилям больше лет, чем ДВС )
Пока высказывание не подтвержденго экспериментально, оно может быть не более, чем гипотезой.
Я этого не вижу. Процитируйте, пожалуйста. Мы вообще об одной и той же статье говорим?
Обсуждать можно сколько угодно. А экспериментальных измерений на одном и том же FPGA я не видел. Опять жду пруфа.
Боюсь, это риторический вопрос. У ребят просто не было выбора, так как написать компилятор для VLIW архитектуры слишком трудоемко. IMHO, это получилось очень хорошее приближение. Причем совершенно корректное, так как возможности оптимизации статического планирования в компиляторе намного выше, чем простейшего динамического на FPGA.
Это только Ваше предположение. Такие подробности в статье опущены.
Я могу быть не прав только посмев разместить ссылку на статью? Лично я до сих пор вообще ничего не утверждал, кроме констатации факта, что есть статья со следующими выводами. Вы о чем вообще?
«implementing a VLIW architecture based on that ISA is the lack of a powerful compiler to schedule original instructions in accordance with the VLIW instruction format»
«We design a simple instruction scheduler to exploit the parallelism potential of sequentially original instructions dynamically.»
Если коротко и по-русски, то они реализовали динамическое планирование в связи с отсутствием компилятора, который должен был бы осуществлять статическое планирование.
Ни с одной из этих малюток они свой дизайн не сравнивают. Явно же написали:
«we design a single-issue pipelined five-stage 32-bit RISC-V architecture»
«The architecture’s ALU supports the same integer and floating-point instructions with the same latencies»
То бишь, по сути то же ядро, с тем же планировщиком, но с пятиступенчатым конвеером.
Как раз тем это исследование меня и заинтересовало, что тут сравниваются процессоры с одинаковой (насколько это вообще возможно) микроархитектурой. Тогда как все остальные стравнения суперскалярных CPU с VLIW были явно с разной микроархитектурой.
Не все с этим согласны. У ребят получилось совсем наоборот. Выигрыш VLIW от 1.2 до 1.57 раз против пятиступенчатого конвеера на, по сути, одной и той же архитектуре RISC-V.
Прикол в том, что VLIW у них базируется на RISC-V и 256-битных командах.
Так что VLIW еще рано хоронить.
Нашел ссылку
Простите, но именно "когнитивная сложность" и доставляет мне удовольствие в программировании. А от деятельности, которая не требует постоянно напрягать мозги и решать сложные задачи мне тошно и некомфортно.
Так что, если судить по себе (имею я право на субъективное мнение?), программист должен любить решать сложные задачи и получать от их решения удоволетворение. Как получают удовольствие некоторые школьники, решая олимпиадные задачи. Просто так, для себя, потому что это интересно и приятно.
То бишь если мы шифруем сообщения по отдельности, так как не знаем в каком порядке они будут обработаны сервером, то одинаковые сообщения дадут одинаковый код после шифрации. А если мы шифруем поток, то одинаковые сообщения дадут разный код после шифрации, так место в потоке у них различно.
В общем случае, в критически важном участке кода лучше вообще отказаться от всего лишнего, включая malloc() и free(), выделив всю необходимую память заранее.
А это другая крайность. С точки зрения надежности системы лучше получать в том числе и сырую информацию с датчика. Хотя бы потому, что таких сервисов может быть несколько дублирующих. И тогда, обладая всей полнотой информации, намного проще будет разобраться, какой из них вышел из строя, если вдруг они стали выдавать различающиеся данные.
И чем тогда тот же Jami не угодил?
Без разницы. Особенно если мессенджер не децентрализованный.
На 10КВт? В районе 200 евро.
А Тульская область где? В Азии что ли? :)
Даже на скромные 100 кв.м. площади газовый котел требуется не менее, чем на 10КВт. Подобный тепловой насос будет стоить в 20 раз дороже газового котла.
Но даже без учета стоимости насоса или котла тепловой насос все равно в минусе. Куб газа дает не менее 10 КВт*ч при цене у меня в деревне 6 руб. за куб. Даже если котел будет с COP=5 (предел для воды), то 2 КВт*ч электричества в той же деревне стоят больше 9 руб (4,57 за 1 КВт*ч).
А для параноиков есть WiFi роутеры с vlan (или с возможностью прошивки их openWRT).