Comments | thesz: Замечательная статья про закон Амдаля.

thesz

Замечательная статья про закон Амдаля.

Jul 03, 2011 01:54

Почему в гугле предпочитают быстродействующие процессора экономичным.

Закон Амдаля: S=1/((1-P)+P/S). S - общее ускорение, P - доля ускоряемого кода в коде программы (доля времени выполнения), S - ускорение этого самого ускоряемого кода. Коротко P и (1-P) можно называть "обработкой" и "анализом ( Read more... )

процессоры, google, mips

Leave a comment

Back to all threads

nicka_startcev July 3 2011, 09:59:55 UTC

х86 привычнее, под него больше разработчиков, под него быстрее найти персонал, итого, разработка быстрее.

permea_kra July 20 2011, 22:32:35 UTC

>У этого файла должно быть (3*количество выполняемых параллельно команд АЛУ+количество параллельно выполняемых операций с памятью) портов ( ... )

thesz July 20 2011, 22:54:51 UTC

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

permea_kra July 20 2011, 23:36:57 UTC

>Очень сильно упрощают. В противном случае получаются пересылки, которые не улучшают производительности ( ... )

thesz July 20 2011, 23:58:13 UTC

>Производительность на байт кода. Но - за счет сильного урезания числа межсоединений и путей в ядре - частоту можно сильно поднять. Вопрос - что перерборет ( ... )

permea_kra July 21 2011, 00:22:03 UTC

>Прошу вас, попробуйте.
Объем работы пугает. Да и в любом случае, сначала надо поискать, не успели ли это уже сделать.

>TTA, transport triggered architecture.
Ага, почитаем.

>Нет, поскольку это - барабанная дробь! - усложняет процессор.
o_0. Не настолько же.

>Беда в том, что там - барабанная дробь! - динамические объекты! Для них надо перестраивать дерево!
Верхнее деление пространства на кубики можно сделать статическое -). Криво, косо, но работать будет. Только я не хочу этого реализовывать. Поскольку с моей колокольки, рей трейсинг - это неинтересно. Вот какой-нибудь b3lyp - это интересно, но там уже все сделано до меня.

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

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

thesz July 21 2011, 08:43:43 UTC

>>Нет, поскольку это - барабанная дробь! - усложняет процессор ( ... )

permea_kra July 21 2011, 08:54:22 UTC

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

>память должна быть настоящая DRAM - с CAS/RAS, с чтением и записью через выборку блока.
А вот этого не понимаю, и не очень понимаю, насколько нужно (и нельзя ли обойтись SRAM)

>Уж сколько я про него писал, а всё равно объяснять приходится.
Ваще-то я в жж с 2007-го. Я этого поста просто не застал.

permea_kra July 21 2011, 09:04:39 UTC

*бегло пошуршав* Хм. А нормального пригодного для ОЗУ не-DRAM-то и нет в массово производстве, только в разработке ... Пичалько.

Ладно, поставим вопрос иначе - а нужно ли делать вне-процессорную память больше 16 мб для такого пробного симулятора?

thesz July 21 2011, 19:21:09 UTC

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

thesz July 21 2011, 19:19:12 UTC

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

Этого не надо для первоначальной прикидки. Главное - отношение частот.

>>память должна быть настоящая DRAM - с CAS/RAS, с чтением и записью через выборку блока.
>А вот этого не понимаю, и не очень понимаю, насколько нужно (и нельзя ли обойтись SRAM)

Нельзя. ;)

SRAM в несколько раз менее плотная, не менее, чем в три раза. ;)

Так что заботящимся о количестве транзисторов надо побеспокоиться об использовании DRAM. ;)

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

permea_kra July 21 2011, 06:53:48 UTC

Хм...
А 'традиционные' архитектуры случайно реализуются не поверх этой самой TTA ?

thesz July 21 2011, 08:44:09 UTC

Нет.

cormix July 3 2011, 17:21:22 UTC

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

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

nicka_startcev July 3 2011, 18:09:57 UTC

про закрытость - именно так.

ну, плюс, у большинства не-х86 до сих пор был ряд интересных проблем типа "невыровненное чтение на порядок медленнее нормального", но эти грабли местами уже решены.

thesz July 3 2011, 17:56:52 UTC

in-order имеет довольно жёсткие требования к доступу к памяти, поэтому там приходится располагать данные по-другому и вообще менять многое в программе.

Back to all threads