ыыыы (21.08.2013 20:33, просмотров: 66) ответил amusin на Год-два-три назад эта компания искала то вхдл-щика (потому что ядро сначала гоняли на xilinx), то программиста инструментальных средств (до этого были подрядчики в СПб). Если ваш знакомый действительно сечет фишку, пусть попробует списаться с-
- Чушь, ты не понимаешь как оно работает. - =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)
- Есть ещё 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, ссылка)
- щетаю, что под каждую задачу есть своя архитектура, подходящая под неё оптимальным образом. не вижу смысла требовать от VLIW особо шустрого исполнения кода общего назначения - Mahagam(23.08.2013 09:30)
- Это ваще не в тему, DSP код есть чем считать, это ваще не проблема, на крайнях есть GPU и FPGA. Проблема заключается в повышении производительности на совсем другом коде, именно на том, который на ARMах запускают. - =AlexD=(23.08.2013 07:31)
- сделай мысленный эксперимент. возьми камень типа L138, где есть VLIW DSP и ARM9. запусти линукс на DSP и заставь ARM9 считать fft и прочую математику. Mahagam(377 знак., 22.08.2013 15:41)
- ну а если данные лежат в ячейках i и i+33 и обе они не закешированы, да и банк ddr нужно еще открыть... - ыыыы(22.08.2013 14:55)
- Сделай мысленный эксперимент. У тебя кеш. У тебя работа с памятью по указателю (например список). Ты возьмёшься предсказать задержки в n-ном потоке исполнения? =AlexD=(356 знак., 22.08.2013 14:57)
- какие такие задержки, если шины у нормальных VLIWов будут широченные? к примеру 256 бит на код и 2х64 на данные. да к кэшу данных не одна шинка, а 8 по 32 бита. Mahagam(69 знак., 22.08.2013 14:46)
- Спасибо! Никакой тарабарщины, я хотя и не птенец гнезда Бабаяновского, но немного понял написанное. - Evgeny_CD(22.08.2013 12:33)
- Спасибо за расширение кругозора - Vladimir Ljaschko(22.08.2013 12:23)
- да что там непривычного, погуглите DAG - тот же LLVM + graphiz рисует такие же картинки как и у них в доках (только покрасивше :). ну и вообще, к чему бы у всех архитектур, претендующих на производительность, трехоперандные инструкции? это же типа ыыыы(1997 знак., 22.08.2013 12:38)
- Достаточно понимать как оно не может работать) lexxx-lexxx(34 знак., 22.08.2013 00:41)
- Да, я досконально разбирался с внутренней структурой, системой команд, более того, по моей просьбе проводили разработчики некоторые тесты. Я остался недоволен реализацией, хотя сама идеология очень перспективная. =AlexD=(2622 знак., 22.08.2013 07:15)
- А Вы понимаете, как оно работает? - Evgeny_CD(21.08.2013 20:50)
- Чушь, ты не понимаешь как оно работает. - =AlexD=(21.08.2013 20:36)