Mon Oct 06 2003 08:39, Roman Khvatov wrote to Ilia Tarasov:
RK> То есть все таки это единственная работающая формула в программе :) Что RK> то не верится. Кроме того, здесь уже замечали, что собственно sin и sqrt RK> сами по себе вполне хорошо параллелятся.
Не единственная, но все же основная :) Например, в довольно большой программе почти все время вполне может уходить на выполнение вложенного цикла, перебирающего 5-10 параметров какой-нибудь формулы.
К тому же про синус и корень я уже написал, что пример был неудачный - имелись в виду абстрактные переходы между узлами графа состояний...
IT>> Hе понял... Устройство умножения всего одно, что можно параллелить?
RK> В суперскаляре их несколько.
IT>>>> умножению с накоплением. Представим, что перемножитель один, и ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Понятно, что в реальных кристаллах их может быть несколько... Я про пример.
IT>> Fixed. А Форт-процессор с запараллеленными стеками?
RK> Это будет называться векторная машина. Такие уже были и вымерли за RK> невостребованностью :)
Ага... :)
IT>> Конечно, 3 хороших :) Hапример, стековая архитектура на FPGA Xilinx IT>> дает ровно в 16 раз больший объем стековой памяти на тех же IT>> ресурсах... ;)))
RK> Возможно. Я так понимаю, что стек там делается на FIFO?
На распределенной памяти, конфигурируемой также как FIFO (или стек). Под FIFO есть только языки типа Onyx-а, а это еще экзотичнее Форта.
IT>> Hу, кому как. Согласен, для подавляющего большинства разработчиков IT>> разработка собственного компилятора - далеко не первоочередная задача.
RK> А кто говорит про собственный? RK> Hаписать ХОРОШИЙ компилятор - это _очень_ непростая задача. Его объемы RK> вполне могут зашкалить за несколько милионов строк на С.
Даже неоптимизирующий целевой компилятор для форт-процессора (что-то около 100 строк на Форте) дает очень неплохие результаты.
RK> Есть такое наблюдение - програмист пишет приблизительно с одной и той же RK> скоростью (в строках в час) на _любом_ языке. Теперь прикинь одна строка
Да...
RK> на С - это сколько строк на asm? Что касается Форта, то тут на первый RK> план выходит его 'своеобразность' - с читаемостью его программ дело RK> обстоит даже хуже, чем с обычным asm'ом :) (Тут я полностью согласен с RK> DO)
Слова Форта == функции Си. Отличие исключительно в написании и способе передачи параметров. Ну разве что Си - mainstream, с мегатоннами сопроводительной информации и методических материалов, а Форт - штучный инструмент, который с начала 70-х как-то вот прибился к этому потоку, да так до сих пор и существует. По поводу читаемости - очень спорный вопрос. Читаемость для кого? Для эмбеддера, программирующего по необходимости? Для специалиста в cs, которому по большому счету все равно какой язык? Для фортера со стажем, который не будет писать криво?
RK> А потом он воплощается в железе, которое в отличии от софта уже не RK> исправишь. RK> А выпуск новой версии железа это совсем не то, что выпуск новой версии RK> софта. RK> (Пока я не рассматриваю Форт процессоры в FPGA - там они вполне RK> оправданны)
(А я как раз в основном-то в FPGA - мне актуально :)
К тому же... а что, собственно, надо будет исправлять в железе после тщательного тестирования на моделях? Форт - это ведь не свалившаяся с неба фиговина, стековая машина имеет под собой четкое и ясное математическое описание. Технологам так и вообще все равно, что в железе воплощать, у них другие соображения.
RK> С этим никто не спорит, однако и по производительности он будет ему RK> уступать.
Я одно время сравнивал алгоритмы, реализуемые для пентиума на Си++ и для своего форт-процессора. Численные, с вложенными циклами, с обработкой массивов, с вызовом функций и т.п. В среднем получалось, что для достижения паритета пентиум должен иметь от 1,5 до 4 раз большую частоту!
RK> Компилятору все равно, а написание на голом асме/Форте подходит только RK> для небольших проектов, а для них абсолютно по барабану, какой будет RK> процессор.
Мне попадаются задачи, хорошо нагруженные вычислениями и "мелкой логикой" в их организации. Объем проектов в софт-процессорах ограничен сейчас возможностями ПЛИС, которую не слишком дорого поставить в изделие (десятки килобайт памяти кода). То, что есть из массового, не вполне устраивает, и производительность на имеющихся задачах хуже, чем у специализированной системы, управляемой стековой машиной на том же кристалле.
IT>> для стековой архитектуры сразу IT>> готовы все алгоритмы, а для регистровой надо долго думать, как все IT>> туда упихать, и не завести ли еще регистр, а то что-то места мало и в IT>> память лезть приходится...
RK> А если у Форт процессора кончится стек? Это проблема того же плана.
Во-первых, он больше на тех же ресурсах, и наращивается прозрачнее. Во-вторых, глубина стека хорошо прогнозируется и определяется по максимальной вложенности подпрограмм. Для несложного эмбеддеда 16 - это много.
IT>> (которому желательно симметричный набор) и разработчиком железа,
RK> Железо обычно уже дано как данность, а при проектировании новых RK> процессоров в любом случае стараются сделать симметричный набор регистров RK> - так всем проще.
Тем не менее количество внутренних соединений у полностью симметричного процессора будет больше (хотя я уже занимаюсь формальными придирками :)
IT>> которому проще соединить этот новый регистр с каким-нибудь IT>> аккумулятором,
RK> Так не делают. Обычно есть набор РОHов и какой нибудь аккумулятор (или RK> несколько, или ни одного). Под регистрами в такой архитектуре понимают RK> РОHы, к аккумуляторам (и пр. спец регистрам) относятся как к специального RK> вида аппаратуре, которая используется только при генерации комманд, но не RK> участвует в распределении регистров. И только на последних стадиях RK> оптимизаций уже готового кода (peephole оптимизации) его пытаются RK> использовать под временное хранилище чего нибудь (если он вдруг где то RK> оказался свободным)
Так не делают действительно по многим причинам. Однако технологические проблемы все же имеют место (но это опять формально).
IT>>>> или когда зависимость по данным не вызывает простоев конвейера? RK>>> Hет. IT>> А как это соотносится с (*)? А вот держи примерчик:
IT>> a = b + c + d (1) IT>> b = a + d - с (2) IT>> c = a + b + 3 (3) IT>> d = a + b + c (4)
IT>> Hалицо WAR при подстановке любой из строк 2-4 после 1.
RK> Строки 2-4 зависимы по данным от строки 1, и так будет при любом RK> количестве регистров, ни 5й ни 25й здесь не помогут.
b = (b + c + d ) + d - c с = (b + c + d ) + d - c d = (b + c + d ) + b - c
Видимо, от количества регистров все же зависит?
IT>> Да, это очень реально при многомиллионных вложениях в IT>> проект, я с этим и не спорю. Однако высказываю мнение, что со IT>> стековой архитектурой проблем будет меньше, поскольку увеличение IT>> глубины стека не сопровождается пересмотром основных алгоритмов.
RK> Увеличение числа РОHов - тоже.
Ну как же не сопровождается? Ассемблер-то меняется...
IT>> И с этим полностью соглашусь. Заметь, однако, что сфера применения все IT>> же появляется, и довольно обширная...
RK> Итак, консенсус по всем позициям. И о чем же мы тогда спорим?
А кто спорит? :))))) Я, например, кое-что отсюда за последнее время уже выписал себе в "думательную" тетрадочку, и нахожу это довольно-таки полезным. Конкретно мы, имхо, и не спорим, а просто обмениваемся соображениями... :)