Результаты процессоров Эльбрус в geekbench

так им не могут по закону в Магадане предложить

Ха-ха-ха-ха! Что ещё по закону в твоей стране не могут делать?

запрещает переселение из аварийки осуществлять дальше 5-10 км от старого жилья

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

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

Час для продакшен-сборки и минута для тестовой для сложного приложения выглядят ещё приемлимо. А производительность систем с момента провала Itanium (кажется, уже 2008 про них особо никто не говорил) возросла примерно в 10-20 раз.

Ну вот прикинь, сколько понадобилось, чтобы яблоко.

И ещё вопрос, что там выйдет из этого в итоге

доооо, hello word разве что

А ты сам-то пробовал? Я пробовал. :)

Вот тебе весь патч на поддержку e2k: https://github.com/FWGS/xash3d-fwgs/commit/26616314f840bd959e0229bfcf570354ef0c4715

хотя и последний

Последний живой хочешь сказать? Тем временем в каждой мобильнике вполне себе живёт VLIW процессор отдельным блоком, зовется Qualcomm Hexagon. Благодаря нему же в LLVM как-то пытаются поддерживать VLIW, но я не пробовал и не могу рассказать насколько там всё хорошо.

Всё нормально будет у яблока, как и при переходе с power на x86.

Тем временем в каждой мобильнике вполне себе живёт VLIW процессор отдельным блоком, зовется Qualcomm Hexagon

Хм, интересная инфа, и наших местных критиканов VLIW тыкнуть есть во что ;D

Да, я как первый мобильник со Qualcomm купил, хотел потыкать разработку под его DSP блок, но руки как-то не дошли.

inb4 это DSP, а не CPU. VLIW место только в числодробилках, REEEEE

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

Это конечно если ваша квартира это коробка на пару лет с постоянной миграцией на другое место жительства, а если квартира своя и вы планируете в ней жить и полностью ей распоряжатся, то своя неоспоримо лучше, собственно как и личный автомобиль против какого-нибудь делимобиля, более того если учесть что съём 2-ух комнатной квартиры в приличном районе будет выходить вам 20-30к с возможной доплатой за ЖКХ, то вы по сути купите своему арендодателю за 5-6 лет такую же новую квартиру - что тупо, как собственно и безутешные попытки зачем-то людям навязать дикую мысль о том что съёмная квартира лучше собственной, уже жду когда будете расхваливать школьникам что приёмная семья лучше родной или протез ноги лучше ноги телесной.

Да могут, но это либо с согласия, либо при действительно жалком состоянии жилого дома, в случае фабрикации данных о аварийности которого вы можете оспорить, запросив повторную независимую экспертизу с полным паспортом дома и обратиться в суд в случае, если предыдущая экспертиза не соответствовала действительности, либо вынесено поспешное решение о аварийности в виду наличия возможности провести ремонт, например если аварийность дома была признана в по причине плохого сотояния водопровода/канализации или проводки. А про край города - да, но ИМХО если дом разваливается, то я лучше на окраине города поживу, чем иметь шанс оказаться в один день в траурном списке хроники проишествий по ТВ и медиа из-за «ерундового» обвала дома, пока спал.

как собственно и безутешные попытки зачем-то людям навязать дикую мысль о том что съёмная квартира лучше собственной

Лучше для кого? В каком городе? В разных местах планеты стоимость покупки и аренды сильно отличаются, причём иногда в разные стороны. Там, где я живу, чтобы купить квартиру аналогичную той, которую я снимаю, нужно отдать стоимость аренды за примерно 30 лет. Захочу ли я тут жить через 30 лет? А вот хрен его знает. С другой стороны, где-нибудь в Нидерландах (но не в Амстердаме лол) гораздо проще и дешевле взять ипотеку под низкий процент чем снимать жильё.

Процессорами у нас начали заниматься активно не так давно - очень лихо с ващей стороны называть результат огромного труда «эфемерной сущностью»

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

по мне тот факт, что у нас разрабатывают свои процессоры - это меленькая, но победа

Победа над кем?

они остаются своими, даже несмотря на то, что используется иностранное ПО и «сборка» на чужом заводе

Не сборка, а производство. Прикиньте, если бы Королев смог лишь нарисовать ракету на бумажке, а потом упрашивал ее произвести за бугром. А Курчатов - реактор. Повернулся бы у вас язык называть подобное «своей ракетой», «своим реактором»?

если у нас своё производство появится вы будете говорить, что они не наши,

Странное утверждение. Еще раз напоминаю - произвести процессоры на порядки сложнее и дороже чем нарисовать его виртуальные потроха. Не по зубам коврижка.

Я как раз не говорю о ситуации вынужденного съёма квартир, ясно в условиях недоступности или не разиональности приобретения квартиры её лучше снимать, вопрос в том, что если стоять перед фактом иметь или не иметь собственную квартиру, некоторые же утверждают абсурдную вещь, что даже если возможность иметь свою собственную квартиру есть, то съёмная всё равно лучше, да чем она лучше, если даже если есть собственная вас никто не обязывает в ней жить, т.е. вам никто не запрещает и квартиру иметь и например сдавать её и снимать другую в то же самое время, т.е. абсурдно говорить что 1 больше чем 2. Я же дополнительно придерживаюсь мнения что жить в своей лучше, т.к. вы не обременены ограничениями устанавливаемыми хозяевами, которые повторюсь могут запрещать в т.ч. на уровне договора заводить животных, принимать гостей, заселять семью и т.д., в т.ч. в некоторых случаях это прямо грозит выселением или увеличением арендной платы, т.е. вы чаще всего обременены дополнительными ограничениями, о которых в своей квартире вы даже знать не будете, плюс квартплата + ЖКХ меньше по деньгам, чем аренда, т.е. в своей квартире одни плюсы, повторюсь с одной лишь оговоркой: у вас есть возможность себе её позволить.

Я как раз не говорю о ситуации вынужденного съёма квартир

Что такое вынужденный съём лол?

вопрос в том, что если стоять перед фактом иметь или не иметь собственную квартиру, некоторые же утверждают абсурдную вещь, что даже если возможность иметь свою собственную квартиру есть, то съёмная всё равно лучше, да чем она лучше

Зависит от конкретной ситуации. Универсального рецепта нет.

если даже если есть собственная вас никто не обязывает в ней жить

Зато обязывают платить за неё налоги и разбираться со всеми проблемами, которые она может вызвать. Прикинь вот, ты живёшь где-нибудь в Калифорнии, а в твоей квартире в Москве труба лопнула и соседей залило. Кто с этим должен разбираться? Конечно же ты!

т.е. вам никто не запрещает и квартиру иметь и например сдавать её и снимать другую в то же самое время, т.е. абсурдно говорить что 1 больше чем 2.

Два геморроя – больше чем один, согласен.

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

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

в своей квартире одни плюсы

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

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

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

Я дико извиняюсь, но вы это сами придумали или прочитали где-то?

Я ни разу не видел чтобы программист в ежедневном процессе компилировал с максимальной оптимизацией.

Где вы такое видели?

Из того что я читал, у VLIW оптимизацию ломает любое изменение структурны процессора.

Т.е. оптимизировать нужно отдельно при каждую модель.

Видимо я плохо выразился. Действительно, при разработке программист часто (раз в несколько минут) компилирует debug-версию без оптимизаций — этот процесс должен занимать секунды. И реже (но без этого никак не обойтись, особенно при разборе какой-то проблемы с продакшена) с оптимизациями, желательно на каждый коммит (единицы раз в день).

И уж точно стоит собирать версию «как для продакшена» на build-серверах на каждый pull-request, против которой прогоняются автоматические тесты, без успешного прохождения которых pull-request нельзя принять.

Вряд ли разработчик обрадуется тому, что для слияния его feature-ветки с master/trunk (или для проверки какой-то гипотезы относительно бага на продакшене) потребуется ждать сутки. С pull-request ситуация особенно плоха ещё и потому, что если ждать придётся долго, то в больших коллективах возрастает вероятность того, что кто-то из коллег дождётся своей очереди раньше (например, потому что раньше начал этот процесс), и это сдвинет merge point, что может привести к перезапуску всех тестов.

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

Интел делала так в итаниуме, при таком решении (и при отсутствии суперскаляра) частота падает в разы при исполнении такого кода. В итоге в итаниуме 2 декодер выкинули и сделали программный транслятор. Почему программа эффективней очень простой ответ - потому что jit он только вначале (на «разогреве») тормозной, а дальше у тебя в памяти оттранслированая оптимизированная программа. Аппаратный декодер такого лишен, он тупо молотит как интерпретатор.

Действительно, при разработке программист часто (раз в несколько минут) компилирует debug-версию

Вы живых программистов видели?

Или только на картинке?

И уж точно стоит собирать версию «как для продакшена» на build-серверах

Ну и что мешает это делать на кластере?

– Ничто! Все так и делают уже десятилетиями.

Вряд ли разработчик обрадуется тому, что для слияния его feature-ветки с master/trunk (или для проверки какой-то гипотезы относительно бага на продакшене) потребуется ждать сутки.

Зачем ждать? Дневной билд быстрый.

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

Все так уже много лет.

Вы так и не ответили:

– Вы сами это придумали или прочитали где-то?

Всё нормально будет у яблока, как и при переходе с power на x86.

Справедливости ради переход на интел в свое время обеспечил как портирование игр с винды на мак, так и запуск этой самой винды как на самом железе так и на виртуалке.
Сейчас же эпл опять уползает в свой отдельный мирок как было до этого, да уже даже то что вулкан не поддерживается и стимплей не работает на маке о многом говорит. Десктопная платформа у них все больше превращается в iOS. Я вот переполз на линукс и не жалею.

Это не процессор, а DSP, я же, очевидно, говорил про CPU общего назначения. Ну и вопрос, достаточно ли 4EU для Very Long, дискуссионный.

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

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

Коротко это звучит так - «нет никакой возможности сделать процессор самим»

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

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

виртуальная эфемерная деятельность, а это - реальные технологии

Только вот «реальные технологии» про которые ты тут затираешь явно нихрена в них не понимая, заключены банально в настройке станков и порядке + очередности прохождения через них изделия.

Без электронной промышленности (точные станки, реагенты, программное обеспечение, строительство чистых помещений, обучение квалифицированного персоонала) технологии - пшик. Точно так же как атомное оружие без атомной промышленности.

Архитектура-то понятно. что никуда не делась, потому что эффективна минимум в многопоточной числодробилке. Но в general purpose CPU её уже почти нет. Последний полутруп остался.

Только вот «реальные технологии» про которые ты тут затираешь явно нихрена в них не понимая, заключены банально в настройке станков и порядке + очередности прохождения через них изделия.

Спасибо, поржал. Был такой цикл детских книжек под названиями типа «Цветное телевидение? Это очень просто»

Без электронной промышленности (точные станки, реагенты, программное обеспечение, строительство чистых помещений, обучение квалифицированного персоонала) технологии - пшик. Точно так же как атомное оружие без атомной промышленности.

У вас нет ощущения, что первую, бредово-безграмотную половину вашего поста и вторую писали разные люди? :) Именно что реальные технологии - это куча сопутствующих производств, а не просто «настройка станков». И на каждом должны быть свои технологии, стоимостью в большие деньги. Ракеты строил не Королев и его КБ, ракеты делали тысячи заводов по всей стране - каждый свой кусочек ответственности и свои технологии. Все то же самое в микроэлектронике, а не просто «настроил станок»

Именно что реальные технологии - это куча сопутствующих производств

Да, стали, бетона, кондиционеров, электроэнергии.

В общем целый месяц еще каникул, развлекайся.

Да, стали, бетона, кондиционеров, электроэнергии.

Нет, специфических материалов, специфической обработки. Обычный токарный станок сделать из первых попавшихся подручных материалов и то не получится.

В общем целый месяц еще каникул, развлекайся.

Почитайте что-нибудь. А там вас возможно и на экскурсию куда-нибудь сводят, расскажут что и как делается.

Ну почему полутруп-то?

Квартира, которую ты мне предлагаешь купить
1. Стоит дороже других
2. В ней можно только срать

Нравится тебе жить в говне за свои же деньги - живи. И вы крым езжай. Там таких любителей вроде тебя полно.

Я делаю инфраструктуру, которая в том числе собирает проекты. Ей пользуются живые программисты, и они регулярно приходят ко мне, когда им что-то не нравится.

Мы ведь обсуждаем сборку релизной версии на железе тех времён, когда Itanium был ещё актуален, и при этом хотим выполнять объём вычислений, сравнимый с вычислениями, которые оптимизирующие компиляторы выполняют сейчас. Вы пару сообщений назад оценили это время в сутки, и сказали, что это совсем не страшно, так как нужно редко, и запускается на кластере build-серверов.

Я привожу два сценария, когда мы не можем отказаться от сборки с оптимизациями, и, одновременно, где время сборки важно:

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

2. тесты перед merge в основную ветку.

Если время сборки в этих сценариях будет по-прежнему занимать сутки, люди не смогут работать так же, как они работают сейчас, что почти наверняка приведёт к снижению продуктивности.

Отключить оптимизации (в пользу скорости сборки) в этих сценариях не получится.

Я делаю инфраструктуру

Т.е. не программист

Но сказки о программистах рассказывать любите.

90+ процентов программ нынче пишут на JS, Java, C#, Python.

Расскажите мне какие проблемы компиляции и оптимизации вы встретите на VLIW?

Ваше 1 и 2 просто сказки.

Даже если программист пишет на плюсах, то оптимизацию под прод нужно делать только для вашего кода.

Библиотека оптимизирована заранее кроме того есть т.н. incremental compilation которой пользуются уже много лет. А за день много не напишут.

Т.е. не программист

Необязательно быть программистом, чтобы посмотреть на git diff –stat, историю сборок и очередей build-серверов.

90+ процентов программ нынче пишут на JS, Java, C#, Python.

Расскажите мне какие проблемы компиляции и оптимизации вы встретите на VLIW?

Обсуждать JS, Java, C# и Python особого смысла в рамках e2k vs x86 не вижу, так как сильно оптимизированных версий всего этого под e2k просто нет (насчёт Java могу ошибаться). Производительность работы одних и тех же Python-программ будет сильно зависеть от оптимизаций, которые выполнил C-компилятор во время сборки интерпретатора.

Сотрудники МЦСТ неоднократно рассказывали про то, как после обновления их компилятора и последующей пересборки всех пакетов увеличивается общая производительность системы. Предлагаю ограничить обсуждение программами на C++, как наиболее чувствительных к качеству работы компилятора.

Проблема возникнет, если компилятор будет работать долго. Мы делаем это предположение, рассматривая ситуацию, когда оптимизирующий компилятор в режиме сборки под прод потребляет много ресурсов — столько, сколько потребляет современный компилятор, запущенный на железе 15-летней давности. Вы оценили это время сверху в сутки.

Ваше 1 и 2 просто сказки.

Давайте разбираться. Вы считаете описанные сценарии нереалистичными, не видите в них проблемы или знаете очевидное решение?

Даже если программист пишет на плюсах, то оптимизацию под прод нужно делать только для вашего кода.

Необязательно быть программистом на C++, чтобы заметить, что изменение в заголовочном файле, который сильно связан с другими юнитами компиляции в графе зависимостей приведёт к пересборке почти всего проекта целиком. Да и в стандартной библиотеке довольно много алгоритмов, требующих реализации в заголовочных файлах. Классический пример, который любят приводить в качестве иллюстрации превосходства C++ над C — сортировка, которая инлайнит компаратор и методы доступа к элементам контейнера (чего, очевидно, невозможно сделать с библиотечной функцией qsort из C). Такой подход обеспечивает лучшую оптимизацию, но требует пересборки в том числе и того кода, который вы непосредственно не меняли.

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

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

Еще раз

1. Прочитайте о incremental compilation
2. Нет никакой необходимости запускать с полной оптимизацией PR
3. Редкая сборка для QA в 8 часов никого не напряжет.

Вы не понимаете процес разработки ПО и от этого пишете глупость

Сколько времени занимает полная сборка компилятора С++ для Элббруса?

Думаете неделю на кластере 10-ти летней давности?

Я думаю в педелах минут если они смогли распаралелить. На одном компе скорее всего в пределах часа, если они смогли в кроскомпиляцию и пускают на нормальном компьютере.

У. Vliw есть проблемы из-за которых их перестали использовать даже в видеокартах

Обсуждать JS, Java, C# и Python особого смысла в рамках e2k vs x86 не вижу,

Не видите смысл обсудить 99% разработки ПО?

Забавно. Это слив?

Вообщето звучало так «пока не можем, но это не повод терять время и сидя на жопе ждать»

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

У. Vliw есть проблемы из-за которых их перестали использовать даже в видеокартах

Не всё так однозначно. VLIW2 в super-SIMD

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

У вас нет ощущения, что вы не знаете что сказать, но возразить вроде как надо?

Ну, если считать что simd это Vliw то мы все уже на Vliw и он победил

Ну, если считать что simd это Vliw то мы все уже на Vliw и он победил

SIMD и VLIW разные понятия, их определения можешь найти на wikipedia. Существуют как SIMD VLIW — GPU (TeraScale VLIW4/5), так и VLIW SIMD — CPU (Эльбрус/Denver).

Если интересно, могу рассказать свои догадки почему AMD решила вернуться на VLIW в GPU и откуда в RDNA2 возникло +50% к энергоэффективности.

У Vliw есть проблемы из-за которых их перестали использовать даже в видеокартах

Я предложил сравнить с FPGA - в ответ лишь кинули какашку в меня. Ребят, в самом деле, давайте сравним с точки зрения цифровой схемотехники. Задача мне видится так: выполнить как можно больше параллельных действий за 1 тактовый импульс

Если вам так нравится спорить, так давайте не «компилятор не смогли», а чисто теоретически обоснуйте, какие есть непреодолимые барьеры. Например, невозможность в VLIW предугадать оптимизацию не видя текущие промежуточные результаты вычисления, а x86_64 типичный может - вот это я бы понял

Так было бы интересно всем. А то «компилятор не смогли». Надо что-то более весомое, с какими нибудь показательными сценариями. У критики VLIW не ощущается твердой доказательной базы, при том что сам я подход Intel не критикую - не слепой и вижу выдающиеся результаты, просто считаю что VLIW способен по мере развития компилятора и оптимизаций догнать

Вроде как это не я назвал симд вилв2

Я ни в кого не бросался.

У вас я спрашивал почему не МИПС.

Главные проблемы VLIW, которые видит такой ламер по ЦПУ, как я:

1. Оптимизировать нужно отдельно для каждой модели и версии отдельно
2. Нормально в JIT не оптимизировать а это 99% энтерпрайза.

Вроде как это не я назвал симд вилв2

Я дал тебе ссылку на патент и слово которое там искать.

VLIW2 в super-SIMD

Задача мне видится так: выполнить как можно больше параллельных действий за 1 тактовый импульс

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

У критики VLIW не ощущается твердой доказательной базы

Чьей критики? На лоре нет разработчиков процессоров мирового уровня. Если посмотреть на реально существующие топовые по производительности процы общего(да и специализированного) применения - они не vliw. Видеокарты и прочие ускорители требуют специального подхода к программированию и имеют узкую сферу применимости.

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

На лоре нет разработчиков процессоров мирового уровня

Не верю что на ЛОРе нет тех, кто пишет на VHDL/Verilog, мне кажется таких навалом. Те кто никогда не делал что-то сложнее цифровых часов - как с ними можно спорить?

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

Вы хорошо знаете цифровую схемотехнику?

тех, кто пишет на VHDL/Verilog

делал что-то сложнее цифровых часов

Этого даже близко не достаточно.

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

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