caxapa.ru :: Года три назад так и было. Судя по последним новостям, есть движение.

amusin (21.08.2013 13:13, просмотров: 77) ответил ыыыы на а про мультиклет (екатерингбурский суперпроцессор и компанию его делающую) есть какая-то инфа?

Года три назад так и было. Судя по последним новостям, есть движение. http://sdelanounas.ru/blogs/37116/

Ответить

- Год-два-три назад эта компания искала то вхдл-щика (потому что ядро сначала гоняли на xilinx), то программиста инструментальных средств (до этого были подрядчики в СПб). Если ваш знакомый действительно сечет фишку, пусть попробует списаться с amusin(26 знак., 21.08.2013 13:20)
  - мой знакомый разносит вклочья мои идеи суперкомпьютерности, а к этому мультиклету даже я могу придумать каверзный вопрос: так как все команды одного "яруса" должны исполняться единомоментно, то ожидание данных из памяти останавливает все ядра ыыыы(196 знак., 21.08.2013 20:33)
    - Чушь, ты не понимаешь как оно работает. - =AlexD=(21.08.2013 20:36)
      - А Вы понимаете, как оно работает? - Evgeny_CD(21.08.2013 20:50)
        
        Да, я досконально разбирался с внутренней структурой, системой команд, более того, по моей просьбе проводили разработчики некоторые тесты. Я остался недоволен реализацией, хотя сама идеология очень перспективная. =AlexD=(2622 знак., 22.08.2013 07:15)
        
        да что там непривычного, погуглите DAG - тот же LLVM + graphiz рисует такие же картинки как и у них в доках (только покрасивше :). ну и вообще, к чему бы у всех архитектур, претендующих на производительность, трехоперандные инструкции? это же типа ыыыы(1997 знак., 22.08.2013 12:38)
        
        Кстати, 1024х клеточный Мультиклет невозможен, т.к. инструкция не может получить результат другой инструкции, если она дальше 63 позиций от текущей :-P , разве что систему команд расширять, вводить 64битовые инструкции :-). =AlexD=(126 знак., 22.08.2013 13:41)
        
        Да, современные процы с out-of-order и register reordering|renaming устроены примерно по такому же принципу, но они вынуждены использовать кучу аппаратуры для трансляции регистрового кода в нечто похожее на триплеты (операнды + результат), на лету =AlexD=(2484 знак., 22.08.2013 13:20)
        
        пожелаю мультиклету успеха (несмотря на зависть), хотя меня раздражает излишний PR. казалось бы - возьми ПЛИС Virtex|Stratix и обкатай эту архитектуру, возможно сделать разветвления - это типа эмбедед(с прерываниями), это для графики и т.д. ыыыы(115 знак., 22.08.2013 14:41)
        
        Обижаешь, RTL для плисин они даже продают :-), что нормального симулятора нет - это да косяк-косячище, да и без оптимизирующего компилятора хреново. А пожелать им нужно не столько удачи, сколько мозгов по больше для избавления от косяков :-). - =AlexD=(22.08.2013 14:48 - 23.08.2013 08:17)
        
        Есть ещё VLIW. Где вопросы решаются не на лету, а даже на этапе компиляции (эльбрусы) или на этапе трансляции x86-->VLIW (трансмета). Instructions Per Clock там может быть очень большим. Только это не панацея: не шибко современные программы fk0(360 знак., 22.08.2013 14:14)
        
        да вот не пошла VLIW (как раз таки трансмета, да и DEC побаловался x86->alpha), как раз невозможность компилеру предсказать время поступления данных rd. ставит на EPIC|VLIW крест. были еще варианты, например, ultra sparc имел набор "зеркальных" ыыыы(722 знак., 22.08.2013 14:30)
        
        влив отстой, у них своих недостатков вышекрыши, проблема в том, что статический анализ идёт лесом, когда появляются не прогнозируемые задержки доступа в память. А так в любом Сишном коде парралелизма уровня выражений полно, хотя на верилоге было =AlexD=(23 знак., 22.08.2013 14:19)
        
        какие такие задержки, если шины у нормальных VLIWов будут широченные? к примеру 256 бит на код и 2х64 на данные. да к кэшу данных не одна шинка, а 8 по 32 бита. Mahagam(69 знак., 22.08.2013 14:46)
        
        Сделай мысленный эксперимент. У тебя кеш. У тебя работа с памятью по указателю (например список). Ты возьмёшься предсказать задержки в n-ном потоке исполнения? =AlexD=(356 знак., 22.08.2013 14:57)
        
        сделай мысленный эксперимент. возьми камень типа L138, где есть VLIW DSP и ARM9. запусти линукс на DSP и заставь ARM9 считать fft и прочую математику. Mahagam(377 знак., 22.08.2013 15:41)
        
        Это ваще не в тему, DSP код есть чем считать, это ваще не проблема, на крайнях есть GPU и FPGA. Проблема заключается в повышении производительности на совсем другом коде, именно на том, который на ARMах запускают. - =AlexD=(23.08.2013 07:31)
        
        щетаю, что под каждую задачу есть своя архитектура, подходящая под неё оптимальным образом. не вижу смысла требовать от VLIW особо шустрого исполнения кода общего назначения - Mahagam(23.08.2013 09:30)
        
        А кто требует? Эта ветка вообще-то была не про VLIW :-) , но даже первое упоминание -> о них касалось проблемы распараллеливания вычислений, =AlexD=(326 знак., 23.08.2013 09:39, ссылка)
        
        ну а если данные лежат в ячейках i и i+33 и обе они не закешированы, да и банк ddr нужно еще открыть... - ыыыы(22.08.2013 14:55)
        
        Спасибо! Никакой тарабарщины, я хотя и не птенец гнезда Бабаяновского, но немного понял написанное. - Evgeny_CD(22.08.2013 12:33)
        
        Спасибо за расширение кругозора - Vladimir Ljaschko(22.08.2013 12:23)
        
        Достаточно понимать как оно не может работать) lexxx-lexxx(34 знак., 22.08.2013 00:41)
        
        Однако пока никто не доказал теорему о невозможности создания архитектуры, более эффективной, чем все ныне существующие, по какому-либо критерию, подтвержденном платежеспособным спросом. - Evgeny_CD(22.08.2013 10:43)

Средства и методы разработки