Замечательная статья про закон Амдаля.
Почему в гугле предпочитают быстродействующие процессора экономичным.
Закон Амдаля: S=1/((1-P)+P/S). S - общее ускорение, P - доля ускоряемого кода в коде программы (доля времени выполнения), S - ускорение этого самого ускоряемого кода. Коротко P и (1-P) можно называть "обработкой" и "анализом ( Read more... )
Закон Амдаля: S=1/((1-P)+P/S). S - общее ускорение, P - доля ускоряемого кода в коде программы (доля времени выполнения), S - ускорение этого самого ускоряемого кода. Коротко P и (1-P) можно называть "обработкой" и "анализом ( Read more... )
Производительность на байт кода. Но - за счет сильного урезания числа межсоединений и путей в ядре - частоту можно сильно поднять. Вопрос - что перерборет.
И таки да - идея VLIW - спуститься на уровень ниже, взять на себя роль планировщика инструкций. Соответственно, с какой стати останавливаться на полумерах и не пойти глубже и не расписать процесс подробнее? Собственно, единственное, что этому мешает - это вопрос, а не будет ли проигрыш в объеме кода слишком велик. Есть про это где-нибудь что-нибудь?
>Это большое дело, когда можно заглянуть за серию сохранений или загрузок
А в MIPS есть команды отложенных загрузок? И gcc ими пользуется? И команды отложенных дважды косвенных переходов? Потому что без них ooo рулить будет, это б.-м. очевидно. С ними, и при умном компиляторе - скорее, будет паритет (на такт).
>Прошу, поделитесь. ;)
Ну, построить дерево до 16x16x16 статически, в листья забабахать массив объектов и частично раскрутить итерацию по объектам (блоками по 16, например) в коде проверки попадания в описывающий куб.
>Только после вашей реализации OOO и IO процессоров, сравнении их по площади и по скорости. ;)
Мухаха. Т.е. нужно написать три компилятора уровня gcc. Я такое не потяну -).
Reply
Прошу вас, попробуйте.
В Alpha 21264, по-моему, регистровые файлы для разных конвейеров были раздельны и иногда синхронизировались. Больше я о таком не слышал. Не понятно, почему они так сделали, если честно. Это не сильно урезает регистровый файл (порты всё равно нужны), а сложность железа и компилятора вырастает.
>И таки да - идея VLIW - спуститься на уровень ниже, взять на себя роль планировщика инструкций. Соответственно, с какой стати останавливаться на полумерах и не пойти глубже и не расписать процесс подробнее? Собственно, единственное, что этому мешает - это вопрос, а не будет ли проигрыш в объеме кода слишком велик. Есть про это где-нибудь что-нибудь?
TTA, transport triggered architecture. Объём кода ещё вырастает, в те же 1,5-2 раза (и больше), проседание на задачах типа gcc ещё больше - на самом gcc аж 20 раз.
>>Это большое дело, когда можно заглянуть за серию сохранений или загрузок
>А в MIPS есть команды отложенных загрузок? И gcc ими пользуется? И команды отложенных дважды косвенных переходов? Потому что без них ooo рулить будет, это б.-м. очевидно.
Нет, поскольку это - барабанная дробь! - усложняет процессор. Жрёт транзисторы. ;)
А OOO более общее решение.
>С ними, и при умном компиляторе - скорее, будет паритет (на такт).
Прошу привести ссылку. Или реализовать, всё же, компилятор и процессор.
А то я реализовал один из них, пытаюсь доказать, но вы же даже проблем видеть не хотите. ;)
>>Прошу, поделитесь. ;)
>Ну, построить дерево до 16x16x16 статически, в листья забабахать массив объектов и частично раскрутить итерацию по объектам (блоками по 16, например) в коде проверки попадания в описывающий куб.
Беда в том, что там - барабанная дробь! - динамические объекты! Для них надо перестраивать дерево!
Что тут будет делать IO, мне непонятно.
>>Только после вашей реализации OOO и IO процессоров, сравнении их по площади и по скорости. ;)
>Мухаха. Т.е. нужно написать три компилятора уровня gcc. Я такое не потяну -).
Вы хотя бы процессор сделайте, что уж там про компиляторы. После поговорим.
А то это разговор меня и человека, который даже про TTA не слышал (хотя я об этом писал). Я говорю, вы даже не видите проблем, что уж говорить про решения.
Печально.
Ну что, отважитесь завязать нить обсуждения до реализации чего-то? Или продолжите путь воина интернета?
Reply
Объем работы пугает. Да и в любом случае, сначала надо поискать, не успели ли это уже сделать.
>TTA, transport triggered architecture.
Ага, почитаем.
>Нет, поскольку это - барабанная дробь! - усложняет процессор.
o_0. Не настолько же.
>Беда в том, что там - барабанная дробь! - динамические объекты! Для них надо перестраивать дерево!
Верхнее деление пространства на кубики можно сделать статическое -). Криво, косо, но работать будет. Только я не хочу этого реализовывать. Поскольку с моей колокольки, рей трейсинг - это неинтересно. Вот какой-нибудь b3lyp - это интересно, но там уже все сделано до меня.
>Вы хотя бы процессор сделайте, что уж там про компиляторы.
Ну вот первый компилятор - это из описания процессора на чем-то гуманоидном в симулятор.
>Я говорю, вы даже не видите проблем
Проблемы я вижу. Я не вижу, что сделано в мире. Поэтому, если вы знаете, что стоит почитать - пишите, не стесняйтесь. Я почитаю, мне интересно. Про сроки, правда, ничего не скажу.
Reply
>o_0. Не настолько же.
Уменьшение плотности кода (больший кэш кода, больше промахов, больше расхода электричества), увеличение логики декодирования (небольшое), добавление логики в работу кэша данных (а вот тут может получиться так, что добавится чуть ли не равное scoreboard количество логики, а то и больше).
Всё равно, компиляторы этого не понимают. Все эти улучшения делаются вручную.
>Верхнее деление пространства на кубики можно сделать статическое -). Криво, косо, но работать будет. Только я не хочу этого реализовывать. Поскольку с моей колокольки, рей трейсинг - это неинтересно. Вот какой-нибудь b3lyp - это интересно, но там уже все сделано до меня.
Действительно, чего браться за новую область деятельности, если есть область деятельности, где всё уже сделали до нас. ;)
>>Вы хотя бы процессор сделайте, что уж там про компиляторы.
>Ну вот первый компилятор - это из описания процессора на чем-то гуманоидном в симулятор.
Прошу вас, попробуйте. Только симулятор должен быть потактово-точным, с конвейерами, кэшами и прочим, и память должна быть настоящая DRAM - с CAS/RAS, с чтением и записью через выборку блока.
>>Я говорю, вы даже не видите проблем
>Проблемы я вижу. Я не вижу, что сделано в мире. Поэтому, если вы знаете, что стоит почитать - пишите, не стесняйтесь. Я почитаю, мне интересно. Про сроки, правда, ничего не скажу.
Ну, вот, например, TTA. Уж сколько я про него писал, а всё равно объяснять приходится.
Так что я лучше подожду, пока сформируются вопросы, чем буду давать ответы в воздух.
Reply
Это я б-м понимаю как делать. Но не понимаю, как сделать 'честный' симулятор, выдающий время переключения вентилей и прохода сигнала по проводу.
>память должна быть настоящая DRAM - с CAS/RAS, с чтением и записью через выборку блока.
А вот этого не понимаю, и не очень понимаю, насколько нужно (и нельзя ли обойтись SRAM)
>Уж сколько я про него писал, а всё равно объяснять приходится.
Ваще-то я в жж с 2007-го. Я этого поста просто не застал.
Reply
Ладно, поставим вопрос иначе - а нужно ли делать вне-процессорную память больше 16 мб для такого пробного симулятора?
Reply
Reply
Этого не надо для первоначальной прикидки. Главное - отношение частот.
>>память должна быть настоящая DRAM - с CAS/RAS, с чтением и записью через выборку блока.
>А вот этого не понимаю, и не очень понимаю, насколько нужно (и нельзя ли обойтись SRAM)
Нельзя. ;)
SRAM в несколько раз менее плотная, не менее, чем в три раза. ;)
Так что заботящимся о количестве транзисторов надо побеспокоиться об использовании DRAM. ;)
DRAM полезна ещё и тем, что вносит ещё один буфер между памятью и процессором (помимо иерархии кэшей). Выборка из текущего блока (или запись в текущий блок) относительно быстра, несколько тактов, активных блоков несколько (4 по килобайту, по-моему). А вот смена текущего блока уже длинная - несколько десятков тактов.
Reply
А 'традиционные' архитектуры случайно реализуются не поверх этой самой TTA ?
Reply
Reply
Leave a comment