Комментарии 44
Спекулятивный доступ дает выигрышь в быстродействии. Если его нет, то получится более медленное исполнение. Вот и выбирайте… Быстро, но с уязвимостью, или медленно, но без уязвимости.
Сейчас и программисты получше научились работать с многопоточностью, и инструменты появились.
все эти изменения порядка выполнения инструкций нужны для того, чтобы утилизировать все блоки проца. иначе каждый такт почти все мозги будут простаивать.
Конечно, софт придется переписывать, чтобы получить преимущества, а не наоборот уйти в прошлое.
Представьте себе, у вас 1000 более простых ядер, и вы даете ядра процессу в единоличное пользование. Без переключений контекста.
а если учесть, что, например на десктопе, наиболее критичен поток ГУИ, то совсем печально.
1000 ядер почти бессмыслены в прикладных задачах общего характера.
Там куча потоков используется просто для удобства, даже не для производительности. Отдельный поток слушает нажатия кнопок, отдельный — движения мыши. А процессор видяхи — так вообще прям создан для параллельных вычислений.
2. Наверное, не все задачи параллелятся, но вот я с ходу не смог придумать такую задачу. Все, что я встречал — это просто такая реализация. И скорее всего, ноги росли из начала 2000-х, когда даже 2-процессорные компы были редкостью.
3. А почему нет? Каждой вкладке браузера можно выдать даже не по одному потоку. Отдельно для гуи, отдельно для бизнес-логики. И это, кстати, может уменьшить латенси. А то, если честно, напрягает, когда набираешь код в idea, а на экране все появляется где-то через секунду. И у меня не дохлый комп. core i7, 16 гб. памяти, ssd.
а непаралелятся все задачи итерационной природы, если нежен полный результат в следующей итерации. таких много
да, я знаю. Но в реальности в голову приходит только какая-нибудь глупость, вроде синуса от синуса от… А на практике часто оказывается, что мат. модель можно изменить, например, сделать ее ассоциативной.
Либо, если результат дискретный — можно попытаться сделать иммитацию тех же спекулятивных вычислений, вроде вычисления на других ядрах наиболее вероятных результатов вычисления предыдущей операции с последующим отбрасыванием того, что не угадал.
А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
Если бы Specter/Meltdown наши скажем ещё в 4 пне, то возможно он бы уже давно был исправлен, но его нашли(ну по крайней мере официально) не так давно, в итоге куча чипов да ещё и разных архитиктур оказалась забагована(интересно они что друг у друга покупают модули, или вообще у треттих фирм).
И было бы очень интересно посмотреть на самостоятельное изготовление процессора.
а вот всякие ПЛИС… но тоже сомнительный вариант.
было бы интересно если бы в проце был небольшой кусочек плиса. наверное.
К тому же ПЛИС, которые могут содержать в себе полноценный процессор, стоят как минимум на порядок дороже процессора. Дешевле регулярно покупать исправленную версию серийного производства.
А на счет «иметь кусочек ПЛИСа в процессоре» — в некотором смысле, микрокод именно эту функцию и выполняет.
Вроде бы открытые исходники для академических нужд.
Правда, что-то мне не верится, что открытые исходники процессора, кто-то сможет реально смотреть/исправлять/вести отладку.
Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.
Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.
Можно ведь просимулировать, да это медленно но возможно.
FPGA избыточна потому что переконфигурируемв. А значит если на ней можно уместить какой-то процессор — значит процессор с такими характеристиками можно сделать дешевле, потому что грубее тех процесс, меньше элементов, меньше площадь кристалла или за ту же стоимость — сделать процессор с тем же тех процессом, количеством элементов и площадью — но с существенно лучшими характеристиками. Разумеется при условии достаточно массового тиража такого процессора, а при тираже больше тиража FPGA — он ещё и дешевле выйдет, потому как затраты на R&D по большему числу экземпляров размажутся.
Ну, "открытые исходники для академических нужд" — это всё-таки не "свободные процессоры" и для разработки своего процессора, наверное, далеко не лучший вариант. Хотя, с точки зрения анализа это, конечно, намного лучше, чем ничего.
В софте уязвимости устраняются и пользователи просто обновляют ПО, а с процессором просто так не обновишься, и в итоге будешь и без обновлений сидеть, и с кучей открытых уязвимостей
Во вторых, речь идёт о том, что в открытой системе серьёзные баги не будут жить годами и поколениями.
Баги десятилетиями живут в линуксе.
Имхо в таком случае лучше и баги пусть не находят, и все закрыто будет, чем каждый раз новый камень покупать.
Ну или идем к другу у которого струйник может на кремниевой болванке допечатать недостающие транзисторы, для устранения уязвимости.
В крайнем случе идем в ларёк покупаем чистую кремниевую болванку, а лучше пачку, и печатаем полупроводниковыми чернилами новый процессор.
Всё как раньше, только вместо оптических болванок — процессорные.
Как мне кажется, стоит вспомнить heartbleed в openssl. Код, открытый сообществу, все равно содержал уязвимость. Прежде всего, уязвимость — это баг, такой же баг, как и все остальное. И баги будут всегда, хоть в закрытом, хоть в открытом проекте, хоть в коде, хоть где-либо ещё.
А где гарантия, что в милли(-онах/-ардах) транзисторов нет аппаратной закладки, которая хитро рассредоточена по всей площади? (Ладно, это и в софте может быть)
А где гарантия, что тот кристалл, который вы купили в магазине, сделан по той же схеме, что вы нашли в интернете? (В софте бывает, но его можно пересобрать, а вот 10нм принтер микросхем есть не у каждого дома)
В общем, open hardware — хорошо, но…
Пришло время для открытых и свободных процессоров?